System Architect/Engineering

L’ingénierie est un grand métier. Il y a la satisfaction de regarder un produit de l’imagination émerger à l’aide de la science et d’un plan sur papier. Ensuite, il passe à la réalisation en pierre ou en métal ou en énergie. Ensuite, il apporte des maisons aux hommes ou aux femmes. Ensuite, il élève le niveau de vie et ajoute au confort de la vie. C’est le grand privilège de l’ingénieur.

—Herbert Hoover

System Architect/Engineering

Le rôle System Architect/Engineering représente une personne ou une petite équipe qui définit une vision technique et architecturale partagée pour la Solution en cours de développement. Ils participent à la détermination du système, des sous-systèmes et des interfaces, à la validation des hypothèses technologiques et à l’évaluation des alternatives, tout en travaillant en étroite collaboration avec l’Agile Release Train (ART) et le Solution Train.

Ces personnes, ou équipes interdisciplinaires, adoptent une «vue système» du développement de solutions (principe SAFe Lean-Agile n°2, Appliquer la réflexion systémique). Ils participent à la définition des Nonfunctional Requirements (NFRs) de niveau supérieur. Cela comprend l’analyse des compromis techniques, la détermination des composants principaux et des sous-systèmes, ainsi que l’identification des interfaces et des collaborations entre eux. Ils comprennent le Solution Context et collaborent avec les équipes, les Customers et les Suppliers pour garantir leur adéquation.

En collaborant avec la Solution et Product Management, l’architecte/ingénieur joue un rôle essentiel dans l’alignement des équipes sur une direction technique commune en vue de la réalisation de la Vision et de la Roadmap.

Et, bien sûr, les architectes/ingénieurs sont des leaders Lean-Agile qui comprennent les complexités du développement de solutions à grande échelle et appliquent les principes et pratiques de SAFe Lean-Agile pour les résoudre.

Détails

Architect/Engineering supporte le développement de la solution en fournissant, communiquant et faisant évoluer la technologie plus large et la vue architecturale de la solution.

Les équipes d’architectes et d’ingénieurs se répartissent aux niveaux Program et Large Solution Levels. Les architectes / ingénieurs de systèmes opèrent principalement dans le contexte de l’ART, où ils travaillent avec des Agile Teams et fournissent une habilitation technique concernant les sous-systèmes et les domaines de capacité d’un ART.

Les deux impliquent une collaboration étroite avec les parties prenantes de l’entreprise, les équipes, les clients, les fournisseurs et les parties tierces pour la définition de l’infrastructure technologique, la décomposition en composants et sous-systèmes et la définition d’interfaces entre sous-systèmes et entre la solution et son contexte.

Tout en fournissant une vue générale de l’architecture de la solution, Architect/Engineering permet à ceux qui mettent en œuvre de la valeur en leur donnant les moyens de prendre des décisions locales, permettant ainsi un flux de travail plus rapide et une meilleure économie.

Responsabilités

Les équipes architectes / ingénieurs sont des leaders Lean-Agile qui assument généralement les responsabilités suivantes:

• Participer à la planification, à la définition et à la conception de haut niveau de la solution et explorer des solutions alternatives
• Participer activement au Continuous Exploration dans le cadre du Continuous Delivery Pipeline, en particulier avec Epics Enabler.
• Définition des sous-systèmes et de leurs interfaces, attribution des responsabilités aux sous-systèmes, compréhension du déploiement de la solution et communication des exigences en matière d’interactions avec le contexte de la solution
• Travailler avec les clients, les parties prenantes et les fournisseurs pour établir une intention de solution de haut niveau, ainsi que les modèles d’informations et les exigences de documentation de l’intention de solution
• Établir des NFR critiques au niveau de la solution, participer à la définition des autres
• Agir dans le Economic Framework pour valider l’impact économique des décisions de conception
• Travailler avec les parties prenantes du portefeuille, notamment l’Enterprise Architect, pour développer, analyser, scinder et réaliser la mise en œuvre d’Epics Enabler.
• Participer au Program Increment (PI) Planning et au Pre- et Post-PI Planning, aux System et Solution Demos, ainsi qu’à l’Inspect and Adapt.
• Définir, explorer et soutenir la mise en œuvre de l’ART pour faire évoluer l’intention de la solution, en travaillant directement avec les équipes agiles pour les mettre en œuvre
• Planifier et développer l’Architectural Runway pour prendre en charge les nouvelles Features et Capabilities
• Travailler avec le Product et Solution Management pour déterminer l’allocation de capacité pour le travail d’activation
• Prise en charge des aspects techniques et d’ingénierie du Program et Solution Kanbans
• Assurer la surveillance et favoriser la Built-In Quality

L’origine du rôle dans SAFe

Rôle du System Architect

Les architectes sont la norme dans le développement de logiciels et cette fonction fait partie de SAFe. Ils travaillent au niveau des programmes et des grandes solutions, allant souvent au-delà du domaine des logiciels pour inclure des responsabilités permettant la création de valeur dans un environnement de solutions multi-domaines techniquement et hétérogène.

Rôle de l’ingénierie des systèmes

Toutefois, les entreprises qui construisent des systèmes cyber-physiques (systèmes intégrés, par exemple) reposent également sur une ingénierie système qui englobe généralement plusieurs disciplines, notamment le matériel informatique, les systèmes électriques et électroniques, les systèmes mécaniques, hydrauliques et optiques, ainsi que les éléments logiciels. Le Conseil international sur l’ingénierie des systèmes définit l’ingénierie des systèmes comme [1]:

