Préambule

Notre proposition de raccourci s’inscrit dans l’accompagnement de la transformation du Système d’Information (SI). L’élément déclencheur de l’implication des architectes d’entreprise est fréquemment le lancement d’études d’opportunité sur de nouveaux besoins métier. Notre intervention est donc souvent opportuniste en parallèle de nos contributions aux grands programmes IT.

TOGAF® est le cadre de référence pour l’Architecture d’Entreprise (AE). Il préconise en première itération d’un projet de transformation du Système d’Information (SI) de nous concentrer sur les architectures existante et cible de 4 natures : métier, données, applicatives et techniques. Les données font partie de l’étape C de l’ADM (Architecture Development Method) de TOGAF.

Ce résumé est loin de couvrir le terrain de jeu de TOGAF. Pourtant la matière y est déjà dense.

Nous constatons la difficulté chez nos clients de mobiliser les sponsors, le budget et les disponibilités afin de mener ces premiers chantiers en suivant les préconisations de TOGAF. Or, ces travaux sont indispensables pour réussir une transformation du système d’information (SI) alignée sur les enjeux métier.

Sur la base de ce constat et de ces défis, nous vous proposons un parcours accéléré et minimaliste permettant de maximiser vos chances de réussite sur ces chantiers.

Suivre cet itinéraire devrait vous permettre de sécuriser les projets informatiques à minima.

Quelques cailloux blancs pour jalonner le chemin et nous guider

Le raccourci se déroule en 6 étapes :

1. Structurer l’aire de jeu en détourant les domaines métier ;
2. Reconnaitre les enjeux avec la carte des objets métier ;
3. Formaliser les apports de valeur avec le cycle de vie des objets métier ;
4. Se doter d’une gouvernance en nommant les propriétaires des objets métier ;
5. Organiser l’outillage SI en repérant les fonctionnalités qui transforment les objets métier ;
6. Composer les chantiers par groupements cohérents des fonctionnalités.

Vous remarquerez sur le schéma ci-dessus que des boucles d’ajustement s’intercalent entre les étapes. En effet, chaque avancée enrichit la réflexion de détails. Cela peut remettre en question des hypothèses préalables. Nous sommes dans une démarche agile où nous expérimentons et corrigeons ce qui ne fonctionne pas.

1. Structurer l’aire de jeu

Un problème complexe se résout en le découpant en sous-problèmes abordables plus aisément. Pour cela, nous commençons par organiser notre terrain de jeu en territoires adjacents. Il s’agit des domaines métiers.

Ce découpage est souvent proche de celui des départements de l’entreprise. Ainsi, nous pouvons planifier la rencontre avec les experts de chaque entité organisationnelle, selon les priorités que nous nous donnons.

2. Reconnaitre les enjeux

Le SI est une vaste usine à transformer de l’information pour répondre aux besoins des clients et des utilisateurs. Les enjeux métier s’expriment donc très efficacement sous la forme des artefacts élaborés et de leur représentation dans le SI. Nous appelons ces représentations des Objets Métier.

La clé de notre raccourci est de considérer directement ce qui est au cœur des processus plutôt que les processus eux-mêmes (voir notre article « La boussole du projet de transformation »). Modéliser ces derniers reste un levier puissant, mais cela requiert le parrainage rarement acquis des responsables métier et un budget conséquent. Nous nous donnons donc les moyens d’avancer sans.

Pour cela, nous établissons une cartographie des objets métier principaux de l’entreprise.

Voici trois astuces pour distinguer un objet métier de simples attributs :

• L’identification d’un cycle de vie reflétant une transformation avec valeur ajoutée ;
• L’existence d’une relation n-aire avec un autre objet métier (ceci rendant impossible la représentation en attributs) ;
• L’existence d’une classe de données spécifique dans le SI.

La carte des objets métier n’est pas simplement une liste. Elle met en exergue la relation entre les concepts, de façon à confirmer le grain et la sémantique. Elle constitue le Modèle d’Objets Métier (MOM).

