What makes SOA hard

I've been following a series of posts, most recently one by Todd Biske from Momentum SI, discussing what the phrase, "It's not about the technology," means in the context of SOA, since so many people use it.

The discussion has centered on whether this means "it's not about the technology alone" or whether it means "the technology doesn't matter" (i.e. you can architect without thinking about implementation).

Frankly, though, when I talk with people about SOA infrastructure, neither of these explanations fits the bill.  What I'm told is that "It's not about the technology... it's about the organizational change" -- that is, the hardest thing about succeeding with SOA isn't the technology (not even close), it's about the organizational transition that's required to truly embrace SOA.

Said another way, even if you get the technology perfect, if the organization isn't structured to be successful with SOA your SOA initiative will fail.  On the other hand, if you get the organization changes right, any technology failures will only be transient -- the organization will rebound and adapt.

This, of course, immediately leads to the next question: What organizational transition is needed to be successful? Here's my take on it...

Many 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.

These types of organizations haven't adopted SOA as core to their culture, and so their SOA initiative will either fail completely or hit an early "glass ceiling" (where they barely achieve a small fraction of the benefit they assumed).  Why? 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 posting, it should be 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 truly achieve the benefits of SOA requires that an IT organization change its 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 have been first to break through the SOA glass ceiling 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.

SOA What? The nature of a service delivery culture has many side effects that do impact IT and your technology choices of course.  For example, how do you measure the value you deliver to others (by customer revenue impacted, by number of transactions, by number of users, etc.), how do you ensure you are  providing the quality of service they expect (availability, performance, etc.) and how do they pay you for it (e.g. cross-charges, transfer payments, etc.) -- but your technology choices here will be irrelevant if you don't get the organizational transition moving along the right path.