version 6 de SAFe pour l’architecte d’entreprise ?

Quoi de nouveau dans la version 6 de SAFe pour l’architecte d’entreprise ?

Quoi de nouveau dans la version 6 de SAFe pour l’architecte d’entreprise ?

Thomas Jardinet

Manager Architecture

Salomé Culis

Consultante Architecture

Le VRAI Enterprise Architect

Cet article est le troisième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version 6 du framework SAFe. 

Après avoir étudié le System Architect et le Solution Architect, rencontrons l’Enterprise Architect ! Avant de rentrer dans le vif du sujet, nous souhaitions vous faire part de nos impressions quant aux évolutions du rôle de l’Enterprise Architect. 

Dans les versions précédentes, le rôle de l’architecte d’entreprise n’était pas très détaillé. Il était clair que celui-ci intervenait dans la définition de la stratégie et aidait à mettre en adéquation les évolutions du système d’information avec celles du métier de l’entreprise, mais cela s’arrêtait là. 

Dans cette nouvelle version, le framework contient beaucoup plus de détails sur les responsabilités de l’architecte d’entreprise. Celui-ci gagne ses lettres de noblesse et récupère dans sa bannette des sujets qu’il aurait toujours dû avoir (par exemple la rationalisation du portefeuille technologique). Son rôle n’est plus dans la pure stratégie décorrélée du terrain, il devient plus concret. 

En revanche, il a aussi tout un lot d’activités nouvelles, que nous détaillerons dans la suite, et qui nous font dire qu’il faut avoir les épaules très larges pour occuper ce poste. L’architecte d’entreprise semble être partout à la fois, il est devenu une sorte de couteau-suisse ou d’architecte tout terrain si vous me passez l’expression. 

Serait-il devenu l’architecte de l’entreprise ? Celui qui cumule bon nombre de responsabilités et qui collabore très largement avec l’ensemble de l’entreprise ? C’est ce que nous allons découvrir dans la suite ! 

version 6 de SAFe pour l’architecte d’entreprise

De nouvelles responsabilités : De la définition de la stratégie, aux mains dans le code.

L’entreprise Architect s’est ainsi beaucoup musclé au passage de la version 5 vers la version 6 du framework Safe. Il est certes toujours responsable, au mot près, de la stratégie. Mais d’un rôle de facilitateur semi-passif (« Collaborating », « Assisting », « Helping », « Participating », etc…), il bascule vers un rôle de prescripteur. Un regard critique dirait qu’il retrouve ses prérogatives naturelles… Ainsi les différents (et nouveaux) rôles définis par le framework Safe sont : 

L’architecte d’entreprise reprend donc son rôle d’architecte d’entreprise, du métier aux développeurs, en passant par l’organisation des équipes. Par contre, son rôle est beaucoup plus étendu que dans la version 5, se retrouvant ainsi au milieu de nombreux acteurs.

version 6 de SAFe pour l’architecte d’entreprise

Un accent mis sur la collaboration : D’une tour d’ivoire à un lean-agile leader

En effet, dans la version précédente de Safe, l’architecte d’entreprise était vu comme gravitant surtout dans les hautes sphères et ne collaborait qu’avec les autres architectes et des acteurs de haut niveau ou très transverses (Lean Portfolio Management, Agile Program Management Office, et le Lean-Agile Center of Excellence par exemple). 

Il était supposé maintenir des relations avec les personnes de chaque Train mais ses activités quotidiennes ne s’y prêtaient guère. A présent que son périmètre s’étend considérablement, il sera amené à croiser des acteurs beaucoup plus nombreux. Il intervient comme proxy des acteurs business et doit être capable de porter la vision et la stratégie business auprès des différentes parties prenantes. 

Il participe également à tous les événements en lien avec les enablers epics et aura donc l’occasion d’interagir avec les acteurs opérationnels des différents Trains. 

Ses responsabilités étant également plus distinctes de celles des autres architectes, leur complémentarité est d’autant plus mise en évidence. Une collaboration efficace entre l’Entreprise Architect, le Solution Architect et le System Architect garantit l’alignement. 

