Service integration is key for agility

I posted 3 years ago a similar message on this blog. Looking at the different conversations around, I think it is still quite valid. To give it a larger audience, I am reposting it in English

Service integration has been there for a while

Without looking back to IT origins, IT integration has been available for many years : Remote Procedure Call (RPC) for example was proposing some help to integrate systems together.
This proposal has been improved overtime with DCE, Corba, J2EE, Webservices and now cloud APIs

Service integration brings a complete different proposition from data integration which has been used for ages and remains still very popular. It consists in integrating ready to use services instead of integrating raw data. Data complexity is then hidden behind a service. This layered architecture is bringing a lot of benefits out of which reuse is key.

Reuse is the key word

Reuse in IT is a quest of Grail. Over the years many attempts have been seen, most of them being unsuccessful. What service integration is bringing is that systems can be much more independent, cloud bringing this a step further, where the outsourced service is completely independent from the application which is using it. 
This is facilitating integration because the two systems to have no in depth knowledge of data representation, they share a documented well know interface.

Reuse is key because companies have invested over the past, billions in IT systems and they cannot simply throw those legacy systems away because a new technology is popping up ! For the sake of agility, integration is key : no need to rebuild from scratch what has been built before. Instead, reuse is accelerating time to market, development been focused on the new functionality/technology

Service integration saves time

Integrating a legacy system is a good example of how service integration is providing value and agility : legacy systems are delivering proven services and maintain a lot of key data. How to benefit from these assets through new channels like mobile, pads or simply in a web browser ? Should the legacy system been ported on a newer technology ? Porting is both expensive and slow... Building services out of the legacy (keeping in mind the proper granularity) and integrating those services with the new technology/channel is by far quicker and cheaper.

As a concrete example, a bank, in the beginning of the 90's, was owning a financial engine made of more than one million lines of Fortran 66 associated with a large proprietary database. This company was at that time introducing open systems to users which was giving  a much better user experience but lacking the powerful computations provided by the legacy system. The solution which was gradually introduced was to define from the legacy a set of high level abstract interfaces on top of which new applications were built on the open system platform. This was delivering the best of both worlds, user friendliness and advanced computation capacities
More recently, same applies for companies willing to introduce mobile services. All data and services are already there in legacy systems but unavailable to new channels. In insurance industry, car damage insurance benefits a lot from mobility : pictures can be taken on site by the user, garage, expert and fill the file which is maintained on the legacy. Building web services or using any kind of service integration technology on top of the legacy unlocks existing data and services. In that example a mobile app was build using services from the mainframe such as opening and validating a case, adding new information to a case, ... 

Service integration is not a technical matter

This shows clearly that service integration is not (not only) a technical matter. Service integration means that services are defined functionally. In those examples even if the starting point may have come from a technical integration, very soon in the project, the need of a proper definition of a consistent set of services was raised connecting with Enterprise Architecture.
Understanding up front what are the 50 key services an IT system should offer is helping to success in service integration.
Service integration can leverage Enterprise Architecture, implementing concretely services that architects have identified.

Of course one could argue, that leveraging on old technology is creating a huge maintenance problem : how to maintain legacy cobol systems ? and what if these systems are used also by newer applications making them impossible to decommission ? In fact, this argument is more related to life cycle management rather than service integration. If a legacy system is still using old technology it is not because of service integration !
Instead, service integration is providing flexibility isolating producers from consumers and allowing a decoupled life cycle along the value chain. 

Off-shore et méthodes agiles

On rencontre régulièrement deux types de motivation pour utiliser des ressources off shore : la recherche du moindre coût ou la dimension du bassin d'emploi quand le marché de l'emploi on-shore est saturé. Même si la première motivation est de loin la plus répandue, surtout dans la période de crise actuelle, la seconde existe aussi dans des périodes où l'emploi on-shore est très tendu du fait d'une très forte activité. Dans ces deux approches, on recherche l'acquisition d'une force de développement soit parce que l'on pense qu'elle sera moins chère, soit parce que l'on peine à la constituer on-shore.

Ce qui est frappant, c'est le décalage fort entre le message dispensé on-shore et off-shore. Les entreprises se plaisent à dire que les hommes constituent leur principal capital alors qu'elles vont chercher off-shore des ressources sur lesquelles elles n'ont que peu de maîtrise en privilégiant les coûts. Dans certaines entreprises, on constitue des équipes on-shore avec des profils de haut niveau et on improvise complètement le recrutement off-shore, laissant le soin à des prestataires ou à des intermédiaires de monter ces équipes off-shore.

Tel que présenté ici, le constat pourrait paraître caricatural, pourtant, on peut mesurer la réalité de ceci à travers le nombre de d'entretiens réalisés par les responsables d'équipes on-shore pour sélectionner les membres des équipes off-shore : combien prennent la peine d'aller régulièrement sur les sites off-shore entretenir le contact avec les équipes et recruter les nouveaux embauchés ? Autre élément de mesure, on peut avec quasi certitude, affirmer que tous les responsables d'équipe connaissent la valeur relative des formations dispensées on-shore. Cet élément est indispensable pour aider à créer des équipes équilibrées. Combien de ces mêmes responsables connaissent les filières des pays off-shore dont ils utilisent les ressources ?

