Outils d’architecture d’entreprise : comment choisir la solution qui vous convient

Les outils d’architecture d’entreprise permettent de cartographier les capacités, les applications, les données et les processus, puis d’en comprendre les liens. Le choix dépend de votre objectif : dresser un inventaire, définir des normes et des feuilles de route, ou vérifier comment le travail s’effectue réellement.

Un référentiel indique ce que vous avez et comment les différents éléments sont censés s’articuler. Il ne montre pas nécessairement ce qui se passe lorsque les personnes utilisent ces systèmes et ces processus.

Cet écart ne signifie pas que les personnes chargées de maintenir l’architecture ont échoué. Le travail évolue, les documents vieillissent et les systèmes opérationnels enregistrent des éléments qu’un modèle statique ne peut pas fournir à lui seul.

À quoi servent les outils d’architecture d’entreprise ?

Les outils d’architecture d’entreprise vous aident à décrire une organisation et les relations entre ses différentes composantes. La plupart répondent à trois grands besoins.

• Inventaire : consignez les capacités, les processus, les applications, les données, les responsables et les dépendances.
• Normes et feuilles de route : appliquez des cadres comme TOGAF ou ArchiMate pour évaluer les changements proposés et planifier le passage de l’état actuel à l’état cible.
• Analyse : comprenez le fonctionnement de l’organisation et les effets possibles d’un changement.

Un référentiel peut vous aider à répondre à des questions comme : quelles applications prennent en charge une capacité, ou quels processus dépendent d’un système ? Il peut aussi fournir aux équipes un vocabulaire commun pour parler des changements.

Mais un référentiel d’architecture n’explique pas automatiquement comment le travail se déroule en pratique. Le nom d’un processus, son responsable et sa description ne révèlent ni la fréquence des chemins d’exception, ni les temps d’attente, ni le nombre de boucles de validation.

Cette distinction guide la suite de la comparaison : les outils de référentiel décrivent ce que vous avez et ce que vous prévoyez de faire ; ProcessMind vous aide à examiner ce que vos systèmes montrent réellement.

Que vérifier pour comparer les logiciels d’architecture d’entreprise ?

Évaluez les logiciels d’architecture d’entreprise en fonction du travail qu’ils doivent prendre en charge, et pas seulement des fonctionnalités présentées sur le site d’un fournisseur.

1. Référentiel et métamodèle : l’outil peut-il représenter vos capacités, vos processus à plusieurs niveaux, vos applications, vos données et leurs relations sans contournement ?
2. Prise en charge des cadres : prend-il en charge ArchiMate et TOGAF dans le produit, ou propose-t-il surtout des éléments de diagramme ?
3. Détail des processus : pouvez-vous passer d’un processus de haut niveau à ses sous-processus, activités, passerelles et variantes ? Demandez à voir un processus représenté à plusieurs niveaux.
4. Lien avec les données : certaines parties de l’architecture peuvent-elles être actualisées ou vérifiées à partir des données opérationnelles, plutôt que de dépendre entièrement de mises à jour manuelles ?
5. Collaboration et autorisations : les équipes peuvent-elles contribuer aux travaux et les examiner ? Les utilisateurs peuvent-ils consulter le référentiel sans licence d’édition ?
6. Hébergement et résidence des données : où vos données sont-elles stockées, qui peut y accéder et cela répond-il à vos exigences ?
7. Interopérabilité : pouvez-vous exporter votre architecture et utiliser des API ou des formats ouverts ? Vous devez pouvoir récupérer vos travaux.
8. Licences : comment les licences des éditeurs, des réviseurs et des lecteurs sont-elles définies ? Comparez le coût total pour toutes les personnes qui ont besoin d’un accès, et pas seulement pour l’équipe principale.

Accordez une attention particulière au niveau de détail des processus et à leur lien avec les données. Une cartographie des capacités peut être utile à la planification, mais elle est plus difficile à mettre en pratique si vous ne pouvez pas la relier aux processus suivis par les équipes.

Demandez aux fournisseurs de montrer comment un modèle est maintenu, jusqu’où vous pouvez descendre dans la hiérarchie des processus et si certaines informations peuvent être vérifiées à partir des données. Leurs réponses vous indiqueront si l’outil peut prendre en charge la couche processus ou simplement la consigner.

Ces vérifications vous aideront à déterminer si vous avez besoin d’un référentiel d’architecture d’entreprise, d’une couche de preuves sur les processus, ou des deux.

Quel outil d’architecture d’entreprise répond à chaque besoin ?

Les différentes catégories d’outils d’architecture d’entreprise répondent à des besoins distincts. Pour comparer ces outils utilement, partez du travail à accomplir plutôt que du nombre de fonctionnalités. Le tableau ci-dessous passe en revue les huit critères pour chaque catégorie, avec ProcessMind dans la dernière colonne.

