Zachmann.NET
SOA Cynic
SOA is a plausibly good and sometimes even useful idea that has been blown far out of proportion by various parties with their own axes to grind.
Based on the earsplitting buzz over the past year, you might get the idea that Service-Oriented Architecture (SOA) really is the Next Big Thing in information technology. If you buy the hype, you could be tempted to believe that SOA is, or at least ought to be, the key to future software development in the enterprise.
Nonsense! It's nothing of the sort. SOA is a plausibly good and sometimes even useful idea that has been blown far out of proportion by various parties with their own axes to grind, including:
- IT vendors who pour SOA as their own "special sauce" over their tired legacy solutions, which are more costly, cumbersome, difficult to use and tied into hardware and software platforms.
- IT guru firms that peddle high-priced snake oil as "expert advice" and use high-sounding, yet vague and obscure terminology to cloak the utter banality and limited practical value of what they're saying.
- IT seminar and conference promoters eager to jump on a hot trend to give corporate IT managers opportunities to play golf and drink at their employer's expense under the guise of learning about the next great IT technology.
- Corporate IT managers more keen on playing golf and drinking than actually doing anything to meet the real IT needs of the company that pays their salaries (and expenses).
Simply Stated
Kudos to whoever wrote the first sentence of the current article on SOA on Wikipedia! It states plainly, honestly and with refreshingly unpretentious candor:
"There is no widely agreed upon definition of service-oriented architecture other than its literal translation that it is an architecture that relies on service orientation as its fundamental design principle. Service orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users."
It's a good definition, but it defines a category so broad that it's of little practical use or consequence. Bottom line: SOA simply means designing application systems that create and access local or network services to meet the objective business needs of the enterprise. But this is, in fact, what most well-designed IT systems have been doing, one way or another, for decades. To claim (as does a recent Sun Microsystems document, "SOA RQ Methodology: A Pragmatic Approach") that "for most enterprises, SOA represents a paradigm shift," is ridiculous.
SOA is no paradigm shift. The underlying concepts and architectures are the same as those of minicomputer-based distributed systems in the '70s, PC-based distributed systems in the '80s, CORBA and COM/DCOM in the '90s, and JavaBeans and .NET today. The basic architectural ideas date back to the '60s. So what's the big deal with SOA today?
New Tool and Standards
The only real difference is the emergence of some reasonably good platform-independent XML-based standards that make it easier to build, expose, and consume network-based services. The underlying distributed architecture is not new. Only the more flexible, easier to use, standards-based means and tools to implement it are.
Visual Studio 2005's support for Web services with .NET 2.0/3.0 is a good example. It makes it easy to implement real SOA based on vendor-independent XML-based standards. It also offers the option to bypass the overhead of the full XML Web-services standards stack via .NET remoting when the critical issue is performance rather than interoperability. There's nothing in SOA that can't be done well with Microsoft tools and platforms.
This isn't what IBM, Sun, BEA and other SOA-savvy vendors would have us believe. These companies don't want us to notice that their claims about the unique advantages of their own SOA "special sauce," tied to their own tools and platforms, are readily available to us and easier to use -- generally at lower cost -- with Visual Studio and .NET.
One Among Many
The bottom line is that implementing SOA is a matter of good, modular, object-oriented design using -- when and where appropriate -- network-based services as sources of data and business logic. There's no mystery here.
SOA isn't and ought not to be a way of life -- or a required approach -- for all enterprise application system development. To use Web (or other) services in application development isn't a legitimate or even a useful end in itself. Like any other application-development pattern, SOA should be one of many recipes in a capable corporate developer's repertoire.
By all means, include real SOA in your range of options. If you get the chance, enjoy the cocktails and the golf! Don't, however, let yourself be beguiled into believing that it's really anything different from what you can already do quite well using Web services with .NET. It most certainly is not.
About the Author
William F. Zachmann, born before the modern digital computer was invented, has lived with them (and made his living off of them) all his life. He was director of research for The Forum Corp. in the mid-'70s and senior vice president of corporate research at International Data Corp. (IDC) in the '80s. He has a copy of Windows 1.0 that Bill Gates signed for him the night it was rolled out at Comdex Fall '85. Zachmann is now director of Canopus Research Inc. He programs in C# using Visual Studio 2005 with a focus on ASP.NET and SQL Server 2005.