TOGAF IRL 3 (The End) - Rhapsodies Conseil

5 février 2020

– 7 min

Antoine Arnault

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.