Initial SMF version

Initial SMF version

Introduction

In this paragraph the development of the first SMF version is explained. It is developed in four steps which are all based on the previously developed structure.

In the first step the model’s areas are defined. Subsequently, reasonable maturity levels which should represent a stable and well-defined plateau of SOA adoption are determined. Afterwards the model components are defined for each area at each maturity level and in the last step the relation between expected benefits and the levels of maturity is outlined.

Areas

During the process of collecting relevant criteria for SOA adoptions in the financial services industry, five main areas could be identified. These areas are intended to be as mutually exclusive as possible to avoid the problem of assigning one goal to more than one area. Additionally, they are intended to be collectively exhaustive guaranteeing that all relevant criteria are in line with an area. Another design principle was to reduce the number of areas to a reasonable amount in order to avoid a too strong fragmentation of the model. In the following the identified areas are explained:

Monetary: This area clusters all aspects of a SOA adoption which support or assure the financing of a SOA adoption. It includes the allocation of budget, the right sources for the funding as well as communication strategies to reveal financial benefits in order to strengthen management support for a strategy towards SOA. Because the service provider and the service consumer can be two different entities in a SOA, the financing mechanisms used in traditional IT environments have to be modified [SCH05].
Architecture: The area architecture clusters all goals and practices that influence the design of a SOA. Special attention has to be paid to the fact that the ideal integration of existing systems and new implementations always takes the principles of service orientation into consideration. Additionally, aspects concerning the SOA roadmap or operational goals and practices of a SOA adoption are grouped in this area.
Organization: The area organization clusters all necessary goals that address the organizational structure and the affected people. Since a SOA only reveals the maximum benefit if the organization as a whole supports the paradigm, it is of utmost importance to address organizational issues explicitly within the model. The goals and practices deal with new roles and responsibilities, the right communication, involvement of stakeholders, ramp up of a specialized SOA team, education and training, and many other organizational aspects.
Infrastructure: In this regard infrastructure does not only refer to hardware. This area covers mainly the infrastructure components which are generally used for the implementation of SOAs in the financial services industry including an enterprise service bus and an appropriate discovery mechanism. Additionally, changes to the hardware which are facilitated by the service orientation are covered in this area.
Governance & Security: Governance and security are two distinct topics which are strongly interrelated, though. Because of this interrelation and because of their similarity they are combined in one area in the following two aspects. Governance and security both are underestimated in their effect on SOA adoption in the past and both of them are strongly interwoven with the other four areas. The covered goals and practices are thus concerned with the governance of SOA adoption and operation as well as necessary adjustments to the security concepts because of the paradigm shift.

Levels

During the development of the maturity levels the principles defined for the structure of maturity levels were followed. Hence, each maturity level is designed to represent a stable and well-defined plateau of SOA adoption which provides additional benefit to the business. These levels are designed to represent the most obvious steps towards a SOA adoption [PRO07], [MAS07] which are also used in practice (e.g. Credit Suisse [CIO08]). Nevertheless, as the topic of maturity levels is rather intangible, various other possibilities exist. In general there is no single wrong or right solution because different numbers of maturity levels often assume a different scope per level. The defined maturity levels and their main characteristics are explained in the following:

Maturity Level 1

This level can be seen as an organization’s first experiences towards a SOA. First services are implemented on a project-centric basis, resulting in the first relevant expertise with diverse technologies and standards. Additionally, possibilities for optimizing the system landscape are analyzed. Based on the earned experiences, decisions for the future SOA design and selection of standards and technologies can be made.
Maturity Level 2

Pilot projects have been completed successfully and the SOA strategy is defined. At this level the SOA is mainly used as a flexible way to integrate information systems. Standards and technologies have been agreed on and are implemented partly. Hence, some systems are integrated using services and some of these services are invoked on a regular basis, already. All newly started transformation projects adhere to the principles of SOA and basic SOA governance mechanisms are in place.
Maturity Level 3

The majority of systems are integrated using services and adequate SLAs and policies for these services are drafted, reviewed, and improved on a regular basis at this level. Every transformation project complies with the SOA principles and the overall SOA strategy. The IT organization is well-educated and hence aware of SOA concepts. Services are designed according to the business’ needs. Major parts of the business processes are orchestrations of business services leading to a considerably strengthened business IT alignment.
Maturity Level 4

