As organizations move towards SOA and the use of services as the basis of their future IT architectures, they encounter the need to assess where they are in the migration path, and how to achieve greater benefits to support their businesses and systems.

This maturity model facilitates the assessment of an organization’s current and desired future states in service integration and flexibility. It helps the organization to determine its architectural strategy for adopting service orientation. It can be applied to a complete enterprise, or to an enterprise segment, such as one defined by one or more lines of business.

The model was provided by IBM as an input to work on The Open Group Services Integration Maturity Model (OSIMM).

Overview of the Model

The model defines seven dimensions across seven maturity levels.

The seven dimensions represent different views of the organization: the Business, Organization, Methods, Application, Architecture, Information and Infrastructure views.

The seven maturity levels are Silo, Integrated, Componentized, Services, Composite Services, Virtualized Services and Dynamically Re-Configurable Services.

The complete matrix of dimensions and levels is shown below.

Using The Model

You can use the generic model described here as a reference for the development of specific baseline and target models of an organization's SOA maturity. You can then perform a gap analysis to determine what is needed to move from the baseline to the target, and create a project roadmap for the transformation of the organization to the target SOA maturity level.

Note that this will provide a description of the target and a statement of the activities that need to be undertaken that are at a relatively high level. Further and more detailed analysis will be needed to produce the full target architecture description and implementation roadmap. In an architectural engagement, you would typically use the model at an early stage (for example, in the Preliminary Phase or Phase A of The Open Group Architecture Framework [TOGAF]). The full architecture and roadmap would not be produced until a later stage (for example, TOGAF Phases D and E).

You develop the specific baseline or target model by assessing the maturity of the organization in each of the seven dimensions. The assessment in each dimension results in a summary textual description and a number (1-7) identifying the maturity level. You can then aggregate the assessments through the dimensions to show the overall state of the organization.

You carry out the assessment by interviewing key staff from the organization, using a set of questions about the characteristics of the organization in each dimension. From the answers to these questions, you produce the summary maturity description and level identification. Architecture practices and consultancies will typically have standard sets of questions that they customize for each assessed organization to take account of particular circumstances and requirements.

Dimensions

An organization’s SOA or desired SOA scope can be assessed across the following dimensions.

Business

The Business dimension is focused around the business architecture, the organization’s current practices and policies around the business architecture, how business processes are designed, structured, implemented and executed, how costs of IT capabilities are allocated throughout the enterprise, and how well the IT capabilities support flexibility of the business, business agility and business Service Level Agreement (SLA) management. Because the business dimension includes IT strategy, it includes a high level quantifiable monetary-value justification for moving from one maturity level to a higher level maturity level.

Organization

The Organization dimension is focused on the structuring and design of organizations and resulting measures of organizational effectiveness in the context of an SOA, for example, SOA governance. This includes the types and extent of skills, training and education that are available within the organization, the existence of a formal governance process to keep IT activities and capabilities aligned with the needs of the whole business, how IT management is organized, and how costs are allocated.

Methods

The Methods 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 Life Cycle, such as the use of requirements management, estimation techniques, project management, quality assurance processes, design methodologies and techniques, and tools for designing solutions.

Applications

The Applications dimension is focused on application style, structuring of the application and functional decomposition, reusability, 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.

Architecture

The Architecture dimension is focused on topology, data characteristics, business information model, integration techniques, enterprise architecture decisions, standards and policies, web services adoption level, experience in SOA implementation, SOA compliance criteria, and typical artifacts produced.

Information

The Information dimension is focused on the information modeling aspects, access to enterprise data, abstraction of the data access from the functional aspects, data transformation, service and process definition, handling of identifiers, security credentials, knowledge management, and content management.

Infrastructure

The Infrastructure 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.

Maturity Levels

Each of the seven maturity levels reflects a possible abstract state of an organization in terms of its maturity in the integration of its services (business and/or IT). The following are typical aggregate descriptions for these levels.

Silo

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.

Integrated

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, connecting two systems requires a possibly complex conversion of the data, operations and protocols that they use. 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 not therefore easy to develop new business processes.

Componentized

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 interoperability between systems in different parts of the organization, or different organizations within the business eco-system. This makes it hard to develop cross-organization business processes.

Service

Composite applications can now be built from loosely-coupled business services. The way that services may be invoked is based upon open standards and independent of the underling application technology. The services have an IT infrastructure that supports them with suitable protocols, security mechanisms, data transformation and service management capabilities, even across different organizations within the eco-system, and may be managed by assigning responsibilities for SLAs to relevant parts of the organization. However the flow of control within a composite application is still defined by bespoke programming, rather than by a declarative flow language. The business functionality has been analyzed in detail and is broken down into business services residing within a business architecture that ensures that business services will interoperate at the business level. In addition, it is possible to define the services via a specification language that unambiguously describes the operations performed by each service, enabling the construction of a catalogue of services. The combination of IT and business 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 is still performed by developers writing bespoke code, thus limiting the agility of the development of new business processes.

Composite Services

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 language to define the flow of information and control through the individual services. This permits the assembly of business services into composite business processes, which may be short-running or long-running, without significant construction of code. Thus, the design and development of business services is agile, and may be performed by developers under the close guidance of business analysts.

Virtualized Services

The business and IT services are now provided through a level of indirection. The service consumer does not invoke the service directly, but through a virtual service. The infrastructure performs the work of converting the virtual service invocation into an invocation of the real service, and may as part of this conversion change the address, the network, the protocol, the data and the synchronization pattern of the invocation. Such conversions may be complex services in their own right, for example transforming 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 business 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 business services.

Dynamically Re-Configurable 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 run time, 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.