The Sweet Comfort of the Maturity Model

Not long ago I was talking with a colleague about various SOA implementations we had seen. On one in particular I commented that it was not a SOA but rather what I like to humorously call JBODMWS. That of course stands for "Just a Bunch of Discoverable, Managed Web Services". This is definitely better than what a lot of companies have, but I stressed that simply registering a bunch of web services from different departments and different lines of business does not a SOA make. Even managing the services centrally, while a significant step in the right direction does not qualify as SOA. In fact, what it qualifies for is exactly what I called it, JBODMWS.

My colleague maintained that it was indeed a SOA. This of course set me off on my lecture circuit on how SOA was not about creating a bunch of web services and registering and managing them. Its about composition and granularity and categorization and flexibility and, you know, all that other stuff. Once my colleague understood my argument he made the comment that to this day perplexes me. He said, "OK, I see. But it is still a SOA, its just a SOA maturity level 0."

What do you say that? I can't argue with it. Its not UNtrue. But it certainly isn't necessarily accurate. Needless to say our conversation ended then and there and I have been thinking about it ever since.

What is this monster we've created called the Maturity Model? Sure its useful and when used in the correct context it can be a very important measuring stick. But is that how it is being used? Are people comparing themselves against the model, determining where they stand and then making plans and preparations on how to get to the next level?

I'm afraid to say I don't think so. I think people are evaluating where they stand, finding they are at level 0 or level 1 and then forgetting about it. Did they do anything to get to level 1? Probably not. Maybe next time they evaluate themselves (or have some else do it) they will find they are at level 2. Great! But how did you get there. Did you mean to? What level will you be at the next time you evaluate yourself? Will you even do it again?

I think in reality the maturity model is being used as a blankey. You know the thing Linus had in the Peanuts. It seems to make people feel good about where they are. Consider the following:


Which makes you feel better?

- Your fat

OR

- Your skinny maturity level 0

To be fair, the blame needs to be spread just a bit. It is not just IT departments that are snuggling in the warmth of the maturity model. It is the consultants as well. Do you have the balls to tell someone they are not where they think they are? Or will you just tell them they are maturity level 1 and make them feel better.

Don't get me wrong, I am not saying to hell with maturity models. I'm just saying, don't let it be a passive artifact you warm up to in order to explain your current state. Let it be an active artifact that you are consistently measuring yourself against. Your plans should involve a strategy for achieving the next level. Only then will you be using the maturity model for what it was meant for.

Until next time,
This is Jason Henley, International Heartthrob... Maturity Level 0.

SOA, I could just K.I.S.S you! - Part 6

Welcome back. If you missed the first five parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance

Step 4 – Evaluate Your Infrastructure

Step 5 - Pilot Project

Step 6 - Wrap up
Wrap up.... Wrap up!! How can I just wrap it up now when there is so much left to do?

Well its simple (the theme remember). Much of what is left to do simply involves sticking to it. Learning at each step. Actually allocating some time to analyze services for compliance and reuse opportunity etc.

Now I realize that I've left out some huge pieces. Namely Business Process Modeling, Master Data Management, Service Design, Service Management, Orchestration, Security, Service Life Cycle Management, Service Versioning... I think I could go on for a while but I'll stop there.

These are all very important topics and things that you need to look at and address. The point I want to make is that you do not have to paralyze yourself by taking all of this on at one time.

I hate to say it because it feels like a give up but Rome was not built in a day, and assuming your SOA actually gets built, it will be no different.

At the very core of SOA, in my humble opinion, are very simple concepts not complicated ones, and while the solutions themselves are not always simple, keeping those simple concepts and goals in mind will help you see the solutions that are right for YOU!

SOA, I could just K.I.S.S you! - Part 5

Welcome back. If you missed the first four parts of this series, please follow the links below to start at the beginning.

Step 1 - Stake in the Ground

Step 2 - Education

Step 3 - Organizational Governance

Step 4 – Evaluate Your Infrastructure

Step 5 - Pilot Project

What more can one say about pilot projects. If you do a search right now for SOA Pilot Projects, you will find somewhere in the vicinity of 300 results, one of which is an article co-authored by MomentumSI's own Alex Rosen.

So to save time (mine) I will simply concede that there is not much more information I can add on this topic. I will therefore leave it at this:

1) DO A PILOT PROJECT!!!

2) Learn from said pilot project

3) Roll those lessons into your overall plan (if you need more infrastructure, now you at least have some data)

4) Finally, tackle another project only this time, do it better.

I'll close this wonderfully short entry by passing along some great advice I once read:

Lather, Rinse, Repeat... Ah the simplicity....
____________________
Next Step - Wrap up