Three pitfalls of service-oriented architectures (SOA)

Probably you have heard about Service Oriented Architecture (SOA). It’s an upcoming ‘hype’ in the software business, mostly in business software. It promises more flexibility for big software systems. Also terms like agility, reusability, etc. are passing by when talking about SOA. I’m not going to talk about the rightness of all this terms. However, three common mistakes are made in the field of SOA.

I will point them out all three before giving some tips on choosing SOA or other solutions.

Pitfall 1: SOA is an architecture

In the previous sentence I’ve made the first mistake about SOA. I said ‘choosing SOA or other solutions’, that could be understand as ‘SOA is a solution’. This is not true! SOA is an architecture. A description of a process with which you can come to a solution. In general a software architecture describes the system and its elements as also the relations between these elements. Secondly a software architecture defines a set of steps for implementing or changing a system. At last an software architecture explains some knowledge needed for effectively using the architecture. Best practices can also be included.

So choosing SOA for solving a business problem is choosing a direction in which you search a solution. Of course you can choose SOA based on some requirements. But this is only the start of getting a solution for your problem.

Pitfall 2: The benefits of SOA are based on the partition in services

A service-oriented architecture promise several important advantages in comparison with other software architectures. A system implemented in this way can be more agile, meaning it’s fast and easy to change. The reusability in such a system can also be very high because everything is divided in services (components) and every service can be reused in a simple way. However, in that part lays the trick. How do we split functionality into components? How you do this has big implications.

One way to do this is splitting everything up into services. In this way every function becomes a service. Of course this is a disaster for the performance of the resulting system. What you are doing is programming with services instead of programming with function calls.

The opposite of this is to publish a whole system as a service. By example for combining all the systems of a company in one GUI. Of course this approach does not give you the benefits of a SOA. Simply because there are no ‘building blocks’.

Of course the right way is in the middle (if you aim at the benefits a SOA promise). But in knowing that doesn’t lay the end solution. How can we split up a system in such a way that services has low external complexity and high internal complexity? To tackle this problem a lot of scientific work is done at the moment. I recently saw a nice example of such work at the Delft University of Technology. Dr. Dipl-ing Antonia Albani presented the tool BCI-3D (3D Business Component Identification) which can split up the enterprise ontology (for more information see the work of Prof. Dr. ir. Jan L.G. Dietz and his DEMO methodology) description of a whole company into components. With some configuration you get nice results, eg. high internal and low external complexity. This process can be repeated so that you get from business components to software components.

Concluding: the benefits a SOA promises depend highly on the partition in services and as you can see, this is not a trivial problem.

Pitfall 3: IT governance can be very difficult in a service-oriented architecture

The nice thing in using building blocks (services) is that they can be reused in a quick and easy way. In an ideal situation the service you implement for a certain project can be reused in another project. But have you thought about building services with a lot of people working in parallel? Maybe working on different projects? Your service library will grow very hard and services could have overlapping functionality. A service could also be build again because it is not known that a service already exist with the same functionality. This problem is very actual and you see that big vendors try too tackle this problem by buying companies specialized in semantics. And yes, that could be a nice solution for this problem.

Another point of interest is the use of services outside the using company. It is one of the promises of SOA that it is easy to use services outside a company border. This is true, but if something is going wrong in a service which is not controlled by yourself and this service is an essential building block somewhere deep in the hierarchy of your system structure… you’ll have a BIG problem. This way of using services does not only creates dependencies between services, it also creates dependencies between companies!

Concluding remark

I’m not an enemy of SOA. I think it’s really a good development in software engineering. SOA brings IT and business more together. But I just want to warn you against a ‘hype’ way of thinking about SOA, only seeing benefits influenced by nice sales speeches. There are a lot of benefits, but do not underestimate the complexity of some problems. This complexity stays the same unless which technology you use, see my previous article in which a bit is explained about one of this problems (read article).