From time to time, I find myself lassoing a sacred cow in this Editorial space, dragging it over to the slaughterhouse of rhetoric, and ultimately barbecuing its falsehood over the stainless-steel, six-burner, propane-powered grill of real-world experience. To wit, the current industry obsession with SOA as a panacea for every information system ill from performance to security is, in my humble opinion, a phenomenal load of crap.

Now, please don't misunderstand me. I am not saying that there isn't a myriad of benefits to be derived from exposing systems' functionality for access by other automated systems simply by passing XML across industry-standard networking protocols such as HTTP and TCP. Web services are great! If you have to interoperate with non-Microsoft systems, they may be your only option. If you are building a system today and you suspect that some other system might want to tap into its functionality at some point in the future (hint: you can almost always safely assume that this will happen at some point), then you are wise to architect in a way that will lend itself to exposure via Web services.

What I do not buy into is the idea that all systems should be seen either as services that expose their functionality only via unidirectional XML messaging or as clients of such systems. Specifically, I don't think that all of our problems will be solved if we move in this direction as an industry, nor do I think that such an approach is without colossal problems of its own.

What problems have I seen at clients that have tried this? To begin with, the move to asynchronous system operations requires a massive change in thinking on the part of most developers. Having a separate Architect role on a team can offset a lot of this difficulty by allowing just one individual to orchestrate how a set of discrete, asynchronous services can be aggregated into various useful systems.

Versioning and reliability are two problems that are more tactical, and in some ways harder to resolve. If one considers the move from COM to .NET, for example, one of the major problems that .NET was intended to solve was the so-called "DLL Hell" versioning conflicts that were common in the days of COM. Many of these problems return with a vengeance when one begins to rely heavily upon external Web services, because a change in a Web service that is beneficial to one system may be quite detrimental to another system using that same Web service. Unlike .NET code that is run in process, there are no out-of-the-box standards and tools to help with the versioning of .NET Web services.

Finally, of course, are the eternal problems with all new technologies - unclear return on investment and quickly changing standards. These are the difficult questions that SOA must answer if it is to remain relevant in the computing environment of the early 21st century and beyond! As always, I welcome your feedback via e-mail to derek@sys-con.com.