L’essentiel à retenir
- L’alignement avec le développement Agile des projets se fait en Phase G.
- Une bonne architecture définit le backlog de l’entreprise.
- Les contraintes d’entreprise priment sur la préférence locale d’un product owner.
- L’agilité d’entreprise est plus large que l’Agile logiciel ; partitions, niveaux et itération y répondent.
- Le TOGAF s’adapte et s’intègre aux autres cadres plutôt que de les remplacer.
L’Agile se rencontre en Phase G
Le guide situe l’alignement entre le TOGAF et le développement Agile en Phase G, là où les projets sont réalisés. Il s’agit du développement Agile des projets, qu’il faut distinguer d’un développement Agile de l’Enterprise Architecture elle-même, traité par d’autres guides.
En Phase G, le praticien sert les parties prenantes des projets Agile en protégeant la valeur d’entreprise : la mission, la vision, les objectifs et la feuille de route d’investissement. Il ne livre pas les incréments à la place des équipes et ne bloque pas les sprints.
Ce que l’architecture apporte aux équipes Agile
L’architecture aide à décider quels produits l’entreprise doit posséder, où passent leurs frontières et quelles contraintes s’imposent au product owner. Ces contraintes limitent volontairement les choix de l’équipe : c’est là qu’un produit doit se plier aux enjeux de l’entreprise, et la préférence locale d’un product owner n’y est pas recevable. En résumé, une bonne architecture définit le backlog de l’entreprise.
Développer l’architecture pour différentes finalités et à différents niveaux de détail rend cet apport possible : une architecture au service de la stratégie ou du portefeuille fait apparaître les produits et les priorités, tandis qu’une architecture au service de la livraison de solution fixe les contraintes, contrôles et exigences que les équipes respectent sprint après sprint.
- Identifier les produits nécessaires et leurs frontières
- Poser les contraintes qui encadrent le product owner
- Alimenter le backlog de l’entreprise
Agilité d’entreprise et autres cadres
Le standard rappelle que l’agilité d’entreprise dépasse le développement logiciel Agile : elle permet de mieux réagir au changement en étant plus centré sur le client et le produit, plus efficace et mieux armé pour la conformité réglementaire. Le TOGAF y répond par les partitions, qui découpent le travail en plusieurs initiatives, par les niveaux, qui modulent granularité et détail, et par l’itération. Des guides dédiés approfondissent le sujet : Applying the ADM Using Agile Sprints, Enabling Enterprise Agility, ainsi que le standard Open Agile Architecture.
Enfin, la plupart des frameworks d’architecture décrivent surtout des livrables et restent discrets sur la méthode. Le TOGAF peut être utilisé seul, ou voir ses livrables génériques remplacés ou étendus par ceux d’un autre framework. L’architecte adapte la méthode pour l’intégrer aux processus de l’entreprise, en la combinant si besoin avec ITIL, CMMI, COBIT, PRINCE2, PMBOK ou MSP.
LES MOTS À CONNAÎTRE
Le vocabulaire, avec du sens.
- Agilité d’entreprise
- Capacité de l’entreprise à réagir au changement en restant centrée client et produit, efficace et conforme.
- Product owner
- Responsable d’un produit dans une équipe Agile, dont les choix restent encadrés par les contraintes d’architecture.
- Backlog d’entreprise
- Ensemble priorisé des évolutions à réaliser à l’échelle de l’entreprise, que l’architecture aide à définir.
- Partition
- Découpage du travail d’architecture en plusieurs initiatives menées séparément.
- Niveau
- Degré de granularité et de détail auquel une architecture est développée.