13 novembre 2023
Thomas Jardinet
Manager Architecture
Salomé Culis
Consultante Architecture
Le VRAI Enterprise Architect
Cet article est le troisième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version 6 du framework SAFe.
Après avoir étudié le System Architect et le Solution Architect, rencontrons l’Enterprise Architect ! Avant de rentrer dans le vif du sujet, nous souhaitions vous faire part de nos impressions quant aux évolutions du rôle de l’Enterprise Architect.
Dans les versions précédentes, le rôle de l’architecte d’entreprise n’était pas très détaillé. Il était clair que celui-ci intervenait dans la définition de la stratégie et aidait à mettre en adéquation les évolutions du système d’information avec celles du métier de l’entreprise, mais cela s’arrêtait là.
Dans cette nouvelle version, le framework contient beaucoup plus de détails sur les responsabilités de l’architecte d’entreprise. Celui-ci gagne ses lettres de noblesse et récupère dans sa bannette des sujets qu’il aurait toujours dû avoir (par exemple la rationalisation du portefeuille technologique). Son rôle n’est plus dans la pure stratégie décorrélée du terrain, il devient plus concret.
En revanche, il a aussi tout un lot d’activités nouvelles, que nous détaillerons dans la suite, et qui nous font dire qu’il faut avoir les épaules très larges pour occuper ce poste. L’architecte d’entreprise semble être partout à la fois, il est devenu une sorte de couteau-suisse ou d’architecte tout terrain si vous me passez l’expression.
Serait-il devenu l’architecte de l’entreprise ? Celui qui cumule bon nombre de responsabilités et qui collabore très largement avec l’ensemble de l’entreprise ? C’est ce que nous allons découvrir dans la suite !
De nouvelles responsabilités : De la définition de la stratégie, aux mains dans le code.
L’entreprise Architect s’est ainsi beaucoup musclé au passage de la version 5 vers la version 6 du framework Safe. Il est certes toujours responsable, au mot près, de la stratégie. Mais d’un rôle de facilitateur semi-passif (« Collaborating », « Assisting », « Helping », « Participating », etc…), il bascule vers un rôle de prescripteur. Un regard critique dirait qu’il retrouve ses prérogatives naturelles… Ainsi les différents (et nouveaux) rôles définis par le framework Safe sont :
- Aligning Business and Technical Strategies
- Coeur de métier de l’entreprise architect, son rôle est avant tout d’aligner l’architecture avec la stratégie IT, le tout en partageant ainsi sa vision et la stratégie business. Il identifie également les value streams à mettre en place, entretient ses relations avec les différentes équipes et va même jusqu’à participer aux démos.
- Establish the Portfolio’s Intentional Architecture
- Il s’agit là de définir une architecture cible avec des technologies cibles, des patterns d’architecture, le tout en synchronisant toutes les équipes ensemble. Fait marquant, l’apparition de la démarche inverse de Conway, consistant à définir une architecture, puis à calquer l’organisation sur cette architecture. Le contraire de ce qui est fait en général somme toute. L’architecte d’entreprise devient donc le responsable de la définition de l’organisation des équipes, ce qui en soit est un gros shift!
- Rationalizing the Technology Portfolio
- Le grand classique de l’architecture d’entreprise. On mutualise, on réduit les coûts, on réduit la complexité, etc…
- Fostering Innovative Ideas and Technologies
- Le titre est presque trompeur. Il s’agit surtout de permettre d’avoir un environnement technologique moderne et “propre”, en supprimant les technologies obsolètes, apporter du support aux environnements de développements, mais aussi en alignant les choix technologiques avec les business models pressentis.
- Guiding Enabler Epics
- Il est epic owner sur les initiatives d’architecture, et participe aux réunions safe pour s’assurer du bon alignement des équipes.
L’architecte d’entreprise reprend donc son rôle d’architecte d’entreprise, du métier aux développeurs, en passant par l’organisation des équipes. Par contre, son rôle est beaucoup plus étendu que dans la version 5, se retrouvant ainsi au milieu de nombreux acteurs.
Un accent mis sur la collaboration : D’une tour d’ivoire à un lean-agile leader
En effet, dans la version précédente de Safe, l’architecte d’entreprise était vu comme gravitant surtout dans les hautes sphères et ne collaborait qu’avec les autres architectes et des acteurs de haut niveau ou très transverses (Lean Portfolio Management, Agile Program Management Office, et le Lean-Agile Center of Excellence par exemple).
Il était supposé maintenir des relations avec les personnes de chaque Train mais ses activités quotidiennes ne s’y prêtaient guère. A présent que son périmètre s’étend considérablement, il sera amené à croiser des acteurs beaucoup plus nombreux. Il intervient comme proxy des acteurs business et doit être capable de porter la vision et la stratégie business auprès des différentes parties prenantes.
Il participe également à tous les événements en lien avec les enablers epics et aura donc l’occasion d’interagir avec les acteurs opérationnels des différents Trains.
Ses responsabilités étant également plus distinctes de celles des autres architectes, leur complémentarité est d’autant plus mise en évidence. Une collaboration efficace entre l’Entreprise Architect, le Solution Architect et le System Architect garantit l’alignement.
Enfin, l’Entreprise Architect doit incarner le Lead Agile Leader par excellence. Il mentore les équipes agiles, contribue à la mise en place de nouveaux modes de fonctionnement, et montre l’exemple en continuant à apprendre et à évoluer. Une forme de super héros inspirant tout le monde sur son passage, facile non ?
Si ces sujets vous intéressent…
Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.
Les articles 4 et 6 peuvent en particulier se révéler utiles :
- Article 4 : intitulé “Comment les architectes d’entreprise peuvent interagir avec l’agilité ?”, nous avions évoqué le concept de continuous architecture, et le besoin pour l’architecte de rester opérationnel voir carrément proche du code.
- Dans l’article 6, intitulé “Les 7 formations de l’Architecte Agile”, nous avions évoqué le besoin de formation SAFE pour l’architecte, et nous avions également parlé de la posture de coach de l’architecte via la process communication et la PNL.
Parmi la littérature conseillée par le framework Safe, on ne peut que vous conseiller le fameux livre “Team Topologies” qui évoque le rapprochement des équipes technologies et business :