Increase Flexibility With Service Integration Maturity

We spend a considerable amount of time flying around the country for various service-oriented architecture (SOA)-based projects, and we’ve had the opportunity to learn about not only the recurring client pain points and value propositions around SOA, but also a tiny bit about flying. Pilots are given landing patterns when they approach an airport; air-traffic control gives them these directions, approaches, and coordinates in order to accommodate the complexity of moment-to-moment changes in events that are occurring around the airport: other planes, wind direction, air pressure, and a host of other factors.

In a similar way, the path to SOA must consider several typical approaches. SOA adoption is a gradual process. While some organizations dabble with Web services by wrapping applications as a means of exploring the world of SOA and deciding how to proceed, others engage in enterprise-wide business transformation. Others are in between, and have defined their roadmaps, vision, strategy, and criteria for assessment and governance. They embark on this journey by integrating applications using service-orientation. This latter is called service-oriented integration (SOI) and is the intermediate stage in which many people find their projects.

The Seven Stages of Maturity

At IBM, we have been working on a maturity model and process for achieving desirable stages of maturity, a model called the Service Integration Maturity Model (SIMM). The level of de-coupling and amount of flexibility achievable at each stage of maturity are what make up the following seven levels of maturity:

1. Silo (data integration)
2. Integrated (application integration)
3. Componentized (functional integration)
4. Simple services (process integration)
5. Composite services (supply-chain integration)
6. Virtualized services ( virtual infrastructure)
7. Dynamically reconfigurable services (eco-system integration)

Each level has a detailed set of characteristics and criteria for assessment, including the following highlights of each level:

Level One: The organization starts from proprietary and quite ad-hoc integration, rendering the architecture brittle in the face of change.

Level Two: The organization moves toward some form of EAI (Enterprise Application Integration), albeit with proprietary connections and integration points. The approaches it uses are tailored to use legacy systems and attempt to dissect and re-factor through data integration.

Level Three: At this level, the organization componentizes and modularizes major or critical parts of its application portfolio. It uses legacy transformation and renovation methods to re-factor legacy J2EE or .NET-based systems with clear component boundaries and scope, exposing functionality in a more modular fashion. The integration between components is through their interfaces and the contracts between them.

Level Four: The organization embarks on the early phases of SOA by defining and exposing services for consumption internally or externally for business partners — not quite on a large scale — but it acts as a service provider, nonetheless.

Level Five: Now the organization extends its influence into the value chain and into the service eco-system. Services form a contract among suppliers, consumers, and brokers who can build their own eco-system for on-demand interaction.

Level Six: The organization now creates a virtualized infrastructure to run applications. It achieves this level after de-coupling the application, its services, components, and flows. Now the infrastructure is more finely tuned, and the notions of the grid and the grid service render it more agile. It externalizes its monitoring, management, and events (common event infrastructure).

Level Seven: The organization now has a dynamically re-configurable software architecture. It can compose services at run-time using externalized policy descriptions, management, and monitoring.

Some have also created mappings to Capability Maturity Model Integration (CMMI), which are a natural way to try and understand maturity. The main challenge in a few of these efforts has been to be more than just a categorization according to some semblance of CMMI, and to justify why something is, for example, defined, repeatable, or optimized. This is often easy to do, due to the open and interpretable nature of the descriptions for each CMMI maturity level.

The mapping to SIMM to CMMI is also quite straightforward, but the perceived value of this mapping seems distant when considered independently of the bandwagon factor for the success of CMMI. Service maturity relates to integration capabilities at various levels of business, methods, applications architecture, and infrastructure.

CMMI deals with six levels of capability:

1. Incomplete
2. Performed
3. Managed
4. Defined
5. Quantitatively managed
6. Optimizing

Each capability level consists of related, specific, and generic practices for a process area that can improve the organizational processes associated with that process area. Forrester has been discussing various notions of maturity, although from a different perspective. Zapthink and other analysts have discussed SOA roadmaps, which you can facilitate using SIMM.

Elements affecting maturity include coupling, standards usage, service identification that supports business needs, business models, goals, and metrics that need to be supported by services, technologies, governance, infrastructure, tooling, skills and deployment capabilities.

The Incremental Scope of SOA Adoption

The process of adopting Web services and SOA starts in many cases at the ad hoc stage on projects. This gradually evolves into a general technology adoption within a group that is engaging in that style of projects, using tools, technologies, standards, methods, and patterns that enable the creation of proofs of concept.

Assessments and planning can be done at this stage of adoption. The functionality of the proposed services needs to be verified and validated. The operational side of using run-time tools (monitoring, management, security, registry, and so on) need to be tested and prototyped.

Once the technology adoption stage achieves some level of maturity, the results start trickling into the lines of business. They see the value in sharing services across lines of business to eliminate redundancy and having a single point of access to existing functionality that reduces complexity and cost and increases flexibility.

The business begins using services to access common functionality, often starting at a technology level and then moving on to the business level, which can provide greater value. Businesses can start to partition the functionality they leverage so as to eliminate redundancy.

As the lines of business start using these services, they partition functionality versus being redundant about that piece of functionality. With this comes a certain degree of business buy-in as the services start to percolate toward consolidation of business function across lines of business.

Conclusion

To achieve an optimal level of flexibility when architecting a service-oriented infrastructure, it’s wise to adhere to the seven steps of maturity that we’ve discussed. Doing this, combined with attention to the capabilities described in the Capability Maturity Model Integration, will enable you to develop a well-defined and usable architecture.

Kerrie Holley, is a Distinguished Engineer in IBM Global Services and a Chief Architect in the e-business Integration Solutions where he provides thought leadership for the Web services practice.