The Open Group Service Integration Maturity Model (OSIMM) Version 2 – Relationship to Other International Standards

 

Other international standards exist and are in progress in ISO/IEC JTC1 which are related to OSIMM. This appendix provides positioning with select especially relevant standards and some statements about potential future work on OSIMM.

SC38

The OSIMM specification contains definitions of terms that are important to understand the OSIMM specification.

SC38 WG2 is working on a terminology and technical principles of SOA technical report.

As SC38 WG2 continues its development of terminology in ISO/IEC JTC1 WD 30102, and a final technical report is delivered, a future revision of the OSIMM specification could be done to align terminology, especially where there is conflict such that it interferes with the understanding and application of OSIMM.

SC7 – OSIMM Dimensions and SC7 Domains

OSIMM Dimensions

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

These are essential indicators for effective service adoption for SOA and cloud. The maturity indicators are evaluated in a self-assessment against a set of questions that elicit an organization’s current and target business and infrastructure-related service and SOA-related practices. The results of this self-assessment may be compared with target maturity assessments and re-evaluation to determine progress towards the target maturity levels.

SC7 Domains

The mission of SC7 is by nature international standardization, but its domain and scope is better described by the classification of its program of work than by its current terms of reference.

SC7 core activities are concerned with business processes/methods related to IT infrastructure and IT-based systems. Historically, however, the emphasis has been on IT-based systems that support the business.

SC7 standards and projects can be logically grouped in either process areas or product areas. Note that SC7 does not occupy all the standardization fields within these domains, so its scope is naturally more limited. Some of the work groups in progress at the time of this publication have been provided to help understanding the scope of the efforts.

Enterprise processes are processes that are not specific to one project, solution, system, or organizational unit. For instance:

  • Enterprise Architecture
  • Planning
  • Portfolio Management
  • Management, Control, and Governance

For example, WG42 Architecture, WG40 Governance, WG19 ODP, and WG27 Outsourcing groups are currently in progress. Although these topics are well covered by industry consortia, international standardization in these areas is just beginning, and SC7 currently has a few projects of that nature.

The area of IT Systems Engineering Processes has historically been the kernel of the program of work of SC7, more specifically “Software Engineering”, which can be considered a subset of IT Systems Engineering. Addition of projects in “Systems Engineering” is now bringing a more comprehensive view. These processes are generally labelled as:

  • Solution Architecture
  • Requirements Management
  • Design
  • Specification
  • Acquisition
  • Construction
  • Implementation
  • Management
  • Assessment
  • Measurement

Currently WG07 LC Processes, WG02 LC Work Product, WG24 LC for BVSE, and WG26 Testing are working in this systems engineering domain.

In support of these processes, IT Systems Engineering Tools and Techniques are used. Since these generally support more than one of the above processes, this is considered as a separate item. Examples include WG04’s Tools group and WG19’s Techniques group.

Projects in the area of Systems Management and Services were assigned to SC7 a few years ago (aka WG25 Service Management and WG21 Software Asset Management), and this area is now of growing importance. It includes processes such as:

  • Service Management
  • Release Management
  • Service Delivery
  • Service Support
  • Configuration Management
  • Relationship Management

Quality, Evaluation, and Documentation of IT Systems

The domain of Quality, Evaluation, and Documentation of IT Systems is the companion domain of IT Systems Engineering, and about the products of IT Systems Engineering. It consists of:

  • Quality characteristics of IT-based systems
  • Evaluation of IT-based systems
  • Assessment of IT-based related processes
  • Documentation of IT-based systems

Some of these work groups are WG23 Mapping to 900-1, WG06 Software Quality, and WG10 Process Assessment.

SC7 Standards

In terms of methods, SC7 has process and product reference standards such as:

  • ISO/IEC 12207:2008: Systems and Software Engineering – Software Life Cycle Processes
  • ISO/IEC 15288:2008: Systems and Software Engineering – System Life Cycle Processes
  • ISO/IEC 15289:2006: Systems and Software Engineering – Content of Systems and Software Life Cycle Process Information Products (Documentation)
  • ISO/IEC 90003:2004: Software Engineering – Guidelines for the Application of ISO 9001:2000 to Computer Software
  • ISO/IEC 10746:2009: Information Technology – Open Distributed Processing -- Reference Model
  • ISO/IEC CD 26550: Software and Systems Engineering – Reference Model for Software and Systems Product Lines
  • ISO/IEC 42010:2007: Systems and Software Engineering – Recommended Practice for Architectural Description of Software-Intensive Systems

It has also process and product implementation standards such as:

  • ISO/IEC 14764:2006: Software Engineering – Software Life Cycle Processes – Maintenance
  • ISO/IEC 16085:2006: Systems and Software Engineering – Life Cycle Processes – Risk Management
  • ISO/IEC/IEEE 16326:2009: Systems and Software Engineering – Life Cycle Processes – Project Management
  • ISO/IEC CD 29119: Information Technology – Software Engineering – Testing
  • ISO/IEC/IEEE 29148: Systems and Software Engineering – Life Cycle Processes – Requirements Engineering
  • ISO/IEC 29110:2011: Software Engineering – Life Cycle Profiles for Very Small Entities (VSEs)

In terms of Service Management, SC7 standards form the 20000 series:

  • ISO/IEC 20000-1:2011: Information Technology – Service Management – Part 1: Service Management System Requirements
  • ISO/IEC 20000-2:2005: Information Technology – Service Management – Part 2: Code of Practice
  • ISO/IEC TR 20000-3:2009: Information Technology – Service Management – Part 3: Guidance on Scope, Definition, and Applicability of ISO/IEC 20000-1
  • ISO/IEC TR 20000-4:2010: Information Technology – Service Management – Part 4: Process Reference Model
  • ISO/IEC TR 20000-5:2010: Information Technology – Service Management – Part 5: Exemplar Implementation Plan for ISO/IEC 20000-1
  • ISO/IEC NP TR 20000-10: Information Technology – Service Management – Part 10: Concepts and Terminology

