ISO/IEC 16680:2012

INTERNATIONAL ISO/IEC
STANDARD 16680
First edition
2012-05-01
Information technology — The Open
Group Service Integration Maturity Model
(OSIMM)
Technologies de l'information — Modèle de maturité d'intégration du
service de groupe ouvert (OSIMM)

Reference number
©
ISO/IEC 2012
©  ISO/IEC 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2012 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 16680 was prepared by The Open Group and was adopted, under the PAS procedure, by Joint
Technical Committee ISO/IEC JTC 1, Information technology, in parallel with its approval by national bodies of
ISO and IEC.
© ISO/IEC 2012 – All rights reserved iii

Open Group Standard
The Open Group Service Integration Maturity Model (OSIMM)
Version 2
Standardization with special permission of The Open Group.
The Open Group hereby authorizes you to copy this document for non-commercial use within your organization only. In
consideration of this authorization, you agree that any copy of this document which you make shall retain all copyright
and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right
under any patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing
contained herein shall be construed as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights
reserved by The Open Group, and may not be licensed hereunder.
This document is provided "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR
A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied
warranties, so the above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be
periodically made to these publications; these changes will be incorporated in new editions of these publications. The
Open Group may make improvements and/or changes in the products and/or the programs described in these
publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments,
suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential
and The Open Group shall have no obligation of any kind with respect to such information and shall be free to
reproduce, use, disclose and distribute the information to others without limitation. Further, The Open Group shall be
free to use any ideas, concepts, know-how, or techniques contained in such information for any purpose whatsoever
including but not limited to developing, manufacturing, and marketing products incorporating such information.

Technical Standard
The Open Group Service Integration Maturity Model (OSIMM), Version 2
ISBN: TBA
Document Number: TBA
Published by The Open Group, .

Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to: ogspecs@opengroup.org
ii Technical Standard (2012)
Contents
1  Introduction . 1
1.1  Objective . 1
1.2  Overview . 1
1.3  Conformance . 2
1.4  Terminology. 3
1.5  Future Directions . 7
2  The Model . 8
2.1  Overview . 8
2.2  Maturity Levels . 10
2.2.1  Level 1: Silo . 10
2.2.2  Level 2: Integrated . 10
2.2.3  Level 3: Componentized. 10
2.2.4  Level 4: Service . 10
2.2.5  Level 5: Composite Services . 11
2.2.6  Level 6: Virtualized Services . 11
2.2.7  Level 7: Dynamically Re-Configurable Services . 11
2.3  Dimensions . 12
2.3.1  Business . 12
2.3.2  Organization & Governance . 12
2.3.3  Method. 12
2.3.4  Application . 12
2.3.5  Architecture . 12
2.3.6  Information . 13
2.3.7  Infrastructure & Management . 13
2.4  Service Foundation Levels . 13
2.5  Assessment Questions and Maturity Indicators by Dimension . 13
2.5.1  Service Maturity Assessment Questions . 13
2.5.2  Maturity Indicators-to-Assessment Question Mapping . 14
2.6  Extending the Base OSIMM Model . 14
3  Business Dimension: Base Model . 16
3.1  Business Dimension: Base Model Maturity Indicator . 16
3.2  Business Dimension: Assessment Questions . 16
3.3  Business Dimension: Maturity Indicator-to-Attribute Mapping . 17
4  Organization & Governance Dimension: Base Model . 20
4.1  Organization & Governance Dimension: Base Model Maturity
Indicator . 20
4.2  Organization & Governance Dimension: Assessment Questions . 21
4.3  Organization & Governance Dimension: Maturity Indicator-to-
Attribute Mapping . 21
5  Method Dimension: Base Model . 25
The Open Group Service Integration Maturity Model (OSIMM), Version 2 iii

