Interview: Nicolai Josuttis

Well, there is some disillusionment right now, so that a lot of people are disappointed about SOA. One reason is, that there is no clear definition of SOA and that a lot of people and companies just used the term because it sells well. So, I am not sure about the term, but I am pretty sure that the concept behind the term (at least according to my understanding) will remain. It will remain because the principles of SOA deal with the requirements of globalization in IT. We are moving from system development to the maintenance of system landscapes, where system development is only a part of. SOA provides principles for this need. For example, SOA accepts heterogeneity instead of fighting for harmonization. Harmonization is good, but in a global world requiring harmonization (common platforms, common data models, etc.) is not an option.

The REST community claims that RESTful HTTP is a better approach for the utilization of HTTP. And yes, the fact that the native HTTP calls GET, PUT, and DELETE are idempotent so that in the Internet some caching and retry mechanisms are possible, is utilized with REST but not with SOAP (which uses only HTTP POST). On the other hand, as far as I know significant requirements of a sophisticated SOA landscape are not provided with REST. For example, we still have a variety of payload formats and there is no support for end-to-end security. So, REST might be better, but this is just a minor technical detail in system landscapes where you want to realize distributed business processes. I’d still prefer Web Services, if interoperability is the goal, but for specific connections REST might be a better option. And I see a significant risk of technical-driven interfaces, when people only care for REST. Something, which is definitely the opposite of the idea of SOA.

It is one analogy that might explain why SOA is to some extend as revolutionary as agility. Too long we thought we have to fight against these constantly changing requirements until we (or at least some smart guys) accepted that changes even during development are natural. And too long some people claimed that it is a good approach to have one model, one platform, one programming language, one ESB, etc. But that doesn’t scale. There will be a system size where all these “one fits all”-concepts are not an option. Period. End of discussion.But there are more common things in agility and SOA. In the SOA manifesto you will find a lot of agile requirements. For example, you can only introduce a service-oriented approach step-by-step (iteratively).

They can and they have to. The agile value system is necessary for the establishment and realization of SOA, because to some extend, SOA uses agile principles in a more complex context. You have multiple projects running at the same time, with different virtual teams and multiple product owners involved. Without agile principles you are lost in SOA.

The biggest problem is that almost nobody has a clue, what SOA really is about and what a fundamental strategic approach this is. SOA is sold by technical people, who prefer Web Services or REST, or it is sold by vendors, who want to benefit from the hype, but almost nobody has a clue about the real business case of SOA. We talk about a concept that handles the problem of distribution. But distribution is very very expensive. One key element is collaboration. To realize a solution in multiple systems and teams, you have to work together. From the beginning (design) to the end (common distributed test data). That’s really hard and you might find out that in your enterprise culture you are not able to work together. You will give SOA the fault, but your problem is that you are not able to see the big picture of a problem and collaborate with others. Now, decide on your own: Is your company ready for SOA?

This is a tough question. Going through the principles I tend to give different answers:

• Of course, due to the distribution of system landscapes you have the usual problems with face-to-face communication and trust (Jutta Eckstein is the better expert here).
• Then, early delivery is hard to reach in a distributed system. The first business process using an SOA approach might take 3 to 6 months.
• But may be my final answer is simplicity. There are so many good ideas for a sophistic versioning of interfaces that you don’t see the easy simple way: Each change of a service in production is a new version (independent from its backward compatibility). There are so many tools available that make things more complex. There are so many strange ideas of what an enterprise service bus should be. People don’t start simple and don’t take their time to start simple. In the long term, a lack of simplicity is usually a recipe for a disaster.

Because we can’t stop globalization, the principles will remain.But due to wrong and broken promises the name “SOA” might be a problem. So, the term might fade away but the concepts will stay. A typical request to me as a consultant these days is: “We need help, but please don’t call it SOA, because we are not allowed to use this term any longer.” The common term right now is “integration architecture”.  And, by the way, neither cloud computing nor event-driven architecture are a new or better SOA. The concept of a service is in both ideas, but in very different contexts.