Celui, ou celle, que l’on appelait avant Architecte Fonctionnel et que l’on appelle à présent Architecte d’Entreprise (AE), a vu son domaine d’intervention être siloté avec une approche qui a privilégié les processus souvent au détriment des données.
La notion d’Architecte Data a donc vu le jour sur le marché, ou même Data Architect pour lui donner une aura internationale. A la manière des architectes SI ou techniques qui sont complémentaires aux AE, Est-ce la cas pour l’Architecte Data ? L’est-il ou fait-il exactement la même chose que l’AE sur les données ?
Mais pourquoi tout le monde veut ma place ?
De mon point de vue, l’architecte d’entreprise subit les conséquences d’une posture qui a fini par lui porter préjudice. Le fameux « architecte dans sa tour qui ne comprend pas les contraintes des gens qui font vraiment de l’informatique », réputation contre laquelle nous luttons tous les jours mais qui, nous devons bien nous l’avouer, existe encore parfois.
Un autre problème est lié au vocabulaire que nous utilisons. Un but de notre métier consiste à savoir si tel ou tel développement doit être fait dans telle ou telle application, et pour cela nous travaillons avec les fonctions. Alors une fonction, tout le monde pense savoir de quoi il s’agit mais ce n’est souvent pas le cas, et cela est moins parlant qu’une « Donnée ». De plus, les justifications pour regrouper des fonctions sont floues : cohérents, logiques,… sont des mots à bannir de notre vocabulaire.
Pour commencer : qu’est-ce qu’une fonction ?
Si on demande à Larousse, la définition d’une fonction est la suivante : « Ensemble d’instructions constituant un sous-programme identifié par un nom, qui se trouve implanté en mémoire morte ou dans un programme ». Personnellement, j’en ai une autre : une fonction est une instruction visant à modifier une caractéristique d’un objet.
La raison pour laquelle je préfère ma définition est que le mot objet permet de faire le lien avec un des éléments qui permettent de construire l’architecture fonctionnelle de votre SI.
Comment construisez-vous votre plan fonctionnel ?
Lorsque notre ami architecte d’entreprise définit un plan d’urbanisme fonctionnelde son système d’information, c’est qu’il veut mettre en évidence les fonctions nécessaires aux métiers. Mais quels sont les critères de regroupement ?
Le principal critère de regroupement, c’est la donnée. Pour bien comprendre, prenons l’exemple de l’objet, et donc de la donnée, « Personne » dans le cadre simplifié d’un site de distribution. Toutes les fonctions de l’objet « Personne » sont donc rangées dans le bloc Personne. Prenons ensuite les fonctions rangées dans le quartier Adresse. Ce sont des fonctions qui sont appelées, et donc des données qui sont modifiées, dans un même cas d’usage. Quand une personne déménage, les données liées aux fonctions dans le quartier Adresse sont modifiées. Enfin dans un ilot, vous allez retrouver toutes les fonctions qui peuvent modifier une information particulière : Modifier la rue, modifier le numéro, modifier la ville.
Cet exemple est concentré sur l’objet « Personne » mais cela est vrai pour la globalité de l’entreprise. Le modèle de donnée de l’entreprise est donc nécessaire pour construire un plan fonctionnel global de l’entreprise.
Mais comment parler avec les projets ?
Il faut arrêter de parler de fonctions avec vos projets, ne dites pas « quelles sont les fonctions que vous voulez ajouter » mais « quelles sont les données que vous allez impacter ». Charge à l’architecte d’identifier ensuite les fonctions. Il faut parler le même langage que lui, lui faire comprendre la valeur qu’on lui apporte et ce sera gagné.
L’Architecte Data est un architecte comme les autres. C’est son approche par les données qui met en avant les problèmes de gouvernance auxquels l’architecte fonctionnel était déjà confronté auparavant, alors « Reprenons notre dû, reprenons les data ! »
Dessiner une cible, bien sûr, mais à quel horizon ? Sous quel angle ?
Sur ces sujets, nous devons différencier plusieurs points de vue.
Formaliser la cible à long terme : l’idéal
Récemment, nous avons animé pour un client la définition d’une cible à environ 5 ans qui permettait de donner les grandes directions et surtout de mettre en avant ce qui devrait être (ou non) couvert par l’ERP central.
Cette cible a permis de partager une vision d’ensemble des projets d’étude et des grands pans applicatifs qui allaient évoluer. Et donc aussi de définir ceux qui ne feraient pas l’objet d’investissements conséquents dans les prochaines années.
A l’inverse, sur certains pans du SI, cette cible ne pouvait pas être mise en application de suite car elle était parfois trop éloignée de la réalité. Plusieurs étapes peuvent alors être nécessaires pour atteindre cette cible. Ce genre de cible étant vue comme « inatteignable ». Pourtant 5 ans cela peut être court au regard de certains autres investissements lourds (construction d’usines de production, construction d’un data center…) mais au vu de la vitesse exponentielle de l’évolution de l’IT, cela peut paraître très long.
Formaliser la cible à plus court terme : dans quel cas ?
Une cible a 2-3 ans peut à l’inverse paraître très courte car certains projets peuvent mettre du temps à se lancer. Ensuite, le temps d’organiser les équipes, de comprendre le sujet, etc., il peut déjà se passer facilement 1 an ou 2 dans certains cas. Pour un de mes clients, une grande banque, nous avons passé 6 mois à construire une cible macro, définir les principaux besoins, ce qui devait évoluer et les principales briques du systèmes (à acheter ou à développer). Puis au moment de se lancer et vu l’importance des sujets à traiter, il a fallu passer par une étape « politique » qui consistait à décider d’une structure pour ce programme (et à qui elle devait être rattachée) : nommer de nouveaux responsables ; les faire venir de leurs anciens postes ; procéder au recrutement en cascade qui va bien, aussi bien avec des internes et compléter par des consultants (pour des raisons de charge de travail, d’expertise, etc.).
Une cible à plus court terme peut permettre de faire comprendre les premières étapes de la transformation.
Comme dans tous nos travaux nous devons donc trouver le juste équilibre entre le court, moyen et le long terme. Suivant les cas, il n’y a pas une cible à décrire mais plusieurs ! Certains domaines sont à court terme car ils risquent de devoir évoluer rapidement et on parlera davantage de plateformes. Certains autres sujets doivent être pris sur le long terme (ERP) au vu des coûts et des changements qu’ils impliquent.
LA question qui se pose tout le temps dans les cartographies est : faut-il commencer par décrire la cible ou par décrire l’existant ?
2 écoles s’affrontent irrémédiablement (mais finissent toujours pas se réconcilier).
Commençons par la cible justement
Cela peut paraître difficile pour certains de ne pas parler de l’existant et de directement se projeter vers la cible. Ceux qui préfèrent commencer par la cible avancent comme argument qu’il faut pouvoir s’affranchir des contraintes du présent pour inventer une nouvelle cible qui dépasse les clivages et solutions actuelles. Faire du passé table rase !
Cette solution a souvent pour but de mobiliser les gens rapidement en allant vers une cible (les étapes de description de l’existant étant souvent vues comme coûteuses et peu porteuses de valeur).
Dernièrement c’est ce que nous a demandé un client, de commencer de suite par des ateliers sur la cible. Ce qui a effectivement permis de mobiliser les énergies vers un but commun. Une cible qu’ils ont choisi tous ensemble et où tous peuvent se projeter. L’exercice est porteur de sens.
Mais une fois la cible décrite, il faudra pour construire une trajectoire, la passerelle entre aujourd’hui et le futur, décrire l’existant. Même succinctement mais il faut bien se donner les étapes du passage d’un état à l’autre.
Je vous rassure aussi, lors des ateliers de description de la cible, nous parlerons forcément à un moment ou à un autre de l’existant pour le critiquer, le comparer : faut-il vraiment changer cette solution ? pourquoi changer ? avons-nous les moyens de changer ? etc.
Si on commençait par décrire l’existant ?
Nos clients nous disent régulièrement avoir déjà fait des cartographies. Ce fut long, ce fut coûteux et au final peu productif ! Beaucoup d’efforts pour un résultat et une valeur ajoutée non démontrée.
Pour bien faire cette étape, faisons juste ce qu’il faut.
Un des buts de la cartographie de l’existant est d’estimer là où nous allons positionner les futurs investissements. Si un domaine ou des applications sont stables et ne posent pas de problème particulier, la cartographie passe son chemin !
Comme dit au début, sélectionnons rapidement les domaines sur lesquels nous avons besoin d’une visibilité. Toutes les raisons sont bonnes ! Un de nos clients nous disait : nous venons de reprendre cette filiale, je ne connais pas du tout son SI, rien n’a été fait durant la phase d’acquisition !
Connaitre les flux ? C’est une demande récurrente de nos clients qui nous disent avoir perdu la connaissance des flux.
Un client bancaire nous demandait de regarder en premier les flux envoyés à l’extérieur. Un autre client bancaire lui aussi, nous demandait de regarder en premier les flux potentiellement porteurs d’informations sensibles : au final nous ne l’avons pas fait car une certification était passée par là ! Donc le sujet était maîtrisé et la capitalisation attendra.
L’existant permet aussi de faire émerger les problèmes et de définir des cibles qui vont solutionner ces problèmes. Et la mesure de la cible se fera sur le niveau de réponse apportée aux problèmes existants.
Oui il fut un temps (pas si lointain) ou des armées de consultants étaient utilisés pour décrire un existant. De nos jours cette approche n’est pas souhaitable. Se focaliser sur la valeur ajoutée, périmètre par périmètre. Avec le juste niveau de connaissance. Pour identifier les points d’amélioration ou de contrôle. Voilà les directives qui nous guident dans ces étapes.
Le fameux fonds de carte… Plusieurs « écoles » s’affrontent sur ce sujet car plusieurs possibilités existent qui permettent de positionner le SI et ses applications en fonction du message à faire passer
Le socle des processus ?
Il permet aux métiers de comprendre la couverture des applications / des technologies et donc l’importance qu’ils ont dans le SI (et sûrement aussi dans les budgets donc). Mais trop métier, les SI ne le comprennent pas et il n’est pas forcément pertinent pour mettre en avant les enjeux du SI. Ce socle des processus est parfois dur à construire car les processus existent déjà sous diverses formes au sein de l’entreprise (audit interne, procédures ISO 9001, etc.). Cette vision n’est pas partagée par tous et risque de porter de la confusion. L’avantage est que sur les processus on peut faire porter des stratégies et des enjeux métier. Par exemple l’ouverture vers d’autres société, des délais de réalisation ou de réponse…
Une (business) capability map ?
D’après le nom, cela ressemble fort au socle des processus. Oui mais pas forcément. Un de nos clients, grand groupe industriel, nous a récemment demandé de lui en créer une. Nous sommes partis d’un standard de son métier et nous l’avons complété avec ses spécialités. Le résultat a été une vue des grandes « activités » (donc sans chercher la transversalité comme avec les processus) de l’entreprise. Cette vue a été rapidement comprise par tous. Il est possible avec cette vue capacitaire de mettre aussi des ambitions sur des capacités : pouvoir donner une réponse à un crédit en moins de 24h, faire de la pré-acceptation de crédit dès le dossier complété…
Le plan d’urbanisation ou le pos
Toujours classique et efficace dans sa présentation. Parfois d’un niveau très fonctionnel, il nous est souvent demandé : des adaptations pour intégrer les dimensions applicatives et technologiques notamment. Suivant le niveau de détail, il peut vraiment servir à présenter le SI. Malheureusement il est maintenant surtout utilisé uniquement pour positionner les applications comme dans des boites et ne permet pas de « raconter une histoire » dans le SI. Il ne montre pas les échanges ni en interne ni avec l’extérieur. Cela limite son utilisation pour « raconter des histoires » et donner des ambitions.
Une vue des grands « domaines applicatifs »
Souvent basés sur un découpage organisationnel du SI donc en regard des responsabilités. Ce découpage peut être problématique. Quand il est bien fait, plusieurs clients ont apprécié cette présentation qui leur permet alors de montrer les échanges avec l’extérieur et entre les grands domaines puis de zoomer au fur et à mesure dans le détail de chaque domaine applicatif
Pour décrire le SI, nul doute que la vue des grands domaines applicatifs et des grands flux est un point d’entrée indispensable pour expliquer le SI et son fonctionnement. C’est souvent cette description qui manque.
Les autres vues peuvent être produites à moindre coût et son souvent la promesse des outils d’architecture d’entreprise orientés « data ».
Un fait est certain : les conflits font partie de la vie aussi bien parentale que celle de l’entreprise. Les relations évoluent et passent par différentes étapes. On a beau tout faire pour l’éviter, une crise survient inévitablement. Y a-t-il des signes annonciateurs ? Comment réagir quand certains projets ne veulent pas suivre les recommandations ? Comment faire si l’architecte fait preuve d’autoritarisme ? Comment gérer l’équilibre entre faire ses propres expériences et ne pas se mettre (trop) en danger ? Nous retrouvons à nouveau notre parallèle avec l’éducation parentale qui nous préoccupe tant.
De solution miracle, il n’est pas question ! Nous allons en revanche aborder différentes phases familières et voir ce qu’en dit la littérature et les spécialistes.
Mais qui est ce « Nous » ?
Chloé, architecte d’entreprise, interne d’une grande société qui se demande si son travail est un bullshit job (merci David Graeber). Elle est également jeune maman.
Olivier, architecte d’entreprise senior, consultant et ami de Chloé. Papa (divorcé/recomposé) de grands enfants.
Notes
Le discours s’appuie sur des raccourcis pour en faciliter la compréhension. Bien entendu, dans la réalité, aussi bien personnelle que professionnelle, c’est souvent plus complexe.
Toute ressemblance avec des projets ou des enfants existants ne serait bien entendu que fortuit.
Vous allez sûrement vous retrouver dans les lignes ci-dessous. N’hésitez pas à réagir et à nous faire parvenir vos commentaires, autant sur la forme que le fond, que nous fassions tourner la roue de l’amélioration continue ! Allez, fin du suspense, c’est parti.
En temps de crise, le sage construit des ponts, le fou construit des murs.
Introduction
Chaque crise a une raison spécifique et demande une solution adaptée. Ce que nous allons voir de nouveau dans ce chapitre, ce sont les crises qui débordent, les grandes crises, celles qui demandent un repositionnement du rôle du parent / de l’architecte.
En nous promenant le long de la vie d’une personne de 0 à 100 ans, nous trouverons des parallèles à notre vie en entreprise. Est-ce que ces réflexions vont nous conforter sur l’idée qu’un cadre est indispensable comme nous le préconisons dans le premier chapitre (L’Architecte est un parent comme les autres) ? Est-ce que la vie d’un architecte est toujours aussi simple (noter l’ironie) que celle d’un parent ?
Le rejet de l’autorité à 2 ans
Chloé : Je n’en peux plus ! J’écume toute la littérature sur la gestion de crise en ce moment. A 2 ans, c’est la mini adolescence ou « terrible two » comme on dit chez les spécialistes de la petite enfance. Je te partage ce que j’ai appris ?
Que se passe-t-il dans la vie d’un enfant pour que soudainement, vers 2 ans, l’enfant docile se rebelle ainsi ? Cette bascule surprend d’autant plus le parent que tout est paisible avant. Le premier refus interpelle donc. La raison est assez simple : l’enfant a besoin de s’affirmer. Il veut pouvoir décider. Voilà une des sources de crise : avoir besoin de plus de latitude. Il paraîtrait que c’est normal et même sain. Tu vois où je veux en venir ?
Olivier : Effectivement, je me rends compte d’avoir déjà vécu cette situation en entreprise. Il arrive qu’une personne ou une équipe réclame plus de liberté et rejette les préconisations d’architecture (et non l’architecte !). Alors que fais-tu pour y remédier ?
L’enfant comprend par la répétition les temps forts d’une journée et le rôle des personnes qui l’entourent. Le cadre, à ce moment-là, est strict et les choix sont faits à sa place. Afin de montrer à l’enfant que nous lui faisons plus confiance, car plus mature, la solution est de lui proposer plusieurs choix afin qu’il puisse exprimer sa volonté propre. Et ça fonctionne !
« Veux-tu mettre ce vêtement-ci ou plutôt celui-là, sachant qu’il fait très froid aujourd’hui ? » « Veux-tu créer une API pour ton application ou préfères-tu déverser tes données dans le Datalake, avec tes connaissances maintenant bien ancrées ? ». Le cadre est toujours là (cf Chapitre 1), en revanche les choix possibles pour rester dans ce cadre augmentent. On conseille aussi de faire des câlins, c’est là que le rapprochement avec les collègues s’arrêtent ?
Olivier : Bravo avec ton enfant ! Il est vrai que l’architecte peut adapter son discours face aux équipes et selon la maturité, proposer plus d’options. Au risque de te déprimer, des crises, il va y en avoir beaucoup d’autres, ne serait-ce que l’adolescence. Au secours !
La maladie de l’adolescence est de ne pas savoir ce que l’on veut et de le vouloir cependant à tout prix.
Philippe Sollers
La crise de l’adolescence n’est pas une crise
Chloé : Cette période m’intéresse beaucoup. Mon entreprise en ce moment vit la plus grande transformation possible dans la vie d’une entreprise. Nous redéfinissons les rôles de chacun, la gouvernance, les méthodes et la façon de travailler, nos objectifs, nos relations à nos clients, TOUT, te dis-je !
L’adolescence, c’est exactement cela : une transformation totale. Chacun doit retrouver sa place dans le foyer et se créer de nouveaux repères. La difficulté est d’autant plus grande qu’elle est humaine : remise en cause, doute, perte de confiance envers soi et envers les dirigeants.
Le parent qui savait presque tout ne sait presque plus rien : « c’est toi qui sais ce que tu voudrais faire plus tard, toi qui sais qui tu aimes ou n’aimes pas, … ». C’est effrayant. Je vois les mêmes questionnements actuellement autour de moi. Les managers ne sont plus managers, ils deviennent des (servant) leaders. Les équipes sont responsabilisées : « c’est vous les experts qui prenez vos décisions en autonomie ». Encore plus effrayant.
Alors quelle est la place du parent ou de l’architecte dans cet ouragan ? Comment accompagner ces transformations ? Le risque est grand. Si nous supprimons le cadre (plus aucune règle, plus aucun interdit), nous exposons la famille / l’entreprise à de très grands risques. Si nous restons ancrés sur le cadre historique, alors nous n’avons pas su évoluer avec lui. Comment apporter alors des réponses attendues que nous n’avons pas ?
Un des maîtres-mots de notre transformation est « ensemble ». Si je n’ai pas la réponse et que toi non plus, peut-être qu’à plusieurs, nous allons la trouver. Travailler ensemble veut également dire partager la responsabilité. Nous abattons le mode « Silo » pour un mode plus coopératif.
Est-ce que nous sommes prêts à prendre des risques ensemble et si nous échouons, à trouver de nouveau ensemble des solutions ? Est-ce que nous, architectes, sommes prêts à admettre que le cadre se construit avec ceux que nous accompagnons ? Est-ce que les équipes sont prêtes à entendre que nous n’avons pas toutes les réponses et qu’ils devront également porter une partie des responsabilités en appliquant de nouvelles règles ?
Olivier : Effectivement, la gestion humaine au sein des entreprises est arrivée à la maturité de l’adolescence. Temps délicat pour les leaders et les RH. Personnellement, j’ajouterai : attention aux adolescents silencieux ! Il faut écouter tout le monde, au risque de passer à côté d’une difficulté cachée.
Je pensais que le pire dans la vie c’était de finir seul. Non. Le pire dans la vie est de finir avec quelqu’un qui nous donne l’impression d’être seul.
La crise de la quarantaine
Olivier : Si tu veux bien, on va finir sur la crise dite « de la quarantaine », autrement dit « j’ai envie de changement ». Cette angoisse soudaine qui se profile parce que tout à coup, on se voit vieillir en faisant tout de la même façon, avec les mêmes personnes.
Sur de nombreux sujets, lorsque tout va bien, nous sommes en mode « run ». Nous faisons le strict minimum pour que cela fonctionne au quotidien. Nous prenons le café au même bistrot, achetons la même marque de dentifrice, nous avons des automatismes tels que verrouiller la porte, « d’ailleurs, l’ai-je vraiment fermée ? Je vais revérifier, on ne sait jamais ».
En informatique, la relation MOA/MOE a fait ses preuves durant de nombreuses années : la MOA écoute le client et traduit en termes informatiques / la MOE réalise les demandes. Pourtant, nous nous apercevons que ce duo arrive au terme de son efficacité. Avec la rapidité grandissante des évolutions IT, le couple MOA/MOE nuit à l’innovation de l’IT, car il faut autant entendre la stratégie IT que celle du métier.
La MOE nous fait donc une crise de la quarantaine : je m’ennuie, je veux évoluer, être valorisé. Les spécialistes situent cette crise dans la quarantaine car c’est souvent à cette période que les enfants quittent le foyer (mettons de côté les rides et les cheveux blancs). Une personne qui a fait passer le travail, le couple, les enfants avant soi tel un robot se retrouve « seul » face à une nouvelle situation qui l’angoisse et qui lui permet en même temps de, enfin, se recentrer sur lui.
Les psychologues préconisent de profiter de cette remise en question pour faire un bilan. Qu’est-ce que je sais faire ? Qu’est-ce que je veux faire ? Comment et dans quel objectif ? C’est exactement la place de l’architecte d’entreprise dans l’actualité. Son rôle est d’épauler l’entreprise dans l’évaluation de son SI : par rapport aux nouveaux objectifs que se fixent le métier et l’IT, quels sont les périmètres obsolètes ?
Comment faire évoluer les applications afin d’apporter de nouvelles valeurs ? L’architecte doit être capable de comprendre la profondeur des changements et donc de reposer les bonnes bases pour le futur.
Conclusion
Olivier : si je résume, être architecte demande autant de souplesse qu’un parent. Il se tient à l’écoute de l’entreprise et selon sa maturité et ses besoins, adapte son accompagnement et son cadre. C’est exactement ce que défend TOGAF, et l’amélioration continue. Je pense que nous sommes plutôt raccord avec l’actualité. Rémi Cocula parle de l’évolution « d’Architecte à Métarchitecte » dans une conférence Devoxx. Pour aller plus loin, voir la littérature sur l’Emergent Architecture qui pose la place de l’architecte dans une organisation agile.
Restez connectés pour les prochains chapitres de « Dessine-moi un architecte » :
Si vous ne l’avez pas encore fait, découvrez les deux épisodes précédents : TOGAF IRL 1 ; TOGAF IRL 2.
La fin d’un monde sans contraintes
Ça y est, Vous avez collecté la liste des exigences ! Vous avez rencontré le métier, l’IT et la production de votre IT. Vous avez vérifié que vos exigences sont bien cohérentes les unes avec les autres, vous avez même probablement commencé à réfléchir à quoi ça pourrait ressembler, mais si vous vous dites que le reste devrait couler, vous vous trompez. Car c’est à partir de maintenant que vous allez vous confronter « au réel ».
Vous n’êtes pas le seul projet en cours (enfin normalement), les différents composants sur lesquels vous voulez apporter des modifications ont leur propre cycle de vie, leurs évolutions, leurs contraintes. Et puis votre projet également : le chef de projet a un budget, un délai et des objectifs à respecter. Alors il va falloir prendre tout cela en compte, sinon vous ne serez qu’un architecte de plus avec la réputation de « travailler dans une tour d’ivoire ».
Nous allons donc continuer à parcourir ensemble la roue ADM et au final, nous pourrons nous poser la question : TOGAF, applicable In Real Life ou pas ?
Phase E : Opportunités et solutions
L’objectif de cette phase est de construire la phase initiale de la feuille de route de l’architecture de votre projet. C’est-à-dire que l’on va créer la vision AS-Is du périmètre projet, la cible ainsi que les différents lotissements.
Pour l’existant, vous pouvez commencer en vous basant sur le contenu du référentiel d’entreprise (s’il y en a un) et de la documentation existante mais vous devrez tout de même aller voir vos différents interlocuteurs. Cela vous permettra de vous assurer de la fraîcheur de l’information que vous avez. Profitez-en pour demander si ces composants ont déjà des évolutions de prévues et quand elles auront lieu. Cela vous servira d’entrée pour définir vos trajectoires.
Pour la cible, identifiez les changements et identifiez les exigences liées à ces changements. S’il y a des exigences sans changement associé, c’est que vous avez des oublis.
Maintenant que vous avez votre point de départ et votre cible, il reste à définir le chemin… ou plutôt les étapes de votre chemin (les états stables de votre trajectoire). Pour cela, il est nécessaire de négocier avec l’équipe projet. Il y a évidemment l’enchaînement logique des évolutions (par exemple, si vous devez consommer de nouvelles données clients, vous allez mettre à jour votre référentiel en même temps que l’application consommatrice et non après), mais il est important d’intégrer les contraintes du projet (coûts et priorités) pour définir vos étapes. De la même manière, si vos contraintes ne permettent pas d’atteindre votre cible, identifiez une étape intermédiaire qui pourra servir de cible projet tout en remplissant les exigences principales du métier.
Dès que l’on parle de modélisation en architecture, arrive très vite la question de l’outil de modélisation ou d’Architecture d’Entreprise. Nous n’allons pas parler ici de quel outil utiliser ou comment le faire car ce n’est pas le sujet de notre article, mais plutôt est-ce vraiment nécessaire. De mon point de vue la réponse est non, on peut très bien faire sans et power point est largement suffisant. Par contre si c’est le choix qui est fait, cela implique plusieurs choses :
Définir un modèle de document qui sera appliqué pour chaque projet
Définir un métamodèle et une légende commune
Avoir un outil de gestion documentaire pour éviter que toutes les connaissances acquises soient perdues.
J’ai personnellement travaillé dans des grands groupes bancaires, dans des entreprises de service ou industrielles qui avaient fait ce choix et cela permet d’éprouver la démarche sans avoir à faire des investissements qui peuvent parfois être lourds pour l’entreprise ou la DSI.
Phase F : Migration et planning
Vous connaissez la direction que vous voulez prendre ainsi que le chemin, mais il reste encore une chose à savoir : quand ? Le but de cette étape est de finaliser la feuille de route d’architecture et le plan de mise en œuvre de la transformation. Jusqu’à présent vous avez intégré les contraintes de votre projet mais vous ne vivez pas seul sur une île déserte. D’autres projets touchent peut-être les mêmes composants que vous et peut-être sont-ils plus prioritaires que vous.
Dans ce cas, TOGAF préconise de voir le chef de projet ainsi que le responsable du portefeuille de projet. Il faut faire attention tout de même, certains chefs de projets, emportés par la volonté de mener à bien leurs travaux, ont tendance à minimiser les impacts de leurs collègues et les responsables de portefeuille n’ont pas toujours la vision exhaustive des impacts de tous les projets qu’ils suivent. A titre personnel, je vais toujours faire le tour de l’équipe d’architecture en plus, mais je vais également voir les responsables d’application car ce sont ceux qui ont une vue complète des évolutions à venir.
A présent votre feuille de route est terminée. pensez à bien mettre en évidence la valeur ajoutée pour le métier de chaque incrément car, quand vous communiquerez sur le déroulé de votre projet, ce sera le critère clé pour votre client : le métier. Si cela est possible, mettez cela en balance avec le risque lié à chaque étape dans un diagramme comme celui-ci :
Phase G : Implémentation et gouvernance
L’objectif de cette phase de la roue ADM est de s’assurer que les mises en œuvre sont bien conformes aux spécifications de l’architecture cible, en d’autres termes : faire le suivi de l’architecture du projet.
Cette phase est très souvent négligée par les équipes d’architecture. Cela nécessite d’investir beaucoup de temps et la valeur est souvent sous-estimée. Or, il est dommage de définir une architecture répondant au mieux aux attentes du métier, si derrière l’implémentation ne correspond pas.
Idéalement, il faudrait pouvoir faire des revues de code régulières, mais malheureusement cela est très chronophage. En réalité, il est souvent suffisant de participer aux comités projets pour les projets « en V » et d’y identifier les futurs travaux ou de relire la Sprint Back log pour les projets agiles. En toute logique, il est préférable d’intervenir avant que la réalisation commence, car il est très rare de voir un projet faire marche arrière.
Phase H : La gestion du changement
Ce n’est pas parce que le projet a démarré qu’il n’y a pas de nouveaux besoins. Dans cette phase, vous êtes censés vérifier 2 choses :
Si les nouveaux besoins collectés nécessitent de redémarrer un nouveau cycle (bref un nouveau projet) ou juste une mise à jour de l’actuel.
Si le projet est conforme ou non et si ce n’est pas le cas, si une dérogation peut être accordée ou non.
Pour les nouveaux besoins, il faut évaluer les impacts sur l’architecture et pour cela vous pouvez utiliser quelques critères tels que :
Le changement touche un ou plusieurs composants ?
Cela remet-il en cause l’architecture actuelle ?
Cela nécessite-t-il la mise en place de nouveaux flux ? De déployer de nouveaux composants ?
Pour vous donner un exemple, j’interviens actuellement sur la mise en place d’un ERP chez un client. Ce client a deux nouveaux besoins qui sont apparus. Dans un cas, il a été nécessaire de déployer un nouveau composant et cela a entraîné le lancement d’un nouveau sous-projet. Dans l’autre cas, il a fallu également déployer un nouveau composant, mais cela n’a pas nécessité de nouveau projet, car il s’agissait d’un ISV (achat du composant sur une market place de l’éditeur de l’ERP). En réalité il s’agit d’une décision collégiale entre le chef de projet et le sponsor et vous ne pouvez qu’apporter un avis.
Pour les réserves et les dérogations, on peut utiliser les mêmes critères et comme pour les nouveaux besoins, la décision se prendra entre le chef de projet et le sponsor.
Alors TOGAF, applicable IRL ou pas ?
Parmi tous les reproches que l’on entend au sujet de TOGAF, celui qui revient le plus souvent est celui de la rigidité. Reconnaissez que c’est un reproche étonnant car ce que l’on attend d’un framework : c’est un cadre, et un cadre est rarement souple.
Alors comme disent nos amis anglais : « first learn the rules then break them ». La valeur de cette démarche et qu’elle permet de comprendre les interconnexions entre toutes les décisions durant un projet et leurs impacts sur le résultat final. Une fois que l’on a compris cela, il suffit juste d’adapter TOGAF à son environnement comme nous l’avons fait lors de ces trois articles.
A titre personnel, il arrive que ma démarche soit encore plus éloignée des règles TOGAF. Il arrive même que je me passe de certaines phases de la roue mais cela est toujours propre à l’environnement dans lequel je travaille.
TOGAF in real life : sans doute pas, mais TOGAF in your own life : sans aucun doute.
Question subsidiaire : la certification, utile ou pas ?
Vous m’auriez posé la question il y a quelques années, je vous aurais dit que cela est utile, surtout si vous travailliez comme consultant. Aujourd’hui (nous sommes en 2020), cela me parait beaucoup moins nécessaire. Je suis consultant depuis bientôt 15 ans. Je suis intervenu chez une trentaine de clients et le dernier à m’avoir posé la question, c’était il y a 3 ans et c’était pour me dire que lui venait de le passer. En fait, TOGAF a irrigué beaucoup de services d’architecture. Beaucoup de gens en font sans le savoir et finalement ce n’est plus un facteur différenciant. Alors si on vous le propose, dites oui mais vérifiez que cela ne va pas être juste du bachotage, car la formation a plus de valeur que le coup de tampon.
