InfoQ

InfoQ

InfoQ

En | 中文 | 日本語 | Br

592,113 Apr unique visitors

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

SOA Maturity Models

Posted by Stefan Tilkov on Feb 22, 2007

Sections
Enterprise Architecture,
Process & Practices,
Architecture & Design
Topics
Maturity Models ,
SOA ,
Adoption ,
Methodologies ,
Programming ,
Architecture ,
Enterprise Architecture ,
Agile

Many large organizations consider adopting SOA, and many of them decide to actually do so. But once that decision is made, how do you proceed? A reasonable strategy is to assess your current status, decide on where you want to go, and build a road map from there. To do so, many are looking for help in the form of maturity models. A maturity model defines a number of levels an organization can be one with regards to … and here the debate starts.

An interesting discussion has recently taken place between Dave Linthicum and Todd Biske. In a blog entry, Linthicum described his maturity model, which contains the following “levels” (in brief):

  • 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.
  • Finally, Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration.

Biske does not agree that this approach is the right one for assessing maturity:

The first difference between my efforts […] 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.

In a posting to the Yahoo! SOA discussion group, Dennis Djenfer provided a useful list of (more or less publicly available) maturity models:

As enterprise-scale SOA adoption is still not very frequent, it’s hard to assess the value of any particular model, since they’re neither proven in practice, nor (in general) derived from significant number of particularly successful SOA efforts.

What are you’re experiences using SOA maturity models? Did you use any of these, did you define your own or do you consider them a waste of time?

  • This article is part of a featured topic series on SOA and also Agile

9 comments

Watch Thread Reply

If you use TIBCO you are automatically at Level 5 by Prashant Rane Posted
Re: If you use TIBCO you are automatically at Level 5 by Stefan Tilkov Posted
Non-technical aspects by John Harby Posted
Re: Non-technical aspects by Todd Biske Posted
Real case by Carlos Rodriguez Posted
Maturity Models concepts by Kunal Mittal Posted
Re: Maturity Models concepts by Stefan Tilkov Posted
Another one to add to the list by Todd Biske Posted
Capability based maturity model by jun yang Posted
Sort by date descending

  1. Back to top

    If you use TIBCO you are automatically at Level 5

    by Prashant Rane

    You can go from Level 1 to 5 or just use a product that let's you have all 5 levels to start with.

    Reply

  2. Back to top

    Re: If you use TIBCO you are automatically at Level 5

    by Stefan Tilkov

    But having a capability is different from actually using it ... just because a buy a middleware product doesn't mean I have transitioned all my applications to it.

    Reply

  3. Back to top

    Non-technical aspects

    by John Harby

    It's cute but what about all of these non-technical SOA aspects we keep hearing of, governance, etc? Also, I would suspect most organizations will immediately get the functionality of Level 5 for some services then spend time maturing all of their enterprise applications into this architecture.

    Reply

  4. Back to top

    Real case

    by Carlos Rodriguez

    Well, we first are in level 0, then we go to level 3 because we added UDDI to the architecture. Then, we go to level 4 and 5 because we use bpel and we manage our services with X applications. After that, we go to level 2 (because use transform with xslt for integracion with other systems.). We dont use queueing and dont use routing. Are we on level 5 or are not. I think that it is levels of Adoption or recommendations of adoption or ...

    But it is a good idea for thinking about Level of Madurity and recommendations of Adoptions.
    It could be firsts steps. (discutions is good practice to make good knowlegde)

    Reply

  5. Back to top

    Maturity Models concepts

    by Kunal Mittal

    I don't believe Maturity models should be based on technologies. Let us not forget the CMM. It is about process. In SOA, I would apply the concept of a maturity model to process, architecture, governance and policies.

    BTW - the link to my maturity model listed above it incorrect. Please read my maturity model at
    www.kunalmittal.com/html/soamm.shtml

    Reply

  6. Back to top

    Re: Maturity Models concepts

    by Stefan Tilkov

    Thanks Kunal, I've fixed the link.

    Reply

  7. Back to top

    Re: Non-technical aspects

    by Todd Biske

    John, have a look at these entries on my blog that discuss my work. You'll find that technology is only one dimension of the maturity model (and even within that dimension, it's more focused on appropriate use, rather than what you have). Other dimensions include approach & governance, organization, operational management, architecture, and communications & training.

    www.biske.com/blog/?p=128
    www.biske.com/blog/?p=129

    -tb

    Reply

  8. Back to top

    Another one to add to the list

    by Todd Biske

    I just came across this work from Microsoft on Enabling the Service-Oriented Enterprise. It has another maturity model to add to the discussion.

    msdn2.microsoft.com/en-us/library/bb245664.aspx

    -tb

    Reply

  9. Back to top

    Capability based maturity model

    by jun yang

    I like the model from Microsoft better because it addresses the key challenges of adopting SOA in large enterprises -- capability. Just like any other popular technologies before SOA, once it becomes popular, everybody wants to jump to the bandwagan without even understanding what a service is and forgive my rudeness, most of them don't even have background on computer science.

    Reply