TOGAF IRL 2 (In Real Life) - Rhapsodies Conseil

18 décembre 2019

– 4 min

Antoine Arnault

Tout le monde est aligné sur le départ

Souvenez-vous ! Lors du dernier article, nous venions d’obtenir notre certification TOGAF et nous voulions voir comment appliquer ce framework dans la « vraie vie ». Nous avons donc mis en place Les capacités d’architecture (phase Préliminaire et phase A), et maintenant nous allons continuer en suivant la roue ADM (Architecture Development Method).

Nous allons donc parler dans cet article, de la définition des exigences propres à chaque niveau du Système d’Information (la couche métier, la couche applicative et la couche technique) et qui vont impacter le projet. Puis dans le prochain article, nous finirons avec leurs conséquences sur le design des solutions et comment fermer la roue.

La définition des exigences peut changer du tout au tout en fonction du domaine d’activité de votre entreprise / client. Culturellement, le domaine industriel a toujours été plus sensible à la rédaction des exigences que le domaine tertiaire. Vous imaginez bien que pour construire une centrale nucléaire, la liste des exigences est plus importante que pour construire une application de gestion de la solution client (CRM) car en cas de problème, les conséquences sont moins importantes.

Gestion des exigences ou le référentiel des exigences

La gestion des exigences doit permettre de s’assurer du bon suivi des exigences exprimées lors des différentes phases de la roue ADM mais également de s’assurer de leur cohérence. Pour cela, il faut 3 choses :

Un référentiel des exigences pour les stocker
Un processus de mise à jour
Un processus de revue pour la mise en cohérence des exigences.

TOGAF est un framework avec une approche « Test Driven Design ». C’est-à-dire que les exigences du système d’information ont pour but d’être testées. Il est donc primordial de bien les maîtriser de les prioriser, de connaître leur historique, de pouvoir les évaluer et de voir à la fin si le produit fini du projet y répond correctement.

Pour cela, il peut être intéressant d’outiller la gestion des exigences et de créer un référentiel. Si un outil existe déjà, utilisez-le, les plus connus sont IBM rational DOORS, Envision Requirements, JIRA ou autre. Dans le cas contraire un fichier Excel dont la gestion sera sous la responsabilité de l’architecte projet sera bien suffisant. De plus, les exigences seront gardées à la fin du projet et pourront être réutilisées lors du démarrage d’un nouveau cycle de la roue ADM. Il est alors préférable de nommer un responsable de l’administration de ce référentiel.

Maintenant que tout est prêt, nous pouvons continuer de parcourir la roue ADM et commencer à identifier les exigences auxquelles il va falloir répondre.

Phase B : Architecture métier ou comment solliciter son métier à bon escient ?

La phase B de la roue ADM doit permettre de décrire comment votre entreprise (ou le domaine métier impacté par votre projet) doit s’organiser pour atteindre les objectifs. Le travail va donc se concentrer sur la définition de la stratégie, sur la gouvernance, l’organisation métier et les informations clés des processus métier. Et comme lors des précédentes phases, le but est de ne pas surinvestir et de ne consommer que de la charge de travail avec une véritable valeur ajoutée.

La majorité du temps, les équipes d’architectes font partie de la DSI, les relations avec le métier peuvent donc être multiples :

Nous avons directement accès au métier et les impacts sur les processus sont faibles : La disponibilité du métier risque d’être faible car il a ses tâches récurrentes à effectuer (vente, gestion, comptabilité). Dans ce cas, il est nécessaire de lui prendre le moins de temps possible : traduire les enjeux métier, lister les processus et les « pain points ». Seuls quelques ateliers seront nécessaires pour collecter ces informations, il suffit ensuite d’en déduire les exigences métiers.
Nous avons directement accès au métier et les impacts sur le métier sont importants : dans ce cas, le métier doit se rendre disponible pour répondre au besoin. C’est généralement le cas préféré des architectes car cela permet de poser ses questions en toute liberté.
Nous devons passer par une MOA, qui est un intermédiaire avec le métier. L’avantage de cette relation est qu’une MOA est intégrée dans le projet et qu’elle se rendra disponible pour répondre aux besoins du projet. Le problème est que la MOA n’est pas forcément au courant des enjeux du métier, selon l’organisation mise en place entre la DSI et le métier.

