SOA and enterprise architecture
Roger Sessions has just published “A Better Path to Enterprise Architectures”. His main point is that large, centralized, big-bang enterprise architecture efforts fail. I could not agree more. Sessions gives some good arguments for why you would want to deliver incrementally. He calls this approach SOA.
This is a fairly common way of defining SOA - basically SOA is another name for incremental deliveries. If this is SOA, I don’t hate SOA at all. However, I find that “SOA as incremental deliveries” fails to shine any new light on the subject. To paraphrase Sessions: if you have a $100 million system, you should at least split it up in 10 deliveries. Now, this is neither hard, unusual, or especially helpful. The problem is of course, a $10M project is still very large. How can you split that up further. Finding good services without too high coupling is harder as you move down into single-project scales. And so far, I have seen no description of SOA that sheds any light on this particular issue.
I have discovered that SOA services (at least XML-based protocols in Java) tend to be used as horizontal integration. That is, you insert a SOA layer as the interface to your data access logic. This is by definition going to be a very wide interface, and any changes to the UI, the data services or the database are likely to require a coordinated change through the whole stack. SOA is not necessarily a good idea for horizontal integration. (There is one valid use: Rich clients beyond the firewall). SOA for vertical integration (for example: a webshop that integrates with a payment system) seem to be benefitial fairly frequently. However, I have not seen this as often in the wild as I’ve seen harmful horizontal integration.
I’d like to finish this post with a jab at a small comment in Sessions’ article: “Code Sharing—Many organizations believe that reuse is achieved through code sharing. It is somewhat amazing that this belief persists, despite decades of failure to achieve this result. The best way to reduce the amount of code that a given project needs is through delegation of functionality (as in the case of Web services), not through code sharing.” This is one of the most common myths about SOA. I would like to submit that code sharing has succeeded wildly. Look at reuse of Java open-source projects, especially after Maven entered the picture. Reuse through services, on the other hand, couples your whole service network together, making it hard to change anything without risking breaking something totally unrelated. With horizontal integration being the most common way to use SOA, the information schema is larger, and the coupling is even tighter. Code sharing is not without problems, but SOA does nothing to improve upon these problems.