Contact me!

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 e-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: services, a service registry, some form of orchestration, data transportation and transformation (whether done with an ESB or not), persistence, authentication and authorization, administration, event notification, business intelligence, and governance.

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 potentially valid points. The thing is, I’m not really all that concerned about what true SOA should be, but whether or not SOA, pieces of SOA, or something entirely different is the most appropriate technical solution to a 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. Recently I’ve attended a number of strategy sessions to come up with an SOA migration path for our department.

To me, this is what SOA is not: a silver bullet, an easy way to pay off years of accumulated technical debt, the answer to all your prayers, a way to double your business in 24 hours, a way to get rich quick, the magic diet that will help you lose weight but still allow you to eat as much pie as you want, something you have to deliver. Yet, when I speak to 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, 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. But wiring them together to accomplish a specific business objective is complicated, especially when crossing organizational boundaries. From my (albeit limited) SOA experience, the most difficult aspect of an SOA project is governance, and 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: reduce support costs; prepare for increased usage; provide a new business feature that would generate X number of new customers; generate 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 bad word sooner or later. Next time someone mentions SOA, focus less on the acronym and more on the spirit of what you’re trying to accomplish. Paying attention to the latest and greatest buzz is important, but just be careful not to commit “design by buzzword”.

Oh, and if you think an ESB is going to solve all your problems, I’ve got some magic beans to sell you.