Top 10 SOA Pitfalls: #10 – Not Invented Here syndrome

Top 10 SOA Pitfalls: #10 – Not Invented Here syndrome
Posted by Vincent Partington in the early morning: April 23rd, 2008

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.

While this kind of NIH is not very pretty, it is something that can be fixed on a per-service basis, once the awareness is there. The other kind of NIH we have to deal with in a SOA is the one where you ended up building your own Enterprise Service Bus (ESB), a situation harder to resolve. We've seen two ways in which this came about:

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!

In both cases, getting out of this situation involves a lot of work. These proprietary systems are at the core of your systems, so phasing them out will take a long time. For example, if you would decide to buy a COTS ESB, you would need a migration scenario where you would migrate one service at a time from using the old system to the new ESB. You would need a bridge between the old and the new system for that transition time. Actually, we have not seen such a migration scenario work all the way through to the end because the old system usually still lingers in some corner of the organization.

The moral here would be: before you start writing your own services and your own ESB, have a look at what's available. Your "temporary" service will probably be around for a very long time!

Next week, Rik de Groot will continue with pitfall #9.

Filed under Architecture, SOA | 4 Comments »

4 Responses to “Top 10 SOA Pitfalls: #10 – Not Invented Here syndrome”

Blog Xebia France - Les 10 pièges de la SOA : 10 - Le syndrome “Not Invented Here” Says:

Posted at: May 16, 2008 at 8:55 am

[...] Traduction libre du billet “Top 10 SOA Pitfalls: #10 – Not Invented Here syndrome” publié par Vincent [...]

Top 10 SOA Pitfalls: #4 - Incorrectly applied Canonical Data Model | Xebia Blog Says:

Posted at: June 2, 2008 at 1:50 pm

[...] therefore only include entities that are relevant in that domain. Another pitfall refers back to SOA Pitfall #10: Not Invented Here Syndrome and are from the ground up developed CDMs. Potential models that could be reused are ignored, while [...]

Top 10 SOA Pitfalls: #7 - Incorrect granularity of services | Xebia Blog Says:

Posted at: June 10, 2008 at 10:57 pm

[...] and are not aware of each other (or worse, they simply do not want to communicate, also see Not Invented Here syndrome). Each department or project is only considering their own perspective and that will lead to [...]

Top 10 SOA Pitfalls: Wrap-up | Xebia Blog Says:

Posted at: June 29, 2008 at 1:27 pm

[...] #10 – Not Invented Here Syndrome [...]