8: Selecting an SOA Maturity Model
(EN: In the chapter introduction, the author returns to "maturity" as a motivation, and even uses the child-to-adult analogy to suggest that being "mature" should be considered a goal even if there are not supporting rationale. I'm inclined to disagree, and suspect that this rhetorical tactic is often used when there is no good reason for accepting an "all or nothing" proposal. Instead, a company should decide what level of adoption is appropriate and productive for its needs, for objective and defensible reasons, and proceed accordingly. The author's use of this tactic is going to color my perception of the content that follows.)
GAUGING MATURITY
Organizations may wish to gauge the level of SOA adoption tend to measure its own operations against other businesses or compare their current level of adoption with a their overall goal, both of which are subjective approaches. A more objective approach is to gauge the degree of adoption against a "maturity model" for a given technology.
There are existing maturity models that borrow upon concepts from the "battle-tested" capability maturity model that is used broadly in the IT field and provides an objective (or at least constant) standard against which the adoption of any technology can be assessed. The author suggests a Google search, but mentions three specific models that are common: the Web Services maturity Model, The Service Integration Maturity Model, and the Service Oriented Architecture Maturity Model.
Most models define four phases of technology adoption: early learning (discovering the capabilities, running pilot tests); integration (including the technology as part of an array of systems); reengineering (replacing older systems with the new technology); and maturity (when the technology becomes the standard for the organization).
SERVICE INTEGRATION MATURITY MODEL
This model was developed by IBM, whom the author regards as "one of the foremost authorities on SOA." IT defines seven levels of maturity:
- Silo - The organization is dependent on legacy technology but begins to experiment with services in an unorganized and ad-hoc manner
- Integrated - The organization seeks to better coordinate service development, and the services begin to become "shared" outside the silos in which they were developed
- Component - Services are developed with the intention of being usable outside of their silos (to serve as components in applications development)
- Simple Services - IT focuses on developing services for their own benefit, as elements that perform simple functions that are intended to be reused
- Composite Services - Enterprise-wide standards emerge for service development, and solutions are developed by leveraging existing services
- Virtualized Services - The company evolves to developing services for the sake of providing functionality in and of themselves (not merely middleware to systems where the functionality exists) and, over time, the need for the legacy systems atrophies.
- Dynamic Reconfiguration - Solutions are developed that leverage services "dynamically", such that infrastructure tools become proactive rather than reactive, an systems gain the intelligence to reconfigure themselves, serving as intelligent agents that leverage services to respond to the organization's needs. The author concedes that many people dismiss this as science-fiction, as it's more of a vision of a possible uture rather than a state that can be presently achieved.
The author suggests this model is the only one that describes how enterprises evolve from legacy systems to service-oriented solutions realistically, in that it reflects how SOA adoption is actually done in organizations that have adopted SOA.
SERVICE ORIENTED ARCHITECTURE MATURITY MODEL
This model was developed by "a consortium of vendors" the develop SOA as a "model for visualizing future success" (EN: and going back to my earlier note, this means that the vendor has successfully sold the company everything it possibly can, not that the company is successful - which is my primary suspicion about the rhetoric of a "maturity" model).
This model describes five levels of maturity:
- Initial Services - Services are developed as stand-alone projects, largely to fill a current need with some, though limited, forethought to potential reuse outside of the present need.
- Architected Services - Services are develop with deliberate consideration of reuse outside of the present need, but still within the same system or business unit
- Collaborative Services - Services are developed with deliberate consideration of reuse outside of the present system or business unit, and services become managed on the enterprise level
- Measured Services - Services become the primary method of delivering technology solutions, which requires performance criteria and a monitoring infrastructure
- Optimized Services - The organization seeks to evolve its library of services as a means to supporting future strategic initiatives.
This model is intended to promote the adoption of SOA by capitalizing on the technical and business impacts of SOA adoption.
SELECTING A MATURITY MODEL
The maturity model adopted by an organization should be one that aligns with the organizational culture and goals of the IT department and the enterprise. Some models are geared to measure the adoption of SOA as a natural evolution of information systems, others see SOA as a paradigm shift and measure the degree to which the organization adapts to this change; others take the perspective that adoption of SOA leads to a better alignment of and collaboration between the IT department and the remainder of the business.