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.
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.
OSIMM defines a set of dimensions, representing different views (e.g., business, architectural) of an organization, as follows:
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.
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:
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:
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:
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:
Some of these work groups are WG23 Mapping to 900-1, WG06 Software Quality, and WG10 Process Assessment.
In terms of methods, SC7 has process and product reference standards such as:
It has also process and product implementation standards such as:
In terms of Service Management, SC7 standards form the 20000 series:
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.
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.
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.
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:
This method is applicable to all processes (not only software or systems engineering), as long as they are defined in a standard way.
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:
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.
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.