SOA Maturity Model

David Linthicum recently re-posted his view on SOA maturity levels and I wanted to offer up an alternative view, as I’ve recently been digging into this subject for MomentumSI.

Interestingly, Dave calls out a common pattern that other models he’s seen define their levels around components and not degrees of maturity. He states:

While components are important, a maturity model is much more important, considering that products will change over time…

I completely agree on this. Maturity is not about what technologies you use, it’s about using them in the right way. Comparing this to our own maturity, just because you’re old enough to drive a car, doesn’t mean you’re mature. Just because you’ve purchased an ESB, built a web service, or deployed a registry doesn’t mean you’re mature.

Dave then presents his levels. I’ve cut and paste the first sentence that describes each level here.

  • Level 0 SOAs are SOAs that simply send SOAP messages from system to system.
  • Level 1 SOAs are SOAs that also leverage everything in Level 0 but add the notion of a messaging/queuing system.
  • Level 2 SOAs are SOAs that leverage everything in Level 1, and add the element of transformation and routing.
  • Level 3 SOAs are SOAs that leverage everything in Level 2, adding a common directory service.
  • Level 4 SOAs are SOAs that leverage everything in Level 3, adding the notion of brokering and managing true services.
  • Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration.

While these levels may be an accurate portrayal of how many organizations leverage technology over time, I don’t see how they are an indicator of maturity, because there’s nothing that deals with the ability of the organization to leverage these things properly. Furthermore, not all organizations may proceed through these levels in the order presented by Dave. The easiest one to call out is level 5: orchestration. Many organizations that are trying to automate processes are leveraging orchestration engines. They may not have a common directory yet, they may have no need for content based routing, and they may not have a service management platform. You could certainly argue that they should have these things in place before leveraging orchestration, but the fact is, there are many paths that lead to technology adoption, and you can’t point to any particular path and say that is the only “right” way.

The first difference between my efforts on the MomentumSI model and Dave’s levels is that my view is targeted around SOA adoption. Dave’s model is a SOA Maturity Model, and there is a difference between that and a SOA Adoption Maturity Model. That being said, I think SOA adoption is the right area to be assessing maturity. To get some ideas, I first looked to other areas, such as CMMI and COBIT. If we look at just the names of the CMMI and COBIT levels, we have the following:

0 Non-Existent
1 Initial Initial
2 Managed Repeatable
3 Defined Defined
4 Quantitatively Managed Managed
5 Optimizing Optimized

So how does this apply to SOA adoption? Quite well, actually. COBIT defines a level 0, and labels it as “non-existent.” When applied to SOA adoption, what we’re saying is that there is no enterprise commitment to SOA. There may be projects out there building services, but the entire effort is ad hoc. At level 1, both CMMI and COBIT label it as “Initial.” Again, applied to SOA adoption this means that the organization is in the planning stage. They are learning what SOA is and establishing goals for the enterprise. Simply put, they need to document an answer to the question “Why SOA?” At level 2, CMMI uses “Managed” and COBIT uses “Repeatable.” At this level, I’m going to side with CMMI. Once goals have been established, you need to start the journey. The focus here is on your pilot efforts. Pilots have tight controls to ensure their success. Level 3 is labeled as “Defined” by both CMMI and COBIT. When viewed from an SOA adoption effort, it means that the processes associated with SOA, whether it be the interactions required, or choosing which technologies to use where, have been documented and the effort is now underway to extend this to a broader audience. Level 4 is labeled as “Quantitatively Managed” by CMMI and “Managed” by COBIT. If you dig into the description on both of these, what you’ll find is that Level 4 is where the desired behavior is innate. You don’t need to handhold everyone to get things to come out the way you like. Standards and processes have been put in place, and people adhere to them. Level 5, as labeled by CMMI and COBIT is all about optimization. The truly mature organizations don’t set the processes, put them in place, and then go on to something else. They recognize that things change over time, and are constantly monitoring, managing, and improving. So, in summary, the maturity levels I see for SOA Adoption are:

  1. Ad hoc: People are doing whatever they want, no enterprise commitment.
  2. Common goals: Commitment has been established, goals have been set.
  3. Pilot: Initial efforts are underway with tight controls to ensure success.
  4. Extend: Broaden the efforts to the enterprise. As the effort expands beyond the tightly controlled pilots, methodology and governance become even more critical.
  5. Standardize: Processes are innate, the organization can now be considered a service-oriented enterprise.
  6. Optimize: Continued improvement of all aspects of SOA.

