In a recent article in Redmond Developer News, William F Zachmann, claiming to be an SOA cynic, attempts to brush SOA off as no big deal.
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.
In fact, surprisingly (!) he goes on to state that all you really need is .NET and Web Services….what was the name of the magazine again?
There are some points in the article on which I would agree. I am a great believer that there is much obfuscation going on in the marketplace over and around SOA, but I hate to say that this article is just another example. It goes on to say
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?
I am all for keeping things simple, as anyone reading this blog or any of the papers provided at Lustratus would, I hope, realize. But Mr. Zachmann has missed the fundamental point about SOA that makes it a bit more than just a smart type of structured programming. As I have written about before, SOA services are designed with boundaries that satisfy a business rather than a technical context. In other words, the service executes a discrete piece of business functionality as opposed to a set of technical operations. It is this business context that delivers the improved business visibility of operational systems and improves the alignment of IT with business.