Why I Hate SOA: Bad Ideas that Just won't Die
When I see people after they have read about SOA or attended a conference with SOA, there are a few ideas that seem to pop up repeatedly. I have even been guilty of using these ideas myself. These ideas were proven to be bad before SOA came around, and (some) SOA evangelists seem to think that SOA solved these problems. It did not. It just refused to learn from history. Some of these ideas work under some circumstances, but recent SOA-itis has caused them to be used in inappropriate contexts.
1. SOA DAO tier
Distributing a program at the DAO level is someting that comes back to haunt us every few years. The DAO level is a particularly bad place to try and divide and conquer: It is a very wide interface, as it will depend on your whole domain model. While projects are in active development, the domain model will have a lot of forces on it to change. Projects are better off resolving with these forces, but having a contractual interface will make this harder. The second reason the DAO is a bad candidate for distribution is that the database already does this! In many situations, putting a DAO in a separate physical tier gives no benefit over using the database directly. Using the database directly is supposed to be bad. SOA does not take away any of the reasons why this is bad. Appropriate use: A SOA DAO tier is appropriate if you would want users outside your organization to have direct access to your database, but the only thing preventing you is the firewall and authorization concerns. In this case, be aware that there are forces to change domain model exposed by the DAO. These forces should be dealt with responsibly. But if you wanted to give people access to your database, you already knew this, right? Antidote: Use SOA to integrate with other applications, not with other tiers of the same application.
2. Visual programming
Visual programming has been a recurring bad idea for over 20 years. SOA has resurrected it, but only in zombie form. The ugly truth is that the examples people use to demonstrate “the power” of BPMN are examples that turn out to be pretty simple in good Java-code, too! When you get to try and solve the hard and interesting problems, the workflows are no longer very understandable. And they will depend on code which will be harder to write, because the logic (in a programming language) is detached from it context (the workflow). Personally, I think it was the same kind of detachment that made EJBs fail. Visual programming is a powerful image, even though it is fundamentally flawed. I am sure we will see it come back to haunt us many times again.
3. Component Specialization
“You work with that bit, and I’ll just sit over here and work with this bit”. These are the saddest words I hear on a software project. The strategy of dividing a system into components and having the developers specialize in each of their component would be a good idea if integration was easy and if component design was easy. However, the non-technical challenges of integration ("What? The ’email’ field is the senders email, not the receipients email? But I don’t have that information here!") will not go away by using SOA. And splitting a system into components has always been difficult to do well. The only solution I have found is the let the interface be maleable long enough that we can correct the inevitable initial mistakes. SOA projects that define a component structure and divide the team according to this structure are on the fast-track to wrapper-land. The antidote is strangely enough related to a strong point of SOA: Organize your problems by perceivable functionality to the users (that is, services). These services cut through your application, from UI to database. A developer should be able to understand the flow through all the layers.
4. Interface with the World Early
“We develop with Web Services, so other systems can connect to us without more work.” If you haven’t designed a protocol with external use in mind (and that costs a lot more!), your interface is likely to be bad for your new users, whether it is written in Web Services, CORBA, or RPC. By opening your system for integration with other systems, you freeze the interface, which also has a huge cost, especially with an immature interface. The reason databases are the choke point for change in many organizations is because it has a potentially unknown number of systems integrating with it. SOA does not solve this issue. If you need an interface that the world can use, you should expect this to cost time and planning. SOA gives a few tools to help you along the way, but opening yourself to the world is still something you want to consider very carefully before you do. And it will always be. Don’t expose yourself to the world unless you get paid for it. (Is that the porn star principle?)
5. The cost of technology integration
“.NET is good for user interfaces, EJBs are good for business logic [sic!]. Why don’t we use them both and just integrate via Web Services?” There are many reasons why developing a system with a large set of technologies is a bad thing. Most of them have nothing to do with technical integration. By all means, if you have large, heterogenous systems that need to be integrated, SOA technologies will probably help you. But don’t design your system as several large, heterogenous systems yourself!
6. DIY protocol
“We have rewritten our CORBA service to only take strings as input and output, so now it is SOA”. I think I will leave that one as an exercise to the reader. In truth, SOA has helped preventing people from creating their own protocols. There is still work to be done, though.
Conclusion
SOA doesn’t fix the underlying problems with visual programming, exposing your domain model to the world, the costs of published interfaces, or the cost of developing a system with several dissimilar technologies. It makes some of these problems more managable, but when you are designing a single system (or Service), these things are still very expensive and problematic. The focus on SOA seems to have made a lot of people forget that it will always be cheaper to develop one system than to develop several systems and glue them together. Use these technologies when there is a real, business problem to be solved by them. In most cases, my guiding principle continues to be “Don’t use it unless you really need it.”