Lors de la mise en œuvre d’une démarche SOA outillé, je fais souvent le constat que l’interconnexion est assez coûteuse en effort humain. Il faut beaucoup communiquer pour clarifier les mécanismes envisageables, identifier les contraintes, définir les capacités du système, mettre en corrélation avec les patterns existants, etc. tout ceci avec de nombreux interlocuteurs : les chefs de projets, les architectes logiciels, les architectes systèmes, les architectes SOA et les urbanistes. Malgré tous ces efforts et après d’âpre discussions, le propriétaire du système craint alors des impacts sur ses flux existants et veut donc, tout naturellement, minimiser l’impact de ces nouveautés.
Derrière ce constat se cachent 2 problématiques :
- le manque de confiance dans la gestion du changement
- le manque de contrôle vis-à-vis de cet usage imposé.
Ce constat est exaspérant car il est consommateur d’une énergie folle. Il faut constamment se réunir et se synchroniser pour expliciter les besoins, décrire les données transférées, demander l’exécution d’un service (ensemble de règles) et faire correspondre avec les patterns et les outils d’interconnexions existants. Petit ou gros changements, l’effort humain pour faire aboutir ces besoins est majeur.
Les parties techniques sont souvent les plus simples. Il convient de mettre en place des mécanismes spécialisés portés par le Bus d’entreprise 9 fois sur 10. Voici quelques exemples:
- Les connecteurs ABAP ou IDOC SAP
- Les pooling et CDC (Change Data Capture) des bases de données
- Les API d’accès aux couches natives
- Exposition de règles par des Web Services
Pour chaque système, une série d’interconnexions est définie, prototypée puis validée.
Bref, chaque système subit l’évolution de son écosystème. En fonction des demandes externes, transverses ou globales, des interfaces supplémentaires sont ajoutées au fur et à mesure.
Si l’on s’attarde sur les causes, 1 système est principalement impacté lors de l’émission d’une demande de changement (ie l’exigence). En fonction de ses dépendances avec les autres systèmes, il doit trop souvent répercuter cela. Les impacts en cascade sont malheureusement courants car pour manipuler une nouvelle donnée d’autres liens sont à réaliser.
Il y a donc une dépendance directe ou indirecte à exigence initiale. Ce point est problématique car je vous rappelle que la démarche SOA a pour principal objectif de réduire l’adhérence entre les systèmes en proposant une vision métier transverse et stable.
Si l’on revient à notre cas, l’exigence engendre des changements multiples sur N+1 systèmes. Comme les exigences sont multiples et diffuses dans le temps, les systèmes bougent sans arrêt.
Impacts des Exigences :
- T0 : E1 -> S1 -> S2 et S3
- T1 : E2 -> S3 -> S4
- T2 : E3 -> S4 -> S1 et S2
Perspective temporelle | Perspective Système |
Pour arrêter ces cycles infernaux, il faut casser le paradigme de l’attentisme des systèmes. Il faut basculer sur un mode coopératif.
Pour rappel, l’organisation des services SOA selon T.Erl est la suivante :
- Couche Processus
- Couche Services métier / entité
- Couche Utilitaires
Les usages consomment les Processus et les Services Métier alors que chaque service d’une couche utilise ceux des couches inférieures.
L’approche que je vous propose est de positionner une couche de Ressources métier sous la responsabilité des systèmes. Ceux-ci en deviennent donc maitre et par conséquence choisissent les services et les API qu’ils exposent. Ils mettent à disposition leurs Ressources métier au reste du SI.
Chaque système doit exposer volontairement ses « ressources principales » afin de créer rapidement de la valeur au niveau de l’entreprise.
Exemple pour un système SAP: Pour un ensemble d’objets métier, ceux-ci sont exposés systématiquement de la manière suivante :
- Consultation d’un objet sur ID
- Recherche sur critères simples
- Edition d’un objet sur ID
Les objets peuvent être les articles, les clients, les agences, etc. sur le domaine de vente par exemple. Les mécanismes d’interactions sont alors factorisables et maitrisés par l’équipe SAP. Les protocoles techniques sont spécifiques, propriétaires et optimisés pour SAP: tRFC / IDOC pour les éditions et Web Services pour les consultations et recherches.
L’effort d’exposition au reste du SI est alors mieux partagé et moins consommateur en énergie. Pour faciliter ces efforts, il est préférable de travailler par domaine fonctionnel afin d’exposer des grappes métier cohérentes et regrouper les efforts d’exposition. Enfin, seules les ressources principales sont proposées, l’exposition de ressources secondaires doit rester « à la demande » pour une simple raison de maîtrise des coûts.
Cette approche est tout simplement empruntée à l’API Management qui a pour vocation de proposer des ressources sans lien avec leurs usages. La barrière ainsi construite casse le rythme des évolutions constantes et stabilise enfin le système sur son périmètre fonctionnel principal. Le parallèle s’arrête là. Technologiquement, il n’y a pas d’obligation à proposer la stack de l’API (REST, JSON, SoAuth, etc). Comme illustré avec SAP, les outils et frameworks doivent être cohérents et homogène avec l’application. Une rupture technologique non maitrisée ne ferait que réduire l’agilité de celle-ci.
L’organisation de T.Erl est aussi bien respectée. Les services Métiers utilisent ces API de ressources pour :
- proposer de la plus-value
- garantir la cohérence entre les applications du SI
- factoriser les comportements d’entreprise.
A contrario, les services de Ressources n’exposent pas de modèle pivot. En cas de besoin, des services Ressources Proxy peuvent être crées et proposées dans la couche Services métier.
Par ailleurs, cette approche facilite l’externalisation de l’orchestration des intégrations applicatives. Sur la base de services de ressources, une série de services d’intégration va coordonner les échanges. Ceci est d’ailleurs préférable pour les ERP et autres solutions spécialisées (WMS, etc.) car les développements spécifiques sont minimisés.
Exemple : Lors de la réception d’une facture d’un partenaire (interne ou externe), le service de coordination va utiliser les ressources SAP suivant des contraintes et des règles SAP pour répondre à ce besoin.
Ces services de coordination exploitent uniquement les ressources d’une même et unique application. Ils sont donc sous la responsabilité des acteurs de ce système. L’évolution en sera donc facilitée car maitrisée par des compétences fonctionnelles fortes.
Par ailleurs, ces services ne sont pas à positionner dans le moteur d’orchestration des services d’entreprise. Ils peuvent utiliser un outillage similaire mais :
- Ils ont une liberté importante pour exposer des objets métier de leur périmètre. Il n’y a pas d’usage de modèle pivot.
- Les rejeux et les reprises ne concernent que leur périmètre.
- Ils ne sont pas nécessairement avec état.
A la différence avec ces services applicatifs, les services d’entreprise sont agrégateurs, facilitateurs, cohérents et respectueux des services de chaque périmètre applicatif.
En conclusion, cette méthode apporte une plus grande souplesse dans la gestion des nouveaux usages. Ainsi lors de la construction de nouveaux besoins, l’effort est moindre car les ressources sont plus nombreuses et agnostiques de l’usage. Les services et les API d’entreprise, cf. article, réutilisent les ressources stables de l’entreprise. L’adhérence est alors bien plus faible !
La construction de plus-values est accélérée grâce à un socle plus stable, plus simple et moins coûteux en management.