You’ll note that there’s no mention of technologies anyway in there. That’s because technology is just one aspect of it. Other aspects include your organization, governance, operational management, communications, training, and enterprise architecture. SOA adoption is a multi-dimensional effort, and it’s important to recognize that from the beginning. I find that the maturity model is a great way of assessing where an organization is, as well as providing a framework for measuring continued growth. That being said, your ability to assess it is only as good as your model.

8 Responses to “SOA Maturity Model”

  • Hong S Kim:

    Maturity in the real world should be accompanied by ROI matter. I hope that ROI and maturity model be expressed in near future.

  • You may have missed the point entirely in an effort to promote your own views Todd. Also, you may want to Google the larger paper I wrote on this topic, it’s a bit more comprehensive, albeit old. Indeed, you’re taking a different approach, and I actually have a model for that as well. Seem like you’re CMMing SOA. Which is logical, in some respects, but that’s not why I’m posting.

    “The easiest one to call out is level 5: orchestration. Many organizations that are trying to automate processes are leveraging orchestration engines. They may not have a common directory yet, they may have no need for content based routing, and they may not have a service management platform.�

    Not really accurate Todd.

    Just so we are clear, I indeed am saying that there is the notion of maturity within these levels. So, if you have an orchestration layer, Level 5, than you should have all of the levels below it. For instance:

    “Finally, Level 5 SOAs are SOAs that leverage everything in Level 4 [and levels 3, 2, 1, and 0], adding the notion of orchestration.�

    This includes “content-based routing� and “service management.�

    Thus, there is a dependency on the more primitive which is built into the model. Very much like the concepts you’re putting forth, but the approaches are a bit different.

    Just thought I would clear that up, and good blog topic for the morning.

    Dave Linthicum

  • Thanks for your comments Dave. I appreciate the discussion, as I think healthy debate is good for the community. I don’t think I missed your point, I just disagree with it. While there may seem to be a logical progression of how technology should be leveraged, the fact that a company does it in a different order doesn’t make them less mature. What matters is that they use it appropriately.

  • […] I just finished giving a webinar on the importance of SOA pilots with Alex Rosen, and I hope the attendees found it informative. One of the things that I discussed in the webinar was the scope of SOA adoption. Given the recent attention to my last post, I thought I’d discuss it a bit more, since it’s one of the two dimensions of the maturity matrix. It’s also what makes the effort more than just a “search and replace” on the SEI CMMI models as one commenter over on InfoWorld thought. […]

  • […] I would never expect a positive ROI on a pilot project. Pilots should be run with the expectation that there are still unknowns that will cause hiccups in the project, causing it to run at a higher cost that a normal project. A pilot will then result in a more standardized approach for subsequent projects (the extend phase in my maturity model discussions) where the potential can be realized. Pilots should be a showcase for the potential, but they may not be the project that realizes it, so be careful in what you promise. […]

  • […] SOA Maturity Model: This post on February 15, 2007 opened up a short-lived debate on maturity models, but this is certainly a topic of interested to many enterprises. […]

  • […] a five level maturity approach that sounds very similar to what I’ve discussed in the past (here, […]

  • […] covers eight different dimensions. The maturity model has familiar levels if you’ve looked at my work, CMMI, or COBIT. Level 1 is ad hoc, level 2 is repeatable, level 3 is defined, level 4 is […]

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.