Une fois que les exigences métiers sont identifiées et le référentiel mis à jour, nous pouvons passer aux exigences liées au système d’information.

Phase C : L’architecture du système informatique car même l’IT a ses propres exigences…

Les exigences du système d’informations se découpent en 2 catégories. Celles qui s’appliquent à l’intégralité du système d’information et celles qui s’appliquent au projet.

Les exigences qui s’appliquent à tout le SI sont souvent les plus faciles à appréhender pour les architectes : ce sont les exigences d’architecture que nous connaissons tous comme :
1. Un identifiant doit être unique et non interprétable.
2. Une fonction ne peut pas être implémentée plusieurs fois dans le SI…
3. La séparation des fonctions de production et de distribution,
4. Celles liées aux échanges (API, couche d’échange…),
5. Sur les sources de données (le terme de « Golden Source » est souvent utilisé),
6. Ou les réglementations comme sur la protection des données (Règlement Général sur la Protection des Données, ….).
Puis viennent toutes les exigences spécifiques au projet en lui-même comme celles liées à la confidentialité, l’intégrité, la disponibilité ou l’authentification / identification. La mise à niveau des exigences précédemment édictées par le métier est souvent négligée. Quand cette mise à niveau n’est pas faite (peu importe le formalisme), cela révèle souvent un manque de dialogue entre les équipes projet métier et IT. Cet effort est nécessaire car une partie de la valeur de l’architecte est justement de créer un pont entre ces deux mondes.

Phase D : Architecture technique

Dans les DSI importantes, des architectes dédiés ont généralement la charge de la partie technique. En effet, un architecte ne peut pas avoir le même niveau d’expertise sur toutes les couches du système d’information et la frontière se trouve historiquement à ce niveau. Dans les DSI plus petites, la césure entre les architectes techniques et les architectes fonctionnels est moins importante mais elle existe souvent malgré tout.

L’architecte technique doit avoir une bonne connaissance du catalogue des normes et standards de l’entreprise. Savoir quels sont les composants (technologies, logiciels…) à utiliser, où en est leur cycle de vie et les mettre en regard du projet. L’architecte se confronte également à la stratégie de la DSI et à sa politique fournisseurs notamment (quand elle existe).

Dans le cas de solutions hébergées en interne, l’architecte technique doit définir les exigences techniques qui permettent de dimensionner correctement l’infrastructure. Dans le cas de solutions Cloud ou d’application en SAAS, les exigences liées aux infrastructures n’ont plus de raison d’être, elles doivent être définies en termes de SLA (plus besoin de calculer le nombre de serveurs, car l’hébergeur est garant du dimensionnement). Dans ce dernier cas, s’occuper des interfaces est plus que nécessaire.

A la fin de cette phase, le référentiel d’architecture doit s’enrichir en précisant les composants à utiliser pour atteindre la cible désirée et la feuille de route provisoire avec les recommandations de mises en œuvre.

Conclusion

A ce niveau d’avancement, nous avons pu collecter et finaliser l’ensemble des exigences du projet. Nous avons également une vue assez claire d’où nous partons et où nous voulons aller, sauf que nous sommes encore dans un monde « sans contrainte ». Nous savons ce que nous voulons (ou ne voulons pas) mais il faut à présent se confronter au monde réel, fait de contraintes de planning, de budget, de disponibilités des ressources et donc sortir de cette tour d’ivoire où se sont parfois enfermés d’autres architectes avant vous. Les négociations et les arbitrages commencent et la valeur tangible apportées aux projets se mesure ici, comme nous le verrons dans le troisième et dernier article de cette série sur TOGAF In Real Life.