Dans la pratique, le MOM est construit par fragments sur des périmètres restreints (quartier fonctionnel, squad, pôle utilisateur, etc.). Lorsque nous avons suffisamment de matière chevauchant plusieurs fragments, nous procédons à un assemblage et à une mise en cohérence desdits fragments. Il est en effet très difficile de travailler d’emblée sur une vision complète de MOM à l’échelle de l’entreprise. Réunir toutes les parties prenantes étant le plus souvent impossible, la construction du MOM est donc itérative. L’architecte d’entreprise ne décide pas ce qui est ou ce qui n’est pas objet métier, il est un maïeuticien qui permet de faire émerger l’expression de besoin, expression qu’il s’astreint à dégrossir et à reformuler au mieux. Il est indispensable que sa retranscription soit fidèle à l’esprit voulu par les représentants métier, raison pour laquelle l’architecte veille systématiquement à faire valider cette retranscription par ces derniers.

UML est la notation adaptée à la représentation des entités. Idéalement, chaque objet est relié à ses voisins par une flèche libellée d’un verbe d’action. Nous avons communément la relation « Se décompose en » ou « Se décline en ». Nous utilisons aussi « Consomme », « Requiert », « Est porté par », « Supporte », « Influence », « Est la propriété de » …

La cardinalité d’une relation est une subtilité très intéressante pour valider le modèle. En revanche, elle est maîtrisée par les modélisateurs aguerris. Elle correspond au nombre d’éléments de chacun des 2 concepts en relation. La cardinalité la plus simple est la bijection notée « 1..1 ». Elle dit que chaque élément d’une famille d’objets est en relation avec exactement un élément de l’autre famille d’objets.

Notre article « L’Architecture d’Entreprise est-elle toujours pertinente face à l’Agilité ? Volet 3 : La boite à outils de l’architecte d’entreprise » présente un exemple de carte des objets métier.

3. Formaliser l’apport de valeur

La vision statique des objets métier permet de comprendre l’écosystème et de partager un vocabulaire commun. Un grand bond est réalisé quand nous lui associons la vision dynamique avec les changements d’état. Le cycle de vie d’un objet métier exprime sa transformation pour satisfaire le besoin initial.

Il est une manière très concise de représenter un processus métier sans évoquer des activités.

Le résultat est un graphe à états finis, où des chemins alternatifs peuvent coexister.

Si nous rencontrons une difficulté à formaliser les états successifs, alors il est possible que l’objet soit mal identifié. Un travail itératif avec la reconnaissance des enjeux est alors nécessaire.

Si le changement d’état dans le cycle de vie d’un objet modifie l’enjeu, alors vous avez affaire à 2 objets, que vous devez distinguer.

Lorsque nous disposons d’une cinquantaine d’objets métier et de leur cycle de vie, notre cartographie est robuste.

4. Se doter d’une gouvernance

À cette étape, nous disposons d’un socle sûr et fidèle aux enjeux métier. Nous pouvons alors réfléchir à la façon de pérenniser le dispositif.

Gouverner, c’est connaître le patrimoine, organiser son usage, garantir sa qualité et anticiper ses évolutions.

S’agissant des données et par extension des objets métier, nous entendons parler d’une dizaine de rôles emblématiques :

• Le directeur des données (chief data officer) pour la vision ;
• Le propriétaire des données (data owner), pour la définition, l’intégrité, la qualité et les usages ;
• L’intendant des données (data steward) en appui au propriétaire sur les usages et la qualité ;
• Le chercheur en données (data scientist), pour l’exploration et la valorisation ;
• L’analyste métier (business analyst), pour la synthèse et l’aide à la décision ;
• Le responsable de la protection des données (data protection officer), pour la conformité ;
• L’administrateur sécurité des données (data security referent), pour la politique de sécurité et les risques ;
• L’architecte des données (data architect), pour les principes, les référentiels et les formats ;
• L’utilisateur des données (data consumer).

Doter l’organisation de ces rôles est difficile. Cela requiert un renforcement des mécanismes de synchronisation pour que tout ce monde s’harmonise. Autant de complexité est-elle souhaitable dans votre contexte ?

Dans notre parcours accéléré, nous mettons l’accent sur le rôle de propriétaire. A minima, nous positionnons chaque objet métier sous la responsabilité d’un domaine métier de l’aire de jeu.