Enfin, l’Entreprise Architect doit incarner le Lead Agile Leader par excellence. Il mentore les équipes agiles, contribue à la mise en place de nouveaux modes de fonctionnement, et montre l’exemple en continuant à apprendre et à évoluer. Une forme de super héros inspirant tout le monde sur son passage, facile non ? 

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 4 et 6 peuvent en particulier se révéler utiles : 

Parmi la littérature conseillée par le framework Safe, on ne peut que vous conseiller le fameux livre “Team Topologies” qui évoque le rapprochement des équipes technologies et business :

Google, le clouder de l’intégration

Google, le clouder de l’intégration ? Zoom sur leur nouvelle solution d’iPaaS

Google, le clouder de l’intégration? Zoom sur leur nouvelle solution d’iPaaS

7 novembre 2023

Srikanth Ramanoudjame

Consultant Architecture

“Application Integration” est un ajout récent au catalogue de services de la plateforme Cloud Google (GCP). Il s’agit d’une solution d’iPaaS (Integration Platform as a Service), composée par Google sur la base de ses Services Managés pour offrir des fonctionnalités que nous retrouvons traditionnellement dans les solutions  d’intégration pure players (#Boomi #MulesoftAnypoint #Snaplogic, …) (bibliothèque de connecteurs techniques/applicatifs, environnement de développement, mappings, …).

Quelles sont les caractéristiques du service “Application Integration” ? 

Sous quelle forme se présente le service et comment s’intègre-t-il avec les autres technologies de la plateforme GCP ?

Interface de la plateforme et modèle de déploiement

La plateforme permet de concevoir graphiquement les flux d’intégration entre applications à l’aide :

“Application Integration” est un service full managé de Google Cloud Platform. Pour l’heure un déploiement en mode hybride ou On-Prem n’est pas possible.

Modèle de facturation par typologies de connecteurs

Le service comprend une bibliothèque de connecteurs technologiques / applicatifs permettant de s’interfacer avec différentes applications, composants de l’écosystème Google ou tiers (progiciels du marché, bases de données open source, systèmes de messaging…). 

Ces « Integration Connectors » fonctionnent sur un modèle de paiement à l’usage, selon différentes modalités. Ainsi la facturation s’effectue en fonction des éléments suivants :

A titre d’exemple, on peut donc distinguer les connecteurs suivants :

Zendesk, Splunk ou encore ElasticSearch, etc. – pour des applications autres et en Preview

Google, le clouder de l’intégration

Intégration avec des outils/environnements de développement tiers 

Comme évoqué précédemment, la plateforme fournit une interface graphique pour construire des flux d’intégration en Drag & Drop, mais il est également possible d’intégrer des traitements spécifiques supplémentaires. 

Google Cloud Functions est un service de la plateforme GCP permettant de créer des fonctions déclenchées sur évènement.

La « Cloud Function Task » permet d’interagir avec des Cloud Functions crées sur GCP (seul l’environnement d’exécution Python est supporté par le service Application Integration pour l’implémentation des fonctions). 

L’exécution de la Cloud Function sera intégrée à la séquence d’exécution du flux d’intégration sur Application Integration.

Automatisation de parties de workflow de développement de flux 

Duet AI est un service Google proposant un assistant virtuel, intégré à l’interface d’”Application Integration”. L’assistant est ainsi intégré dans le workflow de développement du flux d’intégration, suggérant un mapping à l’aide d’inputs en langage naturel, sur l’intégration à implémenter :

En point notable, nous remarquons qu’”Application Integration” est avant toute chose une solution full GCP. Pas d’hybridation, cette modalité d’instanciation à date n’est dévolue qu’à APIGEE dans le catalogue de GCP sur les briques d’intégration. 

La solution Apigee est-elle pour autant le point d’entrée unique d’une architecture hybride ? C’est en tout cas l’impression que cela nous donne à date. 

Néanmoins, nous saluons l’effort de Google d’aller sur le marché de l’iPaaS, sans offre équivalente sur le marché des clouders Azure / AWS. Ces derniers proposent à ce stade, à couverture fonctionnelle comparable en matière d’intégration, des services / modules distincts plutôt qu’un applicatif packagé (logic apps, lambda, step functions…).   

“Application Integration” parviendra-t-il à détourner la clientèle des solutions iPaaS pure players ? Nul doute que les actuels clients GCP s’interrogeront.

sécurité, internet de confiance, chine, cloud souverain

Cloud Souverain & Internet de confiance – Comment copier le modèle chinois tout en garantissant les libertés individuelles ?

Cloud Souverain & Internet de confiance - Comment copier le modèle chinois tout en garantissant les libertés individuelles ?

25 septembre 2023

Thomas Jardinet

Manager Architecture

La question peut paraître saugrenue, car nous sommes habitués à dire que ce sont les chinois qui nous copient, et qu’en termes de libertés individuelles la Chine n’est pas nécessairement un modèle souhaité en France. Néanmoins, la Chine pense sur le temps long, avec une accumulation de plans quinquennaux qui au final peuvent s’étaler sur plus de 10 ans. Et le sujet de leur souveraineté numérique au sens large en fait clairement partie.

Pour revenir au sujet du cloud souverain, il est clairement d’actualité, avec l’amendement du député Philippe Latombe qui a été accepté, obligeant les opérateurs d’importance vitale pour la France à utiliser du cloud souverain plutôt que non souverain.

Mais avant de se comparer à la Chine, revenons aux basiques en retournant à l’étymologie du mot « souveraineté ».

souveraineté cloud et sécurité internet
Source : Pexels – Kevin Paster

La souveraineté, une proposition de définition.

Étymologiquement, et dans son sens premier, est souverain celui qui est au-dessus, qui est d’une autorité suprême.

Cela s’applique ainsi logiquement à un État, qui lui-même est chargé de défendre les intérêts français, que l’on parle de citoyens mais aussi d’entreprises. Citoyens, qui expriment leur souveraineté populaire (au sens rousseauiste du terme) dans le cadre d’élections.

Mais appliquons cela à ce qu’on entend alors par “cloud souverain”.

Ainsi, en déclinant cette idée de souveraineté au cloud, dont les clients potentiels sont l’état, les entreprises, les individus, il s’agit de placer l’état en garant des intérêts des citoyens et des entreprises, qui se mettent sous la coupe des lois françaises, lois assumés par tous par le mécanisme de souveraineté populaire.

cloud souverain
Source : Pixabay – The DigitalArtist

Le cloud souverain, une proposition de liste de principes.

Dis comme ça, cela reste flou. Alors soyons plus pratico-pratiques : 

Une réalité éloignée de ces principes

Or, un certain nombre de points ne correspondent pas avec les acteurs étrangers.

Alors quelle est la réponse de la Chine face à ces enjeux? 

Une utopie réaliste

Par rapport à cette liste à la Prévert, je n’invite pas à restreindre les libertés publiques mais à avoir une politique numérique très ambitieuse. Impossible n’est pas français comme je l’entendais dire dans ma jeunesse, et oui, un autre modèle est imaginable : 

Plus qu’un cloud souverain, un Internet de la confiance

Comme on peut le voir, je prends le contre pied de la Chine sur la vie privée et la confidentialité, et je cherche à démontrer que l’effort technologique n’est pas un mur infranchissable. 

L’effort pour les DSI, RSSI, architectes, consiste à sensibiliser, mais aussi à promouvoir l’usage de solutions et de clouders certifiés secNumCloud, qui soient bien de droit français. La liste est régulièrement mise à jour.

Et oui, il faut « franciser » son SI. Et/où l' »open-sourcer ». 

Sur le sujet de la sécurisation pour tous, être contre c’est être pour que n’importe qui dans la vie réelle puisse écouter ce que vous dites. On me rétorquera que la collecte d’adresse IP est nécessaire pour la lutte contre le harcèlement en ligne par exemple… Alors renforçons les pouvoirs et les moyens de la CNIL. Exigeons de nouvelles certifications plus sévères et plus contraignantes. Ce sujet de collecte d’ip pour des crimes graves (https://twitter.com/laquadrature/status/1658012087447085056) peut être la limite acceptable et contrôlable de notre vie privée et de notre sécurité. Car être contre notre sécurité et notre vie privée c’est être contre la protection de nos intérêts vitaux et économiques (https://twitter.com/amnestyfrance/status/1658449051296186369). La liberté individuelle et la liberté d’entreprendre sont ici parfaitement compatibles, elles vont même de pair. Croire l’inverse, c’est laisser la porte ouverte à tous vents, aux inconnus, aux belligérants. Et nous devons tous comprendre qu’il en va de l’intérêt général.

cloud souverain sécurité
Source : Pixabay – PixelCreatures

La souveraineté n’étant que l’exercice de la volonté générale ne peut jamais s’aliéner, et le [peuple] souverain, qui n’est qu’un être collectif, ne peut être représenté que par lui-même ; le pouvoir peut bien se transmettre, mais non la volonté.” Jean-Jaques Rousseau

Le GraphQL : des usages qui s’étendent !

Le GraphQL : des usages qui s’étendent !

10 août 2023

– 5 minutes de lecture

Le GraphQL : des usages qui s’étendent !

Erik Zanga

Manager Architecture

Le GraphQL, technologie introduite il y a maintenant une dizaine d’années, permet de changer les paradigmes de l’API. Pour une présentation et une analyse plus précise, je vous invite à consulter notre précédent article écrit par Erik : https://www.rhapsodiesconseil.fr/api-graphql-on-casse-encore-tout-on-recommence/

Qu’en est-il aujourd’hui, le GraphQL est-il réellement une alternative concrète aux APIs standard ?

Mais déjà, qu’est-ce que le GraphQL ?

Le GraphQL se définit par la mise à disposition d’une interface de “requêtage” qui s’appuie sur les mêmes technologies d’intégration / les mêmes protocoles utilisée par les API REST.

Ici, nous restons sur le protocole HTTP et par un payload de retour (préférablement au format JSON) mais la différence principale du GraphQL, pour le client, repose sur le contrat d’interface.

Le contrat d’interface façon GraphQL devient variable, tout comme la réponse. En effet, dans la requête nous pouvons spécifier ce que nous souhaitons recevoir exactement dans la réponse.

Nous mettons ainsi le doigt sur un gros avantage de cette interface GraphQL qui, par essence, va grandement diminuer le “overfetching et le “underfetching” (comprendre ici le fait de récupérer trop peu ou au contraire trop d’informations jugées inutiles dans le contexte) d’API

Autre avantage, ce besoin en données spécifiques pourra être différent à chaque appel et donc permettre une grande flexibilité d’usages à moindre effort.

Le GraphQL s’est fait sa place !

A l’époque de l’écriture de notre premier article, le GraphQL commençait à s’introduire dans certains cas d’usage, très souvent en mode POC et découverte, avec un concept attrayant mais sans preuve réelle de plus value.

Aujourd’hui nous observons une vraie adhésion à ce nouveau mode d’interfaçage, bien que nous en constatons encore des points d’amélioration.

Ce qui est intéressant à remarquer est qu’il se développe sur des métiers très variés. Non seulement au niveau des éditeurs de logiciels mais également dans le cadre de développements spécifiques, de plateformes dédiées.

Les usages à date : quelques exemples

Netflix, qui utilise le GraphQL pour unifier les accès aux différentes APIs.Dans le retail, Zalando, pour récupérer les informations sur les différents produits et pour gérer les consentements.MonEspaceSanté, le service lancé par l’ANS en début d’année, et qui effectue de requêtes GraphQL à partir du navigateur.

Le GraphQL comme réponse à un besoin d’uniformisation ?

Avant la naissance du GraphQL, le besoin d’uniformisation de ce type d’interaction était dans la ligne de mire de certains acteurs. Aujourd’hui le GraphQL peut apporter une réponse concrète et standardisée à ces problématiques.

Deux exemples d’envergure : 

Microsoft : Microsoft a par le passé essayé de fournir des APIs “flexibles” pour adresser certains cas d’usage. Cette tentative s’est matérialisée par la création de l’OData et de l’API Microsoft Graph. 

Ne vous trompez pas, l’objectif reste similaire mais l’approche est, à ce stade, différente. Dans une logique d’uniformisation et standardisation, nous voyons difficilement Microsoft s’affranchir d’une réflexion autour du GraphQL pour atteindre ces objectifs.

Salesforce : Salesforce propose également depuis plusieurs années, une API bas niveau qui pourrait, par ses caractéristiques et son besoin de flexibilité, être adaptée à la technologie GraphQL.

Constat actuel sur les usages du GraphQL

Quand nous regardons les cas d’utilisation de GraphQL, nous pouvons constater qu’il est majoritairement utilisé côté Front-end. 

En lien avec ce cas d’utilisation, nous observons également que le GraphQL est souvent vu comme un agrégateur d’API, et pas comme un moyen de requêtage directement lié à une vision pure données. 

Mais pourquoi ce type d’usage ?

Nous listons trois arguments principaux pour expliquer la prédominance de ce type de cas d’usage.

  1. La restitution de format est très adaptée au monde du web : une réponse simple, toujours vraie et personnalisable ; le protocole HTTP et des concepts proches des APIs REST, le GraphQL s’adapte très bien aux couches front.
  1. Chaque API derrière GraphQL gère son propre périmètre, si nous faisons la correspondance avec les architectures DDD (Domain-Driven Design), nous pouvons affirmer que l’API bas niveau adresse un domaine particulier, alors que le GraphQL est là pour pouvoir “mixer” ces différents concepts et donner une vision un peu plus flexible et adaptée à chaque cas d’usage. Dans ce cas nous allons faire de l’overfetching sur les couches bas niveaux, et faire un focus utilisation au niveau de la partie frontale.
  1. Le cache, éternelle question autour du GraphQL. Dans ce cas d’usage le cache reste possible au niveau des APIs de bas niveau, qui iront donc moins solliciter les bases de données, alors que sur la couche GraphQL, de par sa variabilité de réponse, nous en avons peut-être moins besoin. Pour rappel, le cache sur une requête GraphQL, bien que possible, devient naturellement plus complexe à gérer et donc perd un peu de son intérêt. 

Pourquoi ne faut-il pas limiter le GraphQL à ces usages ?

Pour nous, c’est notre conviction, le GraphQL a de nombreux atouts et doit se développer sur ces usages de prédilection, mais pas que !

UN ARGUMENTAIRE FORT : L’ACCÉLÉRATION DE LA CONCEPTION !

Un des grands atouts de la mise en place d’une API GraphQL reste le côté, si vous m’autorisez le terme, “parfois pénible” de la définition des API Rest : des discussions infinies entre le métier et l’informatique pour définir ce dont nous avons besoin, le découpage, etc.

Une API GraphQL par définition n’a pas une structure ou un périmètre de données définis, mais s’adapte à son utilisateur.

Le GraphQL comme moyen d’accélérer les développements ? 

UNE DISTINCTION CLAIRE : ATTENTION AUX CAS D’USAGE !

Nous ne visons certainement pas tous les cas d’usages, mais l’objectif ici est de casser un peu certains mythes.

Si utiliser des mutations (en gros l’équivalent de l’écriture) intriquées, nous l’avouons, peut être très complexe, dans les cas de requêtage de bases de données ayant comme objectif principal l’exposition en consultation, nous disons “pourquoi pas !”. 

Vous auriez probablement reconnu le pattern CQRS, avec, par exemple, une Vision 360 Client qui expose les informations avec une API GraphQL.

CÔTÉ TECHNIQUE

Les améliorations dans la gestion des caches, ces dernières années, permettent de gérer ce sujet, tout en restant plus complexe qu’avec une API REST standard. 

Attention aux autorisations

Nous n’allons pas nous attarder sur ce sujet, que nous avons déjà traité dans notre précédent article (que nous vous invitons à parcourir ici), mais nous souhaitons le rappeler car il est crucial et extrêmement critique. 

Si nous souhaitons traiter les sujets d’accès à la donnée avec une API GraphQL, une logique RBAC avec rôles et droits définis au niveau de la donnée (matrice d’habilitations rôles / droits proche de la donnée elle même) nous semble à ce stade la meilleure solution : N’AUTORISONS PAS L’ACCÈS UNIQUEMENT AU NIVEAU DE L’API, MAIS ALLONS AU NIVEAU DATA !

Conclusion

La technologie continue de s’affirmer, un standard semble se définir et s’étoffe de plus en plus. Dans un monde API qui se complexifie de jour en jour, les enjeux autour de la rationalisation et de l’optimisation des usages API restent au cœur des débats sans pour autant trouver de solution directe et efficace via la technologie REST. Et c’est encore plus vrai quand le besoin de base n’est pas clairement défini…

Le dynamisme apporté par le GraphQL, dans certains cas de figure, permet de simplifier ces discussions en apportant des réponses cohérentes avec le besoin.

Ce n’est pas une solution magique faite pour tous les usages, mais une réelle alternative à considérer dans les conceptions API.

Et vous ? Avez-vous pris en considération cette alternative pour vos réflexions API ?

Ne vous en faites pas, il n’est pas trop tard, parlons-en, ce qui ressortira de nos discussions pourrait vous surprendre.

Architecture-Entreprise-Agilite-Les-formations-Architecte-Agile

Quoi de nouveau dans la version 6 de SAFe pour l’architecte solution?

Quoi de nouveau dans la version 6 de SAFe pour l’architecte solution?

25 juillet 2023

– 4 minutes de lecture

Architecture

Thomas Jardinet

Manager Architecture

Salomé Culis

Consultante Architecture

Cet article est le deuxième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe. 

Après avoir étudié le System Architect, nous allons donc voir en détail les différences pour le Solution Architect avec la précédente version de SAFe.

Une position de “pivot” de l’architecture 

Le Solution Architect, positionné entre l’Entreprise Architect et le System Architect, a cela de de particulier qu’il est un réel pivot d’architecture : 

Il n’est pas pour autant un simple passe-plat, et encore moins une boîte mail générique, mais un acteur qui doit insuffler une direction technologique à l’ensemble du SI.

Il définit ainsi une vision technique, qu’il définit, cadre, met en place et partage. C’est par exemple à lui d’identifier les futures technologies à mettre en place, et à les instancier en les industrialisant.

Mais revenons un peu à ce rôle de pivot. Il est en effet extrêmement marquant pour moi de voir une citation du livre de Donella H. Meadows “Thinking in Systems”: 

“You think that because you understand ‘one’ that you must therefore understand ‘two’ because one and one make two. But you forget that you must also understand ‘and.’ “

Cela ne vous parle peut-être pas, mais cette phrase est une très bonne synthèse (certes très raccourcie) de la théorie des Systèmes développée par l’autrice et son mari. Pensée systémique qui influença l’émergence de l’agilité, en expliquant que la complexité des systèmes se mesure dans le nombre d’acteurs et de leurs interactions.

Théorie des systèmes qui m’est personnellement très chère, considérant à titre personnel comme faisant partie de ma liste de livres à lire absolument. Cette théorie apporte en effet une grille de lecture très intéressante de l’environnement qui nous entoure, en cela qu’elle explique que nous sommes tous liés à ce qui nous entoure, et que nous réagissons par rapport à ce qui nous entoure. N’ayant pas toute la sagacité de ses penseurs, je vous laisserais creuser vous-même cette théorie qui inspire fortement entre autres les travaux du GIEC.

Et cerise sur le gâteau pour moi, certe déjà présente dans la version 5 du framework Safe, nous retrouvons l’idée de “démarche inverse de Conway”, qui consiste à calquer l’organisation sur l’architecture souhaitée, et non l’inverse. Démarche qui ferait de l’Architecte Solution un Architecte d’Entreprise qui s’ignore? Néanmoins, on retiendra que cette démarche inverse de conway fonctionne de manière plus fluide dans une organisation réellement agile et se voulant fluide, comme le recherche le framework Safe.

Et comme cette position d’architecte pivot de solution mais aussi de l’organisation ne provient pas non plus de nulle part, nous allons nous entâcher d’abord à réexpliciter son rôle.

Les responsabilités clés de l’architecte solution

Si nous devions chercher à être synthétique, nous pourrions dire que l’architecte solution est l’architecte “support” de l’Entreprise Architect en définissant avec lui la roadmap solution. 

Roadmap solution qui est aussi défini en support avec le System Architect, mais lui en apportant des facilitations, des enablers, et le déchargeant des contingences techniques transverses.

Ainsi les différentes responsabilités du Solution Architect sont les suivantes : 

Les nouvelles relations du Solution Architect

Le rôle du Solution Architect dans la version 5 était peut-être réductrice. En effet il était auparavant quasiment aggloméré avec les architectes systèmes (vision assez réductrice à mes yeux, comme si un architecte solution ou un architecte system était la même chose). Il n’avait ainsi que des échanges avec l’équipe de Solution Management.

De cette modélisation bi-latérale du rôle du solution architect, la version 6 du framework Safe jette cela par la fenêtre pour le remplacer par un rôle de pivot de 4 équipes distinctes : 

,

Le tout bien évidemment dans une logique de collaboration, et non d’une simple logique purement top-down ou bottom-up.

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 1 et 2 peuvent en particulier se révéler utiles : 

Et évidemment, je ne peux que vous conseiller la lecture du livre mis en référence par le framework safe 6

Quoi de nouveau dans la version 6 de SAFe pour le système architecte ?

Quoi de nouveau dans la version 6 de SAFe pour le système architecte ?

11 juillet 2023

– 5 minutes de lecture

Salomé Culis

Consultante Architecture

Cet article est le premier d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe.

Nous allons donc voir en détail les différences pour le System Architect, en particulier sur les sujets d’interactions avec les autres parties prenantes et les responsabilités du System Architect.

Changement de nom pour un nouvel architecte

Un premier point qu’il est important de souligner est le changement de nom de cet acteur lors du passage à la version 6 du framework. Celui-ci passe de “System Architect / Engineering” à “System Architect”, tout simplement. 

Cela permet d’éviter une éventuelle confusion avec le Release Train Engineer ou même avec certains concepteurs fonctionnels qui sont plus proches d’un rôle de PO.

Mais ce changement de nom cache un changement beaucoup plus profond du rôle et de la posture de l’architecte système.

La compétence clé de l’architecte système, la collaboration

Dans cette nouvelle version du framework, la notion de collaboration est mise en exergue comme une compétence clé de l’architecte. 

En effet, l’architecte système collabore avec différents groupes de parties prenantes : 

Ainsi, l’architecte système doit être capable de travailler avec des acteurs très variés, de les aider à remplir leur rôle et de partager sa vision de l’architecture afin que le Train avance dans la bonne direction. 

Nous voyons ici apparaître une notion de base de l’agilité, présente dans le manifeste agile (que vous avez tous sur votre table de nuit ou encadré au-dessus de votre bureau, j’en suis certaine !). 

Cette nouvelle version du framework positionne très clairement l’architecte système comme un acteur qui sort de la tour de verre de l’architecture et va s’intégrer au quotidien dans les équipes. 

La proximité favorise la collaboration

A titre personnel, en tant qu’architecte sur un programme de refonte de la relation client, j’avais fait le choix d’aller m’installer dans l’open space avec les équipes agiles. Cela permettait de :

Au-delà des aspects cités précédemment, je me suis ainsi sentie comme faisant partie du projet à part entière. Je m’étais bien sûr assurée de garder une proximité forte avec mes collègues architectes (nécessaire pour s’aligner aux différents niveaux si vous avez bien suivi !).

Les responsabilités clés de l’architecte système

Vous vous dites peut-être que l’architecte système échange avec beaucoup d’acteurs. Et vous vous demandez peut-être en quoi consiste véritablement son rôle. 

En effet, son rôle évolue pour assumer les responsabilités ci-dessous : 

Les deux derniers points notamment impliquent un véritable changement d’état d’esprit. Le travail de l’architecte ne s’arrête pas au moment de la présentation de la Vision d’Architecture, il doit continuer à accompagner le Train opérationnellement au quotidien pour pouvoir remplir l’ensemble de ces responsabilités. 

Auparavant définies sous la forme d’une liste à la prévert, les tâches du System Architect deviennent à présent un nombre limité de responsabilités clés. 

C’est un vrai shift pour la position de System Architect. 

D’un architecte système qui s’assoit sur les “fauteuils pré-positionnés” par ceux qui ont défini le cadre de gouvernance SAFe, nous passons à un vrai acteur et “modeleur” de l’itération locale du framework SAFe. 

Il n’est pas cantonné à des tâches définies de manière top-down, mais devient un acteur/décideur/influenceur du système.

Si ces sujets vous intéressent…

Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.

Les articles 1 et 4 peuvent en particulier se révéler utiles :