ArchiMate est un langage de modélisation développé par l’Open Group, basé sur les concepts TOGAF, qui permet de partager un langage commun pour décrire, analyser et visualiser l’architecture d’entreprise. Le but ? Aider à la prise de décision des transformations de l’entreprise.
Résultat d’années de réflexions (travaux débutés en avril 2020), la nouvelle spécification ArchiMate 3.2 est publiée le 18 octobre 2022.
L’objectif de cet article est de montrer l’exhaustivité des modifications apportées par la spécification 3.2 d’ArchiMate.
Voici une synthèse de ces modifications qui seront détaillées plus bas :
La couche physique devient un composant de la couche technologie
Modification de la notation
L’ensemble des éléments ont maintenant deux notations : sous forme de boite et d’icône
Tous les éléments de la couche Implémentation et Migration sont désormais de la même couleur
Modification des méta-modèles
Reformulation des définitions de Outcome, Constraint, Business Function, Product et Technology Interface
Modification des relations dérivées
Ajout d’une règle de dérivation pour un élément Grouping
Modification majeure des restrictions
La couche physique devient un composant de la couche technologie
Jusqu’ici indépendantes, Archimate 3.2 intègre la couche Physique dans la couche Technologie.
Les modifications de la notation
Deux changements majeurs dans la notation ArchiMate sont apportés par la spécification 3.2 :
L’ensemble des éléments ont maintenant deux notations : sous forme de boite et d’icône
Tous les éléments de la couche Implémentation et Migration sont de la même couleur
Nous avons fait le travail de synthèse des modifications de la notation dans le tableau suivant :
Modification de la notation ArchiMate 3.2
Voici donc la nouvelle notation Archimate 3.2 :
Notation ArchiMate 3.2
La modification de définitions
ArchiMate 3.2 clarifie et simplifie les définitions des concepts Outcome, Constraint, Business Function, Product et Technology Interface.
Issu de la spécification ArchiMate, nous avons synthétisé l’ensemble des modifications de définitions dans ce tableau (rouge : supprimé ; vert : ajouté) :
Couche
Élément
ArchiMate 3.1
ArchiMate 3.2
Motivation
Outcome
Represents an end result.
Represents an end result, effect, or consequence of a certain state of affairs.
Motivation
Constraint
Represents a factor that limits the realization of goals.
Represents a limitation on aspects of the architecture, its implementation process, or its realization.
Business
Business Function
Represents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.
Represents a collection of business behavior based on a chosen set of criteria such as required business resources and/or competencies, and is managed or performed as a whole.
Business
Product
Represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
Represents a coherent collection of services and/or passive structure elements, accompanied by a contract, which is offered as a whole to (internal or external) customers.
Technology
Technology Interface
Represents a point of access where technology services offered by a node can be accessed.
Represents a point of access where technology services offered by a technology internal active structure can be accessed.
La modification des méta-modèles
La spécification 3.2 modifie les méta-modèles des couches Business, Technologie, Physical, et des liens entre la couche Implémentation et Migration et l’aspect Motivation.
Voici les évolutions de ces méta-modèles :
Business Composite Elements
Technology Layer Metamodel
Technology Passive Structure Elements
Physical Elements Metamodel
Relationships of Implementation and Migration Elements with Motivation Eléments
En synthèse, les modifications des méta-modèles apportent les changements suivants :
Ajout des relations
Agrégation et Composition du Product au Contrat
Agrégation et Composition entre Node, Device, System Software, Equipment et Facility
Assignation du Device à l’Artifact
Assignation du System Software à l’Artifact
Réalisation du Matériel à l’Equipement
Composition et Agrégation du Plateau à l’Outcome
Réalisation et Influence du Work Package au Requirement
Suppression des relations
Réalisation entre des Nodes
Assignation des éléments technologiques de structure active à l’Artifact
Modification des liens d’héritage
System Software, Device, Equipment et Facility n’héritent plus du Node et héritent des éléments technologiques de structure active
Artifact, Material et Path sont des éléments technologiques de structure passive
Évolution des relations dérivées
Dans le but de réaliser des analyses d’impacts plus poussées, la spécification ArchiMate 3.1 avait introduit la notion de relation dérivée :
Si on a deux relations p(b,a):S et q(b,c):T avec a, b, c des éléments, p et q des relations respectivement de type S et T, alors on cherche à connaître la relation r de type U tel que r(a,c):U.
ArchiMate 3.1 définit :
Des règles de dérivation strictes, qui s’applique quel que soit le modèle
Des règles de dérivation potentielles, qui peuvent s’appliquer en fonction du modèle
Des restrictions sur les règles de dérivation
En complément, Archimate 3.2 :
Réécrit totalement les restrictions sur les règles de dérivation, qui étaient jusqu’ici difficiles à lire
Ajoute une règle de dérivation potentielle pour un élément Grouping : S’il existe deux relations p(b,a):S et q(b,c):T, avec S une relation de type Agrégation ou Composition, b un élément de type Grouping et T une relation de type Realization ou Assignment, alors une relation r(a,c):T pourrait être dérivée seulement si le métamodèle permet une relation T de a à c.
Conclusion
Les modifications du langage de modélisation Archimate apportées par la spécification 3.2, bien que mineures, permettent d’homogénéiser la notation, d’améliorer le méta-modèle et de supprimer des ambiguïtés par la clarification à la fois des définitions et des règles de restrictions des relations dérivées.
Il n’est pas toujours évident de s’y retrouver dans la jungle que constituent les différents comités en entreprise, et les comités d’architecture ne font pas exception. Vous êtes perdus et ne savez pas comment définir la comitologie qui répondra aux besoins de votre organisation ? Suivez le guide !
Dans cet article, nous aborderons deux grandes étapes :
la définition de la comitologie d’architecture, dans un premier temps,
suivie par un focus sur l’animation de cette comitologie.
Une comitologie utile et intéressante doit être construite pour répondre à vos objectifs
Identifier clairement les objectifs de la comitologie
Les objectifs des organisations étant très divers, il est naturel qu’une myriade de comités d’architecture différents existent :
des comités transverses ou spécifiques à un programme de transformation,
des comités de partage entre architectes,
ou des comités d’arbitrage.
L’un des écueils principaux consiste à faire surgir dans les agendas autant de comités que de champignons après les premières pluies d’automne. On voit souvent des participants occasionnels se mélanger les pinceaux avec les trois ou quatre réunions portant un nom approchant. Et s’ils ne savent pas les différencier, nul doute qu’ils ignorent leurs objectifs…
Mais dans ce cas, comment créer une comitologie d’architecture claire, lisible et utile ?
Afin de choisir la plus adaptée, il est tout d’abord capital de bien comprendre le contexte de votre entreprise et d’identifier vos objectifs. Cela peut passer par des interviews mais aussi être exploré dans le cadre d’un audit de maturité de l’architecture, qui comporte un volet sur la comitologie.
Définir ensemble la comitologie qui répond aux objectifs identifiés
Une fois les objectifs clarifiés, la construction collaborative de la comitologie peut ensuite débuter !
Rhapsodies Conseil vous aide à dessiner la comitologie qui vous conviendra le mieux en s’appuyant sur :
les éléments de contexte,
un catalogue d’exemples de comités d’architecture,
un arbre de décision.
Votre connaissance fine de l’organisation dans laquelle vous évoluez sera également précieuse et devra être prise en compte.
Vous obtiendrez à terme une description des différents comités d’architecture à mettre en place précisant :
leurs objectifs,
la fréquence à laquelle ils seront tenus,
leurs périmètres respectifs,
les différents participants.
Ces éléments seront bien sûr diffusés au sein de l’organisation pour bien expliquer le rôle du ou des comités d’architecture. Bien communiquer en amont de la mise en place des comités permettra de s’assurer que tous les participants, récurrents ou occasionnels, n’aient pas de doutes sur leurs objectifs.
Il ne reste plus qu’à les mettre en œuvre et les animer !
Pas si simple me direz-vous ? Comment s’assurer que cette comitologie soit animée de manière efficace et réponde ainsi aux objectifs de l’organisation ?
Tout en évitant à tout un chacun d’écouter distraitement d’une oreille en travaillant sur un autre sujet en parallèle ou en traînant sur son téléphone…
Eh bien, en s’appuyant sur le PMO de l’architecture !
Le PMO de l’architecture : cet acteur clé qui rend vos comités efficaces et productifs
Qui est le PMO de l’architecture ?
Ce terme de “PMO” a été dévoyé et il peut paraître n’être qu’un scribe qui n’apporte pas de vraie valeur ajoutée. Notre conviction chez Rhapsodies Conseil est la suivante : cet acteur doit avoir une culture de l’architecture d’entreprise. Il peut alors faire tellement plus pour l’équipe architecture que compléter un fichier excel une fois par mois !
Il dispose ainsi de nombreuses compétences :
bonne connaissance du SI
maîtrise de la gouvernance de l’architecture,
bon relationnel,
compréhension de l’organisation et du rôle de l’équipe d’architecture,
compréhension des enjeux projets,
connaissance des dossiers d’architecture et des modèles,
techniques d’animation de réunions.
C’est pourquoi il est le plus à même d’animer la comitologie d’architecture et de la rendre intéressante pour l’ensemble des participants, décideurs y compris.
La première activité du PMO de l’architecture : sélectionner et vérifier les dossiers d’architecture
C’est lui qui propose un ordre du jour en fonction de la maturité et du niveau d’urgence des dossiers d’architecture. Il vérifie que ceux-ci sont bien complets avant leur passage en comité. Il comprend les enjeux et peut donc appuyer les différents architectes dans la préparation de leurs dossiers. Il dispose aussi de templates de dossiers d’architecture afin de guider les architectes nouvellement arrivés dans la rédaction de leurs premiers dossiers.
Une bonne préparation avec des attendus précis, dont le PMO de l’architecture est le garant, permet d’éviter bien des désillusions en comité… Et de devoir à de nombreuses reprises rapporter les mêmes éléments complémentaires devant des participants qui ont oublié une bonne partie du sujet…
Le PMO de l’architecture est aussi en charge de l’animation des comités le jour J
L’animation des comités en tant que tels fait également partie de son rôle : il partage l’ordre du jour, suit le bon déroulement du comité, recueille les avis en séance et prend les notes explicatives. Il établit le relevé de décision et partage le compte-rendu aux différents participants.
Il peut aider à remettre le comité sur le droit chemin quand les échanges s’enlisent.
Un suivi est mis en place par le PMO pour que les décisions ne restent pas lettre morte
Suite aux comités, il réalise le suivi des dossiers en fonction des décisions :
passage en mode projet,
programmation d’un deuxième passage du dossier,
études à refaire ou à compléter.
Il établit donc les ordres du jour des prochains comités.
Ce suivi fin des ordres du jour permet d’éviter ce que l’on voit parfois :
un ordre du jour déformé car il a été mal compris par la personne chargée du suivi,
la présentation d’un sujet devant des décideurs qui ont oublié l’avoir demandé.
Il peut identifier les décisions qui donnent lieu à de la dette et en faire le suivi.
De plus, connaissant les différents dossiers en cours, il maîtrise les dépendances entre les sujets. Il est donc à même de prévenir les architectes dont les sujets peuvent être impactés par les décisions du comité. Le PMO de l’architecture ayant une vision globale de l’avancement des sujets, il peut créer du lien entre les architectes. Cela permet aussi d’assurer que l’ensemble des décisions prises lors des comités restent cohérentes.
Le PMO de l’architecture participe également à l’amélioration continue de la gouvernance de l’architecture
Enfin, son rôle transverse lui permet de construire le reporting de la comitologie : il suit le nombre de dossiers qui passent en comité, les décisions et les avis émis… Il peut alors proposer des améliorations de la comitologie afin d’optimiser la gouvernance de l’architecture. Il pourra donc vous aider à ajuster la comitologie si nécessaire en fonction de ce qu’il observe en comité et des issues des présentations.
J’ai tenu ce rôle pendant 1 an et eu la chance de travailler avec des collègues qui avaient aussi tenu ce rôle. J’espère que cette synthèse vous sera utile et que vous connaissez désormais mieux le PMO de l’architecture, cet acteur qui garantit le succès de vos comités. N’hésitez pas à nous contacter pour échanger sur vos retours d’expérience.
Savez-vous que lancer les développements d’une solution sans modélisation de données, c’est comme construire une maison sans en avoir fait les plans ?
Si vous voulez avoir des solutions performantes et pérennes pour vos projets de transformation de vos SI, utilisez la modélisation de données, et en particulier la modélisation de données conceptuelle, comme un levier de performance.
Stocker des données n’est pas modéliser des données
Très souvent après avoir validé vos projets de transformation des SI pour atteindre les enjeux métier d’entreprise, l’objectif est de rapidement importer les premières données pour pouvoir les rendre ‘visibles’ et avoir des premiers résultats ‘concrets’.
Des développements sont donc lancés, sans l’étude préalable des données et des concepts nécessaires pour faire le lien avec le métier de l’entreprise. Ces développements conduisent à définir des tables et des jointures avec pour objectif de stocker des données. C’est la modélisation de données dite physique. L’objectif n’est pas le bon à ce stade. C’est une vision de solution court-termiste.
Une notion importante à appréhender est que le stockage des données et la structure de la base de données impactent directement la restitution, et donc l’usage des données. Cette structure est développée au travers du modèle de données physique.
Si vous mélangez les notions de modèle de données physique et de modèle de données conceptuel, et si vous ne comprenez pas bien les concepts fonctionnels manipulés, alors le modèle de données physiques ne répondra pas à tous les besoins adressés.
Toutes ces questions sont adressées au travers de la modélisation de données et en particulier la modélisation de données conceptuelle.
Dès lors, quels sont les objectifs de la modélisation de données ?
Nous avons vu que lorsque nous pensons modélisation de données, nous pensons tables, jointures, clefs étrangères. En réalité, cela revient à penser, tuyaux en PVC ou en cuivre, briques ou parpaings, avant même de savoir si nous souhaitons une maison de plain-pied ou à étages. La modélisation de données conceptuelle est donc une obligation.
Le modèle de données conceptuel conceptuel permet de définir des concepts (étonnant, non ?) transverses à l’entreprise, clairement définis entre les parties prenantes. Ces concepts sont liés pour répondre à un ensemble d’usages, qui lorsqu’ils sont regroupés dans des fonctions (définies au travers de l’architecture fonctionnelle), constitueront la solution informatique répondant aux besoins.
Le modèle de données conceptuel doit d’abord répondre à des usages propres au métier de l’entreprise. Prenons un modèle de données client par exemple. Il sera différent pour un assureur ou pour un industriel. Il sera également différent entre deux assureurs du fait de leur positionnement sur le marché. Le modèle conceptuel est donc basé sur l’utilisation des données qu’il contient : les usages valident le modèle.
La modélisation de données : une démarche à valeur ajoutée pour la DSI et surtout pour le métier
Le modèle de données conceptuel décrit les données stockées dans la solution de manière compréhensible par les métiers. D’autre part, il impose une démarche rigoureuse de conception concourant à la réussite du projet.
La modélisation de données doit ainsi commencer par lister les usages et les données sous-jacentes ou associées. S’entourer à la fois d’experts des données et d’experts métier est donc la clé. En effet, nous avons mis en évidence plus haut que le modèle de données conceptuel doit répondre aux deux enjeux à la fois :
Les experts des données sont responsables de découvrir et connaître les données, leur qualité réelle et leur utilisation réelle.
Les experts métiers sont responsables eux de décrire les usages actuels et cibles de ces données. Les usages étant les processus métiers de l’entreprise dans lesquels vont être utilisées ces données, mais aussi les contraintes liées à la mise à disposition de ces données (réglementaires, sécurité, etc.).
Construire et valider le modèle de données conceptuel est donc une démarche itérative afin d’échanger très régulièrement entre le métier, les experts de la donnée et la DSI.
Un modèle de données conceptuel performant est avant tout un modèle métier qui traduit des besoins métiers : on ne peut modéliser sans avoir une expression de besoin décrivant les usages.
La modélisation conceptuelle s’inscrit également dans une démarche de gouvernance des données. En effet, les premières questions posées naturellement quand le modèle de données se construit sont par exemple : quelle est la définition de ce concept ? dans quel cycle de vie s’inscrit-il ? etc. Les métiers définissent les concepts, les périmètres et les responsabilités avec le modèle de données conceptuel.
Avec cette démarche, en tant que DSI, vous minimisez les risques de choix court-termistes et de complexité de la solution développée. Vous bénéficierez ainsi d’une solution évolutive, maintenable, documentée et qui minimise également le shadow IT.
En tant que métier, cela vous permet d’être au plus proche des développements et vous comprenez grâce au modèle de données conceptuel, les données manipulées dans la solution. Vous minimisez ainsi les risques d’inadéquation avec les attentes métier.
En tant que responsable projet, product owner, ou responsable SI, imposez donc d’avoir une démarche de modélisation de données qui commence par un modèle conceptuel dans tous vos projets SI. Il est un facteur clef de réussite !
La modélisation de données : une compétence clé
La gestion du cycle de vie du modèle de données conceptuel et des impacts sur le stockage des données (base de données), doivent être suivis et validés par une personne experte en modélisation de données. Le cycle de vie du modèle de données est un processus lent dont les évolutions ne se voient pas forcément.
Une modélisation de données performante doit garantir une cohérence, une intégrité et une interopérabilité des données et des solutions. Une mauvaise modélisation de données crée ainsi lentement des blocages SI pour de futurs usages. Une illustration simple de cette mauvaise modélisation de données, est de laisser en attributs des données qui ont des cycles de vie différents de l’objet auquel ils sont rattachés. Multipliés par le nombre de données à l’échelle de l’entreprise et ajoutés à la complexité d’un modèle, ces problèmes de modélisation de données rendent le SI rigide.
La modélisation de données est donc une compétence spécifique. C’est une expertise qui s’acquiert au fur et à mesure des projets. Elle est nécessaire aux équipes de conception telles que les Business Analysts et les Architectes de données.
La modélisation de données, un facteur clef de succès de la transformation des SI
La modélisation des données est donc indispensable à un projet de développement de solution informatique. Comme évoqué précédemment, avec le modèle de données conceptuel, elle manipule des concepts métier de l’entreprise. Elle doit donc se projeter et anticiper les nouveaux concepts nécessaires aux nouvelles demandes client. Elle garantit ainsi l’agilité et l’évolutivité de votre solution face à la diversité des usages à adresser pour répondre aux demandes client en perpétuelle évolution.
Une question reste alors : la modélisation de données dépendant de la qualité des données des concepts métier, est-ce que les processus métier actuels de l’entreprise peuvent être modifiés pour fournir la qualité des données nécessaires aux nouvelles demandes client ?
Les projets d’API Management sont fondamentalement simples. Il s’agit de faire échanger des données d’un système A vers un système B. Mais c’est sans compter sur le fait qu’un projet d’API Management fait intervenir un grand nombre d’acteurs, ce qui engendre de la complexité.
Les acteurs de la gestion des API
Pour commencer, nous pouvons énumérer les acteurs typiques impliqués :
Le CxO qui a décidé que les API faisaient partie de la stratégie de l’entreprise, mais qui ne vous donne pas un parrainage très fort ;
Les autres CxOs qui ont d’autres priorités que les APIs ;
L’équipe A qui veut accéder à des données, mais qui n’a pas le temps de s’occuper de vous ;
L’équipe B qui est responsable de données exposées, mais qui n’a pas de temps à vous consacrer ;
Les développeurs de la solution qui veulent accéder aux données ;
Les développeurs de la solution qui exposent les données ;
Les membres de l’équipe de gestion de l’API ;
Et au moins un architecte, bien évidemment !
On voit bien qu’il y a une multiplicité d’acteurs, qui vont tous pousser dans leur propre direction. Et on perd rapidement toute forme de coordination si :
L’équipe de gestion de l’API ne joue pas un rôle de coordination constructif ;
Il n’y a pas de parrainage des membres du CxO.
Le défi de la complexité
Il est donc nécessaire de maîtriser la complexité de l’entreprise et la complexité due à ses interactions et à ses acteurs. En effet, selon la théorie des systèmes complexes, la complexité du système « entreprise » réside dans le nombre élevé d’acteurs et le nombre élevé d’interactions entre eux !
Ce qui est complexe, ce n’est pas de faire une API avec un acteur, mais de faire une API avec, par et pour de multiples acteurs.
Il est donc fondamental de :
Chercher à aligner tous les acteurs dans la même direction par une très bonne communication, des explications sur les bonnes pratiques, etc. ;
Faire de l’équipe de gestion des API un point d’échange central pour toute conversation sur les API ;
Infuser les connaissances dans toutes les équipes autant que possible.
A partir de là, on peut déduire deux prérequis :
Une gouvernance claire, simple et efficace est essentielle ;
Un sponsorship solide doit garantir l’alignement de l’entreprise sur un projet d’API.
Le mode d’organisation le plus souvent utilisé est le mode de gouvernance que j’appelle open source. L’équipe API encadre, guide, aide, soutient, mais surtout permet à chacun de contribuer facilement et efficacement.
De ces activités et défis ainsi énumérés, nous pouvons ainsi déduire deux types d’activités.
Deux typologies d’activités de l’équipe API
On peut ainsi diviser les activités d’une équipe API en deux types d’activités : les activités régaliennes et les activités étendues. En effet, la gouvernance d’une équipe de gestion d’API doit fixer un cadre dans lequel tous les acteurs impliqués dans les API doivent s’inscrire, afin que tous les acteurs puissent pleinement travailler.
Les activités régaliennes
Nous pouvons appeler activités régaliennes les activités pour lesquelles l’équipe de gestion des API a toute l’autorité et ne peut être supprimée. Dans ces activités, nous pouvons mettre :
La mise en œuvre et l’administration technique de la plateforme API Management.
La définition des meilleures pratiques de gestion d’API.
Les formats des ateliers de définition des API – pour passer de réunions interminables et contre-productives à des réunions efficaces et productives. J’ai personnellement réduit par 4 le nombre d’ateliers, juste en repensant la façon dont nous les animons !
L’organisation des ateliers API – Pour être le moteur des sujets API, mais libre à l’équipe API Management de laisser les équipes concernées s’organiser elles-mêmes si elles sont suffisamment autonomes.
La gestion de la formation et de la communication – Pour assurer l’adhésion des équipes, et pour démontrer la valeur ajoutée des équipes d’API Management.
Les activités étendues
Certaines activités doivent cependant être menées non pas sur un mode purement régalien mais sur un modèle beaucoup plus collaboratif, car après tout, il s’agit d’organiser les échanges entre au moins deux systèmes :
Définir et gérer le cycle de vie des API avec les projets et les architectes fonctionnels – Même si l’équipe API a le dernier mot, elle reste au service des projets et du métier ! Ne l’oubliez jamais !
Travailler avec les architectes sur l’alignement des besoins en API dans une feuille de route claire – Les architectes sont censés avoir une vision à moyen et long terme des besoins futurs, les équipes API sont censées s’aligner sur eux !
Outiller pour les développeurs afin d’apporter les bons outils et cadres de travail – Dire à un projet « allez-y et faites l’API » n’est pas suffisant ! Dites-le à un projet Legacy ! C’est aux équipes API de travailler avec les projets pour moderniser la base technique, la distribuer et la partager avec d’autres équipes de développement.
Contribuer à l’idéation avec les métiers pour trouver de nouvelles idées d’API – Le but étant de tirer le maximum de valeur des actifs de l’entreprise.
2 typologies de gouvernance, ou plutôt 2 “curseurs” de gouvernance
Enumérer une liste de tâches n’est pas pour autant équivalent à définir une gouvernance API.
De ces deux typologies d’activités, on remarque que le pattern “décentralisée” revient forcément.
En effet, le mode de gouvernance qu’on pourrait appeler “décentralisée” revient très souvent. Dans ce mode de gouvernance, l’équipe d’API Management a comme but principal de permettre à tout à chacun de contribuer facilement et efficacement. Ainsi, charge à l’équipe API Management de cadrer, orienter, aider, d’apporter du support, mais pas nécessairement d’implémenter et définir les APIs. C’est une logique de gouvernance qui cherche avant tout à permettre aux autres équipes de travailler de manière autonome.
Dans une logique totalement inverse, l’autre mode de gouvernance que l’on rencontre régulièrement est une gouvernance centralisée. Le centre de compétence d’API regroupe alors toutes les compétences nécessaires, et travaille de manière auto-suffisante.
Pour autant, rares sont les entreprises qui mettent en place une gouvernance aussi “marquée” par une de ces deux logiques. Toute la question est de pouvoir s’adapter à l’organisation de l’entreprise et de son SI, mais aussi de s’adapter à la maturité et à l’autonomie des équipes en place. Il faut toutefois bien chercher à autonomiser les équipes, sans quoi il vous sera impossible de “scaler” votre organisation autour des APIs, sans compter les effets de bord d’une logique de tour d’ivoire…
Il y a encore aujourd’hui de nombreuses entreprises qui ne misent pas encore sur les API et qui se demandent encore comment faire. Elles se retrouvent souvent bloquées par le grand nombre de questions qui se posent à elles, ne sachant pas comment aborder ce genre de projets. Elles se retrouvent rapidement bloquées. C’est pourquoi je préconise une démarche MVP.
L’approche MVP pour un projet d’API Management
Parler d’approche MVP pour d’aussi gros projets peut surprendre. En effet, les points à soulever sont nombreux, que l’on parle de sécurité, des solutions techniques, de l’organisation, de la roadmap API ou encore de la définition de bonnes pratiques.
Mais les avantages d’une démarche MVP pour un projet d’API Management sont nombreux :
Démontrer la valeur :
En mettant en place la première API en mode MVP, il est possible de communiquer plus rapidement aux métiers ce que l’on peut désormais faire grâce aux API.
Démontrer la faisabilité :
Dans le cas de systèmes Legacy complexes, encore plus s’ils sont cloisonnés, les raisons sont nombreuses de penser qu’il sera long et compliqué de mettre en place des API. Grâce à l’existence de nombreux modèles d’architecture d’intégration (comme le CQRS), il est plus facile qu’on ne le pense de faire sauter les verrous !
Obtenir des retours d’expérience :
Plutôt que les audits SI et autres audits de maturité, qui sont longs et pas toujours pertinents, rien de tel que des REX réguliers pour faire avancer un projet d’API Management.
Prioriser les initiatives :
Grâce aux premiers retours d’expérience, il est possible de savoir quelle initiative prioriser. La gouvernance doit-elle être étudiée ? La stratégie d’intégration ? La communication interne ?
Réduire les risques :
La démarche MVP permet d’adopter une approche totalement intégrée, avec des décisions de type Go/NoGo à chaque étape. Vous courrez donc un risque réduit à sa portion la plus congrue.
Cette approche MVP peut rapidement aboutir à une première API en un mois, certes imparfaite, mais utilisable. Est-ce qu’il y aura encore des questionnements après un mois ? La réponse est évidente : c’est oui ! Et vous serez même en mesure de classer ces questionnements par ordre de priorité !
Approche MVP et grandes étapes
Une approche MVP étalée sur quatre semaines est clairement réalisable, pour peu qu’on suive les grandes étapes suivantes :
Définition du périmètre (première semaine) :
Choix d’une API candidate :
Vous allez d’abord choisir une première API en fonction de sa facilité à être instanciée et de la valeur qu’elle apportera. Visez le gain rapide !
Lister les attendus :
Plusieurs contraintes techniques, fonctionnelles et autres sont susceptibles d’être émises par les parties prenantes, qu’ils soient métier ou IT. Collectez-les !
Visioning (deuxième semaine) :
Définition de l’architecture :
Vous devez ensuite définir l’architecture cible de votre gestionnaire d’API. Une solution sur site ? dans le nuage ? L’important est de le faire rapidement. Ce n’est pas compliqué de changer le gestionnaire d’API, vous aurez le temps de le changer plus tard. Visez vite et pas cher ! Et n’oubliez pas les sujets d’authentification.
Définition de l’API :
Il vous faut ensuite définir l’API. Un travail à faire de concert avec les métiers, les développeurs et les architectes.
Validation :
Partagez enfin votre API et votre architecture avec tout le monde, pour la valider.
Construction (troisième semaine) :
Installation des composants :
Il est donc temps d’installer votre gestionnaire d’API ! N’oubliez pas, dans le cas de solution cloud, de vérifier s’il n’y a pas de contraintes de sécurité à gérer !
Développements :
Rien n’est plus simple que d’instancier une API, avec son interface. Et n’oubliez pas les sujets d’authentification (bis repetita).
L’intégration et les tests avec les systèmes consommateurs :
Bien sûr vous devez tester. Avec toutes les parties prenantes disponibles, idéalement en même temps…
Rétrospective (quatrième semaine) :
REX technique et métier :
Faites des démonstrations de votre API, avec présentation de la plateforme d’API Management. Ce faisant, vous obtiendrez des retours techniques et métiers.
Initiatives à venir à prioriser :
C’est le bon moment pour lister les prochaines initiatives. Comme les retours d’expérience viennent d’être faits, il n’est pas question de tout arrêter. Continuez !
En respectant ces étapes, vous serez en mesure de poursuivre votre programme API grâce au travail des initiatives priorisées, mais surtout, de pouvoir continuer sur votre lancée ! Et n’oubliez pas que les projets d’API Management nécessitent beaucoup de communication et d’évangélisation !
J’ai analysé Pro Santé Connect, un service fort intéressant avec plein de potentiels, réalisé dans les règles de l’art et qui suit les standards actuels du domaine de l’authentification. Mon retour : j’adore ! (oui bon laissez-moi mes kiffes hein…).
Pro Santé Connect, c’est quoi ?
Il s’agit d’un service d’authentification et d’identification des professionnels de santé.
Ce service est construit sur les bases des standards du marché actuel : OAUTH2 pour l’authentification et, cerise sur le gâteau, de l’OpenID Connect pour avoir le complément d’information d’identification qui va bien : que pouvons-nous demander de plus ?
À quoi sert Pro Santé Connect ?
Ce service permet qu’un organisme d’état certifie :
La personne qui est en train de s’authentifier est bien celle qu’elle dit être, avec des preuves à l’appui ;
La personne qui accède à mon site dispose bien de certaines caractéristiques qui ne viennent pas d’une auto-déclaration mais d’informations recensées et vérifiées au niveau des organismes d’État ;
Ces informations sont transmises de façon sécurisée et non corruptibles (jetons JWT signés).
Pour être clair, il fonctionne un peu comme France Connect, mais son caractère médical, associé aux caractéristiques spécifiques de la profession, sécurisé et complété par l’OiDC, ouvre la possibilité d’exploiter beaucoup plus d’informations : quel est son lieu de travail ? dans quel établissement ? quelle spécialisation médicale le professionnel pratique ? et d’autres encore…
Pour finir, ces informations peuvent être propagées à des applications tierces, avec un simple transfert de jeton sécurisé, ce qui permet d’éviter les surcoûts et les efforts d’authentification à plusieurs niveaux.
Et alors, on en pense quoi de ce service d’authentification ?
J’adore. Je n’aurais pas fait mieux, ni pire… Techniquement ça a l’air de tenir la route et même plus.
L’utilisation de standards reconnus et plébiscités par le marché, alors que personnellement j’en ai ch…, pardon bavé… Veuillez m’excuser, j’ai eu un peu de mal dans le passé avec des standards d’interconnexion mal documentés, incompréhensibles… Ils étaient pondus par des organismes publics qui, dans un souci de sécurisation, avaient rédigé des documents illisibles et impossibles à utiliser. Bref, je pense qu’ils n’ont jamais rencontré de problèmes de sécurité, vu que personne n’a dû réussir à les implémenter…
Dans le cas de Pro Santé Connect, ceux qui ont déjà implémenté de l’OAUTH2 ou de l’OiDC, se retrouvent dans un cadre familier, clair, bien documenté, enfin un vrai plaisir (bon au moins de mon point de vue hein… laissez moi ce plaisir…). Pour les autres, ces standards sont tellement bien documentés que, avec un peu d’effort de lecture, on peut vite en comprendre les concepts.
Des informations certifiées, complètes, simples à lire ? Il est où le pépin ?
C’est beau tout ça, magnifique, dans ce monde parfait nous n’avons plus rien à craindre ! Plus de questions à se poser ! Nah…
Bon ce n’est pas forcément le cas, une alerte reste d’actualité et se base sur un concept cher à pas mal de DSI : la qualité des données traitées et leur fraîcheur.
Si le service a une chance de marcher tel qu’il est présenté, la collecte des informations devra se faire :
Dans des délais très courts, à partir du changement de situation du professionnel de santé ;
Avec une qualité irréprochable.
Or, la fusion de plusieurs référentiels dans un seul (le RPPS), en cours, plus l’effort que l’ANS semble mettre dans cette initiative, laissent présager des bons résultats.
En conclusion
La voie est la bonne, techniquement pas de surprise, une implémentation reconnue et éprouvée, un service qui nous plaît !
Et maintenant nous attendons le même service pour les personnes physiques, en lien avec Mon Espace Santé et les domaines associés !