5.1  Method Dimension: Base Model Maturity Indicator . 25
5.2  Method Dimension: Assessment Questions . 26
5.3  Method Dimension: Maturity Indicator-to-Attribute Mapping . 26
6  Application Dimension: Base Model. 30
6.1  Application Dimension: Base Model Maturity Indicator . 30
6.2  Application Dimension: Assessment Questions . 31
6.3  Application Dimension: Maturity Indicator-to-Attribute
Mapping . 31
7  Architecture Dimension: Base Model . 36
7.1  Architecture Dimension: Base Model Maturity Indicator . 36
7.2  Architecture Dimension: Assessment Questions . 37
7.3  Architecture Dimension: Maturity Indicator-to-Attribute
Mapping . 37
8  Information Dimension: Base Model . 40
8.1  Information Dimension: Base Model Maturity Indicator . 40
8.2  Information Dimension: Assessment Questions . 41
8.3  Information Dimension: Maturity Indicator-to-Attribute
Mapping . 42
9  Infrastructure & Management Dimension: Base Model . 45
9.1  Infrastructure & Management Dimension: Base Model Maturity
Indicator . 45
9.2  Infrastructure & Management Dimension: Assessment
Questions . 46
9.3  Infrastructure & Management Dimension: Maturity Indicator-to-
Attribute Mapping . 46
10  The OSIMM Assessment Method . 50
10.1  Overview . 50
10.2  OSIMM Assessment Steps . 51
10.2.1  Identify the Pain-Points, Scope, and Business Goals . 51
10.2.2  Extend the OSIMM Model . 52
10.2.3  Assess Current State . 52
10.2.4  Determine Future State . 52
10.2.5  Identify the Gaps and Determine the Roadmap . 52
A  Example Assessment . 54
A.1  Business Objective . 54
A.2  Analysis . 54
A.3  Recommendations . 55
B  Benefits of Moving to Higher Maturity Levels . 59
B.1  From Silo to Integrated . 59
B.2  From Integrated to Componentized . 59
B.3  From Componentized to Services . 59
B.4  From Services to Composite Services . 60
B.5  From Composite Services to Virtualized Services . 60
iv Technical Standard (2012)
B.6  From Virtualized Services to Dynamically Re-Configurable
Services . 60
C  Relationship to Other SOA Standards . 61
D  Relationship to Other International Standards . 64
D.1  SC38 . 64
D.2  SC7 . 64

The Open Group Service Integration Maturity Model (OSIMM), Version 2 v

Preface
The Open Group
The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of
Boundaryless Information Flow™ will enable access to integrated information within and
between enterprises based on open standards and global interoperability. The Open Group works
with customers, suppliers, consortia, and other standards bodies. Its role is to capture,
understand, and address current and emerging requirements, establish policies, and share best
practices; to facilitate interoperability, develop consensus, and evolve and integrate
specifications and Open Source technologies; to offer a comprehensive set of services to
enhance the operational efficiency of consortia; and to operate the industry's premier ®
certification service, including UNIX certification.
Further information on The Open Group is available at www.opengroup.org.
The Open Group has over 15 years' experience in developing and operating certification
programs and has extensive experience developing and facilitating industry adoption of test
suites used to validate conformance to an open standard or specification.
More information is available at www.opengroup.org/certification.
The Open Group publishes a wide range of technical documentation, the main part of which is
focused on development of Technical and Product Standards and Guides, but which also
includes white papers, technical studies, branding and testing documentation, and business titles.
Full details and a catalog are available at www.opengroup.org/bookstore.
As with all live documents, Technical Standards and Specifications require revision to align with
new developments and associated international standards. To distinguish between revised
specifications which are fully backwards-compatible and those which are not:
 A new Version indicates there is no change to the definitive information contained in the
previous publication of that title, but additions/extensions are included. As such, it
replaces the previous publication.
 A new Issue indicates there is substantive change to the definitive information contained
in the previous publication of that title, and there may also be additions/extensions. As
such, both previous and new documents are maintained as current publications.
Readers should note that updates – in the form of Corrigenda – may apply to any publication.
This information is published at www.opengroup.org/corrigenda.
vi Technical Standard (2012)
This Document
This document is the Technical Standard for The Open Group Service Integration Maturity
Model (OSIMM), Version 2. It has been developed and approved by The Open Group.
The Open Group SOA Integration Maturity Model (OSIMM) provides consultants and IT
practitioners with a means to assess an organization’s Service Oriented Architecture (SOA)
maturity level. It defines a process to create a roadmap for incremental adoption which
maximizes business benefits at each stage along the way. The model consists of seven levels of
maturity and seven dimensions of consideration that represent significant views of business and
IT capabilities where the application of SOA principles is essential for the deployment of
services. The OSIMM acts as a quantitative model to aid in assessment of current state and
desired future state of SOA maturity.
The Open Group Service Integration Maturity Model (OSIMM), Version 2 vii

