All over their involvement in plans (Oriented Architecture service), the consultants of Xebia live on nice successes. But they also meet some plans which struggle or that are in failure.
To share these experiments, our Dutch colleagues, Gero Vermaas, Viktor Grgic, Rik de Groot and Vincent Partington unwind a series of tickets introducing 10 traps of the implementation of an orientated architecture services (SOA). As always in this type of  "classification" , this list is not either exhaustive or final.

The first of these traps is the syndrome "Not Invented Here" (). This syndrome meets in a lot of domains of IT. As part of the implementation of an orientated architecture services (SOA), it manifests itself particularly at two levels:

• Service reuse.
• The installation of a third of intermediation.

Service reuse

One of the objectives underlain by the implementation of SOA is service reuse.
If the department A constructs a service get_personal_details (who goes back, between others, him complete address), there are not enough arguments which plead in favour of the building by the department B of a service get_address. There are however several reasons which can lead the department B to construct this service:

1. The teams of the department B do not know service get_personal_details. It denotes generally the absence of a directory / service register (or its mismanagement). We will discuss this point in another ticket of this series.
2. The way the department B conceives its application does not encourage it to think of reuse. It is in general what arrives when one    (a step of completely Top down conception) is applied  . This point will be also discussed in detail in another ticket of series.
3. The teams of the department B know service get_personal_details, but they decide not to use it. Either because they do not know precisely what he makes (they fall again then in the first case), or because they do not trust in the department A as for its capacities to accomplish this service correctly, or, still, because they prefer having a complete control of the realisation of this service.

The third reason is a case typical of the syndrome NIH. It is then urgent to unite both departments around a table so that they discuss the responsibility of this service and so that they find a ground of understanding on which each is in confidence.
This type of behaviour is unfortunately rather common. But, it is something that can, in general be regulated case by case once dialogue and confidence were restored.

The installation of a third of intermediation

The second scenario in which the syndrome NIH during the implementation of SOA is met is more difficult to solve. It is the one who leads a computer direction to construct his own service bus (). It can arrive mainly of two ways:

1. At the beginning of 2000s, applicative integration based on messages made appear the need of a plinth of technical r utilisables services (transport, routeing, transformation). This need drove houses, in many firms, to the building of frameworks of messaging, most often above a backbone of messages as MQ SERIES. This frameworks returned proud services in the past, but all over their nature, they are very strongly coupled today with the applications which they support (or the opposite), hindering so the introduction of standards ESB in the facilities of YES.
2. Beyond this phenomenon, today even, some people write their own ESB. Indeed, a good many of architects have an impression that ESB is a marketing product strongly pushed by the editors and sees them as something useless. This vision of things is a bit exaggerated, and it is necessary to have very good reasons (and the solid shoulders) to write these own services of transport / routeing / transformation. What returns to implement its own ESB!

In both cases, to go out of this situation implicates a lot of job. These possessing systems are in the middle of systems, their abolition will ask therefore a lot of time.
The acquisition of ESB (sales and marketing person or open source) implicates the implementation of a plan of migration in which services will have to be migrated one after another to use this ESB rather than the ancient system. A bridge will therefore have to be supported between the ancient system and ESB for the duration of migration. So, it is probable that the disconnection of the ancient system is not real long before

Perspectives

Before beginning writing his own services or his own bus of message, it is therefore desirable to study what they have. There are big chances that a service or a "temporary" platform  remains active for a long time

 

---

Translation free from the ticket    published by Vincent Partington.