10th of August, 2009
Don’t get me wrong, I think the spirit of SOA is fantastic. Adaptable, flexible, maintainable, loosely-coupled applications supported by open governance, strong relationships between business and technology folks, and co-operation across all silos and levels of an organization. What’s not to love?
SOA has become one of the most commonly-heard buzzwords around the water-cooler over the past few years. It seems like everyone is talking about SOA these days. Architects, developers, business folks, management, non-management, and everyone in-between. I hear about SOA more than I hear about AJAX and Web 2.0 put together. I wouldn’t be surprised if my Dad calls me up out of the blue to chat about SOA — and he sells shopping carts, the real ones made of metal, not the electronic ones.
I love nothing more than applying an elegant solution to a difficult problem, but I’m concerned when a misunderstood solution is applied to an unknown problem.
At the root of SOA are some extremely useful technologies. An average SOA stack includes:
You may disagree with my above list.
Are you kidding, ESB is SOA!
Why didn’t you mention Quality of Service?
Are you sure you mean orchestration, or do you mean choreography?
Those are all potentially valid points. The thing is I’m not really all that concerned about what SOA should be, but whether or not SOA, pieces of SOA, or something entirely different is the most appropriate technical solution to a given business opportunity.
I’m by no means an SOA expert. I’ve been involved in a number of WS initiatives, and one project with the SOA label applied to it. I also spent a month attending training sessions provided by Software AG on their webMethods product. I’ve also attended a number of strategy sessions to come up with an SOA migration plan for our department.
Yet, when I speak with friends and colleagues about SOA, this is how it’s being communicated. Interestingly enough, in some cases it’s being pushed by business rather than the technical staff. At first glance this may sound reasonable; after all, it’s a good thing for a business case to exist when spending millions of dollars. But the scary thing is the way it’s being marketed.
Company X just unveiled their SOA solution, so we need one to stay competitive.
If you take a look at the technology stack I listed above, none of the concepts or technologies are particularly complex or difficult to implement on their own, but wiring them together to accomplish a specific business objective is definitely complicated; especially when crossing organizational boundaries. Based on my limited SOA experience, I believe the most difficult aspect of a SOA project to get right is governance. It’s the one that I’m shocked to see so overlooked.
Is true SOA simply too ambitious for most companies to deliver? Is it a clash of paradigms? Most organizations undertaking SOA initiatives are, at their heart, stove-piped; siloed departments with siloed applications and processes. Can an architecture whose goal is to promote rapid adaptation to changing business conditions and flexibility work in an organization whose entire structure is reluctant to adapt and inflexible by nature? These are questions I can’t answer, but questions I’m surprised more people aren’t asking.
My opinion is this: unless the stakeholders of an SOA initiative can provide clear and reasonable ROI estimates at specific milestones of an SOA migration, the project is most likely doomed to failure. If I bought a bus ticket and the destination read, “you’ll know when you get there”, I’d ask for a refund.
Unfortunately, SOA itself will be blamed for the failure of SOA initiatives. Until the SOA buzzword became so hot I’d never heard of a project funded without specific business objectives, such as reducing support costs, preparing for increased usage, providing a new business feature that would generate x number of new customers, generating x amount of new revenue per customer, and so forth. On the flip side, I’ve chatted with a number of friends who are involved in SOA projects and most of them can’t figure out what the actual, concrete, measurable goals of their SOA initiatives are.
I think SOA will become a dirty word sooner or later. Next time someone mentions SOA, focus less on the acronym and more on the spirit of what they’re trying to accomplish. Paying attention to the latest and greatest buzz is important, but just be careful not to commit design by buzzword.