What to look for in a SOA maturity model

As companies move beyond the "what" and "why" of SOA to the "how," they are looking for any tool or approach that will accelerate the adoption and lower the risk of their service-oriented architecture (SOA) implementations. In response to this need, several SOA Maturity Models have cropped up that aim to help companies find out how far they have progressed on the SOA journey. Since SOA itself is still a set of emerging best practices, the main challenge with these models is that they all have different angles on the issue of SOA maturity, in many cases adding to the confusion over SOA rather than clearing any of it up. In this ZapFlash, we aim to cut through the noise and confusion, not with our own SOA Maturity Model (there are probably enough already), but rather with advice on how to understand what the differences are among the various models, so that you can evaluate whether such models will help you be successful with your SOA rollouts.

What is a Maturity Model?

Most of the SOA Maturity Models currently under development hearken back to the widely popular Capability Maturity Model (CMM), and its update the Capability Maturity Model Integration (CMMI) , both out of Carnegie Mellon University's Software Engineering Institute. The CMMI is a method for evaluating and measuring the maturity of an organization's software development and integration processes. The CMMI describes five maturity levels that identify the characteristics of increasingly mature processes, giving an organization a sense of their current progress with IT and where they need to improve.

SOA Maturity Models are only loosely related to CMMI, because while they take the notion of a maturity model from CMMI, they don't have much else in common, because CMMI measures the maturity of IT processes, while SOA Maturity Models should measure the maturity of an organization's architecture. After all, since CMMI applies to all software, integration, and IT processes, CMMI would arguably apply just as well to service-oriented approaches. We may argue whether CMMI is the best tool for measuring such processes, but that's not the topic of this ZapFlash.

Instead, it makes sense to discuss and measure the maturity of a company's architecture. When architects develop or use a SOA Maturity Model for this purpose, they should be looking for a checklist of features or capabilities their architecture might exhibit. The goal is to identify gaps or missing elements in the architecture to better rank the remaining priorities of the architectural initiative. The SOA Maturity Model should have levels similar to CMMI's (although there may be more or less than five), which serve as groupings of architectural features and capabilities that the architect can use to compare their progress to another company's, or to provide milestones for funding or executive buy-in purposes, or to guide their purchases of new software.

It is vitally important, however, for a SOA Maturity Model to measure the maturity of the architecture itself, not just its implementation. ZapThink has seen some so-called SOA Maturity Models that don't measure the maturity of architecture, but rather how advanced an organization's services are, or possibly how mature their runtime infrastructure might be. One such model gaining steam is the poorly named "SOA Maturity Model" from Sonic Software, Systinet, AmberPoint, and BearingPoint, which falls into this trap. It's a good model for measuring the maturity of the services an organization develops as part of its SOA initiative, but not for measuring the maturity of the architecture itself. As a result, this maturity model is really more of a services maturity model, as it fails to address architectural maturity.

What's In a SOA Maturity Model?

Another aspect of SOA maturity is how well a company leverages architectural models, in particular the service model that should represent both the services in production as well as the requirements from business for new or modified services. At lower maturity levels, companies may have no service model at all, or at best a sketchy model that serves as a limited design-time artifact. At higher levels, however, organizations leverage the service model at both design-time and runtime to represent services as they continue to evolve.

A third measure of SOA maturity that should find its way into the SOA Maturity Model is the scope of the application of SOA. At the lower levels, a SOA will often have pilot or departmental scope. As companies increase their SOA maturity, their application of SOA will typically spread across departments, and finally at the highest maturity levels, the application of SOA will be enterprisewide (or even multi-company).

A SOA Maturity Model may also contain measures of the maturity of the implementation of the architecture, as well. Clearly, a purely theoretical architecture is not likely to be as mature as one you've fully implemented, tested, and put into production. However, don't miss the forest for the trees -- a mature implementation is primarily a result of a mature architecture. Without measures of architectural maturity, a maturity model cannot be a true SOA Maturity Model.

Which SOA Maturity Model Should You Choose?

To help you decide where to turn for a SOA Maturity Model, it's useful to understand why various companies would create such a thing in the first place. Software vendors, for example, would create a SOA Maturity Model as a sales tool for their software. Such models will likely focus on capabilities their creators offer in their products, and deemphasize capabilities they don't do well (or don't offer at all).

Consulting firms, on the other hand, are likely to produce SOA Maturity Models that help them identify their clients' needs. Yes, such models also serve as sales tools to some extent, but no more so than any other assessment tool a consultant is likely to use, and they necessarily focus on customer value in any case. Professional services firms that offer comprehensive SOA consulting will produce SOA Maturity Models that are likely to be more complete than specialists who focus on one aspect of SOA or another. A good example of a reasonably complete model is the "Service Integration Maturity Model" from IBM Global Services.

A third place to look for a SOA Maturity Model is from an industry group. The advantage of such models is that they likely won't serve an alternate role as a sales tool, but on the downside, they will probably not be as complete or detailed as one coming from a consulting firm. You may also find analyst firms producing such models -- but those models will always promote the firm's particular spin on SOA. So be sure you buy into the analyst firm's overall SOA story before using their model.

Finally, you can always create your own. ZapThink has seen enterprise architects hammer out their own SOA Maturity Models, and such models have the clear advantage of being specific to each company's particular situation. However, such models will only be as good as the individuals who put them together. Strong architects tend to produce strong SOA Maturity Models, but weak architects, well, usually don't.

The ZapThink Take

This ZapFlash begs the question as to whether ZapThink will produce our own SOA Maturity Model. We might someday, to be sure, but we've found our SOA Implementation Roadmap to be at least as useful in helping companies understand the direction they must go to accelerate their SOA adoption as a proper SOA Maturity Model might be -- and arguably much more practical for many people. Our roadmap focuses on real-world advice for companies looking for a way to reduce the risk of implementing SOA. In fact, our 2003 Implementation Roadmap was so popular, we just published a new version of ZapThink's SOA Implementation Roadmap, available for free download today. If you run into us in person or take one of our certified training courses, be sure to ask for a print copy! But more importantly, help us focus the industry on producing practical SOA Maturity Models that don't simply serve to sell products or services, but help t o accelerate your successful adoption of SOA.