Trademarks
® ®
Boundaryless Information Flow™ is a trademark and ArchiMate , Jericho Forum , Making
® ® ® ® ® ®
Standards Work , Motif , OSF/1 , The Open Group , TOGAF , UNIX , and the ``X'' device
are registered trademarks of The Open Group in the United States and other countries.
The Open Group acknowledges that there may be other brand, company, and product names
used in this document that may be covered by trademark protection and advises the reader to
verify them independently.
viii Technical Standard (2012)

Acknowledgements
The Open Group gratefully acknowledges the contribution of the following people in the
development of this document:
 Ali Arsanjani, IBM (Original SIMM Mapping)
 Tony Carrato, IBM
 Jorge Diaz, IBM
 Jack Fujieda, Regis Inc.
 Mats Gejnevall, Capgemini
 Henry Hendrikx, Capgemini
 Alex Heublien, HP
 Kerrie Holley, IBM (Original SIMM Mapping)
 Dave Ings, IBM
 Heather Kreger, IBM (Co-Author)
 Chris Moyer, EDS
 Ranu Pandit, Deloitte
 Vishal Prabhu, Deloitte
 Madhu Reddiboina, Deloitte
 Chuck Reynolds, Deloitte
 Andras Szakal, IBM (Work Group Chair, Model Extensions, Author)
 Srinivasan Vembakkam, IBM
 Mohan Venkataraman, Deloitte
 Steve Wolf, Marriott
 Members of The Open Group SOA Work Group
The Open Group Service Integration Maturity Model (OSIMM), Version 2 ix

Referenced Documents (Non-Normative)
The following documents are referenced non-normatively in this Technical Standard:
[BPEL] Business Process Execution Language Standard; refer to:
http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html
[SOA GF] The Open Group SOA Governance Framework, Technical Standard, August 2009
(C093); refer to: www.opengroup.org/bookstore/catalog/c093.htm
[SOA ONT] The Open Group SOA Ontology, Technical Standard, October 2010 (C104); refer
to: www.opengroup.org/bookstore/catalog/c104.htm
[SOA RM] OASIS Reference Model for SOA (SOA RM), Version 1.0, OASIS Standard, 12
October 2006; refer to: docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
[SOAWG] SOA Definition, The Open Group SOA Work Group; refer to:
www.opengroup.org/projects/soa
[SOA WP] Navigating the SOA Open Standards Landscape Around Architecture, Joint White
Paper from OASIS, OMG, and The Open Group, July 2009 (W096); refer to:
www.opengroup.org/bookstore/catalog/w096.htm
x Technical Standard (2012)
1 Introduction
1.1 Objective
This document is The Open Group Service Integration Maturity Model (OSIMM). It specifies:
 A model against which the degree of service integration maturity of an organization can
be assessed
 A process for assessing the current and desired degree of service integration maturity of
an organization, using the model
1.2 Overview
Service Oriented Architecture (SOA) is an architectural style that supports service orientation.
A service is a business task with an externalized service description that often represents a
contract between a provider and a consumer. As organizations adopt SOA and the use of
services as the fundamental structuring element of their architecture, they increasingly encounter
the need to assess where they are in their migration path and how best to achieve the expected
benefit derived from integrating and investing in greater levels of SOA maturity.
OSIMM helps an organization to create a roadmap for its incremental transformation towards
more mature levels of service integration, in order to achieve increasing business benefits
associated with higher levels of maturity. OSIMM is used to determine which organizational
characteristics are desirable in order to attain a new level of maturity. This will also help
determine whether problems occurring at the current level of service integration maturity can be
solved by evolving to a higher level.
OSIMM is offered to the industry as a standardized model to help organizations guide their SOA
transformation journey. A standard maturity model enables enterprises to benchmark their SOA
levels and develop roadmaps for transformation to assist their planning. It can also be used by
vendors to position their services and software against these benchmarks. OSIMM may also
serve as a framework for the transformation process that can be customized to suit the specific
needs of organizations and assessments. This process consists of the following steps:
 Prepare the OSIMM assessment framework
 Determine the initial level of maturity
 Determine the target level of maturity
 Identify the transformation path necessary for the organization to achieve the desired level
