Some SOA “lipstick on a pig”

It has been a long time, but I’m back! I have had a busy time with exams (for my study) and of course my job. The title of this article is, as you can read, ‘Some SOA “lipstick on a pig”. I have read this quote here. I’m not going to react on that article, I just like the quote. The situation sketched is seen very much at the moment. Companies willing to take part into the ‘hype’. They want to have a service-oriented architecture, but they, in fact, only get some support for web services. That is not the same as a service-oriented architecture!

There are some basic requirements for a service-oriented architecture (SOA).

Of course I’m not going to give an exhausting enumeration, I will just put a few key elements to give you an idea. First a SOA has to enable integration in different situations. This can be inside of outside organisations. Second a SOA has to be flexible for fast responding on changed business demands. A last element I will refer to is the way you can build and integrate software in a SOA. This has to be simple. It shouldn’t take months of work with IT professionals. In the ideal situation people who aren’t integration architect could do the job.

The ideal way to set up a SOA is to implement everything from scratch. Than you can freely choose the different components. This can lead to a good balance between flexibility and performance. In this way all the requirements of a SOA can be fulfilled and the SOA will give all the advantages it have. But, in real life this is never the situation. You always have to deal with legacy applications. How to deal with them? That’s a difficult question. I don’t have a solution which holds in every situation. It depends on the kind of legacy software a company has. It also has a lot to do with the way people work in an organization. How they use the existing software. I will now only give some consequences of just choosing a SOA because you have to have it (hype?).

Some SOA "lipstick on a pig", that’s what you get. Legacy applications will receive a web interface, so you can call them a webservice. A couple of this ‘webbed’ legacy applications together will get the predicate SOA. But it is easy to see that this doesn’t give you the advantages of a SOA, because it is not a SOA. It is a collection of legacy application with some webservice support. I’m afraid a lot of company’s are served with such ‘SOA’s’.

To conclude: webservice support is NOT the same as a service-oriented architecture. If you still want to call this as SOA, call it ‘Some SOA "lipstick on a pig"’!