At Xebia we are involved in quite a number of Service Oriented Architecture (SOA) projects, from small to big. In that capacity we see a lot of good stuff happening, but we also encounter quite a number of projects that have stalled or failed. To share our experiences with these SOA projects, Gero Vermaas, Viktor Grgic, Rik de Groot, and myself have decided to write a series of blogs about the most annoying pitfalls of SOA. Each week we will be publishing one item from the list. This way we hope to spread awareness of these dangers and also provide you with a checklist of what to watch out for. Of course, as is always the case with these kinds of lists, they are not complete and not all the issues are as absolute as the title may imply. YMMV! The first item we want to discuss is the Not Invented Here Syndrome (NIH). Of course this is something that can be witnessed in more areas of IT, but in a SOA context it actually applies on two different levels. First of all, the idea of a SOA is to reuse existing services. If department A builds a get_personal_details service, there's not much point in department B building a get_address service. Assuming the get_personal_details service returns the full address. Of course, there may be multiple reasons why department B would do this:
- They don't know about the get_personal_details service. In this case there is no proper service registry, a point we will discuss later.
- The way they design their application does not cause them to think about reuse. This is one of the things that can happen when applying Big Design Up Front. Something we will also discuss in a future blog (way to build up the suspense, not? ;-) ).
- They've known about the get_personal_details service but they decide not to use it. Maybe they don't know what it does exactly, maybe they don't trust department A to get it right or keep it right, or maybe they'd rather have full control over the implementation. In this case, you have some classical NIH hitting you. This is the time to discuss the ownership of the services and allow both department A and department B to feel in control.
- In the beginning of the 2000's, corporations using message based integration discovered the need for reusable generic services (e.g. translation, routing, transport, etc.). This led to the development of a lot of homebrew messaging frameworks, usually on top of a messaging system such as MQ Series. While these frameworks served a need back then, their very nature has caused them to become intertwined with a lot of the applications in the enterprise and thereby hindering the introduction of an industry standard ESB.
- But even now people are writing their own ESB-like services. Quite a number of architects have the impression that ESB's are pushed heavily by the vendors and disregard ESBs as useless systems they can do without. While that bit about the pushing may be true ;-), writing your own translation, routing and transport services does not strike us as a very sensible answer. You are in fact building your very own ESB!