At level four services are optimized for their usage based on experiences. Furthermore, the service portfolio is consolidated according to the usage and reuse is promoted. Appropriate SLAs are defined and in use for each service. Metrics to monitor services are introduced, reviewed and improved on a regular basis. Process design shifts from IT experts to business experts. The organizational structure in the IT department is entirely adapted to the structure of the SOA. At this stage the architecture has adjusted IT to the business needs.
Maturity Level 5

Level five is the highest level of SOA maturity. At this level SOA adapts dynamically to changing business environment in a time and cost efficient manner. The therefore needed metrics are established and brought to perfection. Involved employees have an advanced understanding of a SOA. Services are insourced and outsourced dynamically. The focus is on the continuous improvement of services and their usage. The business is no longer restricted but supported by the IT. This level is rather expected to provide a vision on SOA in the future than a state of adoption in practice.

Model Components

The model components represent the main content of a maturity model. As explained during the definition of the structure, three model components are used: Generic goals, specific goals, and specific practices. The model components have been derived with the following approach: Firstly, all possible criteria and characteristics of SOA adoptions have been collected. The sources therefore were on the one hand relevant literature concerning SOA adoption and SOA in the financial services industry. On the other hand, criteria were also obtained from existing SOA Maturity Models. Subsequently, these criteria were assigned to the area where the best fit is assumed. Afterwards, these criteria have been assigned to the relevant level of maturity. Because the use of many different sources led to many similar criteria, a consolidation was necessary to aggregate these similar criteria into one. In this step the number of criteria was reduced from a number considerably higher than 500 to about 350. In the last step the specific practices are built by transforming the consolidated criteria into specific practices. As the first version of this model contains 236 specific practices, the derivation is only shown exemplarily. [1] shows how different sources are aggregated to one specific practice.

Abbildung 1: Source criteria aggregated to a specific practice

After the specific practices have been built, specific goals were defined for each group of specific practices which covers the same subject area. Special attention was paid to express the specific goals as universal as possible because they have to be fulfilled in order to achieve a certain level. Specific practices can be expressed more specifically as they only act as recommendations on how to achieve the associated goal.

In a final step the generic goals for each maturity level have been defined. These goals were derived out of the description of each maturity level and the specific goals defined at all areas at the respective maturity level. Hence, the generic goals represent the main objectives at each maturity level.

In order to be able to deal with this amount of model components, unique identifiers (UID) have been introduced which can also be seen on the left hand side of each model component in [1]. ‘2-O-1’ stands for maturity level (2), area Organization (O), and the specific goal number (1). The specific practices associated with this specific goal have the same UID concatenated with an ascending number (e.g. 2-O-1.1).

Benefits

At this stage the technical SOA benefits should be assigned to the maturity levels. Although assigning technical SOA benefits to maturity levels solely based on theoretical reasoning is not expected to provide accurate results, they can be used as a foundation and further discussed during the interviews.

Since only trial SOA projects are realized at the first level of maturity, only limited benefits are expected. To a certain extent additional flexibility due to easier integration of new functionality could be achieved.

With the increasing propagation of services at level two, a higher degree of standardization and interoperability could be achieved. Additional flexibility could be attained because of the reduction of point-to-point interfaces. Because of the available basic services at this level, reusability is also expected to provide benefits, although very limited. Virtualized infrastructure could also be leveraged more effectively by optimized allocation of resources to the services.

At maturity level three many of the aforementioned benefits are expected to be realized in a higher degree. Additionally, the overall complexity could be slightly reduced or at least hidden because of the introduced business services which also have the right granularity to represent units of a business process. Moreover, service composition and orchestration are possible due to the connection of business process management and service composition which is carried out at this level.

The so far achieved benefits are expected to be more effective at maturity level four because of the more optimized character of the SOA at this level. An additionally expected benefit is the application abstraction leading to run time interface coordination which should also result in a higher overall fault tolerance of the systems.

Due to the continuously optimizing character of the SOA at maturity level five, all identified technical benefits are expected to be achieved to a high degree. Nevertheless, the visionary character of this maturity level does not allow a detailed reasoning of the benefits.