Les architectures orientées services ou systèmes SOA sont conçues autour de la notion de services correspondant à une action exécutée par un fournisseur et consommée par un client, alors que l’interaction entre le producteur (fournisseur) et le consommateur (client) du service est assurée par un médiateur «bus». L’intérêts majeur est de permettre une grande modularité des systèmes et surtout une réutilisation de services pouvant contribuer au traitement de nombreux processus distincts. Ils présentent toutefois une contrainte forte au regard de l’intégration de composants nouveaux. En matière d’intégration, le client maître d’ouvrage se voit investit d’une obligation de description de ses besoins, en termes de système cible et de description de son existant ou à tout le moins des composants avec lesquels les fournitures nouvelles « matériels et ou logiciels » devront interagir. Si l’existant est conçu avec une architecture de type SOA, cette organisation sera structurante pour le schéma d’intégration de composants nouveaux. Si le fournisseur ne dispose pas d’un accès ou d’une description de l’annuaire des services assez documentée, il y a un risque de dérive des coûts et des délais de réalisation et surtout d’inadéquation de la méthodologie d’intégration par rapport aux contraintes urbanistiques et architecturales du client.
Les prestataires de TMA (tierce maintenance applicative) ou les centres de services doivent être informés des normes d’architecture utilisées tant pour les services existants que pour de la création de nouveaux services. Les relations contractuelles du maître d’ouvrage avec ses prestataires devront intégrer une garantie de compatibilité des fournitures et prestations avec l’existant et les principes et méthodes qui régissent cet existant. Dès lors que le client a mis en œuvre un schéma directeur intégrant une SOA, il paraît cohérent qu’il s’assure de l’évolutivité des fournitures diverses des prestataires de façon cohérente avec ce type d’architecture. Enfin, la dimension « SOA » devra nécessairement être intégrée dans les protocoles de tests des fournitures, ainsi que dans les plans de réversibilité pour toutes les prestations de services récurrentes.
Autres brèves
- Le devoir d’information du concepteur de progiciel (Mise en ligne Février 2008)
- Tierce maintenance applicative (TMA) : enjeux et tendances (Mise en ligne Juillet-Aout 2007)
- La simple correction d’anomalie ne donne pas lieu à la création d’un logiciel dérivé (Mise en ligne Juin 2006)
- L’appréciation des vices cachés (Mise en ligne Mars 2002)
- La maintenance évolutive (Mise en ligne Décembre 1999)
- La maintenance préventive (Mise en ligne Décembre 1995)
- L’appréciation de la conformité (Mise en ligne Janvier 1995)
- La maintenance curative (Mise en ligne Février 1993)