The Rumors of SOA’s Demise…

OK, everyone, calm down. SOA isn’t dead, in fact, it isn’t even sick. Thousands of organizations are showing real success with SOA around the world, and more are ramping up their SOA efforts every day. Even in today’s economy, plenty of smart organizations realize the cost savings and agility benefits of SOA warrant continued investment in the approach, even in times of tightening belts.

So, why the consternation? Well, if you haven’t been paying attention to the SOA blogosphere for the last few weeks, you missed the firestorm that Anne Thomas Manes from the Burton Group caused with her “SOA is Dead” blog post. In the intervening time, virtually every SOA pundit has pitched in on this topic. However, due to the biweekly nature of our ZapFlash newsletter, ZapThink is in the enviable position of batting cleanup on this issue.

What amazes us most of all about the “SOA is dead” controversy is that there’s nothing new here. In fact, the core themes of both Manes’s comments and the reactions to those comments have been themes in ZapThink’s writings for several years now. So, in an effort to move past the noise and provide a post mortem of sorts — not on SOA itself, but rather on the “SOA as dead” meme — let’s review the relevant ZapThink insight on this topic:

• Calling a project SOA isn’t as important as solving real business problems. (Avoiding Bad SOA, March 1, 2005). In fact, the term “SOA” often gets in the way. Instead, both business and technical people should work to communicate using a common language of Service Orientation that’s neither entirely business-centric or technically oriented (The Third Conversation, April 16, 2007).
• SOA is part of a larger trend toward location independent, loosely coupled computing — a trend that includes Cloud Computing (The Buckaroo Banzai Effect Location Independence, Service-Oriented Architecture, and the Cloud, and Goodbye 2008… Here we Come, 2009!).
• SOA is a loose collection of best practices, and as organizations more broadly adopt these best practices as SOA becomes mainstream, then people will talk about SOA less (Thinking Outside the SOA Box, November 15, 2006). In fact, we’re seeing this trend now.
• SOA has a clear, specific definition, (Forensic SOA, April 29, 2008) even though there’s still confusion on this point, in large part because vendors are sowing misinformation (Avoid Vendor-Driven Architecture (VDA)!, September 20, 2007.)
• SOA is especially important now that we’re in a downturn, as long as you’re able to realize the cost savings and agility benefits short-term (Investing in SOA in a Down Economy, January 8, 2008). While tightening budgets will lead to the cancellation of some SOA projects, numerous organizations are succeeding with SOA, and as a result, realize the importance of continuing their SOA investment.
• Certain industry analysts are lowering the chance of success for SOA initiatives, especially the ones who would rather define markets and rank vendors than uncover and communicate best practices (Who’s Killing SOA?, October 1, 2007).

The most important thread that winds its way around all of these principles is the perspective that SOA consists of best practices. The problem is, best practices are slippery things, for a few reasons. First, they describe human behavior — the proverbial SOA as something you do, not something you buy. Second, among all the various practices an organization might undertake, only a relatively small subset are the best ones, and which ones are best changes over time as people figure out new ones.

The Challenge of Best Practices
There is no hard and fast rule as to which best practices are SOA, and which are not, because best practices are problem-dependent, not terminology-dependent. In other words, which business problems you’re trying to solve will in large part determine which practices are best for that particular situation, a classic example of the right tool for the job. SOA best practices don’t solve all problems, and for any given problem that SOA might be appropriate for, there’s a good chance that some of the best practices that the situation calls far aren’t specifically SOA best practices.

One way of looking at this problem is that there are best practices for how to apply best practices. Just because your SOA textbook says you should do something doesn’t mean that you should do that thing in every situation. On the contrary, what distinguishes a good architect is the knowledge of when not to apply a particular practice, even if that practice might be a best practice in a different situation. When we list SOA best practices — leveraging the intermediary pattern to build loosely-coupled Services, governance best practices like those for Service versioning or reuse, etc., we’re not expecting everyone to apply all of them in every situation.

In fact, the belief that to do SOA right you have to do some fixed set of things every time is a fallacy. Belief in this fallacy, unfortunately, is still quite prevalent, and turns SOA into a straw man. Virtually all failed projects with the name “SOA” failed because the organization didn’t properly apply best practices. In other words, they weren’t really doing SOA at all, because SOA consists of best practices, and what they were doing consisted of practices that clearly weren’t the best.

This point brings us back to the “SOA is dead” meme. Solving business problems the best way available isn’t dead, of course, and never will be. But misapplying practices under the name of SOA can’t die soon enough, especially in tight economic times. Organizations simply cannot afford to waste money doing things they think are SOA, but aren’t.

Should you Call your Initiative “SOA”?
If you are following best practices, then using the “SOA” label is, yes, a best practice if there’s a good reason to do so. For example, if there’s understanding and support for SOA among business stakeholders, then calling the initiative SOA will help firm up that support. Such stakeholder understanding is by no means guaranteed, however. In many cases, the best name for your SOA initiative is a name that ties the project to the business problem you’re addressing. Some of the most successful SOA projects go under names like “Sarbanes Oxley compliance initiative” or “improved customer visibility” or some other phrase that ties the effort to the solution it promises to deliver.

If your organization isn’t following best practices, however, then calling your project “SOA” isn’t going to help — but then again, you have bigger problems. These are the situations where the SOA moniker is a straw man: “I was doing X, I called X SOA (even though it wasn’t, since it wasn’t best practices), and it failed — therefore SOA failed.” Well, we don’t have the time or money to play such games any more. SOA isn’t dead — what’s dead is the fake SOA straw man.

The ZapThink Take
While some of you were no doubt taken aback by the “SOA is dead” conflagration, my guess is that far more of you looked on with more of a sense of bemusement. After all, we talk to dozens of architects every month who are showing real successes with their SOA initiatives, and no single blog post will cause them to rethink their approach to architecture. Sure, there are challenges, and the tight economy isn’t making life any easier, but nobody is trying to tell you to stop doing what you are doing if it’s working for you.

We’re so used to all the hype around SOA that now that SOA is becoming mainstream, the decrease in the hype is both refreshing and possibly worrying. After all, shouldn’t we all be working on the next big thing, be it cloud computing or something else? The fact of the matter is, the answer is no! We should seek to have a laser focus on addressing business needs, and we shouldn’t let hype, or the absence of it, steer us astray.

The “SOA is dead” meme, in fact, might be thought of as a kind of “anti-hype” — which is really just more hype. If SOA really were dead, then either SOA isn’t best practices (the straw man), or best practices are dead, which is just plain silly. Focus on the business problems at hand, apply true best practices to those problems, and ignore the hype, and you will inevitably be successful in your endeavors — regardless of what you call them.