… une approche interdisciplinaire et des moyens permettant la réalisation de systèmes performants. Il s’attache à définir les besoins des clients et les fonctionnalités requises au début du cycle de développement, à documenter les exigences, puis à procéder à la synthèse de la conception et à la validation du système tout en tenant compte du problème, y compris opérations, performances, test, fabrication, coût et calendrier, formation et support disposition. L’ingénierie des systèmes intègre toutes les disciplines et tous les groupes de spécialités dans un effort d’équipe, formant un processus de développement structuré allant du concept à la production, puis à l’exploitation. L’ingénierie des systèmes prend en compte les besoins commerciaux et techniques de tous les clients dans le but de fournir un produit de qualité qui réponde aux besoins de l’utilisateur.

Une approche Lean

Il est impossible de raisonner sur la manière de construire des solutions complexes sans inclure les rôles de l’architecture logicielle et de l’ingénierie système. Cependant, une note de prudence importante est justifiée. Les méthodes traditionnelles dominantes favorisent fortement les approches BDUF (Big Design Upfront). Cette approche est compréhensible car ce sont de gros systèmes et que quelqu’un doit savoir comment s’y prendre pour les construire, et le modèle BDUF était le meilleur disponible à ce moment-là.

Cependant, comme décrit de manière détaillée dans les principes SAFe Lean-Agile, cette approche ne prend pas en charge le flux de développement de produits et ne produit pas les résultats économiques optimaux. SAFe considère l’architecture du logiciel et l’ingénierie des systèmes comme des fonctions permettant un flux de développement de produit continu. Dans la mentalité Lean-Agile, ces rôles sont centrés sur la collaboration multidisciplinaire, la construction de systèmes par le biais de cycles d’apprentissage rapides et basés sur le retour d’informations, la compréhension et la valorisation de la variabilité inhérente au processus de développement de produits et la décentralisation du contrôle.

L’article de SAFe, Conformité, développe davantage le passage des modèles de gouvernance traditionnels à contrôle de phase à un processus Lean-Agile qui permet la fluidité tout en répondant aux préoccupations en matière de réglementation et de conformité.

Prise de décision décentralisée

Les décisions de conception varient considérablement en ce qui concerne leur impact, leur urgence et leur fréquence, ce qui suggère un équilibre entre la prise de décision centralisée et décentralisée (voir Principe n°9, Décentraliser la prise de décision).

En ce qui concerne la conception du système, cela signifie que:

• Certaines décisions architecturales à plus grande échelle devraient être centralisées. Ceux-ci incluent la définition de l’intention du système principal, des sous-systèmes et des interfaces; attribution de fonctions à des sous-systèmes; sélection des plates-formes; élaboration de NFR au niveau de la solution; et élimination de la redondance.
• Cependant, la plupart des décisions de conception relèvent de la responsabilité des équipes agiles, qui doivent concilier l’application d’une conception émergente à une architecture intentionnelle (voir Agile Architecture).

Une collaboration fréquente facilite la conception du système, qu’il s’agisse de discussions face à face informelles et continues ou, plus régulièrement, de PI Planning, de démonstrations de systèmes et de solutions, d’inspecter et d’adapter des ateliers et des ateliers de spécification.

Dans tous les cas, Architecte/Ingénierie présente les caractéristiques des leaders Lean-Agile:

• Collaborer avec, permettre et responsabiliser les ingénieurs et les experts en la matière à la prise de décision
• Éduquer les membres de l’équipe dans les disciplines liées à la conception et diriger des communautés de pratique techniques qui favorisent un échange d’idées ouvert avec les praticiens à travers les traitements antirétroviraux
• Démontrer les principes Lean et Agile, appliqués à la conception de systèmes, par exemple, Set-based Design (SBD)

Une approche empirique

De plus, le succès de tout programme de développement de solutions dépend de la capacité de l’organisation à tirer parti des enseignements tirés de preuves empiriques. Ce paradigme peut défier les mentalités traditionnelles qui soutiennent une conception détaillée, engagée et précoce basée sur des hypothèses et des stratégies de mise en œuvre motivées mais non vérifiées. Dans le cas où il existe des preuves contraires, les responsables ont tendance à défendre la solution et à ignorer les preuves.

La mentalité Architecte/Ingénierie Lean-Agile repose sur la conviction que s’il y a un problème de conception, le problème ne concerne pas les personnes qui l’ont créé. Personne n’aurait pu anticiper les nouveaux apprentissages; c’est la recherche et le développement, après tout. Tout le monde apprend ensemble. Cette conviction est renforcée par:

• Gouvernance factuelle, basée sur une intégration fréquente et des preuves objectives
• Exploration continue pour identifier les solutions de remplacement nécessaires pour prendre en charge les Minimum Marketable Features (MMFs) incluses dans le produit minimal viable (MVP) d’une epic
• SBD, où un éventail de solutions possibles à un problème est envisagé, au lieu d’une idée unique choisie trop tôt
• Étapes d’apprentissage planifiées et exécutées dans le but spécifique de valider les hypothèses techniques et commerciales

Un parti pris en faveur de la prise de décision économique, où des compromis entre les capacités architecturales du système et les résultats commerciaux sont faits de manière continue et en collaboration avec les parties prenantes.

Apprendre encore plus

[1] International Council on Systems Engineering. “What Is Systems Engineering?” https://www.incose.org/systems-engineering.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

© Scaled Agile, Inc.