SOA (Service Oriented Aberration)

While talking to some of the other speakers at the SOA conference in Singapore, it occurred to me that SOA has an interesting side effect that has nothing to do with technology. To make SOA really work, a business has to strictly define what it is they do, to the point that a developer can create services to represent it. That's the rub -- most businesses don't understand their own business to that level of detail. Time and time again, I've noticed that the analysts and developers on a project actually define a client's business processes to a much finer level of detail than the business ever has. To write code for something, you have to really understand it. Some of the clients for which I've worked even commented on the fact that, because of the development process, they understand their business better.

Of course, the opposite is also true (and, alas, more likely) -- companies with poorly defined business processes will try to adapt SOA and fail miserably, creating a case study of SOA failure, when the technology had nothing to do with it. Worse yet, tool vendors of expensive development tools like Enterprise Service Buses will sell their tools to unsuspecting clients as a way to "fix" their business process. Putting a dress on a pig doesn't make the pig any prettier, and it just annoys the pig. SOA, like so many other similar technological breakthroughs (see Programming, Object-oriented and Development, Component-based), won't solve the dysfunction of dysfunctional businesses.