Some people claim you can achieve business agility by using SOA. Agility meaning that IT can quickly deliver what the business needs. And that the business has the freedom to move. You need to be able to change your plans if you want to successfully operate in dynamic competitive markets.
There are two main reasons why SOA would help achieve agility: reuse and loose-coupling. By reusing existing systems you can quickly create new applications. And by applying loose-coupling you can minimize the impact of change, and therefore it’s easier to make changes to your software.
Now, i agree that these are important design principals, and applying them is essential, but i really doubt that you can achieve Business Agility just by using SOA.
What exactly is SOA? I think three words characterize SOA: reuse, heterogeneity, and processes.
SOA is a way to deal with heterogeneity. You can build applications on top of your existing applications. Using xml you can bridge the heterogeneity. It makes your applications data implementation independent. So you build a layer of xml on top of your existing systems.
For some people SOA is about processes. Being able to implement business processes as a first-class citizen in your IT solution. By making processes explicit, it should make it easier to modify the implementation when the business process changes.
But the main part in SOA isn’t about xml or processes, it’s about treating your existing systems as services and building applications on top of them by using these services.
This isn’t exactly a new way of thinking. It is an existing design pattern at the core of most JEE applications (see Service Facade), mostly implemented using EJBs. EJBs promised many of the same benefits now attributed to SOA. EJBs also promised reusable, distributed business logic, enabling you to quickly build new applications by reusing existing logic.
Did this happen? Not really. Reuse is hard. It actually limits your agility in some ways, because you can only use what’s already in the EJB. Or you have to get it changed, which is often a difficult route to take, especially if you are not the owner of the service. Other people, with goals different than yours, have to agree with your changes. And they have to make time to implement these changes. And all the other applications also using the same service need to be regression tested. Reuse and agility not always go hand in hand.
Another reason why we didn’t see a lot of reuse with EJBs was the complexity of EJBs. People disliked using EJBs because of their complexity. They disliked the complexity so much that a lot of alternative frameworks were created. The Spring Framework is one such example. Currently, Spring is probably the default way to build JEE applications. But now that EJBs have been simplified by copying a lot of good ideas from Spring and other frameworks, the use of EJBs is picking up again.
Recently Rod Johnson wrote a blog entry about Hoare: Happy Birthday Tony Hoare. One of the things Rod mentions about Hoare is that he warned about the complexity of software systems. Rod argues that this can be seen as an early warning against the complexity of J2EE.
One thing we learned from Spring is that testability is essential. You need to be able to create unit tests to test your application. This is key for agility. The faster you can test you code, the shorter your coding fase will be, the faster you will be able to deliver new functionality. The easier it is to regression test your system, the easier it is to make changes.
Current SOA solutions are often hard to (unit) test. This is largely caused by the fact that you can’t run your tests out of container, just like with EJBs before version 3. We need to be able to unit test our composite applications out of the BPEL or ESB containers. The current Oracle BPEL test framework doesn’t allow you to do this. Doing automated unit tests is really hard with Oracle ESB. But the situation is improving. For example, compare Apache Camel to Oracle ESB. Routing rules in apache camel can be tested easily, whereas routing rules in oracle esb are very hard to unit test. Guess which one is a better choice if you’re looking for agility.
Today, the java world seems to agree on the fact that simplicity is good. To build reliable systems quickly, we need simple technology, not complex. Complex technology isn’t going to enable agility. The more dependencies you have, the harder it will be to achieve agility. Simple technologies are necessary for agility.
But there’s more to agility than technology. I think technology isn’t the most important factor. Most SOA projects are complex because of the multiple ownership. Who creates what, who pays for what, how do we align all the different agendas? This complexity is hindering agility much more than technical complexity.
Another big challenge in agility is process. Does your process allow you to be agile? Or do your project management methods only allow you to deliver a year after business has requested something? How do you cope with changing requirements? Business agility means that business should be able to change requirements. You need a process that enables agility. You’re not going to be agile if you’re still using a waterfall methodology, no matter what technology or architecture you use. You need something that will enable business to continuously reprioritize their needs. And you need something that will deliver the top priorities fast.
Minimize the number of owners in your project. Use the simplest technology possible. And use the correct project management method. This is the way to deliver business agility.