Les suites d’architecture d’entreprise centrées sur le référentiel, comme Software AG ARIS, Bizzdesign, MEGA HOPEX, Orbus iServer et Sparx EA, sont conçues pour les référentiels d’architecture, les cadres, la gouvernance et la gestion de portefeuille. Elles conviennent aux organisations qui ont le mandat et les moyens de mener un programme d’architecture formel.

Les plateformes de gestion de l’architecture d’entreprise, comme SAP LeanIX, proposent une approche SaaS pour les inventaires d’applications et de capacités. Elles peuvent convenir aux organisations qui souhaitent avoir une vue d’ensemble de leur environnement applicatif et gérer l’architecture d’entreprise de façon structurée.

Les outils de création de diagrammes et ArchiMate peuvent convenir si votre principal besoin est de créer et de partager des modèles. Archi est un outil gratuit, open source et natif ArchiMate. Les pratiques fondées sur Visio permettent également de documenter l’architecture. Vérifiez que les fonctions de référentiel, de collaboration et de gouvernance répondent à vos besoins.

Les modules ITSM et de plateforme peuvent être adaptés si vous souhaitez intégrer les vues d’architecture aux systèmes que vous utilisez déjà. Vérifiez que le niveau de détail de la modélisation et les fonctions de référentiel du module correspondent à vos pratiques d’architecture.

ProcessMind répond à une autre question : comment le travail se déroule-t-il et que montrent les données opérationnelles ? La plateforme relie les chaînes de valeur et les niveaux de processus aux données d’événements déjà produites par vos systèmes. Vous pouvez ainsi consulter l’architecture jusqu’aux activités réalisées et la vérifier à partir des faits observés.

Aucune de ces catégories ne s’impose dans tous les cas. Choisissez l’outil qui répond au besoin prioritaire. Si votre principale préoccupation concerne le déroulement des processus, commencez par les preuves issues de la couche processus ; ajoutez un référentiel si votre programme d’architecture en a besoin.

Pourquoi l’architecture d’entreprise s’éloigne-t-elle de la réalité ?

L’architecture d’entreprise peut s’éloigner de la réalité lorsque le référentiel dépend de mises à jour manuelles et que le modèle reste éloigné du travail qu’il est censé décrire.

Trois facteurs structurels rendent cet écart plus probable :

• Le référentiel est mis à jour manuellement. Les changements apportés aux processus, aux applications et aux responsabilités doivent être saisis puis vérifiés.
• Les bénéfices peuvent se faire attendre. Les équipes auront peut-être besoin d’un inventaire exact lors d’un audit ou d’une analyse d’impact ultérieurs, alors que le travail de mise à jour doit être effectué dès maintenant.
• Le modèle décrit les intentions, pas les pratiques. Un processus documenté ne montre pas nécessairement les reprises, les exceptions, les transferts ni les temps d’attente des cas réels.

Les cartographies des capacités et les inventaires d’applications sont utiles pour comprendre l’organisation dans ses grandes lignes. Mais les personnes qui effectuent le travail peuvent ne pas reconnaître leurs activités quotidiennes dans un modèle qui s’arrête au niveau des capacités ou des applications.

Les écarts apparaissent souvent dans le détail : variantes de processus, transferts, validations répétées et temps d’attente. Un référentiel peut consigner le processus prévu, mais il faut une autre source de preuves pour vérifier si cette description correspond toujours aux pratiques opérationnelles.

Une architecture dans laquelle personne ne se reconnaît échoue de deux façons. Les équipes la contournent, car le modèle prévoit une validation alors qu’elles savent qu’il y en a trois, et finissent par ne plus le consulter. Ou bien elle subsiste comme document de conformité, mis à jour avant un audit puis ignoré le reste du temps. Dans les deux cas, le problème ne vient pas de l’outil, mais de l’écart entre le modèle et le travail.

Une meilleure gouvernance peut contribuer à maintenir le référentiel à jour. Mais elle ne fournit pas, à elle seule, de preuve indépendante que le modèle correspond à la réalité. Relier les modèles de processus aux données opérationnelles vous permet de vérifier cette couche.

Comment relier l’architecture au travail des équipes ?

Décrire le travail là où il s’effectue aide les équipes à se reconnaître dans l’architecture et vous donne des éléments à vérifier à partir des données opérationnelles.

Une cartographie des capacités décrit ce que l’organisation doit accomplir. Un modèle de processus peut montrer comment le travail est réalisé, qui en est responsable et comment les sous-processus s’articulent. Plus clairement ces niveaux sont reliés, plus il est facile de passer d’une vue d’architecture au travail qu’elle représente.

Un journal d’événements apporte des preuves sur les cas terminés. Il peut indiquer les activités réalisées, leur ordre et la durée des cas. En comparant ces éléments à un modèle de processus, vous pouvez repérer les écarts entre les pratiques observées et le parcours documenté.

