Architecture d’entreprise et agilité – chap 4 : comment les architectes d’entreprise peuvent interagir avec l’agilité ?
En tant qu’architecte, quelle posture adopter face à un projet Agile ? Et dans le cadre plus global d’une entreprise Agile, comment est intégrée la notion d’architecture ? Quel rôle est dévolu à la fonction Architecture ?
Les principaux frameworks d’agilité à l’échelle intègrent l’architecture d’entreprise : DAD – Disciplined Agile Delivery-, SAFe – Scaled Agile Framework- et LeSS – Large Scaled Scrum.
Que nous manque-t-il alors pour vraiment travailler ensemble ?
Les architectes et l’agilité se connaissent !
D’un côté, les architectes ont travaillé à l’évolution de leurs pratiques et regardent l’agilité avec intérêt depuis plusieurs années déjà : article de 2008, article de 2010, conférence de l’Agile Tour en 2011, etc… Ils ont inventé la « Continuous Architecture »
La « Continuous Architecture » énonce des principes facilitant l’interaction avec les projets en agilité. Ces principes mettent en avant l’adaptation et l’intelligence qui doivent guider les travaux des architectes pour convenir au rythme et au fonctionnement des projets Agiles.
Voici quelques principes de « Continuous Architecture » qu’il est intéressant de noter : partager les décisions, partager l’information, être collaboratif, etc …
D’un autre côté, les framework d’agilité à l’échelle les plus connus (DAD, LeSS ou SAFe par exemple) ont pris en compte les architectes dans leurs modes opératoires. Des définitions de l’architecture sont proposées. Les livrables et interactions des architectes avec les projets / programmes agiles sont définis.
Quelles questions restent donc à traiter pour que les 2 travaillent en symbiose ?
Une bonne définition de l’architecture d’entreprise dans l’agilité
Les définitions proposées par les frameworks d’agilité à l’échelle reprennent les éléments essentiels de l’Architecture d’Entreprise :
Vision long terme et à haut niveau de la transformation de l’entreprise,
Réutilisation,
Interaction avec les projets,
etc…
Des exemples concrets mettent en avant les apports de l’architecture dans le cycle de vie d’un produit Agile. DAD a un chapitre « Pourquoi l’Architecture d’Entreprise » qui décrit les apports essentiels de l’architecture d’Entreprise pour les projets comme de pouvoir se concentrer sur la valeur ajoutée et une plus grande cohérence dans les solutions.
L’architecture devient agile – forcément
Les frameworks mettent en avant des principes d’agilité que les architectes se doivent de respecter. Ainsi SAFe recommande aux architectes de bien rester en contact avec les activités journalières de développement et les équipes projets. De ce rapprochement, un gain mutuel de confiance est espéré : les architectes auront plus confiance dans les équipes projet pour suivre les cadres d’architecture, les équipes projet auront plus confiance dans les solutions proposées par les architectes.
Pour être en conformité avec les principes agiles, on remarquera que dans DAD, tous les livrables de l’Architecture sont sujets à des feedbacks (retours d’expérience). Il n’y a pas de décision unilatérale. L’architecture est dans un processus permanent de discussion et d’évolution.
Continous architecture – l’architecture agile
Pour se mettre en accord avec les concepts de l’agilité, l’architecture d’entreprise a énoncé un certain nombre de recommandations. L’une d’elles est justement de donner des principes d’architecture et non des règles !
Une autre de ces recommandations consiste à prendre les décisions le plus tard possible, laissant aux projets la possibilité d’étudier plusieurs solutions avant de trancher quand vraiment il le faut.
Une autre recommandation consiste à dire « il faut partager de l’information et non de la documentation », nous rappelle la discussion du chapitre 2 de cette série d’article. En d’autres termes et pour citer le manifeste Agile : les individus et leurs interactions plutôt que les processus et les outils.
Mais parfois l’Architecture semble quand même trop éloignée des préoccupations des projets…
Less et les architectes powerpoint vs les master programmers
Le framework LeSS, dans son chapitre sur Architecture & design, consacre son introduction à préciser que l’architecture de l’informatique est dans le code : ceux qui font sont ceux qui savent. Les architectes qui ne font plus du code mais font de l’architecture pour les managers ou de l’architecture pour de l’architecture finissent par se couper du monde et ne plus être entendus par les projets. Ils deviennent des « Architectes PowerPoint dans leur tour d’ivoire ».
Même si tous les architectes, qui plus est dans les grandes entreprises, ne peuvent pas rester au contact du code (qui plus en est quand la politique d’entreprise est centrée sur l’intégration de progiciels plutôt que la conception d’applications), il est de leur devoir d’interagir avec les architectes plus opérationnels et de veiller à ce que leurs travaux restent compréhensibles par tous. Et bien sûr applicables !
LeSS rappelle que le principal intérêt d’un modèle est la discussion que l’on a en faisant ce modèle. Le modèle n’est pas la solution et ne doit pas rester figé dans le temps.
Ces images illustrent la différence entre ce qui a été proposé (chemin goudronné) et les usages (chemin tracé par le passage des piétons)
Coaching et agilité ?
La transformation vers l’entreprise agile se fait beaucoup à partir de coaching des équipes et des managers. Ils sont accompagnés dans une réelle évolution de leurs pratiques afin de développer des modes de travail plus collaboratifs et les conditions d’une meilleure coopération.
En général, des coachs agiles interviennent pour faire évoluer ces pratiques et accélérer la transformation. Il faut alors qu’un mode de fonctionnement soit établi et les parties prenantes (comme les architectes) impliquées dans ces transformations.
Les architectes doivent donc être inclus dans ces transformations afin de bien mettre en place les modes de fonctionnement adaptés à chaque entreprise.
Les architectes doivent-ils être certifiés SCRUM Master ou Product Owner ? Doivent-ils être formés aux frameworks d’agilité à l’échelle comme DAD, LeSS ou SAFe ? Doivent-ils être accompagnés de coachs agiles ?
Suivant la transformation en cours, chaque entreprise devra apporter sa réponse. Que cela soit pour les architectes ou d’autres fonctions d’ailleurs !
Pour que l’architecture d’entreprise et l’agilité puissent travailler ensemble, il faut que l’entreprise s’approprie l’un et l’autre et pense bien à les faire travailler ensemble. La communication est un élément clé de cette réussite.
L’architecture d’Entreprise doit être un facteur facilitateur de l’agilité car elle apporte une vision partagée de la stratégie d’évolution du SI et doit donc servir à guider l’ensemble des travaux de l’entreprise sur son SI.
Dans le chapitre suivant, nous parlerons de l’évolution d’un des travaux majeurs des Architectes, le Schéma Directeur du SI.
L’expression « SI Agile » revient régulièrement dans les articles récents. Si son sens premier se comprend bien, quel est le rapport entre SI Agile et Entreprise Agile ?
Nous avons vu dans notre chapitre 1 que le terme « Agilité » était employé pour des moyens, des organisations, des méthodes et des techniques utilisés à différents niveaux dans l’entreprise. Mais rien sur le Système d’Information… Pour le SI, le terme de « flexible » semble plus approprié.
Définition du si « agile » ou « flexible » ?
La définition communément admise est un SI dont la capacité de « time-to-market » a été fortement accélérée.
On rajoutera à cette définition, 2 capacités supplémentaires :
Pouvoir réagir à l’inattendu : arrivée d’un nouveau concurrent (Exemple : Free Mobile pour la téléphonie)
Pouvoir s’adapter facilement aux évolutions métiers (réglementaire, uberisation, digitalisation) et exploiter les nouvelles technologiques (Cloud computing, Big Data).
Cette définition est calée sur les résultats attendus des projets agiles : accélération du Time-to-Market, réagir à l’inattendu et s’adapter aux évolutions en cours. Il est donc tentant d’utiliser le même adjectif « Agile » pour désigner les 2.
Pourquoi distinguer agilité de l’entreprise et flexibilité du si ?
Les projets / organisations / entreprises agiles ont besoin d’un SI qui leur permette de délivrer toute leur valeur ajoutée et notamment l’accélération du « time-to-market ».
A l’inverse, les travaux / investissements réalisés pour rendre un SI plus urbanisé et interopérable peuvent pousser l’entreprise à aller vers des projets agiles afin de profiter de tous les avantages de son SI et de rentabiliser ses investissements.
La mise en agilité de l’entreprise pousse à aller vers un SI flexible. Et réciproquement.
L’agilité de l’entreprise et la flexibilité du SI sont corrélés mais pas identiques. Pour étudier la dynamique entre les 2, il est préférable à mon sens de les distinguer : agilité pour l’entreprise et flexibilité pour le SI.
Comment construire un si flexible ?
Le SI s’est construit par accumulation de couches au fur et à mesure de son histoire. Malheureusement le SI résultat n’est pas naturellement flexible au sens où on le souhaite aujourd’hui. Le rendre flexible nécessite des projets et donc des coûts. Alors comment le construire ? Tout le SI doit-il être flexible ? Est-il possible de n’avoir qu’une partie du SI flexible ? Voilà des questions auquel un Architecte d’Entreprise doit être capable d’apporter son concours pour y répondre.
Retour d’Expérience : la tentative du Bi modal
La notion de SI bi-modal a été introduite il y a quelques années par le Gartner. Elle permettait de différencier 2 pans du SI et donc 2 vitesses de transformation différentes. Un SI flexible qui pouvait évoluer très vite pour des problèmes de concurrence, de stratégie commerciale et d’évolutions des clients et des technologies. Et à l’opposé, un SI non flexible, qui pourrait évoluer à une vitesse moindre car il ne serait pas soumis à ces pressions de « time-to-market ». Le problème de cette analyse était qu’elle opposait le front office (la partie distribution / commerce) avec la partie back office (mainframe souvent), en oubliant que les évolutions du premier avaient des impacts sur le second et donc que leur évolution devait être conjointe.
Une réflexion souvent entendue : « je peux bien faire des évolutions sur mon Front client tous les 15j mais quand je demande une évolution sur le mainframe (ouverture d’un flux) il faut 3 à 6 mois de délai »…. Cette notion de SI Bi-Modal a depuis été revue par ses concepteurs
Le SI des sociétés est composé de plusieurs parties qui peuvent évoluer à différentes vitesses grâce aux travaux menés par les architectes et les urbanistes. Ils ont préconisé la mise en place des systèmes d’échanges, des référentiels etc. Le couplage faible et l’interopérabilité entre les différentes parties du SI prennent maintenant tout leur sens.
Le SI est multiple et composite. Ses contraintes et interactions autant internes qu’externes, sont nombreuses et variées. C’est dans l’étude de ses différentes dimensions que nous allons pouvoir dégager des idées pour le rendre plus flexible.
Rendre à la fois toute l’entreprise agile et tout le si flexible?
Certaines entreprises ont lancé de grands programmes de transformation afin de rendre l’ensemble de l’entreprise agile et de rendre le SI flexible (Axa par exemple). Cette révolution est liée au besoin de transformation digitale, à la concurrence des start-ups (Uber, AirBnB) et des GAFA.
Quand cette transformation est impulsée par la Direction (métier pas uniquement la DSI) sur l’ensemble de l’entreprise, cela engendre un changement de culture global de l’entreprise. La mise en agilité est alors facilitée par les moyens mis en œuvre au niveau des directions, des métiers et de l’IT.
On retrouve néanmoins dans ces plans de transformation les 2 dimensions :
Changement de culture d’entreprise et de méthodes pour aller vers l’agilité de l’entreprise
Fortes évolutions architecturales et investissements pour rendre le SI flexible.
Pour des facilités de communication, les 2 sont alors identifiés sous le terme « Agilité ».
Mais cela n’est pas toujours possible, pour des raisons de budget, de culture d’entreprise, de technologie etc. Avant de lancer un tel programme, il peut être intéressant de ne rendre qu’une partie seulement de l’entreprise agile ou une partie du SI flexible. Cela permettra de tester et de valider la démarche avant de la déployer à l’échelle / sur tout le périmètre.
Un si flexible est un si opérationnel bien architecturé et une usine logicielle en place
Pour que le SI soit flexible, 2 axes sont à prendre en compte :
Le SI opérationnel doit être construit sur des bases solides. Ces bases sont connues : points de référence identifiés pour les données, pas de redondance applicative, couplage faible et interopérabilité entre les applications / services / domaines, Maitrise des flux etc.. Les grands principes de l’urbanisation des SI sont bien présents.
La mise en place « d’usines logicielles » permet l’accélération effective du « Time-to-market », pour développer, tester, recetter et mettre en production (devops – du développement jusqu’à la maintenance) dans les meilleurs délais les applications dans le SI opérationnel.
L’usine logicielle est bien un des moyens qui permet de construire et de mettre en place un SI opérationnel répondant aux critères de la flexibilité.
Traditionnellement les architectes interviennent sur la 1ère composante, le SI Opérationnel. Pour des raisons de cohérence d’ensemble, les architectes pourraient aussi avoir un œil sur la mise en place des usines logicielles.
Quelques outils autour du DevOps … qui ont besoin d’architecture
De l’intérêt de la vue d’ensemble du si et de l’architecture
Pour comprendre le SI opérationnel, il faut en avoir une vue d’ensemble et voir ainsi qu’elles sont les parties qui sont plus « étanches » ou « indépendantes » les unes par rapport aux autres. Celles qui peuvent (éventuellement) évoluer indépendamment d’autres parties.
La cartographie du SI est un point d’entrée essentiel de cette analyse. La cartographie doit prendre en compte plusieurs dimensions du SI : fonctionnelle, technologique, flux et données principalement. Mais peut aussi prendre en compte les processus, la finance, les utilisateurs …
Comme on l’a vu, il faut que cette analyse prenne en compte obligatoirement la dimension métier dans sa transversalité par rapport au SI, car c’était bien le défaut initial du SI bi-modal.
Si flexible sur quel périmètre et pour quels critères ?
Dans la réflexion, il est essentiel de bien réfléchir aux 2 aspects du SI que nous avons déjà identifiés : l’usine logicielle et le SI opérationnel pour garder une vue d’ensemble du SI et de sa construction.
Ci-dessous, nous proposons une base de questions pour identifier un périmètre d’amorce de flexibilité du SI :
Définir le rythme des évolutions demandées, le « time-to-market » : Des évolutions rapides demandées avec des livraisons régulières ? Alors la flexibilité s’impose pour cette partie du SI.
De nouveaux projets ? De nouveaux terrains à défricher ? Il faut en profiter pour mettre en place une nouvelle architecture SI et une usine logicielle adaptée. Attention toutefois à bien définir le périmètre du projet : un périmètre trop restreint ne permettra pas de démontrer les bénéfices et un périmètre trop large aura des risques de rejet.
Profiter des innovations technologiques ? Bien sûr mais attention aux risques liés aux nouvelles technologies et leur pérennité notamment.
Quel périmètre métier ? Distribution ? Cœur de métier ? ou au contraire fonction support ? L’efficacité, le besoin métier, le risque opérationnel mais aussi les facteurs humains doivent rentrer en ligne de compte du choix de périmètre
Il est important, dans ces phases, de faire intervenir les architectes d’entreprise pour garantir la cohérence globale du SI et donc sa future flexibilité.
Construire un SI flexible est un vrai challenge. Souvent lié en plus à un changement de culture avec l’agilité en point de mire.
Par leur connaissance globale du SI et les projets transverses qu’ils peuvent identifier (référentiel, systèmes d’échanges, interopérabilité etc.), les architectes peuvent aider l’entreprise à rentrer dans ce nouveau monde de l’entreprise agile et de son SI flexible.
L’agilité défend 4 valeurs principales. Dans certains cas, on constate des équipes dites agiles mais qui ne sont plus en phase avec les valeurs. Pourquoi ?
En quoi les valeurs de l’agilité et de l’architecture devraient-elles se rejoindre ?
Les 4 valeurs de l’agilité
L’agilité se base sur 4 grandes valeurs qui sont tirées du Manifeste Agile, complétées par 12 principes.
Des valeurs et pas des dogmes
Pour commencer, rappelons que ce sont des valeurs et non des règles. Cela signifie qu’il s’agit d’une vision partagée, chacun ayant la liberté de décider des mécanismes à mettre en place pour y arriver.
Ces valeurs présentent une nouvelle façon de faire, par opposition à l’ancienne.
En effet, quand la valeur prône « la collaboration avec les clients plutôt que la négociation contractuelle », cela ne veut pas dire la mort de tous les contrats. La contractualisation à outrance a eu tendance à éloigner les gens, à les faire se retrancher derrière des clauses comme derrière des barrières infranchissables. La nouvelle façon de faire met en avant la collaboration, le partage d’information, la confiance comme des moyens d’avancer plus efficacement. Les contrats existent toujours mais sont faits différemment, sur d’autres bases.
A l’identique de ces valeurs, pour l’Architecture d’Entreprise, un Framework comme TOGAF pose les bases et bons principes de comment faire de l’Architecture d’Entreprise. Chaque entreprise doit s’approprier ces principes, les décliner dans son contexte et les appliquer suivant sa culture et sa maturité. Il ne s’agit pas d’appliquer l’intégralité du Framework sans une réflexion préalable.
Pour illustrer à quel point les valeurs de l’Agilité peuvent être détournées par les projets ou sont mal comprises par des collaborateurs, j’ai choisi 2 phrases. Elles reviennent régulièrement dans la bouche de collaborateurs et elles nous montrent le chemin restant à parcourir pour la compréhension des bénéfices de l’agilité.
En agile, on ne fait pas de documentation !
Nous allons essayer quelque chose appelée
« Développement Agile »
Ce qui signifie qu’il n’y a plus de plannings et plus de documentation. On commence directement à programmer et à se plaindre
– Je suis content que cela ait un nom.
– C’était votre formation.
La valeur prônée par l’agilité est « des logiciels opérationnels plutôt qu’une documentation exhaustive ». Historiquement, les logiciels disposaient d’une documentation abondante (Spécifications générales, détaillées, etc.) qui n’était pas lue, peu utilisée, pas adéquate et très peu maintenue.
Le but principal d’un projet informatique est bien d’avoir un logiciel opérationnel qui répond aux besoins des utilisateurs. La documentation est un sous-produit du logiciel. Elle doit servir aux utilisateurs, aux personnes qui vont en faire la maintenance, etc. mais elle n’est pas un but en soi.
Beaucoup de projets « classiques » semblaient avoir oublié ce but et donnaient l’impression de livrer plus de documentation que de code à la fin des projets, un comble !
Qu’en est-il pour les projets en Agile ? Etant donné la proximité des participants, il n’est pas nécessaire de formaliser tous les échanges par de la documentation in extenso. Les échanges ayant lieu en direct, et verbalement, ils ont moins besoin d’être complètement décrits. Seul le résultat est conservé, les principales décisions, les règles métier et les choix faits. La documentation est réduite au juste nécessaire et une partie est parfois même stockée dans le code directement. Certains projets agiles en ont-ils profité pour ne pas faire de documentation du tout ? Possible. Les responsables des maintenances ont-ils été surpris de ne pas avoir autant de documentation qu’avant ? Fort probable. Que certains développeurs n’aiment pas faire de la documentation in extenso ? On les comprendrait presque. Mais la documentation ne s’adresse pas qu’aux développeurs. La documentation sur les choix métiers, les données et certaines règles de gestion peut avoir son utilité.
La bonne documentation est bien celle qui va servir par la suite et qui sera maintenue…
L’architecture ne fait que de la documentation ?
A l’inverse, les architectes ont souvent été « accusés » de ne produire que de la documentation. De ne produire que des règles et des normes, pas toujours facilement applicables, que le projet doit ensuite se justifier d’utiliser, ou pas.
Les projets penseraient même que l’architecture les contraint à remplir des dossiers et à passer par des comités qui ralentissent leur bonne marche. Que ces étapes coutent chers et n’apportent rien (ou presque).
Ce n’est bien sûr pas comme ça que nous concevons l’Architecture d’Entreprise. Elle se doit d’être au service et en accompagnement des projets. Leur fournir une aide et non être un frein.
Comme pour les projets, l’architecture doit être documentée utilement et sans excès. Elle apporte la vision d’ensemble du SI dont chaque projet a besoin. Il est essentiel de connaître les règles de construction, pourquoi elles ont été définies et pourquoi certaines dérogations ont été accordées… car la règle est la conséquence d’un besoin et la remise en cause de ce besoin doit remettre en cause la règle.
La bonne architecture est bien celle qui est opérationnelle et donc proche des projets…
Le problème avec l’agilité c’est qu’il n’y a pas de planning
Avant de de faire notre business plan pour l’année prochaine, regardons comment nous avons réalisé celui de l’année passée.
Finalement, nous n’avons rien fait de ce qui était prévu. Comme les autres années
– Pourquoi fait-on l’exercice alors ?
– Cela n’aurait aucun sens de de ne pas avoir de plan
La valeur prônée par l’agilité est « l’adaptation au changement plutôt que le suivi d’un plan ». Avant, le plan était roi et devait être suivi, parfois jusqu’à l’absurde. La planification « à la soviétique » (détaillée sur 5 ans et sans changement possible) en était la parfaite illustration.
Maintenant et dans un monde qui change si vite, les projets doivent s’adapter à l’évolution des besoins et des exigences. Plus question de faire des projets avec des « tunnels » de plusieurs années. Plus question de s’entendre dire, les spécifications sont validées, plus rien ne peut changer avant la prochaine version, l’année prochaine au mieux.
Pour autant et pour des besoins de cohérence et de synchronisation entre les livraisons des produits, il est essentiel d’avoir une certaine visibilité sur les projets. Une vision détaillée à court terme et une vision plus globale à moyen / long terme (les notions de court et moyen terme restent à adapter à chaque situation) sont nécessaires. Des outils agiles existent pour réussir à se projeter sur ces échelles de temps, comme le Burn-Up Chart par exemple. Ils utilisent les données issues des itérations complétées pour alimenter des éléments de pilotage permettant de prendre des décisions.
Car les plannings doivent servir à dégager des trajectoires et des orientations sur le long terme. Ils rendent possible la synchronisation entre les différentes évolutions en cours dans le SI.
Les architectes font des plannings sur 5 ans qui sont irréalisables
Les architectes d’entreprise, garants de la vision d’ensemble du SI, se doivent de dégager une trajectoire globale, long terme, du SI. Ce faisant, ils donnent parfois l’impression de figer les évolutions à plus court terme. Tout semble déjà prévu d’avance et sur 5 ans ! Il semble ne plus y avoir de place pour de nouvelles initiatives ou pour des changements. Les projets ont alors l’impression d’être mis devant le fait accompli et de devoir respecter des échéances qui leur sont imposées sans concertation.
C’est une vision de l’architecte que nous ne partageons pas du tout.
Oui, l’architecture d’entreprise doit bien dégager une vue d’ensemble sur le long terme et essayer de « mettre en musique » les différentes évolutions du SI. Pour autant, il n’est pas question de figer cette trajectoire et de ne pas être en capacité de réagir à court et moyen terme aux événements qui ne manqueront pas de survenir.
La cible du SI ainsi que sa trajectoire sont nécessaires pour consolider les évolutions, donner de la visibilité et apporter de la transversalité. Mais ils doivent être adaptés dès le départ aux contraintes projets et être revus régulièrement en fonction des avancées des projets et de tout ce qui peut avoir un impact (stratégie de l’entreprise, concurrence, avancement / retard des projets, technologies etc.).
La trajectoire du SI constitue un outil d’aide à la décision, d’une part en démontrant que l’évolution du SI répond aux enjeux métiers et d’autre part en mettant en évidence les dépendances entre les différents projets.
Le détournement des valeurs de l’Agilité, nous ramène aux reproches qui sont faits aux architectes : trop ou pas assez de documentation et de normes, trop ou pas assez de planification.
Certains sont trop loin des réalités et d’autres trop proches ?
La convergence de l’architecture et de l’Agile vers un (juste) milieu de documentation et de planification semble donc la solution permettant à chacun d’avoir les outils nécessaires.
Parlons-en et travaillons ensemble seront les maîtres mots des prochains chapitres.
Suite de la série : les solutions arrivent
Chap 3 : Comment l’architecture d’entreprise doit-elle aider à « agilifier » le SI ?
Chap 4 : Comment les architectes (d’entreprise mais aussi les autres) peuvent interagir avec l’agilité ?
En tant qu’architecte d’entreprise, l’agilité fait partie intégrante de ma vie et des projets depuis déjà quelques années. Mais qu’il est difficile de s’y retrouver dans tout ce qui est, ou se prétend, Agile. Alors comme tout bon architecte d’entreprise, j’ai commencé par faire un état des lieux : une cartographie.
Attention : ici je ne parlerai pas de technologies (chaque chose en son temps) mais bien de méthodes et d’approches.
Agilité, vaste monde !
L’agilité tout le monde en parle mais qui en fait vraiment ? De quelle agilité parle-t-on ? De méthodes Agile ? Plutôt que méthode, les termes utilisés sont plutôt culture, approche, mouvement ou courant Agile. L’agilité est mise à toutes les sauces : pour faire de l’innovation, de la gestion de projet, des modes de déploiement mais aussi pour le management d’entreprise.
Et l’agilité s’appuie sur des techniques plus anciennes comme le Lean, qui intègre Kanban et Kaizen.
Certains ont imaginé une carte de l’ensemble des pratiques Agile (voir ci-dessous) ressemblant au métro de Londres. J’avoue qu’avant j’étais un peu perdu, maintenant je suis complètement noyé !
Donc afin de simplifier et de présenter les pratiques d’un point de vue « Externe » à l’agilité, j’en propose une autre :
4 catégories pour s’y retrouver :
Le niveau entreprise : l’agilité a pour vocation de conquérir toute l’entreprise et de proposer de nouveaux modes de management
L’innovation : comment s’organiser pour trouver des solutions innovantes, des produits adaptés aux utilisateurs ?
Equipes et Projets : le Manifeste Agile et la méthode Scrum notamment rentrent dans cette catégorie, pour les projets de petite et moyenne taille. Utilisables par tous les projets mais surtout appliqués dans les projets IT à ce jour
Build et Opération: ensemble des méthodes et des techniques permettant d’implémenter dans le SI les produits délivrés par les projets
En parallèle, une catégorie « Techniques et Ateliers » est identifiée pour rassembler l’ensemble des techniques d’animations proposées dans le cadre de l’agilité et définir leur utilité.
Nous avons choisi de présenter ces 4 catégories dans un ordre qui part de l’innovation, puis des équipes et projets pour aller vers l’implémentation de leurs produits dans le SI en finissant par le déploiement de ces approches au niveau de l’entreprise.
L’innovation
Avec les nouvelles technologies et les nouveaux usages, sont apparues des techniques permettant de faire émerger l’innovation. Ces techniques mettent au centre de ces approches les utilisateurs des futures solutions et produits. Ces démarches sont souvent itératives et donc correspondent bien à la gestion des projets en agilité.
L’apport de ces démarches est de « se mettre à la place de ». Le concepteur de solution doit apprendre à penser comme la personne pour laquelle il doit bâtir une solution. Tous les concepteurs ou les MOA se sont plaints un jour que « le métier » ou « le client » ne savait pas exprimer son besoin. Le problème se résout de lui-même avec ces techniques. Basées sur les interactions avec les futurs utilisateurs, les personnes dont le métier est de concevoir peuvent comprendre voire anticiper leurs attentes.
L’innovation ne peut pas être encadrée ou commandée. Des principes d’innovation et les conditions pour créer de l’innovation peuvent être identifiées et donc mis en place rapidement pour sortir des anciens modes de conceptions de solution.
Méthodes et approches : Human-centered design, Design Thinking, Innovation game
Equipes et projets
Un changement de paradigme complet dans la manière de gérer les projets est apparu avec les approches Agile. SCRUM est la méthode de gestion de projet Agile la plus connue mais il en existe d’autres.
Cette approche a radicalement changé la manière de conduire des projets, le traditionnel « cycle en V », et de produire des résultats. On avance par itération, par incrément. Finis les effets tunnels. Les résultats sont rapidement concrétisés et il est possible de réagir au fur et à mesure.
Les projets en mode agile permettent d’adapter les produits au fur et à mesure de l’avancement du projet et de la réflexion.
Ces approches ont apporté de grands changements dans les méthodes de travail avec des réunions plus courtes mais plus fréquentes (tous les matins !), du management visuel, des capacités d’adaptation et d’auto-organisation qui sont à l’inverse des habitudes de management des anciens projets et de tous leurs travers.
Mais surtout ces approches ont entamé une révolution culturelle car elles font travailler ensemble de manière régulière et rapprochée des équipes, des spécialités qui ne se côtoyaient que peu ou rarement. Ces différents métiers ne se comprenaient pas ou mal. Les faire collaborer est toujours un challenge mais qui conduit à des résultats très concrets.
Méthodes et approches : Scrum, eXtreme Programming, Rapid Application Development, Domain Driven Design, Disciplined Agile Delivery, Dynamic systems development method (DSDM), Crystal Clear, le Manifeste Agile
Build et opération
Un des principes des projets en agilité est de pouvoir livrer régulièrement des incréments de valeur. Le but premier est de pouvoir tester ces incréments au fur et à mesure et de vérifier qu’ils satisfont l’utilisateur final. Dès lors, ces produits partiels (fonctionnels) peuvent être mis en production sans attendre la fin de l’ensemble des sprints.
Encore faut-il que le SI soit prêt à supporter ces mises en production régulières. Il est nécessaire de mettre en place des usines logicielles permettant de produire, tester, mettre en production et maintenir en fonctionnement les produits dans les meilleurs délais. Pas question d’attendre plusieurs semaines ou mois avant de mettre en production un produit prêt.
Les phases de validation, tests, recettes, peuvent être très consommatrices de temps. Elles doivent donc être anticipées et automatisées au maximum pour atteindre une vraie industrialisation. Les gains de temps et de qualité atteints grâce aux équipes et projets ne sont ainsi pas perdus dans les étapes de tests et de mise en production.
Les équipes IT ont mis en place des stratégies qui permettent, dès le début des projets, de prévoir ces futures étapes. Les tests sont identifiés dès le départ et sont automatisés. On parle d’intégration continue, de déploiement continu, de livraison continue.
Et une fois les produits en production, il faut les maintenir et les exploiter. L’approche DevOps (qu’on peut définir en quelques mots par l’agilité pour les opérationnels) devient de plus en plus utilisée aujourd’hui. Cette approche illustre bien le passage sans heurt de la conception des solutions vers leur mise en production et leur exploitation. Les équipes d’opération et de développement travaillent ensemble, et non plus en campant sur leurs positions respectives : « je n’ai pas les documents pour assurer la maintenance », dixit la maintenance, « je ne sais jamais quels documents ils veulent », dixit les développeurs.
Méthodes et approches : Le test-driven development (TDD), Behavior Driven Development (BDD), Continuous delivery, Continuous deployment, Mikado Method, devops
Le niveau entreprise
Faire travailler des équipes en mode agile suppose de la responsabilisation et de l’autogestion. Le reste de l’entreprise, et notamment le management, ne peut continuer à fonctionner comme avant au risque d’être contre-productif.
En agile, c’est l’équipe (via notamment le Product Owner) qui est responsable de son produit, le rôle du manager n’est plus alors de décider ce qui doit être fait.
Le manager change de rôle et c’est un vrai changement culturel. Les hiérarchies actuelles n’ont pas du tout été formées à ces approches. Le manager devient un facilitateur, celui qui met dans les bonnes conditions, c’est aussi un vrai relai d’information dans les 2 sens (vers l’équipe mais aussi vers le reste de l’entreprise).
Comme tout changement, il entraine des pertes de repère, de la résistance au changement et donc il doit être maitrisé et accompagné. Plusieurs méthodes, modèles et approches démontrent les bénéfices que l’on peut en tirer sans en nier les difficultés.
Méthodes et approches : Agilité à l’échelle (SAFe, LeSS, Spotify, Nexus), Management 3.0
Les ateliers
Un des principes fondateurs de l’agilité est la co-construction. A ce titre de nombreux types d’ateliers de travail existent. Ils ont pour but de faire réellement travailler ensemble les personnes au sein des équipes, de développer les « softskills » (compétences humaines) mais aussi produire des résultats : produits, plannings, études d’impacts etc. Le nombre d’ateliers et de variantes est infini, même si environ une quarantaine de techniques d’animation se détachent. Nous proposons un regroupement sur 8 thématiques :
Icebreaker : idéal pour se lancer quand les gens ne se connaissent pas ou peu.
Intelligence collective : démontrer la force de la collectivité mais aussi ses manières particulières de fonctionner
Planification (et volumétrie) : construire ensemble des plannings, faire des estimations
Définition de cible : vers où voulons nous aller ensemble, qu’est-ce qu’il est réaliste de proposer ?
Impacts et trajectoire : comment aller vers la cible, quels sont les impacts des changements proposés ?
Priorisation des travaux : décider ensemble de ce qui est prioritaire
Conception de produit : orienter vers l’innovation et la recherche de solutions
Team building : construire des équipes qui savent travailler ensemble et communiquer efficacement
Ces ateliers peuvent être utilisés individuellement mais surtout en combinaison pour atteindre encore plus rapidement et efficacement l‘effet recherché. La durée varie de 15mn à 3j.
Intenses et efficaces, ces ateliers permettent de débloquer des situations et de remettre du lien dans des équipes, de les remotiver pour leur travail : un icebreaker, puis un teambuilding avant de faire de l’innovation et de la priorisation. Le tout en une journée. L’équipe en ressort non seulement remotivée mais surtout avec des résultats concrets et directement utilisables dès le lendemain
Une fois ce paysage posé, l’agilité peut effectivement être identifiée un peu partout dans l’entreprise.
Les architectes d’entreprise en tant que garants de la vision d’ensemble du SI doivent accompagner ce mouvement et y prendre part. Plusieurs niveaux vont être abordés dans notre série « Architecture d’entreprise et Agilité » :
Chapitre 2 : détournement de valeur. Toutes les fausses ou contre-vérités entendues à propos « des projets Agile »
Chapitre 3 : comment l’architecte d’entreprise peut aider à concevoir et entretenir un « SI Agile »
Chapitre 4 : comment les architectes d’entreprise (mais aussi les autres) peuvent interagir avec les projets en agilité.
Voilà un nouveau métier qui fait parler de lui. Le CDO serait-il le nouvel architecte « Digital » ? Par certains côtés, il s’en rapproche et peut même le concurrencer. Ce serait dommage : chacun doit mener à bien sa mission, dans un esprit collaboratif. Nous montrerons ici comment l’architecte peut aider le CDO dans ses fonctions pour mener à bien la transformation digitale.
En se retournant rapidement sur le passé, il est facile de constater combien nos métiers ont évolué. Hier urbaniste, aujourd’hui architecte SI ou architecte d’entreprise suivant les appellations. Chacun a maintenant son architecte : architecte métier, architecte de solution / technique, etc.
Quels seront les architectes de demain ? Le CDO (Chief Digital Officer) est-il l’avenir de l’architecte ? Ou un nouvel allié de la transformation digitale ? Mais d’ailleurs quel est son rôle ?
Le CDO travaille sur la chaîne de valeur dixit Les Echos. Il a donc un rôle d’architecte métier, un lien vers les processus et les pilotes de processus.
Il a la vision la plus large de l’entreprise ou comme le dit « l’usine digitale » « Leur job consiste au contraire à casser tous les silos de l’entreprise et de ses métiers ». L’architecte métier ou le pilote de processus avaient ce rôle-là. Faire coopérer l’ensemble des parties prenantes pour trouver des solutions nouvelles est aussi une partie du rôle de l’architecte d’entreprise.
« En général, ils commencent par faire un état des lieux pour identifier les projets déjà lancés par l’entreprise, ses besoins et les personnes impliquées. ». Qui a la connaissance de tous les projets ? leur périmètre ? les outils ? L’architecte d’entreprise a ce rôle dans les entreprises et doit donc être un point d’entrée pour notre CDO.
Côté constat, cet article nous dit : « un tiers des CDO interrogés regrettent « que leur niveau hiérarchique et leur pouvoir sont inadaptés aux enjeux de leur fonction. » » C’était bien le constat des architectes d’entreprise pendant des années et cela l’est encore fortement aujourd’hui. Le besoin de transversalité, de convaincre est encore bien présent dans les entreprises. L’architecte d’entreprise qui a été confronté à ces problématiques doit pouvoir aider ce nouvel arrivant.
Le CDO apporte de nouvelles dimensions dans l’entreprise en tant que champion de la transformation, il a plusieurs cordes à son arc, comme le précise l’Express :
« Il faut qu’il ait un très bon vécu marketing pour comprendre comment cette transformation doit servir l’activité. ». Le CDO doit comprendre le monde qui l’entoure pour en faire profiter son entreprise et la faire avancer dans sa transformation digitale. C’est un peu la « voix du client » comme on l’appelait avant. Le rôle de l’architecte d’entreprise est pour l’instant plus tourné vers l’intérieur de l’entreprise, en ce sens, où il n’est pas l’instigateur des nouveaux projets de transformation digitale.
« Il doit, aussi, bien maîtriser la gestion des talents : comment les recruter, les fidéliser ». Pour réussir sa transformation, le CDO doit savoir s’entourer, un bon architecte d’entreprise qui saura transmettre vers les DSI tout en intégrant les contraintes de l’existant et en respectant les coûts est un atout important pour un CDO.
Le CDO est le nouveau « champion de la transformation », il incarne la volonté d’un comité exécutif de transformer l’entreprise vers le Digital et le numérique. Il est un nouveau rôle à part entière qui s’appuie sur des rôles déjà existants dans l’entreprise (métier, marketing, DSI etc.). L’architecte d’entreprise se doit d’être au premier rang de la transformation digitale. Il doit être une courroie de transmission à l’intérieur de l’entreprise dont le CDO serait le moteur ! Il parle déjà avec les métiers et avec la DSI. Il est à même de proposer des solutions afin d’intégrer correctement tous les nouveaux usages et outils du Digital dans le SI de l’entreprise tout en augmentant la qualité du SI (rationalisation de l’existant, intégration de nouveaux outils en remplacement des anciens et non en doublon etc.). Architecte d’entreprise et CDO sont des rôles complémentaires dans l’entreprise.
Il semble donc naturel que le CDO et l’architecte d’entreprise s’allient pour faire basculer les entreprises vers un SI toujours plus puissant et au service des clients tout en restant le plus évolutif et le moins cher possible, d’ici la prochaine (r)évolution…
Le CDO est un profil récent dans les entreprises et il doit encore trouver sa place (lire aussi cet excellent article). Je pense que nous n’avons pas fini de parler de l’évolution et des interactions entre les profils (anciens, nouveaux et à venir, éphémères ou durable…) intervenant dans la Transformation Digitale.
Il doit faire une architecture de son temps avec les techniques de son temps
Pour expliquer aux non-initiés l’architecture du SI, on la compare toujours à l’architecture des villes, à l’urbanisation. Une interview récente de Catherine Jacquot (présidente du Conseil national de l’ordre des architectes) montre que les 2 pratiques ont toujours les mêmes points communs. Aussi bien pour montrer l’intérêt qu’elles apportent pour la société tant du point de vue qualitatif que monétaire, que dans l’évolution des pratiques et des outils.
Dans cette interview, les questions du journaliste sont aussi révélatrices que les réponses de l’intéressée. Ce sont les mêmes sujets qui reviennent et que l’on entend dans toutes nos missions : Quelle est votre valeur ajoutée ? N’êtes-vous pas trop cher ? etc.
Quelques phrases sont particulièrement marquantes.
Le phénomène […] empile des strates d’erreurs de différentes époques.
C’est la base même du constat que nous faisons sur les SI de nos entreprises. Toutes ces strates empilées depuis des années et qu’il est très difficile de remettre à plat. Les grands projets de transformation sont difficiles à justifier par les temps qui courent. Il faut être opportuniste et profiter des effets d’aubaine (le digital par exemple) pour proposer des évolutions qui vont dans le sens de la simplification et de la rationalisation et non pas faire que ce soit une couche de plus dans l’empilement.
Ces professionnels sont formés pour mener à bien un projet, y apporter des qualités de construction, d’usage et de confort tout en sachant l’insérer dans l’environnement.
C’est bien là le travail de l’architecte. Proposer des solutions en respectant les normes existantes. Savoir innover quand il le faut. Mettre en avant les usages. Les architectes du SI sont des professionnels et ils doivent faire en sorte d’attirer le respect de leurs clients grâce à la valeur ajoutée apportée par leur travail.
Pour un budget donné, un architecte fera toujours mieux qu’un non-architecte
Cela parait évident, et pourtant, il fait bon le dire ! Oui, l’architecte a un savoir-faire, et les solutions qu’il propose ont de la valeur. Cela ne coûte pas forcément plus cher, car l’architecte sait prendre en compte les contraintes qui s’imposent à lui, et proposer les meilleures solutions.
Son intervention apporte des qualités sans surcoût, « juste avec de la marge en moins pour les constructeurs »
L’architecte saura négocier les aménagements qui optimisent les coûts et les délais tout en respectant au mieux le cahier des charges. Il saura distinguer ce qui est indispensable de ce qui ne l’est pas. Il saura négocier et faire respecter les engagements de coûts et de délais de réalisation du projet. Totalement neutre, l’architecte est indépendant des solutions qu’il préconise : il peut ainsi mettre en concurrence les maîtrises d’œuvre, les challenger et en tirer le meilleur parti. C’est à ce titre que l’architecte saura montrer que sa prestation n’est pas une source de coût mais un gage de qualité.
Il faut faire une architecture de son temps avec les techniques de son temps.
L’architecte doit évoluer avec son temps. D’urbaniste, il est devenu architecte d’entreprise. Les entreprises vont continuer à évoluer, les SI seront de plus en plus inter connectés, de plus en plus complexes. Afin de continuer à apporter les meilleures solutions pour les SI des entreprises, les outils et techniques de l’architectes doivent évoluer. Les architectes sont à même de réfléchir à l’avenir de leur métier pour proposer les solutions les plus adaptées au monde digital, à l’internet des objets, à l’uberisation des entreprises…
L’architecture d’entreprise est un métier jeune et qui évolue rapidement. L’architecte d’entreprise reste le maillon indispensable dans la maîtrise de l’évolution et de la transformation au sein des entreprises. Les entreprises doivent continuer à s’appuyer sur les compétences des architectes d’entreprise et leur donner la place qui leur revient, car l’architecte d’entreprise assure une maîtrise de la transformation vers des SI toujours plus efficaces, évolutifs et économes…
