ISO IEC 16680:2012 pdfダウンロード

ISO IEC 16680:2012 pdfダウンロード。Information technology — The Open Group Service Integration Maturity Model (OSIMM)
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 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 language – such as WSDL or Service Component Architecture (SCA) – that unambiguously defines the operations performed by the service, permitting the construction of a catalog of services. The combination of IT and 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 and flow of control within a composite application are still defined by developers writing bespoke code, rather than by a declarative flow language. This limits the agility of the development of new business processes as services.