of maturity
The Open Group Service Integration Maturity Model (OSIMM), Version 2 1

OSIMM structures the assessment of the organization’s current state in service integration and
flexibility (including service orientation) and of its desired or future state for different lines of
business or enterprise, taking into account pain-points in flexibility or integration that need to be
improved. It provides a model for assisting the organization in determining its architectural
strategy when adopting service orientation, including the creation of an architectural roadmap
for initiatives in legacy transformation, integration with one or more packaged applications,
application renovation and development, and systems integration. This roadmap helps to
determine the scope, focus, and incremental steps for different parts of the organization in order
to transform them towards a higher level of service orientation and service integration, with
justifications in terms of anticipated business benefits. OSIMM provides a framework for
surfacing insights and identifying IT improvements in terms of component development, service
integration, SOA, and IT governance.
OSIMM focuses on increasing levels of flexibility in seven aspects of an organization or
enterprise: business, organization and governance, methods and processes, application portfolio,
architecture, information, infrastructure, and operational management. Focus on these aspects
aids the adoption of a more flexible business by planning integration in advance and constructing
business models, processes, applications, and infrastructure mindful of flexibility.
The OSIMM base model is specified by this document. The base model defines the OSIMM
framework and the assessment process. The base model is designed to be extended by allowing
customers and consulting organizations to add additional maturity indicators. By extending the
model, the maturity assessment can be focused on the adoption of evolving industry frameworks,
new techniques, or organizational imperatives. The authors of the OSIMM standard fully expect
that a database of OSIMM extensions will evolve, providing greater insight into the process of
SOA adoption.
OSIMM may be used to conduct assessments of the current and desired levels of maturity for an
enterprise or line of business within an organization and design a plan of action to transform
from the current to the desired levels. For example, an organization may wish to apply OSIMM
to a particular set of applications in the organization’s portfolio. A decision is made to partition
the large number of applications into a small number of partitions, based upon affinity to
business function. The current state of each partition is then assessed using the maturity model.
Based upon the pain-points, business drivers, and goals, the target state for each partition is
established. The transformation increment for each partition (which may be different for each
partition) is then defined in order to achieve the target state for that partition.
1.3 Conformance
This specification describes the OSIMM SOA maturity model and a corresponding SOA
maturity assessment process. It describes the characteristics of architectures necessary to achieve
a particular level of SOA maturity. Maturity models and maturity model assessments must use at
least the terminology, matrix, dimensions, levels, and attributes described herein in order to be
conformant with this specification. Particular maturity model indicators are not mandated for
conformance. An exemplary process for assessment that conforms to this specification is
provided in The OSIMM Assessment Method (Chapter 10) but is not mandated for
conformance.
2 Technical Standard (2012)
1.4 Terminology
This terminology section provides definition for terms that have a specialized meaning within
OSIMM or are prone to alternative interpretations; therefore, the following definitions apply to
this OSIMM standard:
Adoption
The detailed steps that are required to achieve a transformation. These steps may include the
adoption of new technologies, methods, processes, and integration techniques, and the
establishment of corporate initiatives, IT directives, technical standards, Executive Councils,
Architecture Boards, and Governance.
Architectural Style
A combination of distinctive features in which architecture is performed or expressed. The SOA
architectural style has the following distinctive features:
 It is based on the design of the services – which mirror real-world business activities –
comprising the enterprise (or inter-enterprise) business processes.
 Service representation utilizes business descriptions to provide context (i.e., business
process, goal, rule, policy, service interface, and service component) and implements
services using service orchestration.
 It places unique requirements on the infrastructure – it is recommended that
