Seven fallacies of SOA

Guest Commentary
Seven fallacies of SOA
by Jason Bloomberg, Senior Analyst, ZapThink, LLC

There is an old saw that says that there are two types of people in this world: those who divide the population into two groups, and those who don't. As absurd as this saying is, sometimes it seems that the discussion of Service-Oriented Architecture (SOA) falls into two categories: those who think that SOA is the best thing since sliced bread, and others who believe that SOA is nothing but hot air.

In fact, being the optimists and proponents of SOA that we are, some people believe ZapThink falls into the sliced bread category. On the contrary, we think that the overly sunny perspective is every bit as flawed as the overly cynical one. Refuting the fallacies that both extremes espouse, in fact, is a core part of our job at ZapThink. The truth about SOA rests between these extremes. Here, then, are seven popular fallacies of SOA -- both overly positive and overly negative, and ZapThink's counterpoint to each.

Fallacy #1: There's nothing new under the sun, and SOA is no exception.
SOAs have been around since the early nineties, most notably in the CORBA world, say the naysayers. CORBA had its problems, in spite of being an official standard and once being touted as the solution to heterogeneity in a distributed computing environment. Today's talk about SOA is nothing but old ideas warmed over. Who's to say that SOA won't suffer the same problems and setbacks of CORBA?

Counterpoint: It's true today's Web Services-based SOAs stand on the shoulders of CORBA. But there's no question that we're making significant progress. Just as object-oriented approaches solved many (but not all) of the problems with procedural techniques, Service-Oriented approaches will solve more problems. It's also important to remember that today's Web Services standards already have far broader industry and user acceptance than CORBA ever saw.

Fallacy #2: SOA is a revolutionary paradigm shift
SOA is unlike any architecture that came before, says the SOA fanatic. SOA is an entirely different approach to distributed computing, and once companies adopt SOA, they'll never do things the old way again.

Counterpoint: When Thomas Kuhn coined the term paradigm shift in the context of scientific revolutions, he had a much broader, deeper set of changes in mind -- think the industrial revolution or the information revolution. In fact, the latter is the actual paradigm shift we've made: the shift to an information-based economy and more broadly, an information-based civilization.

SOA, however, is more evolutionary than revolutionary. As pointed out in Fallacy #1, we're making progress by doing similar things as before, only better. That's not a paradigm shift, but it is an important shift nevertheless. SOA evolves enterprises' approach to distributed computing and improve on its implementation, but SOA doesn't represent the sort of disruptive, revolutionary change that would qualify it as truly revolutionary.

Fallacy #3: SOAs are all hype, no substance
The doom-and-gloomers are quick to point out that far more companies are talking about SOA than implementing it. Is it possible that the core tenets of SOA that ZapThink loves to talk about, like loose coupling and coarse granularity, are easy to talk about but too difficult to implement in practice? Is SOA just a fad, to go the way of leg warmers, 8-track tapes, and low-carb diets?

Counterpoint: Clearly, implementing an SOA that realizes all the benefits that ZapThink espouses is difficult. While not a paradigm shift, moving to SOA is still a challenge for many companies' operations, both in IT and line-of-business. Furthermore, many of the underlying standards are still incomplete, products are immature, and best practices have not been fully established. SOA adoption will take time. But make no mistake -- hundreds of enterprises are already running successful SOAs today, and thousands more are on the SOA implementation roadmap. There is more SOA activity going on in companies large and small than many people realize. Departmental developers and product managers are slowly introducing Web Services and SOAs into their projects to solve, at first, tactial problems. As these Services increasingly gain widespread notice, many firms will be compelled to implement SOA as a side-effect of the success of their Services.

Fallacy #4: SOA is a panacea
Is your IT environment not doing everything you'd like? Don't worry, SOA will fix it. Once everybody has an SOA, the world's problems with IT will be a thing of the past. Furthermore, everybody should have an SOA everywhere in their IT organization. SOAs can solve all forms of integration problems, and can be used for all distributed computing scenarios.

