Après quelques retours d’expérience sur des outils d’Architecture d’Entreprise, une question s’est rapidement imposée à moi : pourquoi prendre un EAMS (Enterprise Architecture Modeling System) et quel intérêt peut-il apporter aux équipes projets agiles ?
Certes, ces outils d’Architecture d’Entreprise disposent d’une base de données d’assets variés sur les business capabilities, les applications, les processus, l’infra… Une fois croisées, ces informations représentent une vraie mine d’or, permettant un reporting opérationnel instantané. Pour prendre deux exemples, piloter les coûts directs ou la roadmap d’obsolescence des applications devient un jeu d’enfant grâce à la mise à disposition d’informations de qualité, accessibles sans délai. La prise de décision est plus efficace.
Une fois les données mises en qualité et chargées dans l’outil, il contient nombre d’informations utiles pour les projets. Pour conduire une étude de faisabilité ou d’impacts, l’EAMS fournit la cartographie des interfaces entre applications, voire même les projections (to be) de grands programmes ou projets. Les équipes projets disposeraient instantanément d’informations à forte valeur ajoutée, comme la cartographie globale des flux, des processus métiers de l’entreprise… Sur le papier, l’utilisation d’un outil d’Architecture d’Entreprise pour modéliser les projets présente donc un intérêt certain.
Or, avec la généralisation des projets menés en mode agile, l’outil d’Architecture d’Entreprise correspond-t-il vraiment au besoin des équipes projets ? L’effort de documentation semble lourd et inadapté au cycle de production des équipes agiles. Fonctionnant par itération ou incrément, la vision du produit final évolue en permanence. La documentation complète d’un projet agile risquerait de ne plus coller au besoin, pour finalement ne jamais servir.
Le contenu de l’outil d’Architecture d’Entreprise peut évoluer au même rythme ? L’équation effort fourni-utilisabilité-ROI est-elle avantageuse ?
En somme, l’Agilité sonne-t-elle la fin des outils d’Architecture d’Entreprise ?
L’outil d’architecture d’entreprise : un bon élève comme un autre
Un outil d’Architecture d’Entreprise vise à modéliser l’entreprise dans son ensemble : ses processus métier, ses applications, ses flux de données… A ce titre, plus il est rempli, mieux c’est. Encore faut-il trouver la bonne granularité à décrire. Car plus l’outil est fourni, plus il risque de perdre ses contributeurs, donc de ne pas être tenu à jour et de ne servir à personne.
Ainsi, l’outil d’Architecture d’Entreprise doit contenir assez d’informations pertinentes et de qualité pour intéresser les contributeurs (responsables de domaine, responsables d’application, équipes projets…), mais également pour leur donner envie de compléter ces informations en leur proposant, par exemple, des dashboards et rapports intéressants, des vues synthétiques de l’intégration des applications entre elle, de la couverture fonctionnelle…
Les utilisateurs, et plus particulièrement ceux qui sont contributeurs occasionnels, ne doivent pas perdre un temps fou à trouver une information. L’outil doit être intuitif et simple d’utilisation. Par exemple, si mon projet, mené en mode agile, ne touche que le domaine marketing, je m’intéresserai en priorité aux informations impactant ce domaine. Les informations liées à d’autres métiers ou contextes ne m’intéresseront pas directement. En revanche, bénéficier de référentiels et de toutes les informations liées au contexte de mon projet m’apportera une vraie valeur ajoutée.
Avec du recul, être le meilleur élève de la classe auprès des équipes projets, c’est restituer efficacement l’information auprès des différentes parties prenantes. La valeur ajoutée d’un tel outil n’est pas d’agréger le plus d’informations possible sur tout et n’importe quoi, mais bien d’identifier les informations utiles, les acteurs qui peuvent la fournir et le meilleur moyen de la restituer.
Partir du cas d’usage
Pour éviter un rendez-vous raté entre équipes agiles et outils d’AE, il faut savoir se poser les bonnes questions pour évaluer les bons critères. A quoi mon outil d’Architecture d’Entreprise doit-il me servir ? Qui seront mes utilisateurs ? Quels seront mes principaux cas d’usage ? Optimiser mes processus, rationaliser mon portefeuille applicatif, réduire les coûts IT, préparer un audit du SI, vérifier que je suis en conformité avec la RGPD ?
En tant qu’Architecte d’Entreprise, j’aurai besoin d’une vision globale de mon entreprise, pour mener des analyses croisées, des études d’impacts et orienter les décisions stratégiques.
C’est le même raisonnement qui doit guider l’apport de valeur aux équipes agiles. De quoi ont-elles besoin pour mieux travailler ? Qu’est-ce qui leur manque aujourd’hui ? Concentrées sur leur projet, il leur manque souvent une vision globale et complète, de l’entreprise comme des autres projets.
Le rôle de l’architecture d’entreprise face à l’agilité : l’enabler
Cette vision globale, l’Architecte d’Entreprise en est le garant. Il bâtit une roadmap des projets en cours et à venir, ainsi que de leurs interdépendances. Avec l’Agilité, l’architecte anime la vision de cette roadmap. Il construit et maintient l’architecture cible qui doit résulter de ses projets. Comme la cible évolue en permanence, car les besoins changent en cours de route, il n’est pas envisageable de reconstruire perpétuellement le chemin. L’Architecture d’Entreprise doit savamment doser entre apporter de la visibilité au projet, indiquer la direction et les étapes obligatoires, sans produire une trajectoire trop précise qui ne servira plus dès le premier changement de cap.
Ici, le rôle de l’Architecture d’Entreprise sera de dire au projet dans quel cadre s’insérer, sans leur prescrire une solution que les équipes agiles trouveront d’elles-mêmes. L’Architecture d’Entreprise, rendue accessible grâce à l’EAMS, indiquera par exemple dans quel quartier la maison, c’est-à-dire le projet, doit se trouver, sans pour autant dire à quoi elle va ressembler.
C’est le rôle de l’équipe agile de coller au plus près au besoin du métier et d’y être réactive. Par conséquent, l’outil d’AE ne devra pas représenter un frein à l’Agilité, mais un accélérateur. Dans ce cas précis, nous pourrions parler de facilitateur, ou encore d’ »enabler« , c’est-à-dire que l’outil d’AE, et a fortiori l’Architecture d’Entreprise en elle-même, devient un facilitateur de l’Agilité.
« J’ai les moyens de vous faire parler »
Finalement, l’EAMS sert à rendre accessible au plus grand nombre les bénéfices de l’AE, c’est-à-dire la connaissance accumulée sur l’entreprise et les informations croisées. L’enjeu est bien de faire parler l’outil, de rendre l’information utile et communicante. Pour ce faire, il faut avoir défini les cas d’usage de l’outil. Car, sans savoir ce que je veux, je peux avoir le meilleur outil du monde, jamais je n’arriverai à le faire parler, ni à prouver sa valeur.
Maintenant, il se trouve que les équipes agiles savent se débrouiller pour s’informer. Et qu’elles possèdent leur propre langage. Elles utilisent des outils agiles de type Confluence, Jira, Visio, des sites web, Wiki… Dans son domaine, chacun produit ses modèles et les met à disposition pour aller plus vite.
Ces dernières années, les outils et les formats de restitution se sont multipliés. Historiquement, PowerPoint emportait largement la bataille du support de communication. Or, aujourd’hui, on ne travaille plus de la même manière grâce aux nouvelles méthodes, voire à la nouvelle philosophie, apportées par l’Agilité. Il n’est plus pensable de se contenter d’un PowerPoint ou d’un fichier Excel : les supports sont dynamiques, calculés en temps réel et facilement exploitables, à l’instar des sites collaboratifs, tel SharePoint, qui proposent même d’incorporer des iframes à partir de domaines externes.
Si l’on y réfléchit quelques instants, le dénominateur commun des équipes est de bénéficier d’un outil de communication collaboratif et facile d’utilisation. A ce niveau, une question serait pertinente pour chatouiller les EAMS : l’outil d’Architecture d’Entreprise me permet-il de communiquer rapidement ? De fournir les livrables (études de faisabilité, dossier d’Architecture, roadmap d’obsolescence…) dont j’ai besoin ?
Si certains outils hautement configurables peuvent fournir presque toutes les formes de reporting possibles et imaginables, on peut rarement avoir le beurre et l’argent du beurre. Ainsi, des études de faisabilités, certaines cartographies et autres dossiers d’architecture, ne sont pas d’emblée exploitables et reproductibles dans un outil, une difficulté souvent inhérente au formalisme propriétaire et à la prise en main de l’outil.
On ne peut plus prescrire, alors adoptons un architecte d’entreprise
Pour des raisons de rationalisation des coûts, l’outil d’Architecture d’Entreprise est souvent imposé, sans consultation de ses futurs contributeurs. Or, cela entre en contradiction avec la philosophie des équipes agiles : communication, partage, transversalité… Du fait de leur autonomie, elles sont pleinement capables de choisir les outils qui les aideront à être plus performantes. Pour délivrer de manière continue, elles choisissent les outils qui supportent efficacement leurs méthodes de travail, tout en leur laissant flexibilité et marge de manœuvre.
En revanche, ces outils vivent le temps du projet, négligeant ainsi le collectif et la capitalisation. L’outil d’Architecture d’Entreprise reste la solution privilégiée pour capitaliser sur la connaissance et la cartographie du SI. Certes, l’EAMS ne peut pas être imposé aux équipes projets : il doit être adopté. Mais sa facilité de prise en main, son apport d’informations intéressantes et ses qualités de restitution achèveront de prouver sa valeur.
C’est le parti pris de nouveaux acteurs dans le secteur des outils d’Architecture d’Entreprise et nous nous intéresserons à cette question dans un futur article. La suite dans le prochain épisode !
Les autres articles qui peuvent vous intéresser
22 octobre 2024
Architecture