Ils ne savaient pas que c’était impossible
Proposer une offre spéciale alors que le client est toujours présent sur le site augmente les ventes. S’apercevoir que l’utilisateur tente de faire quelque chose et lui proposer une aide améliore son expérience. Réparer une erreur en magasin avant que le client n’en sorte influe sur la qualité. Détecter une fraude en cours de traitement diminue les risques. Analyser les données en temps réel d’un moniteur médical contribue à la santé du patient, et de son infirmière ! …
Les géants du Net ont été les premiers à être confrontés massivement à des moments où la technologie suggère un changement de paradigme dans les modes de fonctionnement. Leur réussite vient de leur opiniâtreté à mettre au point l’adéquation de leur Business Modèle à la technologie - et inversement – sans s’embarrasser de règles édictées par d’autres, avant, ailleurs.
Ils ne savaient pas que c’était impossible, alors ils l’ont fait. Ces quelques exemples dans le seul domaine du « Fast Data » montrent qu’il faut parfois savoir transgresser la loi d’Airain de la cohérence du Système d’Information au bénéfice de la rapidité des traitements ou de la tolérance aux pannes.
Ils ne savaient pas que c’était un choix d’architecture, alors ils l’ont fait.
On ne peut pas ne pas architecturer
Dans sa théorie de la communication, Paul Watzlawick - le psychologue de l’Ecole de Palo Alto – a formalisé son axiome d’impossibilité : "on ne peut pas ne pas communiquer " pour exprimer le paradoxe qu’il faut bien dire quelque chose pour signifier qu’on ne souhaite rien dire.
Si un système est un ensemble de composants et d’interaction entre ces composants, son architecture est une représentation de leur agencement. On en déduit que tout système dispose forcément d’une architecture. Mais laquelle ? Est-t-elle bonne ? Quels sont les critères d’une « bonne architecture" ?
Le fait de savoir si cette architecture est formalisée ou pas, intentionnelle, émergeante ou purement circonstancielle est surtout sujet d’organisation. La question était déjà posée en 1999 par Éric Raymond dans son essai « La Cathédrale et le Bazar » où l’auteur compare le processus de développement traditionnel (en V : la Cathédrale) à celui mis en œuvre pour Linux (coopération de développeurs indépendants : le Bazar).
Dans un monde complexe et agile, on ne peut donc pas distinguer l’architecture, la manière d’architecturer et l’organisation des acteurs qui sont en train d’architecturer. La seule adoption des dernières pratiques à la mode (tribut, kanban, poker planning, …) n’y suffira pas.
Il faut aller jusqu’à revisiter les règles et les concepts d’architecture, les démarches et les étapes ainsi que les postures, les organisations et les instances de gouvernance, et d’autant plus précisément que le changement et l’itératif seront leur quotidien.
Une fois encore, des chercheurs ont confirmé la Loi de Conway et sont allés jusqu’à en mesurer les effets : un système produit par une organisation souple (comme des équipes agiles) est lui-même 8 fois plus souple (faiblement couplé) qu’un système produit par une organisation classique (hiérarchique).
Autonomie versus Alignement
Comment concevoir une architecture modulaire et faiblement couplée ? Comment répartir au mieux ces éléments entre chacune des équipes, les plus autonomes possibles ? Comment faire pour que ces équipes aillent toutes dans la même direction et qu’elles livrent de manière synchronisée des composants qui forment un tout ? …
Les organisations classiques ont tenté de résoudre ces problèmes par une approche de conception « Top - Down ». A partir des besoins exprimés, l’architecte conçoit l’architecture générale de la solution et la spécifie en détail : il n’y a plus qu’à la réaliser, la tester et la mettre en œuvre.
Malgré tous les amendements apportés ces trente dernières années, force est de constater que ce mode d’organisation taylorien – qui distinguent ceux qui décident de ceux qui font - génère plus d’échecs que de satisfaction. Et d’autant plus que les besoins évoluent rapidement avec la pression de la concurrence et des innovations technologiques. Le temps qu’une décision se prenne, le client a choisi un autre fournisseur.
A l’inverse, les organisations « agiles » postulent que la prise de décision doit se faire le plus tard possible et au plus près du besoin du moment et de sa réalisation. Cela permet à l’équipe autonome de mieux comprendre les spécificités du besoin et de s’adapter aux inévitables changements intempestifs.
Toutefois, pour coordonner plusieurs équipes agiles, il est nécessaire de les aligner sur les objectifs communs et les fonctionnalités particulières du produit. Pour qu’elles puissent s’ajuster entre elles en fonction des circonstances, elles doivent disposer d’un accès large à l’information stratégique du projet et de possibilités de coopération horizontale.
The Agile Architecture Framework (AAF)
La nécessité pour les Métiers, les compétences, les outils existent déjà pour la plupart. Mais on sait déjà que ces changements radicaux dans la manière de concevoir et de réaliser les systèmes et leur architecture va prendre du temps, soulever des problèmes divers qu’il nous faudra surmonter, nécessiter des efforts de chacun et notamment des architectes eux-mêmes.
Pour structurer les réflexions en cours et mieux partager les retours d’expérience, un collectif d’acteurs – dont MEGA International ! - a publié auprès de The Open Group le livre blanc « Agile Architecture in the Digital Age » (en anglais).
Ce document propose une structure pour l’élaboration d’un cadre d’architecture agile – « The Agile Architecture Framework (AAF) » -en douze points (ci-dessous) répartie sur trois thèmes :
- Autonomie, isolation et alignement
- Rôles et processus d’architecture
- Recueil de bonnes pratiques d’architecture
Comme l’évoquait Didier Drouin, coach agile de Pôle Emploi : « il reste du chemin à parcourir, mais la route est belle ! »
Si vous souhaitez en savoir plus sur la tendance agile et son impact sur l’organisation des départements IT, découvrez notre webcast gratuit « Agile at scale: Architecture in the age of complexity » présenté par Antoine Lonjon Directeur innovation chez MEGA International (en anglais).
