InfoQ has published an excerpt of Nicolai Josuttis' new book, "SOA in practice". On this occasion, InfoQ's Stefan Tilkov had a chance to sit down with Nicolai to ask about his views on SOA, the main industry misconceptions about it, and key success factors for SOA.
InfoQ: Can you briefly define SOA - or rather, your view on SOA?
Nicolai Josuttis (NJ): For me, SOA is an approach for the maintenance of system landscapes. Based on this approach you have all the concepts to successfully manage a specific system-of-systems in a way that you can realize and modify business processes that are distributed over heterogeneous systems.
SOA is not a checklist nor a recipe. Take for example the key concept "loose coupling". According to SOA you should apply loose coupling where it is appropriate. But loose coupling has many different forms (in my book I list 11 of them). The problem is that the application of loose coupling always has a price. Therefore, there still has to be a system architect who decides where and in which form loose coupling is appropriate in a concrete project.
InfoQ: This seems rather vague. How do you decide when a given set of systems conforms to service-oriented concepts and forms a service-oriented architecture? Do you see some sort of litmus test?
NJ: One important aspect from my point of view is whether there are different owners involved. That is, do you have to realize business functionality over systems that are maintained by different companies, departments or teams so that they have to collaborate to get something done? If this is the case a lot of design principles for small systems don't work any longer. For example, you can't simply decide as one person to change a common data type. There is not necessarily a "natural" master of data (guess for example two companies sharing data of the same customer). You have different schedules, interests and budgets. And suddenly you need a culture of collaboration and trust to get things done.
In addition, I would try to get the answer of some typical design and implementation questions that demonstrate how good people know what they do when they implement SOA.
For example:
- Do service interfaces encapsulate implementation details?
If there is an interface such as
customerOP(action, id, name, address)
where action can be "create", "read", "change", or "delete" and other parameters might be null depending on the action, I'd consider this as a smell for technical-driven business services, which is something different from having services such as:
createCustomer(name, address)
readCustomer(id)
changeCustomerAddress(id, address, verify)
deleteCustomer(id)
- What is your meta model for service interfaces and which MEPs do you provide?
The answer to this question has important influence to the interface design and interoperability.
However, I also often ask the meta question: Why do you want to know whether it is SOA or why it is so important that you have SOA? I usually would like to have appropriate solutions instead of solutions that have a specific name (well, unless the customer or management resp. only pays for a useful solution if it has a "SOA" tag on it, which might happen these days).
InfoQ: What are the main misconceptions you see in the industry about SOA?
NJ: There are several things wrong with the way the SOA movement is handled these days.
First, we have the problem that we don't have a community for it. It is totally driven by major vendors, analysts, and integrators. These companies often only want to sell products and consulting effort, but the concept rises so many important questions that we need platforms to talk about the application of SOA seriously and honestly instead of just telling that you have to use SOA to do your business. The point is, again, that it never matters whether or not you use SOA, the only important thing is whether a specific IT solution is appropriate.
Second, it is simply not true that a major business case for SOA is better reuse. All experiences of SOA landscapes of significant size demonstrate that on average the number of consumers for a service is between 1 and 2. This helps, but the major business case for SOA is something different: the investment into loose coupling to maintain system landscapes so that you can react fast and cheap to changing requirements.
Third, it is also simply not true that SOA is established as a standard technology or architecture respectively. SOA landscapes of significant size are relatively rare and almost no company uses BPEL engines in mission-critical applications.
InfoQ: What would you consider to be the main challenges of SOA?
NJ: SOA will led to a lot of frustration because currently it is used in too many ways that are not appropriate. And in the established SOA landscapes I see, we face problems that are far beyond the scope of a lot of current SOA initiatives. Many of these problems have to do with the fact that distribution in itself introduces a lot of drawbacks (therefore it never should be an end in itself). For example, providing distributed test data and distributed debugging can be really challenging.
InfoQ: So if there are cases where SOA is not appropriate, which would those be? How can an organization decide whether or not SOA is a good strategy for them?
NJ: SOA as a concept is not appropriate to solve problems of connectivity beyond distributed business processes. For example, database replication and database synchronization is something different. You might, however, benefit from SOA principles there.
The most critical misuse of SOA I currently see is to use SOA to separate user-interfaces from business logic. Services always provide self-contained backend functionality. That means that they should never contain the state of a running user session. They can keep the state of a running business process, which is not the same. The latter are process services such as a shopping cart application or an order where the customer and other stakeholder can get the current state while it gets processed.
As a consequence I recommend to be very careful to use BPEL extensions such as BPEL4people (currently evolving in standards such as WS-B4P and WS-HT, where HT stands for "human task"). Frontend workflows are a different thing than backend workflows. A corresponding separation helps to decouple things. While prototypes might look great, you often pay a price in the long term.
Because the prices of distribution usually is high, in general I recommend to avoid SOA where you can avoid it. But there are enough requirements where you have to connect distributed systems with different owners. Inside large companies, you have to connect different systems provided by different departments and business units. In addition, we more and more connect different companies. Mobile phone companies for example exchange data with mobile phone vendors, banks, credit card companies, and logistics companies (to ship the mobile phones). They even work together and share customers with airlines, warehouses, resellers and so on. There is no alternative other than to apply SOA principles to realize these requirements.
InfoQ: Can you list some key success factors?
NJ: The most important key success factors I see currently are:
- Understanding, what SOA is really about
- You need top management support
- You need a culture of collaboration and trust
- You need a very careful introduction
- Teams that introduce SOA have to consider themselves as service providers for the business teams
Note that non of these factor are technical. While we have several problems for example with Web Services these also will be important but I don't consider them to be mission critical for an SOA strategy as long as the factors above are not a problem.
InfoQ: Apart from reading your book, what would be your advice to people starting to look at SOA?
NJ: With SOA, it's all about experience of large systems and system landscapes under maintenance. In general, this is hard to teach. You might find other books or trainings, but the best advice I can give is to learn day-by-day about how large systems work. Beside working in these projects, it is important to abstract facts and experiences. One good way to do that is to perform reviews and retrospectives.
Finally I want to give you a strong advice regarding Web Services and tools. SOA provides principles to deal with heterogeneity. This is important because we talk about a solutions for a system of systems under maintenance. However, don't fall into the trap of assuming that this preparation for heterogeneity is not necessary for your SOA tools and technologies. Of course, over time there will be different middleware technologies and infrastructures. Of course, over time you will use different BPEL engines and other ways to orchestrate services (including implementing them in your favorite programming language). For this reason, be careful not to make your whole SOA strategy too dependent on one technology, such as Web Services, or one specific tool. Otherwise you will have to replace your solution by something else in a couple of years, which probably uses all the SOA principles, but has a different name because officially for you SOA didn't work. It only works if you apply it appropriately.
InfoQ: Thanks for your time.
Nicolai Josuttis is an independent system architect, technical manager, author, and consultant. He is well known both in the programming community and to attendees at various conferences because he not only speaks and writes with authority (being the (co-)author of "SOA in Practice", "The C++ Standard Library", and "C++ Templates") but is also an innovative presenter. Currently, he is a team lead for the realization of a SOA at an international mobile phone company running with Millions of service calls per day.