ISO/IEC 16680:2012 情報技術—オープングループサービス統合成熟度モデル（OSIMM） | ページ 4

1.1 目的

この文書は、Open Group Service Integration Maturity Model (OSIMM) です。以下を指定します。

• •組織のサービス統合の成熟度を評価できるモデル
• •モデルを使用して、組織のサービス統合成熟度の現在および望ましい程度を評価するプロセス。

1 Introduction

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

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.

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.

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

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.

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.

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