Open Group Service Integration Maturity Model
History
In 2005 IBM started to develop the Service Integration Maturity Model (SIMM). IBM defines SOA as a way to support IT flexibility, whereas SIMM provides the means to achieve a SOA through several consecutive states of service integration maturity [ARS06]. Each level of maturity results in a defined amount of maturity and a defined level of decoupling [ARS08]. In contrast to most other maturity models the SIMM has seven levels of maturity, whereas the first three are basic levels which do not make use of services at all. These seven levels relate to seven key integration dimensions which are further divided into domains [ARS08]. Although a mapping between CMMI and SIMM is presented in [ARS08] it is not deliberately based on CMMI. Unfortunately, publicly available information about the SIMM content is very limited.
Since 2007 a vendor-neutral and technology-neutral consortium called The Open Group has been responsible for the further development of the Open group Service Integration Maturity Model (OSIMM) which is based on IBM’s SIMM. The Open Group members are well-known companies like Capgemini, EDS, HP, IBM and many more. Together they should work collaboratively on the OSIMM [TOG09]. Nevertheless, almost two years later, in January 2009, there was only an OSIMM draft (version 0.3a) available. The version is solely based on the original IBM version [TOG09] and acts as a source for further description. The OSIMM idea is to provide a standardized maturity model to the industry which allows to benchmark their maturity as well as to build a roadmap for the transformation effort. Unlike the maturity models mentioned earlier, OSIMM also describes a process to assess the current and desired level of service integration maturity.
Structure
According to SIMM, OSIMM defines seven levels of maturity across seven dimensions which can be divided into domains. Each of these mappings of one particular maturity level and one particular domain builds a few maturity indicators. These indicators can either be fulfilled or unfulfilled. During the assessment the fulfillment of all indicators leads to a fulfillment of the corresponding domain. If all domains within a dimension are fulfilled, the associated dimension is fulfilled. Only at the time when all dimensions at one maturity level are achieved, the associated level of maturity is achieved. In the following the key characteristics of the service integration maturity levels are explained:
- Level 1 – SiloThere is no integrated IT system and different standards, processes and technologies are used across the organization. Without manual interaction organizational wide processes are impossible.
- Level 2 – IntegratedInteroperability is achieved by connecting the silos. Nevertheless, complex data conversions and protocol conversions are indispensable in order to make these connections possible. The additional code leads to tighter coupled systems and therefore reduces maintainability.
- Level 3 – ComponentizedIT systems are componentized and interaction is done via well-defined interfaces but still tightly coupled. The ability to flexibly implement cross organizational processes is still very limited.
- Level 4 – ServicesAt level four a basic SOA exists. Applications can be built out of loosely coupled services across the whole organization. According to the SOA design principles these services are invoked using open standards and first contracts or Service Level Agreements (SLA) are concluded. Furthermore, a service description language to unambiguously define all operations a service performs is used. The definition of new processes is still cumbersome because services are connected by developers using hard-coded calls.
- Level 5 – Composite ServicesInformation flow and control flow between services can be defined using a composition language (e.g. BPEL). This allows a faster and more flexible design of business processes.
- Level 6 - Virtualized ServicesVirtual services are created by introducing facades. Facades invoke the underlying business and IT services thus tremendously increasing service reusability. Services also get more independent of their infrastructure as they can convert the parameters of a call to allow the use of other services by leveraging a conversion service.
- Level 7 – Dynamically Re-Configurable ServicesAt level seven business processes can be constructed at runtime instead of being assembled by a developer at design time. The decision of which service to use is rather complex. Ideally, it is based on the best match of a service’s SLA and the requirements. If for instance the availability of one service is below the required availability, the service can be exchanged as a reaction to the changing circumstances in real time. This ultimately leads to a very loose coupling as well as higher fault tolerance.
As shown in [1], the OSIMM dimensions are provided across all maturity levels. In total there are seven dimensions, each one covering several domains. OSIMM provides several assessment questions for each dimension. These questions should act as a solid starting point for an assessment but have to be customized to the
respective circumstances such as industry specific or company specific conditions. In the following an exemplary question for each of the seven dimensions is listed. A comprehensive list of all questions can be found at [TOG09].
- Business dimension'What are the major business drivers for this initiative?’
- Organization dimension‘What types of skills are common in your IT staff?’
- Methods dimension‘What is the current practice for service development and management?’
- Applications dimension‘What is your current application development style?’
- Architecture dimension‘How would you characterize your architectural topologies?’
- Information dimension‘Do you have independent data models for different applications?’
- Infrastructure dimension‘What are your current infrastructure usage guidelines?’
OSIMM also provides a list of possible benefits which can be achieved when moving to a higher level of maturity. Although the benefit description is a bit more detailed it can be compared to the prime business benefits category in SOAMM. In general OSIMM covers a broader aspect of SOA adoption than SOAMM because it also considers non-technical aspects such as organization. Although the available version 0.3a is with regards to content still IBM’s SIMM, it is surprisingly independent from proprietary software solutions.
Letzte Änderung: 13.05.2009, 13:08 | 1008 Worte