La piste architecturale selon SAFe

La piste architecturale selon SAFe
La piste architecturale selon SAFe

La piste architecturale, souvent évoquée sous le terme d’Architectural Runway, est une composante cruciale pour le succès des projets de grande envergure. Elle comprend le code existant, les composants et l’infrastructure technique nécessaires pour mettre en œuvre des fonctionnalités à court terme avec un minimum de réaménagement et de retard.

La piste architecturale permet un flux continu de valeur à travers le Pipeline de Livraison Continue, en fournissant la technologie nécessaire pour définir, construire, valider et déployer rapidement des fonctionnalités et des capacités. Elle soutient également la pratique de l’architecture Agile en permettant au paysage technologique d’une organisation d’évoluer en réponse aux besoins changeants de l’entreprise.

Développement agile et conception émergente

Dans le développement Agile, l’accent est mis sur la conception émergente, avec la croyance simple que « les meilleures architectures, exigences et conceptions émergent des équipes auto-organisées ». Cette approche favorise la pratique de la conception émergente, qui consiste à définir et étendre l’architecture uniquement lorsque cela est nécessaire pour livrer le prochain incrément de fonctionnalités. Cependant, la conception émergente seule ne peut pas gérer la complexité du développement de solutions à grande échelle.

Les problèmes de la conception émergente à grande échelle

À grande échelle, s’appuyer uniquement sur la conception émergente conduit à plusieurs problèmes, notamment :

  1. Le manque de normes augmente les coûts de livraison et les retards.
  2. Les solutions ponctuelles deviennent difficiles à modifier et à entretenir.
  3. Les systèmes deviennent vulnérables aux problèmes de sécurité et de stabilité.
  4. La qualité dépend des connaissances tribales, limitant l’interopérabilité et la réutilisation des composants.

Ces problèmes peuvent entraîner une mauvaise performance de la solution, des résultats économiques défavorables et des retards dans la mise sur le marché. Les organisations surmontent ces problèmes en équilibrant la conception émergente avec une architecture intentionnelle, qui nécessite une planification centralisée et une coordination entre les équipes. Ces deux aspects sont mis en œuvre avec des « Enablers » (facilitateurs) qui « pavent » ensemble la piste architecturale.

piste architecturale
piste architecturale

Architecture intentionnelle pour guider l’évolution du système

L’architecture intentionnelle prend en compte ces considérations de conception systémique et fournit des directives architecturales planifiées qui permettent d’intégrer le travail indépendant des équipes Agile dans une solution cohérente et durable. Ces directives transversales sont généralement définies par des architectes d’entreprise, des architectes de solutions et des architectes système en étroite collaboration avec la gestion des produits et la gestion des solutions. Ces rôles sont bien adaptés à cette tâche en raison de leur connaissance approfondie du paysage technologique et de leur compréhension approfondie du contexte de la solution.

L’architecture intentionnelle est codifiée sous forme d’Enabler Epics, de capacités et de fonctionnalités dans les Backlogs de Portefeuille, de Solution et de l’ART (Agile Release Train). Les architectes guident ensuite les Enablers à travers les systèmes Kanban appropriés pour s’assurer qu’ils produisent la piste architecturale souhaitée.

Construire la piste architecturale

Plusieurs rôles peuvent être impliqués dans la définition de la piste architecturale, mais sa mise en œuvre relève de la responsabilité des équipes Agile. Ces équipes sont souvent responsables de la livraison de produits ou de services axés sur les utilisateurs finaux. Par conséquent, la construction de la piste architecturale ne doit pas les contraindre de manière excessive. Il est nécessaire d’avoir exactement la bonne quantité de piste architecturale à tout moment. Trop de piste, et l’architecture crée des goulots d’étranglement pour les équipes et sur-conçoit l’incrément de solution actuel. Trop peu, et l’organisation n’aura pas la piste dont elle a besoin pour respecter ses engagements commerciaux à court terme.

responsabilité de la piste architecturale
responsabilité de la piste architecturale

L’allocation de capacité s’applique au Backlog de l’Équipe pour garantir que le ratio de travail des facilitateurs par rapport au travail orienté vers le client est toujours équilibré. Une équipe Agile dédiée supervise souvent la mise en œuvre initiale lorsque des investissements importants dans la piste architecturale sont nécessaires, par exemple, pour permettre le lancement d’un nouveau produit, une initiative de portefeuille Horizon 3 ou un environnement existant.

équipe agile dédiée à la piste architecturale
équipe agile dédiée à la piste architecturale

Quelle que soit l’entité responsable du travail, les règles de construction de la piste architecturale sont simples et agiles :

  1. Les équipes qui construisent la piste adoptent une approche itérative, tout comme les autres équipes Agile de l’ART.
  2. La valeur réside dans les systèmes en fonctionnement, pas dans les modèles ou les spécifications.
  3. Les fonctionnalités et les histoires des facilitateurs ne doivent pas prendre plus d’un PI ou d’une itération, respectivement, pour être livrées.
  4. Les équipes Agile sont des parties prenantes de la piste architecturale, l’utilisant pour respecter les engagements envers les clients et fournissant des commentaires sur son efficacité.

Investissement continuel dans la piste architecturale

