The Open Group Service Integration Maturity Model (OSIMM) specifies how to measure the service integration levels of an organization and its IT systems and business applications. In addition, it provides guidance on how to achieve certain levels of service maturity necessary to realize related business benefits.
The OSIMM has seven dimensions across seven maturity levels. Each maturity level represents a significant increase in the level of maturity necessary to realize service orientation. This concept is referred to as service integration maturity within OSIMM. OSIMM may also be utilized as an SOA maturity model. While many SOA techniques and practices are used to realize service orientation, the OSIMM is intentionally inclusive of new and evolving techniques for implementing services such as cloud computing. The extensibility of the OSIMM framework is intended to provide a method to augment the base OSIMM model to include such concepts.
OSIMM defines a set of dimensions, representing different views (e.g., business, architectural) of an organization, as follows:
The seven SOA maturity levels are:
The maturity level of each dimension is assessed by matching maturity indicators to maturity level attributes. The total assessment of maturity indicators for all the dimensions provides a holistic view of the service integration maturity level of the organization.
The OSIMM maturity matrix which defines the maturity dimensions and levels is shown in OSIMM Maturity Matrix.
OSIMM Maturity Matrix
The columns of the matrix correspond to the maturity levels, and the rows correspond to the dimensions. Each cell in the matrix defines the maturity level for each of the dimensions in each column. The overall SOA maturity of an organization is assessed by identifying its maturity level in each dimension.
For example, consider the cell Information x Silo, with the label “Application-Specific Data Solution”. Maturity attributes are mapped to maturity indicators within OSIMM, as described under Assessment Questions and Maturity Indicators by Dimension. If the maturity attributes suggest that the Silo level maturity indicators are present for a particular assessed application or system, then the maturity of the Information dimension is considered to be Silo (Level 1), so the assessed application or system is characterized as having an Application-Specific Data Solution.
Each dimension may be assessed in a similar way, leading to a level assessment for each dimension or business view, organization, etc. The overall picture, in terms of the assessed maturity level for each dimension, may itself be assessed to provide a view of the overall maturity level of the organization.
At the heart of OSIMM are the seven levels of enterprise business and IT service-integration maturity. Each of the seven levels reflects a possible abstract state of an organization in terms of its maturity in the integration of its services (business and/or IT) and SOA solution. Each maturity level builds on the foundation of its predecessors and will have a cumulative set of maturity attributes.
Individual parts of the organization are developing their own software independently, with no integration of data, processes, standards, or technologies. This severely limits the ability of the organization to implement business processes that require co-operation between the different parts, and the IT systems cannot be integrated without significant manual intervention, such as re-keying and re-interpretation of data.
Technologies have been put in place to communicate between the silos, and to integrate the data and interconnections. The construction of an IT system that integrates across different parts of the organization becomes possible. However, integration does not extend to common standards in data or business processes. Therefore, to connect two systems, it requires a, possibly complex, conversion of the data, operations, and protocols used by these systems. Each such connection may require bespoke code and adapters, leading to a proliferation of software that is difficult to manage and complex to code. It is therefore not easy to develop or automate new business processes.
The IT systems in the silos have been analyzed and broken down into component parts, with a framework in which they can be developed into new configurations and systems. There may also be some limited analysis of the business functionality into components. Although components interact through defined interfaces, they are not loosely coupled, which limits agility and interoperability between different segments of the organization (or even different organizations within the business “eco-system”). This causes difficulties in development and deployment of shared business processes. Business and infrastructure components are discrete and re-usable through code and EAI re-use techniques. However, they are often replicated and redundant.
Composite applications are built from loosely-coupled services. The way that services may be invoked is based upon open standards and is independent of the underling application technology. Services run on an IT infrastructure that is supported by the appropriate protocols, security mechanisms, data transformation, and service management capabilities. The services may therefore interoperate across all of the parts of the organization and even across different organizations within the eco-system, and are often managed by assigning responsibilities for managing Service-Level Agreements (SLAs) to segments of the organization. The business functionality has been analyzed in detail and is broken down into services residing within a business architecture that ensures that services will interoperate at the business level. In addition, it is possible to define the services via a specification language – such as WSDL or Service Component Architecture (SCA) – that unambiguously defines the operations performed by the service, permitting the construction of a catalog of services. The combination of IT and service architectures permits the construction of systems based upon these services, operating right across the organizations in the ecosystem. However, at this stage the composition of services and flow of control within a composite application are still defined by developers writing bespoke code, rather than by a declarative flow language. This limits the agility of the development of new business processes as services.
At this level of service maturity it is now possible to construct a business process for a set of interacting services, not just by bespoke development, but by the use of a composition or business process modeling language, such as BPEL [BPEL] of information and control through the individual services. Composite services include static, process, and activity-based services. This permits the assembly of services into composite business processes, which may be short or long running, without significant construction of code. Thus, the design and development of services is agile, and may be performed by developers under the close guidance of business analysts.
The business and IT services are now provided through a façade – a level of indirection. The service consumer does not invoke the service directly, but through the invocation of a “virtual service”. The infrastructure performs the work of converting the virtual invocation into a physical call of the real service, and may as part of this conversion change the address, the network, the protocol, the data, and the synchronization pattern that is contained in the call. Such conversions may be a complex service in their own right, such as the transformation of data from one data model to another. The virtual service thereby becomes more loosely coupled from the infrastructure on which it is running, permitting more opportunities for the composition of services. This is in contrast to the lower levels of service maturity, where the service is more closely coupled to the infrastructure. Although virtualization has been used in non-SOA systems, this level extends the concept (and advantages) of virtualization to services.
Prior to this level, the business process assembly, although agile, is performed at design time by developers (under the guidance of business analysis and product managers) using suitable tooling. Now this assembly may be performed at runtime, either assisted by the business analysts via suitable tooling, or by the system itself. This requires the ability to access a repository of services and to query this repository via the characteristics of the required services. In its simplest form, these characteristics may have been defined in advance, restricting the system to selecting and locating specific instances of services.
An organization’s level of SOA maturity can be assessed across the following set of dimensions which are essential indicators for effective SOA adoption.
The Business dimension is focused on the business architecture; i.e., the organization’s current business practices and policies; how business processes are designed, structured, implemented, and executed. The Business dimension also addresses how the cost of IT capabilities is allocated across the enterprise, and how well the IT capabilities support the flexibility of the business, agility, and SLAs. The Business dimension includes IT strategy. And thus includes the necessary value proposition for moving from one maturity level to a higher level maturity level. A discussion of these value propositions are in Benefits of Moving to Higher Maturity Levels.
The Organization & Governance dimension is focused on the structure and design of the organization itself and the necessary measures of organizational effectiveness in the context of an SOA and SOA governance. The Organization aspect is focused on organizational structure, relationships, roles, and the empowerment necessary to adopt a service-oriented strategy. This includes the types and extent of skills, training, and education that are available within the organization. Governance is associated with formal management processes to keep IT activities, service capabilities, and SOA solutions aligned with the needs of the business. Governance guides many aspects of the other maturity dimensions, including how management is structured and costs are allocated.
The Method dimension is focused on the methods and processes employed by the organization for its IT and business transformation, and the organization’s maturity around the Software Development Lifecycle such as the use of requirements management, estimation techniques, project management, quality assurance processes, design methodologies and techniques, and tools for designing solutions.
The Application dimension is focused on application style, structuring of the application and functional decomposition, re-usability, flexibility, reliability, and extensibility of the applications, understanding, and uniform use of best practices and patterns, whether multiple applications have been created to serve different lines of business with essentially the same functionality, and the availability of enterprise schema and object models.
The Architecture dimension is focused on the structure of the architecture which includes topology, integration techniques, enterprise architecture decisions, standards and policies, web services adoption level, experience in SOA implementation, SOA compliance criteria, and typical artifacts produced.
The Information dimension is focused on how information is structured, how information is modeled, the method of access to enterprise data, abstraction of the data access from the functional aspects, data characteristics, data transformation capabilities, service and process definitions, handling of identifiers, security credentials, knowledge management, business information model, and content management.
The Infrastructure & Management dimension is focused on the organization’s infrastructure capability, service management, IT operations, IT management and IT administration, how SLAs are met, how monitoring is performed, and what types of integration platforms are provided.
The first three layers of the OSIMM maturity model – Silo, Integrated, and Componentized – are referred to as the Service Foundation Levels. Service integration and orientation is much easier to achieve if business and infrastructure functions are developed as discrete components that are componentized, location-independent, and loosely-coupled from the underlying runtime environment. The Service Foundation Levels can be seen as recommended prerequisites for services enabling a legacy environment (or even aggregating existing services). While it is possible to provide services over poorly structured legacy environments, it may compromise the success of the SOA solution. Green-field SOA applications may be an exception and not require the same steps to achieve service orientation as re-using legacy business functions. Services developed using web services and other service enabling technologies should also meet the maturity characteristics defined by the Service Foundation Levels.
The maturity indicators are assessed against a set of questions that elicit an organization’s current business and infrastructure-related service and SOA-related practices. The OSIMM base model includes a set of assessment questions and maturity indicators that can be used as provided or extended to determine an organizations service integration maturity.
Assessment questions are used to survey the target organization for the purpose of eliciting the service maturity attributes that map to a specific service maturity level. Assessment questions are grouped by maturity dimension. The OSIMM facilitator uses the assessment questions to conduct a survey of the IT and business stakeholders responsible for defining and deploying services. For example, the following groups within an enterprise may be surveyed to gather enough information to map maturity attributes to a maturity indicator:
Assessment questions are correlated to maturity attributes for each maturity indicator by dimension. This helps the assessment facilitator evaluate which assessment questions are intended to elicit information that can be used to correlate specific maturity attributes to a particular maturity indicator, thereby determining the service maturity level. Assessment Question Mapping for Level 1 Business Dimension Maturity shows that Business dimension questions 2 and 3 elicit the maturity attributes that would indicate a Silo (Level 1) Business dimension (i.e., business processes are not formally defined and documented).
Assessment Question Mapping for Level 1 Business Dimension Maturity
The standard set of assessment questions and maturity indicators are defined in Business Dimension: Base Model as the base OSIMM model. The base OSIMM model can be extended by adding additional maturity indicators, assessment questions, and corresponding attribute mappings; for example, to encompass maturity indicators specific to an industry or enterprise. Industry extensions may be standardized to provide a common baseline to measure service integration maturity against adoption of specific industry service frameworks (such as retail and financial frameworks).
Maturity indicator weighting is used to provide a method to weight multiple maturity indicators within a dimension; for example, when organizational or industry maturity indicators are added to the base model. In addition, the OSIMM facilitator can adjust the weighing at the start of the assessment to align with the target organization’s expectations and business requirements.
The OSIMM base model provides maturity indicator weighting based on a 10-point scale by maturity level. The maturity score can be a value in the range up to the weighted value. All weights are summed for a single score. Additional maturity indicators could be allocated a maturity weight based on a portion of the total possible dimension maturity score. Scoring and weighting is defined by the assessment facilitator and agreed to by the target organization. The maturity level weighting in the base OSIMM model is based on a 10-point scale. A total maturity assessment score can be established by totaling each of the assessment weights from an assessment. For example, a total score of 210 would indicate a holistic SOA maturity assessment of Componentized. However, it is important to realize that the organization should focus on the SOA maturity assessment of each dimension and the business value that can be realized by increasing the organization’s SOA maturity within a particular dimension. Domain scores and single scores can be compared to target maturity scores for an organization to show progress towards maturity goals. However, maturity scores are not meant to be compared between organizations since each organization is unique.