Pourquoi ?
- Principe 1 : Tout système a une mission – La mission d’un système doit pouvoir s’exprimer en une seule phrase simple, compréhensible et partagée par tous. Incarnée par un sponsor légitime, sa réussite doit être mesurée par un nombre très limité d’indicateurs de performance définis au préalable.
Quoi ?
- Principe 2 :Toute partie prenante doit avoir été identifiée – Les parties prenantes d’un système vont bien au-delà des clients et des utilisateurs : certaines sont souvent cachées alors qu’elles ont une influence indirecte forte. Il faut les connaître et les faire participer en amont !
- Principe 3 : Tout composant d’un système doit avoir un propriétaire – Un système doit toujours être aligné avec l’organisation projet qui le conçoit et l’organisation qui l’utilise opérationnellement. Si une « boîte » technique n’a pas de propriétaire métier clair & naturel, c’est que l’architecture a mal été conçue.
Comment ?
- Principe 4 : Tout système doit être décrit simplement à haut niveau – La vision de haut niveau d’un système doit tenir sur un nombre très limité (pas plus de 7) de diagrammes simples à comprendre et à partager avec tous les acteurs clefs concernés, qu’il faudra ensuite affiner progressivement.
- Principe 5 : Réduisez la complexité en découplant vos problèmes – Décomposez toujours un problème en le séparant en un nombre limité de petits problèmes plus simples à traiter et les plus indépendants possibles – sur le plan organisationnel et technique – les uns des autres.
- Principe 6 : Concentrez-vous d’abord sur les interfaces – Les interfaces sont clefs et doivent être négociées avec soin par toutes leurs parties prenantes concernées avec l’aide d’un architecte facilitateur.
- Principe 7 : N’oubliez jamais les données – La connaissance des données est extrêmement structurante car elles transitent dans tout le système : n’oubliez donc jamais de définir en amont leur architecture avec toutes les parties prenantes concernées.
