By now there are lots of different "maturity models" for SOA - virtually every vendor and analyst has one (which isn't surprising). What is important, though, is that all of these are pointing to the same thing: most companies adopting SOA are hitting a glass ceiling they can't get beyond, regardless of which maturity model you look at.
Most are getting stuck at the same place -- at the levels of the model below where business value and alignment are anticipated.
What's causing this? Here's my take on it...
Fundamentally these organizations are treating building SOA services the same way they treated building applications: As a product delivery. That is, you roll out a service, and at a later date (6, 9, 12 months later) you roll out the next version, and the software development lifecycle continues.
The issue is that these organizations are getting confused about what the "S" in SOA means. It doesn't mean "service" as in "SOAP interface" or "web service" or "technical service"; it means "service" as in "customer service" or "service industry" or "software as a service".
If you only take away one thing from this blog its that in SOA you don't build services, you deliver services.
This is the difference between Siebel and salesforce.com. Product delivery is very different from service delivery. To break through the SOA glass ceiling requires that an IT organization change it's culture from a construction culture to a delivery culture. Unfortunately IT organizations are used to building applications for the business, shipping them, and going on to the next (typically) unrelated thing to build. This is, no doubt, a hard change and not every organization is going to be able to make the change.
The organizations that are first breaking through the glass ceiling of SOA are ones that already have a service delivery culture; Whether it's information service providers like Standard & Poors, or travel service provides like Starwood Hotels they have one thing in common - delivering services is in their blood and so more easily filters down into IT.
To raise awareness of this, I think we as an industry, need to coin a new term like "service as a service" because it's the industry that created the confusion in the first place by misusing the term service, so it's up to us to fix the problem we created. But we must go further: The "software development lifecycle" is already well defined, but we need to define what makes the "service delivery lifecycle" different (and it's definitely not just the same SDLC on a smaller scale).