implementations use open standards to realize interoperability and location transparency.
 Implementations are environment-specific – they are constrained or enabled by context
and must be described within that context.
 It requires strong governance of service representation and implementation.
It requires a “Litmus Test”, which determines a “good service”.
Assessment
Evaluation or appraisal process for determining maturity.
BPEL
Business Process Execution Language Standard (see Referenced Documents).
Business Service
A self-contained piece of business functionality that may be called through a well-defined
standard interface and protocol, independent of implementation platform, and managed under a
contract specifying availability levels and quality-of-service.
The Open Group Service Integration Maturity Model (OSIMM), Version 2 3

Can
Describes a permissible optional feature or behavior that an assessment may have.
Dimension (or View)
A major axis, along which the SOA maturity level of an organization may be measured.
The dimensions represent significant views of the business and IT environment where the
application of SOA principles can have a major effect. An organization may be at a different
maturity level on each dimension, and the overall maturity level of the organization may be
aggregated from the dimension levels. Dimensions are to a first approximation independent, but
there are relationships between them.
Domain
A subdivision of a dimension, representing a more specific aspect of that dimension, along
which the organization may be measured as to its SOA maturity level. Again these represent
aspects where SOA principles can have an effect. Each domain has one or more maturity
indicators at each maturity level, and the sequence of indicators identifies a pathway from less to
more mature SOA. The overall maturity level of a dimension is aggregated from the individual
maturity levels of its domains.
Dynamic Configuration
The ability of a system to look up new services, based upon the matching of a required
specification, and to configure itself to call these new services without the development of new
programming code.
Framework
A foundational structure or set of structures, which can be used for developing a broad range of
architectural products. An architecture framework should contain a method for designing an
information system in terms of a set of services, and for showing how the services fit together. It
should contain a set of tools and provide a common vocabulary.
Master Data Model
A virtualized federated data model service with a master view.
Maturity
The creation of characteristics and behavior in an organization, as a result of transformation and
adoption, that permits it to operate better in accordance with its business goals.
For example, an organization may have put in place processes for the identification of new
services, which will facilitate the creation of services in the future. The nature of the
4 Technical Standard (2012)
characteristics and behavior created in the organization defines the service integration maturity
level, and this is contained within the OSIMM model.
The concepts of SOA transformation, adoption, and maturity are inter-related; transformations
are broken down into adoptions, which create new characteristics – a sign of maturity.
Maturity Indicator (or Characteristic)
A characteristic of the business or IT that may be measured and assessed by asking specific
questions. Each maturity indicator is associated with a specific domain (and by implication a
dimension) and maturity level; if the indicator is assessed as true, then this is evidence for the
domain being at that level of maturity.
Maturity Level Attribute
Observed characteristics of a maturity indicator within a dimension for each maturity level.
Maturity Model
A means of and scale for evaluating and assessing the current state of maturity.
A maturity model also provides a means for developing a transformation roadmap to achieve a
target state of maturity from a given current state of maturity. It quantifies the relative growth of
certain salient aspects within various dimensions typically within, but not limited to,
organizational boundaries.
Must
Describes a feature or behavior that is mandatory for an assessment. An assessment that
conforms to this specification shall include this feature or behavior.
Open Group Service Integration Maturity Model (OSIMM)
A model that enables estimation of the degree to which an organization or enterprise has taken
up the principles of SOA within their IT and business. There are seven levels, Level 1 being the
least take-up and Level 7 being the greatest take-up. Higher degrees of maturity are likely to lead
to a higher degree of agility in the business, but are not necessarily “better”, as each organization
may have an ideal level of maturity depending upon their business requirements and business
and IT context.
Organization
Any entity interested in SOA adoption for the purpose of deploying service-enabled business
processes, including governments, businesses, lines of business, projects, an enterprise, service
ecosystem, or an industry.
The Open Group Service Integration Maturity Model (OSIMM), Version 2 5

Service
A logical representation of a repeatable business activity that:
 Has a specified outcome (e.g., check customer credit; provide weather data, consolidate
drilling reports)
 Is self-contained
 May be composed of other services
 Is a “black box” to consumers of the service