SC7 and OSIMM

The objective of OSIMM is to assess the maturity of an organization’s current business and infrastructure-related service and SOA-related practices. SOA is an architectural style used to develop service-oriented systems. OSIMM also states the requirement for a formal SOA development and deployment method.

Formalizing methods and practices in the area of architecture, modeling techniques, systems and software engineering, and service management is the core activity of SC7, and it is quite natural that many of the dimensions selected for OSIMM (more specifically method, architecture, infrastructure, and management) are also covered by SC7 standards and active projects.

Conclusion

Better integration of OSIMM with the ISO set of software and systems engineering standards could be achieved if the terminology used in the document, more specifically, in the checklists, were harmonized with existing FDIS 15504 standards.

The purpose of OSIMM is not to measure an organization's compliance with standards; therefore, it need not use SC7 standards as normative references.

SC7 – SC7 and OSIMM Assessments

OSIMM Assessments

OSIMM is a self-assessment to help companies determine the gaps and roadmap to changing their usage of services in their solutions. The target of OSIMM assessments is the use of services and application of service-orientation to business solutions. It is valuable to compare the maturity level of a solution over time to assess progress on their roadmap for SOA adoption. However, it is not appropriate to compare the maturity of two different solutions in two different organizations; each assessment is with different weights and business objectives. Nor is it appropriate to dictate or require a level of maturity for all organizations.

OSIMM uses the term “assessment” and “assessment method” to designate something that is somewhat less formal than the accepted meaning of these terms in the SC7 FDIS 15504 standard. The process proposed by OSIMM is closer to the assessment activities of a planning lifecycle, or the enterprise architecture processes, which perform a survey of the current situation, define a target, and then do some form of “gap analysis” between both, to identify and prioritize future activities.

SC7 Assessments

These terms (“assessment” and “assessment method”) have a different and more formal meaning in SC7. In the last 15 years work has produced and refined a maturity/capability assessment model structure and framework that is used as a basis for both integration (with other measured aspects of the organization) as well as harmonization (the vehicle by which all these standards can work within the organization) .Without such a shared model and framework, the assessment results of other aspects of the organization will not be comparable or even mappable.

The approach taken by SC7 is to separate the assessment processes and products into three independent but related parts:

  1. The assessment method, documented in the standards and technical reports identified in the next section
  2. The assessment baseline, called a Process Reference Model
  3. The assessment criteria, called a Process Assessment Model

This method is applicable to all processes (not only software or systems engineering), as long as they are defined in a standard way.

SC7 Standards

In the area of process capability assessments, SC7 has a series of documents, published as parts of ISO/IEC 15504. These documents have been restructured and revised, and are now in preparation as part of the 33000 series:

  • ISO/IEC 15504-1:2004: Information Technology – Process Assessment – Part 1: Concepts and Vocabulary
  • ISO/IEC TR 15504-2:1998: Information Technology – Software Process Assessment – Part 2: A Reference Model for Processes and Process Capability
  • ISO/IEC 15504-3:2004: Information Technology – Process Assessment – Part 3: Guidance on Performing an Assessment
  • ISO/IEC 15504-4:2004: Information Technology – Process Assessment – Part 4: Guidance on Use for Process Improvement and Process Capability Determination
  • ISO/IEC 15504-5:2006: Information Technology – Process Assessment – Part 5: An Exemplar Process Assessment Model
  • ISO/IEC TR 15504-6:2008: Information Technology – Process Assessment – Part 6: An Exemplar System Life Cycle Process Assessment Model
  • ISO/IEC TR 15504-7:2008: Information Technology – Process Assessment – Part 7: Assessment of Organizational Maturity
  • ISO/IEC TR 15504-8:1998: Information Technology – Software Process Assessment – Part 8: Guide for Use in Determining Supplier Process Capability
  • ISO/IEC TR 15504-9:1998: Information Technology – Software Process Assessment – Part 9: Vocabulary
  • ISO/IEC DTR 15504-10: Information Technology – Process Assessment – Part 10: Safety Extension

SC7 and OSIMM

Even if OSIMM and SC7 are using the same terminology from ISO/IEC 15504 when describing assessments, it is obvious that we are in the presence of two different sets of assessment requirements, and two different assessment methods.

Conclusion

If SC38 decides to refine the OSIMM approach to something where the assessment results are more comparable between organizations, then it would be possible to use SC7 documents and expertise to do so. It is important to note that SC7 Capability and Maturity assessment methods (ISO/IEC 15504) are generic, using the equivalent of “plug-in” modules, depending on the domain that is to be assessed. Other domains have been assessed, like software engineering (ISO/IEC 12207), systems engineering (ISO/IEC 15288:2008), service management (ISO/IEC 20000), and VSE lifecycle (ISO/IEC 29110:2011) (see www.spiceusergroup.org).

The OSIMM approach could be formalized in a ISO/IEC 15504-compliant process framework (a Process Reference Model) and ISO/IEC 15504-compliant assessment criteria (a Process Assessment Model).

This would make comparable assessments possible, and make the maturity levels fit into the established SC7 framework.

At the time of this publication, there are no plans for such a refinement. With OSIMM being a self-assessment model, there is no overlap with the SC7 program of work or assessment standards.

 

⇒ Referenced Documents