SOA, Service oriented architecture, has been the hype for a while. Major vendors are embracing, even hugging, this concept and every so-called IT evangelist is writing tons of columns about it. And somehow I keep asking myself what’s new?? And more important, what is the added value of an architecture, a shared understanding of system design, based on services, based on procedural components that can be invoked remotely?

To answer the question we have to go back into history. Suppose you are a major Internet bookseller during the late 90-ties. You’re selling hundreds of hundreds of millions of books a year by Internet. The bulb is expanding, everybody believes in Internet and everybody invest in internet. And at that right moment, a not to name but very big traditional American book shop who has missed the digital bandwagon wants to jump on the services you are offering. Commercially spoken, within minutes the deal has been signed. Technically some things need to get arranged to make it possible. The only problem, your system was not designed to serve other clients than browser based book buyers. Your local low-payed script-kiddie has the solution! Let the traditional book shop simulate a browser and you can close the deal. After some e-mail discussion between your technical guy and the IT department of your new business partner, a protocol and some server-side handlers were implemented and business to business was a fact. The first web service was born.

Two months later a major television broadcasting company, having a big hit with a cooking show around an over-hyped chef-de-la-cuisine who can only cook an egg in actual life, wants to sell kitchen related books on the website of this particular show. Same protocol, same server side handler and yet another happy business customer. One year later your protocol has become a standard. Two years later a committee of wise men of an independent club with three-double-u’s in their name has asked you formalize it in a too complex and unreadable document and SOAP has been born.

No problem so far. You are running your business, others can make use of it and even exploit the same mechanisms in a complete different setting. And business-to-business communication has never been so easy. Except for the damn protocol your script-kiddie has come up with. But, no CORBA, no EDI, language independent, XML-based, invokable by HTTP and working. Cool!

Until the moment some clever guy, who is happy he will be anonymous for the rest of his life, came up with the idea to use this business-to-business technique for application-to-application communication. Still okay when both applications are written in a different language, are running on a different platform, and somehow need to communicate. But not okay, or better said not the most ideal solution, when both applications have a similar nature and the only reason to use web based services is for future openness. This guy denominated it as application integration and the industry has prefixed it with the word enterprise.

And then, the design pattern gang came along. And one of their ideas was to introduce facades. Great, love the pattern, use it every day, but somehow applications that are being used by other applications need a service-oriented facade to hide implementation. And somehow the facade pattern introduced composite applications. And somehow this pattern in combination with your popular million selling e-shop has become SOA. And nowadays we are facing the problem that every elementary function of every possible application in an IT landscape can be normalized into a web-service.

So ignore the idea of a service oriented architecture? On one hand yep! On the other nope! There are good things about the idea. Distribution of loosely coupled components focused on re-use instead of re-invention for example. Modelling of business processes into these kind of components is another. But I realize when you walk the way of component-based development, no matter if you use Web services, EJB’s or something similar, you walk directly into maintenance problems. Once a hardly visible dependency network has been twisted around (or within) your applications, it is hard to change something. You cannot blame your SOA, you should blame the way you have set-up your SOA. When chosen for web services, you have chosen for a procedural approach. Your customer service is nothing more than a bunch of old fashioned C functions (or Pascal procedures) sitting in a module called ‘Customer’. And from the procedural world we have learnt at least one major lesson: do not wire to much! Maybe it is time for object oriented web services or is this a contradictio in termino?

Knock knock. Web services are OO! Look, I have my customer definition and then I have a CRM-customer, An ERP-Customer, a BI-Customer and a whatever more customer. Using SOA I send a ‘create customer’ message to the back and I don’t care what all these customers are doing. Implementation has been perfectly hidden from interface and I can even produce polymorfistic behaviour. That’s not OO, that is procedural multiplexing. And again, SOA has some good ideas and multiplexing is one of them also. But do you need a SOA to multiplex your calls?

So, implementing a SOA, an architecture driven by procedural calls, will drive you into maintenance problem. And even worse, everybody knows SOA’s are unmaintanable but nobody is telling. Instead, to solve your maintenance problems, the big players are selling SOA solutions. You have to go or even think liquid to quote just one. When there is a book in your system, you need a book service, when there is a customer in your system, you need a customer service and when you have to many services and wires between services, your facade can’t be managed by a bunch of developers. You simply need tooling. Because you can’t change anything without predicting the impact. Guess who sells the tools? And when we call this added value, I’m lost.

So what is new? You did not have a problem until someone told you to arrange things in such a way only his tooling can help you to get out of the mess, Nothing new, everyday IT industry business where problems do not exist but get created. Why can’t we go back to the old days, when web services were used to glue business together instead of applications? Forget your SOA, go ahead, develop the applications you need, implement a message broker when a message broker has reasons for existence within your architecture, and when you are in the need of interfacing with a third party, look at protocols like SOAP. But remember, in house nobody (new) is a third party by default!