SMF structure
Introduction
During the development of the SMF it was decided to design the model based on CMMI. This decision was basically taken because of the all-embracing and adaptable framework CMMI provides. Due to CMMI’s open definition it gives enough freedom to create a maturity model which accounts for a SOA’s special requirements but still provides good assistance during the creation of such a model. By reusing CMMI’s structure, model components, and representation a lot of experience and development efforts can be leveraged. Nevertheless, influences from other Maturity Models on the structure were not categorically excluded during the development process.
Representation
CMMI defines a staged and a continuous representation. Since the most reasonable way to SOA adoption is known to be a gradual and consecutive process [ARS08], the staged representation was considered to be more appropriate because it defines a more rigorous pathway for improvements. In contrast to the continuous representation it does not allow delaying certain areas, hence conveying an equally balanced adoption process. Besides, the maturity of a single area which would come to the fore when using the continuous representation is of rather limited explanatory power for the maturity of a SOA.
Nevertheless, some obstacles come along with a threshold model. If two criteria at one level represent alternative solutions to the same issue, both of them would need to be fulfilled in order to follow the rules and achieve the next level. Other counterproductive examples include criteria which do not need to be fulfilled mandatory but are important to be mentioned in the maturity model. Some maturity models (e.g. Cobit Maturity Model) overcome these issues by being defined as a continuous model instead of a threshold model. CMMI offers a remedy for these problems by providing different model components. The model components used in the SMF to overcome these issues are explained in the following paragraph.
Model components
According to CMMI, required model components and expected model components will be used. Informative model components as defined in CMMI provide guidance on how to interpret model components. Because this would go far beyond the scope of this thesis, informative model components will not be considered. Nevertheless, informative model components are useful for the derivation of a more detailed SOA roadmap out of the maturity model and are therefore a possible area for further research.
The required model components are used to describe key goals which need to be achieved for each level and are therefore mandatory, whereas expected model components are only anticipated to result in the achievement of associated goals and are therefore optional. With these two model components the issues concerning non-fulfillment can be overcome because mandatory goals can be defined as required model component, whereas the expected model components can illustrate two distinct means to achieve a goal as well as to highlight an important but optional possibility. Generic goals and specific goals are the used required model components.
The expected model component used in the SMF is the specific practice. Each specific practice is defined for exactly one specific goal and for each specific goal more than one specific practice can be defined.
In this chapter the model components and their relations are described using a metamodel. According to [KAR07], a metamodel is a model describing another model. The model described using the metamodel is the SMF which describes the reality.
Maturity levels
A maturity level in the SMF is a stable and well-defined plateau of SOA adoption and is the key benchmark for SOA adoption. One maturity level should be defined for each major and essential step towards a complete SOA adoption. Thereby, at each maturity level the SOA should provide additional benefits to the business in order to avoid unnecessary expenses which do not reveal benefits. Each maturity level is based on the level beneath and represents the basis for the level above. One or more generic goals are defined for each maturity level. The goals have to be fulfilled in order to attain the related level of maturity. The first level of SOA maturity is not achieved if an organization has not made a sufficiently broad based effort towards SOA adoption to achieve at least all goals defined at the first level.
Areas
Multiply different perspectives have to be considered in order to successfully adopt a SOA. In the SMF the concept of areas, which is similar to the process areas used in CMMI, is introduced to facilitate clustering of specific goals which relate to a similar aspect of SOA adoption. Nevertheless, areas in SMF are to some extent different from process areas as defined in CMMI. In contrast to CMMI’s process areas, one specific goal can only be associated to one area and all areas exist at each level of maturity. These adoptions to the CMMI concept should further stress the importance of a holistic approach for a SOA adoption which considers all areas. The areas are defined for the whole model which means that all areas exist at each level of maturity. For each area at each level of maturity, one or more specific goals have to be defined. As a consequence of the relation between specific goals and the specific practices, the specific practices are bound to the same area as the associated specific goal.
Benefits
As described earlier the SMF should also be used as a communication tool. In this regard it could be used to define the level of maturity aspired by an organization as well as to analyze weaknesses in the current adoption. In both cases it is essential to show at least a rough estimate of the benefits which could be achieved at a certain level of SOA maturity. Although an exact determination of the prospective benefits revealed by a SOA adoption is not possible, it is to the best advantage to be able to show industry specific benchmarks of benefits which are usually achieved at each level of maturity. Therefore, the technical SOA benefits and their effect on the financial services industry challenges are combined with a SOA maturity model to build the SMF. This allows deriving SOA’s impact on the financial services industry at each level of SOA maturity. Nevertheless, the quality of the results heavily depends on the association of technical SOA benefits to the maturity level. Although benefits and maturity levels can be mapped based on theoretical rationale, the mapping should be verified and aligned with the benefits actually experienced in the relevant industry.
SMF metamodel
The structural elements presented in the previous sections can be combined to the complete SMF metamodel as shown in [1]. This metamodel builds the foundation for the next developments. The constraints ‘m’ and ‘n’ in [1] ensure that each area is connected to each maturity model.
Letzte Änderung: 11.05.2009, 20:23 | 1215 Worte