Services Oriented Architecture is climbing the hype cycle. Amazon's S3 and Elastic Computing Cloud are exemplars of a brave new world of SOA. Modest success stories are making the rounds. IT folks are getting excited and starting to make promises they won't be able to keep.
This isn't going to end well.
Remember ILM? For several years storage vendors were beating the drum for Information Lifecycle Management. Simply classify data by its value over time to efficiently manage the data and its infrastructure. Who could argue with that? I did (see ILM is Bunk) and now, with SOA, here I go again.
ILM wasn't even a solution in search of a problem. It was a marketing idea spawned by storage vendors desperate to justify their costly and underutilized enterprise storage arrays.
Like ILM, enterprise SOA's business justification is theoretical, not practical Call me a Mammon-worshipping MBA, but there is no way for enterprise IT to monetize the advantages of SOA. Without that, it is game over. Although most people won't realize it for a couple of years.
Let me sketch it out why enterprise SOA is a hard sell:
Bottom line: don't bet your career on SOA.
The demand side of the equation Enterprise IT is a tax-supported institution. The tax is paid by the Lines of Business or LOBs. The LOBs would like to pay less in taxes, but only if their service levels are unchanged. The chance to save a few bucks isn't compelling.
If IT priced its services it could say to the LOBs "this new architecture is more efficient and will allows us to offer you more and better services at a lower cost. Interested?" Of course!
No way to show a return SOA is about providing services for applications. So how do you measure success? When does enterprise IT start getting cheaper? Or better? Under a taxation-based revenue model, never. Why? Because there is no way to measure success.
You invest in SOA upfront while the payoff waits for other applications to use the service, spreading the cost. Just as Object Oriented Programming failed to make reusable code work, the idea that generic "services" will be reusable is just as unproven. OOP code reuse failed because code contains implicit assumptions that other applications didn't share. Are services really so different?
SOA increases execution variability SOA assumes a data-flow architecture. New inputs drive new outputs. But what happens when a service goes down?
If an application is relying on a dozen independent services whose timing and delivery are dependent on a dozen different infrastructures, that application can only be as fast as the slowest service. At the very least application response time variability will grow. Ask yourself, "do my users want less variability or more?" I think you know the answer.
"They make you feel cool. And hey. I met you. You are not cool." Almost Famous Enterprise IT is not cool. High volume, low variability workloads can't be cool, because there is very little room for the playfulness - bopping iPod users! - that coolness requires. The internet data centers of Google, Amazon and MySpace are cool because they are pushing the computing envelope with radical architectures and clean-sheet designs.
In Amazon's case they are also monetizing a public SOA by selling it. The services are priced so businesses can figure out an ROI. Conversely, enterprise data centers are centrally planned economies like the old Soviet Union. How well did that work? Without prices for their services IT can never align themselves with their customer's needs.
The Storage Bits take SOA is fundamentally about making enterprise IT cool like the web, which is a lost cause. If you really want to change the culture of IT, start competing for LOB dollars. Put very granular prices on IT services. Give lower prices for computes and network bandwidth on nights and weekends. Charge higher prices during the end of quarter crunch. Make users pay more for a Fibre Channel I/O than an iSCSI one. The technology is there and is implementable today.
Prices aren't a perfect method of allocating resources, but they are the most effective tool we've got. SOA isn't the answer, just as ILM, OOP, client server and all the other nostrums peddled through the years weren't either.
Agree or not, let me know in the comments. I'll try to respond.