Se pose également, pour les grandes entreprises, la question de la structuration du pôle off-shore. Faut-il acheter du service à des sociétés locales, disposer de sa propre structure ou tenter une solution mixte ? Il n'y a certainement pas de réponse unique à cette question : tout dépend de la stratégie et de la notoriété de l'entreprise. Des sociétés peu connues mondialement et peu connues dans les pays off-shore auront du mal à attirer les meilleurs profils qui se dirigeront le plus souvent vers des entreprises connues ou leur offrant des possibilités de travail en occident. Pour ces sociétés dont la notoriété est moins grande, le recours à la sous-traitance à travers les sociétés de service locales est sans doute la bonne solution. Pour les autres, une installation locale peut être à considérer.

Quelque soit la solution retenue, soit parce qu'une solution de sous-traitance a été mise en place, soit du fait de la création d'une « Business Unit » distincte, une relation de type client-fournisseur s'installe entre l'équipe on-shore et l'équipe off-shore.

De ce fait et également du fait de l'éloignement culturel et géographique, les méthodologies de développement en cycle en « V » ont la préférence des managers qui pensent pouvoir ainsi mieux maîtriser les développements réalisés off-shore. Ces méthodes introduisent, dans les différentes phases du cycle en « V », des ruptures entre les équipes. L'articulation entre spécifications et développements n'est pas facile à réaliser sans perte d'informations et les exemples de dysfonctionnement à ce niveau sont très nombreux. L'adoption de telles méthodes dans un contexte on-shore/off-shore rend encore plus problématique l'articulation entre Maîtrise d'œuvre et d'ouvrage. La distance culturelle et géographique joue à plein pour gêner la compréhension entre les équipes, par ailleurs, peu favorisée par les méthodes en cycle en « V ».

Pour éviter ces écueils, on essaye de fluidifier la relation entre les équipes on-shore et off-shore en mixant par exemple, quelques personnes des différentes équipes. Même si ces dispositions améliorent le fonctionnement, elles n'éliminent pas les frottements et introduisent des coûts supplémentaires.

Globalement, du côté des coûts, les économies sont moins substantielles que la différence de taux horaire ne le laisserait supposer. Si l'on regarde uniquement l'aspect coût sans prendre en compte ni la qualité ni les fonctionnalités fines, l'économie communément admise par la profession est d'environ 20%. Même si cela n'est pas négligeable, il n'est pas évident que l'off-shore soit aussi attractif lorsque l'on prend en compte tous les aspects mesurables ou non mesurables.

Tout ceci montre que la façon traditionnelle d'envisager le développement off-shore n'est pas optimale car elle introduit beaucoup d'inefficacités. Pour améliorer cette situation on peut avoir l'idée d'introduire les méthodes agiles dans le développement off-shore. Ces méthodes proposent de simplifier et d'accélérer le cycle de développement en évitant les « effets tunnel » et en essayant de limiter l'incompréhension entre les équipes, notamment avec les utilisateurs. Sans chercher à décrire ici ces méthodes, elles apportent généralement des cycles ou itérations de quelques semaines au bout des quelles un livrable doit être produit et le possesseur de l'application doit mesurer la valeur ajoutée et définir le contenu de l'itération suivante.

Étant donné le format très réduit de chaque itération, la communication au sein de l'équipe et avec les autres équipes est primordiale et souvent organisée à travers des réunions quotidiennes. Lors de ces réunions, l'équipe retrace les travaux et difficultés de la veille et établit le plan de la journée. Ce mode de fonctionnement paraît assez peu compatible avec un mode off-shore. Cependant, les capacités de communication actuelles permettent la tenue de réunions quotidiennes en visio conférence qui rassemblent les équipes même localisées en différents endroits. L'adoption d'une méthode agile va réunir les équipes on-shore et off-shore sur un même projet en structurant et en organisant une forte communication dans l'équipe, en mettant en place une méthodologie de travail commune et fédérant l'ensemble des acteurs sur des objectifs communs régulièrement revus. Les décalages et incompréhensions inhérentes à la distance sont ainsi détectées plus facilement et surtout plus rapidement. Les conséquences de ces problèmes sont donc mieux maîtrisées ce qui en limite les coûts.

Mais la mise en place de telles méthodes ne peut s'envisager sans une révision drastique du recrutement : il n'y a plus d'équipe off-shore et on-shore mais une équipe unique travaillant en plusieurs endroits sur le même projet. Le recrutement de tous les membres de l'équipe doit s'effectuer d'une façon homogène quelque soit le site. C'est d'ailleurs une condition nécessaire au respect indispensable au fonctionnement interne de l'équipe. Cela a également un impact sur la structure organisationnelle du site off-shore : il est plus facile d'organiser ce type fonctionnement avec des filiales off-shore qu'avec des prestataires sur lesquels le contrôle du recrutement sera moins aisé.

Pour finir sur une note légèrement provocatrice qui résume le raisonnement sous-tendant cette proposition, on pourrait dire : étant donné les formations de qualité existantes dans les pays off-shore, pourquoi les ingénieurs de ces pays seraient-ils moins compétents que les nôtres et pourquoi ne pourraient-ils pas travailler dans les mêmes équipes ?