Cela ne signifie pas que toutes les composantes d’une architecture d’entreprise peuvent être déduites des données d’événements. Les décisions de portefeuille, les normes et les choix d’état cible nécessitent toujours des pratiques d’architecture et une gouvernance. Les données peuvent fournir un socle vérifiable pour la couche processus, mais ne remplacent pas l’ensemble du référentiel.

Décrire les processus au plus près du travail permet d’éviter ces deux écueils. Lorsque l’architecture détaille les activités, les transferts et les temps d’attente, une équipe peut reconnaître son propre travail dans le modèle et un responsable peut voir quelle décision lui incombe. Un outil d’architecture d’entreprise peut gérer le portefeuille. Pour relier ce portefeuille aux personnes qui le font vivre, il faut représenter le travail lui-même.

Les preuves apportent un élément vérifiable par les personnes chargées de l’examen. Le temps d’attente indiqué dans le modèle devrait correspondre à celui du journal. Si ce n’est pas le cas, la discussion porte sur le processus plutôt que sur le diagramme. C’est plus utile qu’une nouvelle série de mises à jour.

Cela change aussi l’ordre des travaux. Au lieu de terminer d’abord le référentiel en espérant que le niveau de détail suivra, mesurez un processus, reliez-le au niveau supérieur et vérifiez le modèle là où il peut être confronté aux faits. Ce premier périmètre est assez restreint pour être mené à bien et fournit au programme d’architecture un exemple concret plutôt qu’un simple plan.

La documentation de l’architecture des processus vous permet de voir comment les niveaux de processus et leurs relations sont représentés. Pour la partie données, consultez la création d’un journal d’événements pour le Process Mining.

Pourquoi ProcessMind aborde-t-il l’architecture autrement ?

ProcessMind aborde l’architecture à partir des éléments que les données permettent de vérifier. Cette différence est un choix délibéré, et non une version réduite de ce qu’offre un référentiel.

La gestion de portefeuille, du cycle de vie des applications et des normes relève du domaine des référentiels. ARIS, SAP LeanIX, Bizzdesign, MEGA HOPEX, Orbus et Sparx répondent bien à ces besoins. Ici, l’accent est mis sur la couche processus.

Nous nous concentrons sur la couche processus : chaînes de valeur, niveaux de processus configurables, répartition des responsabilités RACI, flux de gouvernance et portail de consultation, le tout relié aux données d’événements. Cette couche répond à elle seule aux questions sur les processus et peut compléter un référentiel lorsqu’un programme d’architecture en a besoin.

Comment choisir un outil d’architecture d’entreprise ?

Faites votre choix en fonction des questions auxquelles vos équipes doivent répondre et des travaux d’architecture que vous devez encadrer.

• Vous avez besoin de gérer un portefeuille, des normes et des feuilles de route : présélectionnez une suite complète d’architecture d’entreprise et prévoyez les ressources et les processus nécessaires à la maintenance du référentiel.
• Vous avez besoin d’un inventaire SaaS des applications et des capacités : évaluez une plateforme de gestion de l’architecture d’entreprise comme SAP LeanIX au regard de vos besoins d’inventaire et de gouvernance.
• Vous cherchez à comprendre le déroulement des processus : commencez par les modèles de processus et les données opérationnelles, puis déterminez si un référentiel plus large vous est également nécessaire.
• Vous hésitez encore : repérez les questions que les équipes posent le plus souvent. Vous pourrez ainsi déterminer s’il vaut mieux commencer par un référentiel, des preuves sur les processus, ou les deux.

Si vous comparez des outils centrés sur le référentiel, consultez notre comparatif des alternatives à ARIS. Si vous évaluez la manière dont les modèles et les données s’articulent, lisez comment la modélisation des processus et le Process Mining se complètent.

Commencez là où vous pouvez obtenir des preuves. Ajoutez le référentiel lorsque votre programme d’architecture a besoin de ses fonctions plus larges de gouvernance et de gestion de portefeuille.

Quelle est la place de ProcessMind ?

ProcessMind fournit une couche dédiée aux processus et aux chaînes de valeur, qui relie l’architecture aux preuves du déroulement du travail.

Un référentiel gère le portefeuille et les normes ; ProcessMind gère la couche processus et les preuves qui l’étayent. Les équipes qui utilisent les deux disposent d’une architecture dont le niveau de détail des processus peut être vérifié. Celles qui n’ont besoin que de la couche processus peuvent l’utiliser seule.

Vous pouvez organiser les processus en niveaux configurables, les modéliser en BPMN 2.0, attribuer les responsabilités RACI et utiliser des flux de gouvernance ainsi qu’un portail de consultation. Vous pouvez également relier les modèles de processus aux données d’événements pour comparer les processus documentés aux pratiques observées. La simulation des processus vous permet d’étudier les effets d’un changement dans le modèle avant toute modification du processus en production.

Pour découvrir plus en détail les fonctionnalités d’architecture des processus de la plateforme, consultez la page consacrée à l’architecture des processus d’entreprise. Vous pouvez également en savoir plus sur la gouvernance des processus et sur le Process Mining.