Il s’agit de tisser une toile où les tensions se régulent sous l’influence des porteurs d’enjeux. Pour que l’équilibre s’établisse, chaque enjeu est défendu par un porteur enthousiaste.

Idéalement, ce dernier ne cumule pas des enjeux contradictoires afin de préserver son intégrité. Il est par exemple malsain de confier à une même personne les responsabilités d’affaires commerciales et d’expertise opérationnelle. Le discours devenant alors flou, l’un des enjeux en pâtit inévitablement.

Le propriétaire d’un objet métier arbitre sur son cycle de vie, sa mise à disposition et ses évolutions. Cela couvre en particulier les opérations de création, lecture, mise à jour et suppression. Les flux inter-applicatifs transportant les données sous-jacentes aux objets métier sont également sous le regard du propriétaire.

5. Organiser l’outillage SI

La structuration de l’outillage IT commence par recenser les fonctionnalités qui agissent sur les objets métier. Ce travail se réalise par affinement successif en partant de macro-fonctionnalités vers plus de détail (approche top-down).

Une phase de réconciliation avec l’exploration de l’existant applicatif (approche bottom-up) est intéressante pour nous assurer de ne rien oublier.

Une fonctionnalité est une déclinaison d’un besoin métier. Il est important de tracer ce chaînage. Idéalement, la formulation d’une fonctionnalité nomme un objet métier (ou plusieurs) auquel est accolé un verbe exprimant la transformation voulue. Nous ne présumons pas ici de la solution (le « comment faire »). En revanche, il est très utile de préciser le bénéficiaire (ou utilisateur).

Les exigences de disponibilité, qualité et performance sont indiquées dans la mesure du possible, car elles influenceront les solutions envisagées ultérieurement par les architectes techniques.

6. Composer les chantiers

Il s’agit ici de construire ou ajuster la feuille de route pour mettre en ordre de marche les équipes qui réalisent les solutions informatiques. Le but est de structurer un maillage efficace entre les projets IT (ou pour l’intégration continue des produits confiés à des squads si l’agilité est la modalité retenue). L’architecte d’entreprise n’est pas l’arbitre de l’organisation en chantiers. Il s’assure en revanche de la cohérence globale et prévient d’éventuels conflits de responsabilités.

À l’instar des urbanistes, nous élaborons le Plan d’Occupation du Sol (POS) fonctionnel composé de blocs de fonctionnalités.

La bonne pratique de regroupement est d’utiliser les objets métier comme centres de gravité. Vous obtenez naturellement des blocs cohérents respectueux de la vision métier. Un POS équilibré propose un nombre de fonctionnalités similaire par bloc. Une forte variation de ce nombre peut venir d’une granularité non adaptée à l’identification des fonctionnalités (trop fine par endroit et trop grosse ailleurs). Il n’y a pas de méthode universelle pour ce travail. Le résultat est jugé bon quand la co-construction aboutit au consensus.

Toujours pour économiser de l’effort, nous proposons de construire un POS hybride entre existant et cible. Un jeu de couleur permet d’identifier les fonctionnalités correctement outillées, les fonctionnalités à faire évoluer et les fonctionnalités non disponibles actuellement. Dans les deux derniers cas, le jalon prévisionnel de mise à disposition sur un horizon de temps d’environ 2/3 ans est préconisé.

En démarche agile, nous ne parlons plus de projet, mais de produit. Ce dernier couvre un ou plusieurs blocs fonctionnels et est confié à une équipe de réalisation. Les contours d’un produit dépendent de nombreux facteurs, comme la disponibilité des compétences, la charge de travail estimée, la célérité voulue de mise à disposition des utilisateurs, les contraintes du parc applicatif existant, la continuité de service, la conformité réglementaire, etc.

En synthèse

Nous éclairons ici un parcours d’AE accéléré. Il devient pour nous un standard, tant les tensions budgétaires et de délais s’accentuent d’année en année sur les travaux de transformation du SI. Comme les agilistes, les architectes d’entreprises réfléchissent de plus en plus en termes de minimum viable sur des cycles courts.

Nous travaillons de concert avec les products owners et les métiers pour proposer un accompagnement adapté aux sprints agiles.