La piste architecturale est dynamique. Elle est « consommée » en fournissant des fonctionnalités à court terme et doit être étendue pour prendre en charge les fonctionnalités futures. Plusieurs facteurs peuvent consommer la piste architecturale :

  1. Les équipes Agile à forte cadence – elles utilisent rapidement la piste la plus récente pour fournir des fonctionnalités à court terme.
  2. Préférences des clients – Après avoir investi dans la piste architecturale, les parties prenantes modifient souvent les priorités du backlog pour privilégier les fonctionnalités qui bénéficient directement aux clients.
  3. Innovation technologique – La technologie évolue rapidement, rendant obsolète la piste existante.
  4. Évolution des besoins commerciaux – Les besoins de l’entreprise évoluent en réponse aux opportunités et aux menaces émergentes.

Étant donné que le développement de nouvelles fonctionnalités et capacités consomme la piste architecturale, un investissement continu est nécessaire pour l’étendre. Les équipes s’engagent à étendre la piste en fonction de leurs besoins à chaque itération, afin de maintenir une vélocité de livraison rapide et durable. Cela peut inclure l’ajout d’automatisation au Pipeline de Livraison Continue, l’amélioration des pratiques DevOps, l’augmentation de la capacité des serveurs ou toute autre activité qui accélère la vélocité de livraison.

Investissement continuel
Investissement continuel

La Piste Architecturale dans les Grandes Solutions

Lors de la création de systèmes de grande envergure, la piste architecturale joue un rôle encore plus critique, car plusieurs ART (Agile Release Trains) contribuent à la même Solution dans le cadre d’un Train de Solutions. L’article sur la Livraison de Solutions d’Entreprise décrit dix pratiques Lean-Agile qui guident la livraison de solutions de grande envergure, dont plusieurs sont directement liées à la piste architecturale :

  1. Spécifier la solution de manière incrémentielle – L’intention de la solution définit de nombreuses contraintes en tant qu’exigences non fonctionnelles (NFR). Bon nombre de ces NFR sont des préoccupations transversales qui peuvent être abordées et simplifiées en construisant une piste architecturale qui prend en charge l’intégration et les tests. La piste architecturale permet également aux éléments de l’intention de la solution d’évoluer de manière fluide et progressive.

  2. Appliquer de multiples horizons de planification – Les grandes solutions nécessitent généralement une piste architecturale plus longue, mise en œuvre avec des Enabler Epics sur plusieurs PIs ou même plusieurs années. L’efficacité de la livraison de ces longues portions de la piste est orchestrée grâce à des plans d’itération connectés, des feuilles de route PI et des feuilles de route de solution.

  3. Concevoir pour le changement – Atteindre ces objectifs dans les grandes solutions nécessite une architecture intentionnelle pour mettre en œuvre un Pipeline de Livraison Continue efficace et garantir des opérations simplifiées avec un retour d’information solide grâce à la télémétrie de l’application.

  4. Aborder continuellement les préoccupations de conformité – Une approche Lean de la conformité automatise la collecte et les tests de données de conformité pour fournir des résultats plus efficaces et prévisibles. Cela nécessite un engagement précoce avec les auditeurs et les parties prenantes pour convenir d’une approche acceptable. La création de capacités grâce à la piste architecturale garantit la cohérence et élimine d’importants risques de conformité.

  5. Faire évoluer les systèmes déployés – Un Pipeline de Livraison Continue rapide et économique signifie que les solutions – et les modifications apportées à ces solutions – peuvent être publiées sur demande. La piste architecturale fournit un Pipeline de Livraison Continue permettant aux solutions déployées d’évoluer de manière incrémentielle avec une perturbation minimale pour les clients. Il est essentiel de mettre en œuvre une longue piste de manière incrémentielle. Les Enabler Epics sont divisés en Enabler Features et/ou Capacités, puis mis en œuvre par les ARTs. Chaque Enabler Feature doit être terminé dans un PI, et les Enabler Stories dans une itération. Cela permet des investissements significatifs dans la piste architecturale, en équilibrant de manière adéquate l’architecture intentionnelle et la conception émergente.

Origine de la piste architecturale

Le terme « piste architecturale » a commencé comme une analogie observée lors de l’observation des graphiques de burn-down au niveau PI. Souvent, lorsque la piste architecturale manque lorsque les équipes commencent un PI, toute fonctionnalité dépendante de la nouvelle architecture présente un risque élevé. Les ARTs ne peuvent pas toujours « atterrir ces PIs » (ramener le graphique de burn-down à zéro à la fin du PI). Dans ce cas, ils ne parviennent pas à atteindre les objectifs du PI. Un PI, comme un avion, a besoin de suffisamment de piste pour atterrir en toute sécurité. Dans SAFe, la ligne de la piste architecturale monte et descend au fil du temps car elle est construite, puis utilisée, puis construite à nouveau, puis utilisée, et ainsi de suite. Il doit y avoir juste la bonne quantité à tout moment pour soutenir les objectifs commerciaux à court terme. Pour étendre la métaphore de la piste, plus l’aéronef (système) est grand et plus la vitesse de vol (vélocité) est élevée, plus il faut de piste pour atterrir en toute sécurité.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 942 Articles
  Paquet Judicaël (expert en transformation et AI) Mes activités en France et en Suisse : - ingénieur prompt - coach AI - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile, prompt AI, Intelligence artificielle. [Me contacter]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.