Service Integration Maturity
The level of service integration necessary to realize service orientations defined by the seven
levels of service maturity.
Service-Level Agreement (SLA)
A contract mostly used between service providers and their users to establish availability,
volume, and response time agreements.
Service Management
Practice and techniques necessary to manage services in SOA solutions.
Service Orientation
A way of thinking in terms of services and service-based development and the outcomes of
services.
Note: The explanations of these terms are taken from the definition of SOA that was
developed by The Open Group SOA Work Group; refer to
www.opengroup.org/projects/soa.
Should
For an assessment that conforms to this specification, describes a feature or behavior that is
recommended but not mandatory.
SOA
An architectural style that supports service orientation.
(SOA) Eco-System
A group of one or more organizations that are co-dependent on one another for achieving
business goals by executing services that may leverage another company’s business processes.
6 Technical Standard (2012)
SOA Method
Best practices, reference architectures, templates, and guides for developing an SOA solution.
Transformation
A high-level change from one organizational state to another in order to support business
imperatives and goals. Transformations may be business transformations (for example, a
reduction in the number of customer calls) or IT transformations (for example, the introduction
of support for markets in different geographies). It may be necessary to perform business and IT
transformations in parallel in order to ensure that the business activities are aligned with the IT
activities.
Virtualized Service
A service that is hidden behind a “façade”, so that the caller of the service does not call it
directly but via a proxy that intercepts the call and routes it to a real service based upon
considerations such as load and availability.
1.5 Future Directions
 Development of an OSIMM maturity indicator repository
 Development of an OSIMM case study repository
The Open Group Service Integration Maturity Model (OSIMM), Version 2 7

2 The Model
2.1 Overview
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:
 Business
 Organization & Governance
 Method
 Application
 Architecture
 Information
 Infrastructure & Management
The seven SOA maturity levels are:
 Silo
 Integrated
 Componentized
 Service
 Composite Services
 Virtualized Services
8 Technical Standard (2012)
 Dynamically Re-Configurable Services
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 (Figure 1).

Service Foundation Levels
Dynamically
Re-Configurable
Composite Virtualized
Services
Services Services
Silo Integrated Componentized Services
Isolated Business Business Process Componentized Business provides & Composed Outsourced Services Business capabilities
Business View
Line Driven Integration consumes services Business Services BPM & BAM via context aware
Business Functions
services
Ad hoc LOB IT IT Common Governance Emerging SOA SOA and IT SOA and IT Governance via
Governance &
Strategy and Transformation Processes governance Governance Infrastructure Policy
Organization
Governance Alignment Governance
Structured Analysis & Object Oriented Component Based Service Oriented Service Oriented Service Oriented Business Process
Modeling Development Modeling Modeling Modeling for Modeling
Methods Design
Infrastructure
Modules Objects Components Services Applications Process Integration Dynamic Application
Applications comprised of via Service Assembly
composite services
Monolithic Layered Architecture Component Emerging SOA Grid Enabled SOA Dynamically Re-
Architecture Architecture SOA Configurable
Architecture
Architecture
Application Specific LOB Specific Canonical Information as a Enterprise Business Virtualized Data Semantic Data
Information Data Solution (Data subject areas Models. Service Data Dictionary & Services Vocabularies
established) Repository
LOB Platform Enterprise Standards Common Reusable Project Based SOA Common SOA Virtual SOA Context-aware
Infrastructure &
Specific Infrastructure Environment Environment Environment: Event-based:
Management
Sense and Respond Sense & Respond
Level 1 Level 2 Level 3 Level 4 Level 5 Level 6 Level 7

Figure 1: 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 (Section 2.5). 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
The Open Group Service Integration Maturity Model (OSIMM), Version 2 9

maturity level for each dimension, may itself be assessed to provide a view of the overall
maturity level of the organization.
2.2 Maturity Levels
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.
2.2.1 Level 1: 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.
2.2.2 Level 2: 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, 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.
2.2.3 Level 3: 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 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.
2.2.4 Level 4: Service
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
10 Technical Standard (2012)
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 l
...