Counterpoint: As explained in an earlier ZapFlash, SOA is particularly useful in heterogeneous environments that are subject to frequent changes in the business environment. Is your business environment stable? Is your IT environment homogeneous? Then SOA is probably not for you. Is high performance more important than loose coupling? In other words, would you rather tightly control the consumers of IT functionality in your organization in order to squeeze every last bit of performance out of your technology? Then SOA isn't right for you, either.

In fact, even for companies that can benefit from SOA, there's no reason to throw the baby out with the bathwater and assume that the only architecture you need will be SOA. After all, SOA works well with other architectures, so if something else is working for you, then leave it alone. Furthermore, SOA by itself doesn't solve information and semantic integration challenges -- companies need additional technology approaches to solve these more challenging problems.

Fallacy #5: The overhead from SOA leads to unacceptably poor performance
XML is bad enough, but add the overhead of Web Services and SOA, and you've gone from bad to worse, goes this line of reasoning. Verbose and text-based, XML-based Web Services eat up bandwidth and processing power. Moving an entire architecture to XML is bound to clog the network, choke application servers, and fill up even the largest hard drives. And if that weren't bad enough, what about large SOAP payloads and other large XML messages? Since Web Services should be coarse grained, some messages might be 100 megabytes in size or even larger. The growth of SOA will surely swamp the corporate network.

Counterpoint: There's no question that XML in general, and Web Services-based SOAs in particular, can lead to performance bottlenecks, especially at the network level. But such bottlenecks are problems that have solutions. After all, Moore's law and its corollaries are still with us -- processor power, network speed, and storage size are all increasing exponentially even as their costs drop.

Even so, proactively dealing with increased XML traffic requirements (not just performance, but security and routing as well) is something that ZapThink strongly advises. No longer can the network folks, the operations personnel, and the applications team work independently. They must come together to understand the issues that SOA raises, and address them head-on. In fact, these issues have given rise to an entire marketplace of XML appliances that each address some combination of today's XML traffic and processing requirements.

Fallacy #6: A bottom-up approach to SOA is good enough
A Web Service here, a Web Service there, and pretty soon you have an SOA. Build enough Web Services, and make sure they are secure and managed, and that's all you need to do to build an SOA.

Counterpoint: SOA is architecture, and architecture is a set of best practices and patterns -- in other words, SOA is a discipline. Building Services is tantamount to making sure all your blocks are Legos, but you can't build Legoland with nothing more than a box of Legos, no matter how big your box is. You also need a plan, as well as the required expertise. Just so with SOA. The best approach to building an SOA is to combine a bottom-up approach of building Services that solve integration problems with a top-down, architectural approach that provides process-driven Services that enable business agility.

Fallacy #7: SOA is optional
So, if SOA doesn't solve every problem, and SOA is more evolutionary than revolutionary, and SOA won't replace all of the other architectures I have in my IT environment anyway, then maybe I'll never need an SOA.

Counterpoint: For many companies, most notably those larger companies whose IT organizations have a certain critical mass, it's not a question of whether to build an SOA, it's a question of when. As ZapThink discussed in our last ZapFlash, we're nearing the tipping point for Web Services adoption in the enterprise. Companies are realizing both the tactical and strategic benefits of Web Services and SOA, and as companies implement an increasing number of useful Services in the enterprise, their hands will be forced to tackle more significant architectural challenges. Once we cross that nebulous point, the sheer volume of Services on the network will force companies to tackle SOA, one way or another. You won't need SOA everywhere, they won't solve every problem, and many companies will build poor, ineffective SOAs to be sure, but build them they will.

The ZapThink take
The best advice ZapThink can give people who are considering SOA is to tackle such an initiative with your eyes open. While SOA isn't all hype, there's no question there's plenty of hype out there -- exaggerating SOA's strengths as well as its weaknesses. Always remember that SOA is challenging and often quite risky, so solid education, thorough preparation, and a careful approach are all important. But also remember the promise of SOA -- building an IT infrastructure flexible enough to respond to the needs of the business. With a value proposition as broad and strategic as that, it's easy to accept that SOA is inevitable.

For more information:

• Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
• Are you tired of technospeak? The Web services Advisor column uses plain talk and avoids the hype.
• For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
• Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.

• Visit our huge Best Web Links for Web services collection for the freshest editor-selected resources.
• Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
• Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
• Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
• Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.