16 janvier 2021
– 5 minutes de lecture
Olivier Constant
Senior Manager Architecture
TOGAF est le Framework de l’architecture. Sa roue ADM est un classique. Le nombre de certifiés a explosé en France et dans le monde. Le but de cette série d’article est de voir avec vous, en se basant sur mon expérience de 13 années en tant qu’architecte, si ce framework doit être appliqué ou non, et sans renier la certification, réfléchir à comment l’appliquer et avec quel niveau d’investissement.
Nous allons donc commencer par explorer, dans cet article, les 2 premières phases, puis nous aborderons les autres phases dans de prochains articles.
Enfin certifié
Imaginons un plan de transformation du système d’information, vous êtes architecte et
on vous propose une formation. Comme vous êtes curieux, vous acceptez, et comme vous êtes travailleur vous réussissez l’examen final. Une fois la certification obtenue, et la satisfaction qui va avec, chacun s’est posé cette question : Qu’est-ce que je fais maintenant ? Et trop souvent, le résultat obtenu est décevant.
Il est décevant pour les certifiés qui ne savent pas comment mettre en œuvre ce qu’ils ont appris, mais aussi pour ceux qui ont financé cette certification et tout le monde a déjà entendu « TOGAF est trop loin de la réalité, cela ne sert à rien ». Alors, comment faire pour ne pas en arriver là ?
La phase préliminaire
Une phase primordiale
La première des phases de la roue ADM est celle qui, justement, est en dehors de la fameuse roue. C’est pourtant une phase vitale pour la suite de vos travaux. Elle sert à préparer l’entreprise aux travaux d’architecture (et pas uniquement la DSI). Les questions que l’on doit se poser sont « Où allons-nous faire de l’architecture ? avec Qui et Comment ? », mais également « Pourquoi ? ». L’odbjectif principal de cette phase est donc de construire une vue succincte des besoins, pour ensuite définir les capacités d’architecture que l’on pense nécessaire. Nous sommes en train de cadrer la mise en œuvre de l’architecture.
Capitaliser sur le sponsor
Lors de la formation, nous avons appris qu’il fallait commencer par définir la structure de l’entreprise puis les éléments métiers qui poussent au lancement de ce projet, de formuler la demande de travaux, de définir les principes d’architecture s’appliquant au projet, le référentiel à utiliser et les relations avec les autres référentiels de pilotage. Mais c’est également à ce moment qu’il faut évaluer la maturité de l’entreprise sur les notions d’architecture et que l’on peut adapter la méthodologie et l’ADM au projet.
Les « entrées », informations censées être collectées avant le projet, seraient : le modèle de l’organisation de l’entreprise, le référentiel méthodologique d’architecture, les outils, les principes d’architecture, le continuum d’entreprise, le référentiel d’architecture et le cadre de capacité… mais dans les faits, ces « entrées » sont rarement présentes.
Et pourtant, TOGAF préconise une première réunion avec le sponsor / commanditaire lors de cette phase et celle-ci est obligatoire. Lors de cette première réunion, les points cruciaux sont les entités / fonctions de l’entreprise pour définir le périmètre de l’étude, la gouvernance du projet d’architecture et bien sûr, le driver de la transformation. Sans cette réunion, il n’est pas utile d’aller plus loin, et si cela est difficile à organiser, vous avez déjà votre évaluation de la maturité.
Capitaliser sur ce qui existe pour ne pas consommer trop de temps
D’après TOGAF, il est possible, lors de cette phase, de modifier la roue ADM pour répondre au mieux aux besoins du projet de l’entreprise. Attention toutefois, il peut être dangereux de remettre en cause la roue ADM à chaque itération, et il faut absolument en garder le principe (l’enchainement des phases et les liens entre elles). Il est préférable d’avoir une roue stable sur un segment fonctionnel donné.
Nous allons donc commencer par la phase préliminaire elle-même : Le but est de de capitaliser sur ce qui a déjà été fait. Lors de la réunion avec le sponsor, vous avez identifié les grandes fonctions impactées. Pour identifier la capacité d’architecture nécessaire à votre projet, 3 situations peuvent se présenter à vous :
- Si vous être dans une grande entreprise, il y a déjà des architectes en charge de ces fonctions, il suffit de leur exposer les attendus métier et de collecter leurs retours.
- Si ce n’est pas le cas, il est possible de se baser sur des projets précédents. De façon native, de nombreuses étapes de la roue TOGAF sont déjà mises en place au sein d’un SI : des architectures applicatives ou techniques, parfois des processus sont déjà modélisés, des plans de migration sont mis à plat avec la gouvernance associée. Cela est tout à fait normal car TOGAF est un framework pour répondre à des besoins liés à une DSI et parfois, des réponses ont déjà été apportées à des besoins apparus lors des projets. Il faut alors se baser sur ce retour d’expérience.
- Si vous n’êtes dans aucun des cas précédents, Il ne reste plus qu’à construire vous-même vos hypothèses. Basez vous sur quelques concepts faciles à identifier : Combien de processus ? Sont-ils le cœur de métier de l’entreprise ou pas ? Quelle est l’application au cœur de la transformation et quelle est l’équipe qui en a la charge ? Ces hypothèses seront évidemment fausses mais cela permet de poser une première brique.
Savoir comment valider ses propositions
Pour finir cette phase, il reste à définir comment faire valider vos travaux. Pour cela rien de plus facile : Si un processus de validation existe déjà, demandez-le ainsi que le temps moyen de validation. S’il vous semble imparfait, n’essayer pas de le faire modifier. Vous allez perdre du temps qui serait utile à votre projet. Si aucun processus n’existe, faites valider vos propositions par le sponsor et les parties prenantes, comme cela est préconisé par TOGAF.
Tout le monde sur la ligne de départ
A la fin de cette phase, vous aurez la structure de votre équipe d’architecture, qui valide les étapes et les résultats de l’étude, prête à démarrer votre projet.
La phase a : la vision de l’architecture
Les choses sérieuses commencent
La phase de vision de l’architecture permet de définir les impacts du projet sur le système d’information ainsi que les chantiers d’architecture à mettre en place. Elle est précédée de la phase préliminaire ou de la roue ADM précédente (en plus clair, la précédente phase du projet).
D’après TOGAF, a liste des étapes pour construire la vision d’architecture sont : identifier les parties prenantes et leurs exigences, les enjeux métiers (les bénéfices attendus par le métier), confirmer les objectifs, évaluer le niveau de motivation et de préparation des métiers, ainsi que les capacités des dits métiers, confirmer les principes d’architecture, définir les KPI pour mesurer les bénéfices d’architecture, les risques… Bien sûr, tout cela est logique dans un monde sans contrainte, mais cela arrive peu, pour ne pas dire jamais :
- Comment évaluer les capacités du métier à répondre aux attentes de l’architecture, son niveau de motivation ou de préparation ? L’architecture est habituellement intégrée à la DSI et à quoi bon faire cela ? Comment présenter au métier, qui finance la DSI et l’étude, qu’il n’est pas au niveau et quels seraient les critères pour dire cela ?
- Comment estimer la capacité du métier ? A partir des chaines de valeur ? Le contrôle de gestion de l’entreprise est le seul à avoir les informations nécessaires, mais les informations sont rarement partagées.
- Et pour les KPI, comment faire une évaluation des gains alors que les problèmes à résoudre sont noyés dans le reste des activités des utilisateurs ?
Se concentrer sur l’essentiel
En fait, tout cela s’ajuste au fur et à mesure de l’avancée de l’étude, car cela permet au métier de reprendre le contrôle sur ses outils et ses processus. Cependant, on peut rapidement réaliser quelques étapes de cette phase :
- Construire une carte des parties prenantes permet de faire une estimation rapide des influences de chacun.
- Faire une macro-cartographie pour définir les grands ensembles du projet ainsi que quelques scenarios métiers pour pouvoir « jouer » des cas pratiques lors de la conception de la solution.
- Si la mise en place des KPI n’est pas possible, on peut au moins demander au métier de faire une pondération « à dire d’expert » de ses attendus. En fait, il suffit souvent de demander les différents « pain points » à résoudre ainsi que les nouveaux besoins auxquels répondre, et de demander un ordre de priorité. A la fin du projet, vous pourrez demander au métier si la solution apportée lui convient.
L’état des lieux est terminé
Au final, cela permet à chacun de faire une évaluation plus fine de l’étude à réaliser et de compléter la note de cadrage. Comme dans toutes les épreuves, tous ces éléments vont s’affiner avec le temps et il est bon de garder le document pour le confronter au réel.
La suite
La grande force de la roue TOGAF est qu’elle traite toutes les problématiques liées à l’architecture et apporte une réponse, ou au moins un Framework pour répondre, à ces problématiques. Et comme tout framework, il est important de l’appliquer à un contexte. Suivre TOGAF c’est bien, savoir le faire sans oublier pourquoi, c’est mieux. Il n’est pas utile de tout faire exactement comme cela est préconisé – tous les acteurs du projet n’en saisissent pas forcement les bénéfices – mais il est tout à fait possible d’en extraire l’essentiel. Apres avoir traité les deux premières phases, nous continuerons, dans les prochains articles, à parcourir les autres phases la roue ADM et explorer ensemble TOGAF IN REAL LIFE.
