C’est surprenant, mais… les architectes en SI manquent d’outils logiciels agiles. On ne peut l’expliquer par la seule inertie des éditeurs d’outils d’architecture SI et tout particulièrement d’architecture d’entreprise. Sur le terrain, les architectes nous demandent par où commencer pour pallier cette étonnante disette, et comment l’agilité de l’architecture devient un levier de croissance dans un contexte de digital factory. On leur répond !

 

De quoi on parle ?

 

D’architecture du système d’information (SI) : une activité qui garantir qu’au gré des évolutions du modèle de l’entreprise, des comportements de ses clients et de ses objectifs économiques, son SI évolue sans frein, de façon cohérente et habile. 

Pour ce faire, les architectes SI ont besoin de points de vue – des modèles, des plans – permettant d’opérer les changements en les justifiant auprès d’audiences allant du board aux développeurs,  des lignes métier aux “product owners”. 

 

Pourquoi on en parle ?

 

Parce que l’architecte SI qui reste dans sa tour d’ivoire et édicte immuablement des règles au pragmatisme discutable, cet architecte subira une sélection darwinienne dont le lecteur a tout loisir d’imaginer l’issue.

Si, en revanche la double révolution internet + SaaS & Cloud ne lui a pas échappé, et si, face à la percée du développement agile, l’architecte réalise qu’il a l’occasion de sauter à bord du train de l’agilité, il cherche vite de nouvelles méthodes et les outils d’architecture qui la supportent. Mais là… Silence du marché.

 

Cesser d’opposer méthode agile et “waterfall” 

 

Les statistiques du Standish Group Chaos Study” de 2018 – démontrent que les projets agiles se portent mieux que les projets “waterfall”. Mais si la comparaison brute des deux pratiques conclut souvent que “agile c’est mieux”, les deux méthodes ne s’appliquent pas aux mêmes objets et ne sont pas substituables.  Ce poncif de la littérature IT ne change rien à la vie des équipes sur le terrain. Car c’est la perspective de devoir changer de méthode ou combiner deux pratiques qui trouble le sommeil des équipes étude, projet, architecture et développement, bref, de la DSI. 

 

Alors, par où commencer, ou par où continuer puisque l’architecture du SI ne cesse de changer et qu’aucun stop and go n’est envisageable ?

 

Extension du domaine de l’agilité 

 

L’agilité de l’entreprise est vivement stimulée par une offre technologique révolutionnée par internet dans les années 80, puis par le modèle SaaS / Cloud des années 2000. Cette transformation a profondément changé les “business models”, et aussi la façon de faire, d’acquérir – de ne pas acquérir, justement – et d’intégrer du logiciel. Elle couvre l’intégralité du système d’information et conduit à distinguer les méthodes en fonction des strates impliquées : modèle économique, organisation, opérations, et système informatique incluant son infrastructure.

 

Cette transformation dépasse largement les limites classiques de l’organisation pour s’étendre aux clients et à l’écosystème dans lequel ils évoluent. On pense ici à l’analyse, idéalement prédictive, des comportements d’achat, des réseaux d’influences et de l’adhésion à des systèmes de valeurs qui modifient les habitudes de consommation. Autrement dit l’exigence d’agilité suit celle des clients, touche toutes les strates de l’organisation pour en sortir et atteindre l’écosystème tout entier. 

 

“Mal chaussé”, l’architecte en SI ?

 

Dans ce contexte de hâte permanente et universelle, on imagine volontiers que l’agilité ruisselle pour assurer partout la souplesse et la réactivité souhaitée par les métiers et par le board. En particulier, les architectes SI n’ont-ils pas droit à la même agilité que leurs homologues métier et devops ?

 

Pour eux, le défi est double : adopter des méthodes agiles pour retrouver sa légitimité, et produire une architecture agile. Or, si l’offre en outils de planification agiles est fournie, la disette en outils logiciels d’architecture agile est stupéfiante.  Alors… Comment les architectes en SI pourraient-ils travailler à la même vitesse que leurs homologues “devops” et garantir l’agilité de toute la chaîne de valeur logicielle, du recueil des besoins au déploiement ?

 

Je commence où ?

 

Les outils bureautiques, d’architecture d’entreprise, de PPM ou de planification stratégique sont lourds et complexes. Ce sont des freins, des “millstones around the neck”. Les outils existants connus, les uns nés à l’ère documentaire de la certification qualité – années ‘90 – les autres aux prémices du modèle SaaS du début des années 2000, cartographient a posteriori et sans collaboration. 

 

Les architectes ont toujours besoin de décomposer, visualiser et relier des problèmes à des solutions, des composants métier et IT entre eux avec des modèles pérennes, fiables et intégrés à la chaîne de production logicielle. C’est leurs machines à commande numérique à eux. Mais à l’ère agile ils leur faut des outils qui encaissent sans broncher des changements fréquents sur des itérations rapides et très collaboratives. Ils veulent des outils plus simples, sans perdre la vision globale des cycles de changement, ni compromettre la qualité de l’architecture ou des livrables. Or rare sont les solutions disponibles aujourd’hui. 

 

Par contraste, les équipes “devops” sont, elles, parfaitement outillées. Comme souvent c’est du développement que vient le changement (souvenons-nous que les langages objet ont enterré les méthodes de conception structurées au profit d’UML). Et c’est par là que l’architecte en mal d’agilité doit regarder. 

 

Trouver les gisements de productivité 

 

Les frameworks SAFe, Spotify et Less ont la bonne idée de ne rien hériter de la lourdeur de leurs prédécesseurs. Ils sont riches en proposition d’organisation du travail collaboratif et agile. L’architecte y coopère avec les métiers, les product owners, les développeurs et la production IT. La chaîne de valeur tout entière ne progresse qu’au rythme du plus lent de ses maillons. Pour tenir le rythme l’architecte doit aller vite, réduire ses unités d’oeuvre et s’impliquer directement sur le terrain. Et il doit s’habiller léger : revenir à des outils collaboratifs et simples. 

 

Mais ce n’est pas tout : anticiper les changements d’architecture, des versions de composants logiciels grâce à des notifications et des rapports dédiés… travailler de façon collaborative sans entrave, sont autant de facteurs de productivité et de motivation. Ils permettent à tout moment de réorienter facilement les efforts, pour livrer des systèmes qui suivent au millimètre des demandes de changement très fréquentes. Lorsque la cible est mouvante, l’agilité c’est de pouvoir bouger très vite. 

 

L’architecte en SI est un chaînon stratégique de la transformation digitale des organisations. S’il n’est pas correctement outillé, tout autre effort d’agilité sera vains. Sans lui, impossible d’aligner le rythme de changement du SI à celui des métiers. L’offre technologique de l’architecte reste rare mais quelques acteurs visionnaires prennent le risque de lui proposer des outils qui méritent le détour. 

 

La digital factory de demain ? 

 

Elle repose sur une software factory – devops – et une architecture factory intégrées et également agiles. Et inévitablement, pour les grands projet elle repose sur la “mise à l’échelle” de cette agilité afin d’optimiser les forces en présence sans perdre ni en vitesse de cycle ni en agilité globale. Il faut gager que dès 2021, ⅔ des architectes SI utiliseront des outils d’architecture agile, et qu’alors l’offre pour l’architecture SI agile sera composée à 75% d’acteurs de nouvelle génération (commercialisation 2015) : ce nouveau marché n’existe pas encore, mais certains acteurs eux-mêmes agiles et innovants, s’emploient à le créer.

 

Par Jean-Marie Zirano pour Axellience