How to screw up your services architecture

I almost don’t dare to use the acronym SOA anymore. According to the latest news it is death and probably buried by now. But … long live services! And indeed, SOA has become a synonym for Grand Projects (with governance, business process improvement, methodology, enterprise integration … as small side projects). Needless to say that these projects either fail (for those who are lucky) or continue, without delivering much, until the end of time (for those who are unlucky). People forgot it’s all about a simple yet powerful architecture that uses services as a mental model. 

Even without SOA on the whiteboard and focusing on “just services”, most organization manage to screw that part up to. For them, services = web services = soap. So, they start to spit out “services” after “service”. Of course, in reality they are just spitting out SOAP binding after SOAP binding for .NET or Java methods. It should be considered a crime to call this “services”. Language and tool vendors have made it very easy for these organizations to create services in this way. It takes a couple of mouse clicks and a wizard or two to turn any class into a full fledged “services” (read: expose it with SOAP).

This library, bravely called “ServiceLayer” even takes this a step further … Forgot to create a “service” from your classes? No worries, you can now create a service from them, without recompiling. You just browse the compiled code and select the methods you want to expose as a service. If this continues the very word “service” will become so tainted we can’t even use that anymore.