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 :
De l’Entreprise Architect, il doit prendre en considération les directions stratégiques de l’entreprise.
Du System Architect, il doit prendre en compte les remontées “terrain” des Trains Safe.
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 :
Implementing Lean Systems Engineering :
Mise en place non seulement d’une démarche Devops, transverse aux différents projets, en définissant une architecture toujours prête à évoluer (le fameux Design to Change).
Establishing Solution Intent and Context :
Nouveauté par rapport à la version 5 du framework Safe. Cela consiste d’une certaine manière à un travail de cadrage et de veille. Quelles technologies pour quels nouveaux besoins métier? Et inversement quelles technologies peuvent créer quels besoins métier? Il définit également les différents besoins non fonctionnels et les besoins en termes de respect de la réglementation, mais aussi les “intentions” d’architecture, qui représentent la vision d’architecture souhaitée.
Defining and Communicating Architecture Vision :
Définition de la roadmap solution et de la vision d’architecture, participation aux pré pi-planning et pi-planning, gestion de la charge de ses sujets. Evidemment avec toutes les parties prenantes de l’architecture…
Evolving Solution Architecture with ARTs and Suppliers :
Qu’on pourrait résumer par “support aux développeurs et fournisseurs”, que ce soit sur les aspects d’exploration et d’expérimentation, de modélisation, de revue d’incrément, mais aussi bien évidemment de support à la définition de l’architecture du System avec le System Architect.
Fostering Built-in Quality and the Continuous Delivery Pipeline :
Qui représente la pleine partie DevOps de son travail.. Du développement jusqu’aux infrastructures, en passant par les tests, et bien évidemment la définition de la chaîne CI/CD.
Evolving Live Solutions :
C’est là une nouveauté par rapport à la version 5 du framework Safe. Cela consiste à dire que le Solution Architect doit continuer à suivre la solution passé la mise en production, en s’assurant du respect des besoins non fonctionnels, des contraintes réglementaires, mais aussi de son adaptabilité à de futurs besoins.
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 :
L’architecte d’entreprise qui apparaît dans la version 6, pour aligner ensemble l’architecture d’entreprise.
Le STE et les équipes de Solution Management pour piloter les trains de solution, comme précédemment.
Les systems architectes qui sont enfin distingués du “magma d’architectes” pour faire évoluer l’architecture solution.
Et enfin les équipes systèmes (pour faire simple les DevOps) apparaissent elles aussi, qui après tout sont ceux qui instancient l’architecture de solution.
,
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 :
Article 1 : c’est quoi l’Agilité ? Cet article introduit notamment l’agilité à l’échelle et le framework SAFe. Des ateliers favorisant la co-construction de l’architecture sont également évoqués et pourraient se révéler très utiles pour faire participer les différentes parties prenantes avec lesquelles l’architecte collabore. https://www.rhapsodiesconseil.fr/architecture-dentreprise-et-agilite-chapitre-1-cest-quoi-lagilite/
Dans l’article 2, intitulé “ Détournement de valeur(s) en cours.”, nous avions évoqué dans le paragraphe “Les architectes font des plannings sur 5 ans qui sont irréalisables” le besoin de travailler sur des visions à plus court terme, et qui soient réalistes, conformément aux besoins de roadmap technologique des architectes solutions. https://www.rhapsodiesconseil.fr/articles/architecture-et-agilite-chapitre-2-detournement-de-valeurs-en-cours
Et évidemment, je ne peux que vous conseiller la lecture du livre mis en référence par le framework safe 6
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 :
Le PM et le RTE pour orienter les travaux du Train et contribuer au développement de la vision,
L’architecte solution et l’architecte d’entreprise afin de construire une architecture cohérente aux différents niveaux du framework et de l’entreprise,
Les équipes agiles pour les accompagner dans la mise en place de l’architecture,
D’autres équipes telles que la System Team ou des équipes Shared Services, notamment pour mettre en place des processus d’intégration et de tests automatisés.
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 :
Faciliter la collaboration avec elles,
D’être plus facilement impliquée dans des échanges avec le Programme Management et de mieux connaître les priorités pour pouvoir concentrer mes efforts sur les bons sujets,
D’avoir un vrai lien avec les équipes et qu’elles n’hésitent pas à venir me voir pour échanger sur l’architecture.
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 :
Aligner l’architecture avec les priorités Business (grâce à ses échanges avec le PM et les autres architectes),
Définir et communiquer la Vision d’Architecture (notamment auprès des équipes agiles),
Faire évoluer le système avec les équipes,
Favoriser la qualité au fur et à mesure de la construction du système et permettre la mise en place des NFRs (ou exigences non fonctionnelles). L’architecte s’assure qu’ils soient pris en compte dans le backlog et accompagne leur développement par les équipes,
Permettre la mise en place du DevOps et du Continuous Delivery Pipeline (par la collaboration avec la System Team par exemple).
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 :
Article 1 : c’est quoi l’Agilité ? Cet article introduit notamment l’agilité à l’échelle et le framework SAFe. Des ateliers favorisant la co-construction de l’architecture sont également évoqués et pourront se révéler très utiles pour faire participer les différentes parties prenantes avec lesquelles l’architecte collabore.
Dans l’article 4, intitulé “Comment les architectes peuvent interagir avec l’agilité ?”, nous avions évoqué le fait d’aller vers des modes de travail plus collaboratifs et d’être véritablement partie prenante de la transformation de l’entreprise.
Note préalable à la lecture : ce billet d’humeur est une cascade réalisée par un professionnel de la boutade, n’essayez pas de tout interpréter au premier degré.
SUV : L’empreinte écologique qui grandit à chaque kilomètre
Arrête-moi si tu peux
Tyre Extinguishers, Extinction Rebellion, dégonfleurs de pneus, si vous n’avez jamais entendu parler de la nouvelle mode des activistes sur ces derniers mois, c’est que vous êtes à côté de la plaque !
L’objectif de ces collectifs est simple : dégonfler un ou plusieurs pneus des 4×4 et SUV pour sensibiliser les propriétaires de ces véhicules contre la pollution et le réchauffement climatique, et les inciter à favoriser les transports en commun.
Pour mener leurs actions en toute discrétion, les militants écologistes agissent habituellement la nuit, en arpentant les rues des grandes villes en quête de pneus à dégonfler. Grâce à une méthode bien rodée, ils s’attardent peu sur une voiture et partent sur les chapeaux de roues quand ils se sentent surveillés ou lorsqu’ils sont démasqués.
Le lendemain, les propriétaires constatent, impuissants, que leurs véhicules ont été la cible de ces justiciers noctambules. Ils découvrent un tract apposé sur leurs pare-brises qui explique la démarche du collectif, mais également pour dénoncer la pollution de ces tanks en milieu urbain.
Un acte militant qui gonfle les automobilistes
« Ne le prenez pas personnellement. Vous n’êtes pas notre cible, c’est votre véhicule »
Le message semble clair : le propriétaire n’a rien à se reprocher dans cette histoire et inutile de monter dans les tours.
Seulement voilà, le désagrément, lui, est bien présent et a de quoi irriter le conducteur qui doit utiliser son véhicule au moment de la découverte du message.
Comment l’automobiliste peut-il bien accepter cet « acte de sensibilisation » au moment où il doit prendre le volant pour son besoin professionnel ou personnel ?
Difficile de prendre parti pour cette cause juste lorsque vous vous sentez victime d’une injustice… Bien au contraire, la réaction sera bien souvent à l’opposé de l’effet attendu : le propriétaire aura de quoi péter une durite et se désintéresser des conséquences de sa voiture sur un plan écologique !
En toute logique, les ardents défenseurs de l’écologie devraient poursuivre leurs activités en allant également dégonfler les pneus des jets privés ou siphonner le carburant des yachts privés, sans oublier de déposer le message de sympathie sur les vitres !
Il semblerait que dégonfler les pneus des véhicules ne soit pas suffisant pour retirer les SUV du catalogue des constructeurs automobiles. Au contraire, les SUV sont devenus les chouchous des Français, et représentent près de la moitié des ventes de véhicules neufs.
S U V, 3 lettres qui divisent un monde et qui font débat, à tort ou à raison.
Le militantisme bruyant est-il la seule façon de sensibiliser à la lutte contre le réchauffement climatique ?
Les actions individuelles ne pourraient-elles pas également avoir un impact significatif sur la réduction de notre empreinte environnementale ?
Au-delà des claviers et des écrans : les conséquences écologiques de notre dépendance numérique
L’empreinte numérique : un acteur méconnu de la crise climatique
Trier les déchets, consommer localement, privilégier les moyens de transport moins polluants, acheter des produits recyclés ou réutilisables, et réduire leur consommation globale : ces gestes modestes, cumulés, ont un impact significatif sur l’environnement.
Plutôt que de pointer du doigt les autres, nous pourrions tous agir de manière responsable pour réduire notre empreinte environnementale et contribuer à la lutte contre le réchauffement climatique. Il ne s’agit pas de juger les actions des uns et des autres, mais plutôt de promouvoir une prise de conscience collective, à commencer par son entourage, qui encouragera chacun à agir selon ses convictions et ses moyens pour préserver notre planète.
En particulier, il est intéressant de noter que l’utilisation croissante des objets numériques dans notre vie quotidienne a également un impact significatif sur l’environnement.
Le coût énergétique et environnemental caché de notre utilisation numérique
L’arrivée d’Internet dans nos foyers a marqué une véritable révolution numérique, et aujourd’hui, il est rare de trouver une personne qui n’a jamais été en contact avec une technologie numérique (vous visualisez bien vos grands-parents avec une tablette multimédia ?).
En 2022, Google enregistre plus de 8,5 milliards de requêtes par jour, générant ainsi un coût énergétique non négligeable à l’échelle mondiale.
Ce Cloud-là n’est pas composé de petites gouttelettes d’eau ou de cristaux de glace, mais plutôt de racks de serveurs et d’infrastructures techniques nécessaires pour les héberger.
Malheureusement, l’utilisation croissante d’objets numériques a un impact significatif sur l’environnement.
En prenant une moyenne basse de 4 g de CO2 par email, cela représente environ 486 millions de tonnes de CO2 générés pour cette année.
Imaginez l’empreinte carbone que peut générer un appel personnel ou professionnel en visioconférence !
Par ailleurs, une étude de l’ADEME a démontré que la fabrication d’un ordinateur pesant 2 kg mobilise 800 kg de matières premières, et génère 124 kg de CO² sur un total de 169 kg émis tout au long de son cycle de vie.
À partir de cette constatation, il est facile de comprendre que limiter le remplacement fréquent de nos objets électroniques, tels que les ordinateurs, les téléphones portables ou les téléviseurs, permet de réduire leur impact environnemental.
Il est important de se demander si nous avons réellement besoin de posséder plusieurs modèles d’appareils différents qui risquent souvent d’être laissés de côté.
Alors, prêt à évangéliser cette pratique autour de vous et à faire de la place dans vos placards ?
Pascal, podomobiliste chevronné et fervent croyant de la sobriété numérique
ArchiMate est un langage de modélisation développé par l’Open Group, basé sur les concepts TOGAF, qui permet de partager un langage commun pour décrire, analyser et visualiser l’architecture d’entreprise. Le but ? Aider à la prise de décision des transformations de l’entreprise.
Résultat d’années de réflexions (travaux débutés en avril 2020), la nouvelle spécification ArchiMate 3.2 est publiée le 18 octobre 2022.
L’objectif de cet article est de montrer l’exhaustivité des modifications apportées par la spécification 3.2 d’ArchiMate.
Voici une synthèse de ces modifications qui seront détaillées plus bas :
La couche physique devient un composant de la couche technologie
Modification de la notation
L’ensemble des éléments ont maintenant deux notations : sous forme de boite et d’icône
Tous les éléments de la couche Implémentation et Migration sont désormais de la même couleur
Modification des méta-modèles
Reformulation des définitions de Outcome, Constraint, Business Function, Product et Technology Interface
Modification des relations dérivées
Ajout d’une règle de dérivation pour un élément Grouping
Modification majeure des restrictions
La couche physique devient un composant de la couche technologie
Jusqu’ici indépendantes, Archimate 3.2 intègre la couche Physique dans la couche Technologie.
Les modifications de la notation
Deux changements majeurs dans la notation ArchiMate sont apportés par la spécification 3.2 :
L’ensemble des éléments ont maintenant deux notations : sous forme de boite et d’icône
Tous les éléments de la couche Implémentation et Migration sont de la même couleur
Nous avons fait le travail de synthèse des modifications de la notation dans le tableau suivant :
Modification de la notation ArchiMate 3.2
Voici donc la nouvelle notation Archimate 3.2 :
Notation ArchiMate 3.2
La modification de définitions
ArchiMate 3.2 clarifie et simplifie les définitions des concepts Outcome, Constraint, Business Function, Product et Technology Interface.
Issu de la spécification ArchiMate, nous avons synthétisé l’ensemble des modifications de définitions dans ce tableau (rouge : supprimé ; vert : ajouté) :
Couche
Élément
ArchiMate 3.1
ArchiMate 3.2
Motivation
Outcome
Represents an end result.
Represents an end result, effect, or consequence of a certain state of affairs.
Motivation
Constraint
Represents a factor that limits the realization of goals.
Represents a limitation on aspects of the architecture, its implementation process, or its realization.
Business
Business Function
Represents a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competencies), closely aligned to an organization, but not necessarily explicitly governed by the organization.
Represents a collection of business behavior based on a chosen set of criteria such as required business resources and/or competencies, and is managed or performed as a whole.
Business
Product
Represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
Represents a coherent collection of services and/or passive structure elements, accompanied by a contract, which is offered as a whole to (internal or external) customers.
Technology
Technology Interface
Represents a point of access where technology services offered by a node can be accessed.
Represents a point of access where technology services offered by a technology internal active structure can be accessed.
La modification des méta-modèles
La spécification 3.2 modifie les méta-modèles des couches Business, Technologie, Physical, et des liens entre la couche Implémentation et Migration et l’aspect Motivation.
Voici les évolutions de ces méta-modèles :
Business Composite Elements
Technology Layer Metamodel
Technology Passive Structure Elements
Physical Elements Metamodel
Relationships of Implementation and Migration Elements with Motivation Eléments
En synthèse, les modifications des méta-modèles apportent les changements suivants :
Ajout des relations
Agrégation et Composition du Product au Contrat
Agrégation et Composition entre Node, Device, System Software, Equipment et Facility
Assignation du Device à l’Artifact
Assignation du System Software à l’Artifact
Réalisation du Matériel à l’Equipement
Composition et Agrégation du Plateau à l’Outcome
Réalisation et Influence du Work Package au Requirement
Suppression des relations
Réalisation entre des Nodes
Assignation des éléments technologiques de structure active à l’Artifact
Modification des liens d’héritage
System Software, Device, Equipment et Facility n’héritent plus du Node et héritent des éléments technologiques de structure active
Artifact, Material et Path sont des éléments technologiques de structure passive
Évolution des relations dérivées
Dans le but de réaliser des analyses d’impacts plus poussées, la spécification ArchiMate 3.1 avait introduit la notion de relation dérivée :
Si on a deux relations p(b,a):S et q(b,c):T avec a, b, c des éléments, p et q des relations respectivement de type S et T, alors on cherche à connaître la relation r de type U tel que r(a,c):U.
ArchiMate 3.1 définit :
Des règles de dérivation strictes, qui s’applique quel que soit le modèle
Des règles de dérivation potentielles, qui peuvent s’appliquer en fonction du modèle
Des restrictions sur les règles de dérivation
En complément, Archimate 3.2 :
Réécrit totalement les restrictions sur les règles de dérivation, qui étaient jusqu’ici difficiles à lire
Ajoute une règle de dérivation potentielle pour un élément Grouping : S’il existe deux relations p(b,a):S et q(b,c):T, avec S une relation de type Agrégation ou Composition, b un élément de type Grouping et T une relation de type Realization ou Assignment, alors une relation r(a,c):T pourrait être dérivée seulement si le métamodèle permet une relation T de a à c.
Conclusion
Les modifications du langage de modélisation Archimate apportées par la spécification 3.2, bien que mineures, permettent d’homogénéiser la notation, d’améliorer le méta-modèle et de supprimer des ambiguïtés par la clarification à la fois des définitions et des règles de restrictions des relations dérivées.
Il n’est pas toujours évident de s’y retrouver dans la jungle que constituent les différents comités en entreprise, et les comités d’architecture ne font pas exception. Vous êtes perdus et ne savez pas comment définir la comitologie qui répondra aux besoins de votre organisation ? Suivez le guide !
Dans cet article, nous aborderons deux grandes étapes :
la définition de la comitologie d’architecture, dans un premier temps,
suivie par un focus sur l’animation de cette comitologie.
Une comitologie utile et intéressante doit être construite pour répondre à vos objectifs
Identifier clairement les objectifs de la comitologie
Les objectifs des organisations étant très divers, il est naturel qu’une myriade de comités d’architecture différents existent :
des comités transverses ou spécifiques à un programme de transformation,
des comités de partage entre architectes,
ou des comités d’arbitrage.
L’un des écueils principaux consiste à faire surgir dans les agendas autant de comités que de champignons après les premières pluies d’automne. On voit souvent des participants occasionnels se mélanger les pinceaux avec les trois ou quatre réunions portant un nom approchant. Et s’ils ne savent pas les différencier, nul doute qu’ils ignorent leurs objectifs…
Mais dans ce cas, comment créer une comitologie d’architecture claire, lisible et utile ?
Afin de choisir la plus adaptée, il est tout d’abord capital de bien comprendre le contexte de votre entreprise et d’identifier vos objectifs. Cela peut passer par des interviews mais aussi être exploré dans le cadre d’un audit de maturité de l’architecture, qui comporte un volet sur la comitologie.
Définir ensemble la comitologie qui répond aux objectifs identifiés
Une fois les objectifs clarifiés, la construction collaborative de la comitologie peut ensuite débuter !
Rhapsodies Conseil vous aide à dessiner la comitologie qui vous conviendra le mieux en s’appuyant sur :
les éléments de contexte,
un catalogue d’exemples de comités d’architecture,
un arbre de décision.
Votre connaissance fine de l’organisation dans laquelle vous évoluez sera également précieuse et devra être prise en compte.
Vous obtiendrez à terme une description des différents comités d’architecture à mettre en place précisant :
leurs objectifs,
la fréquence à laquelle ils seront tenus,
leurs périmètres respectifs,
les différents participants.
Ces éléments seront bien sûr diffusés au sein de l’organisation pour bien expliquer le rôle du ou des comités d’architecture. Bien communiquer en amont de la mise en place des comités permettra de s’assurer que tous les participants, récurrents ou occasionnels, n’aient pas de doutes sur leurs objectifs.
Il ne reste plus qu’à les mettre en œuvre et les animer !
Pas si simple me direz-vous ? Comment s’assurer que cette comitologie soit animée de manière efficace et réponde ainsi aux objectifs de l’organisation ?
Tout en évitant à tout un chacun d’écouter distraitement d’une oreille en travaillant sur un autre sujet en parallèle ou en traînant sur son téléphone…
Eh bien, en s’appuyant sur le PMO de l’architecture !
Le PMO de l’architecture : cet acteur clé qui rend vos comités efficaces et productifs
Qui est le PMO de l’architecture ?
Ce terme de “PMO” a été dévoyé et il peut paraître n’être qu’un scribe qui n’apporte pas de vraie valeur ajoutée. Notre conviction chez Rhapsodies Conseil est la suivante : cet acteur doit avoir une culture de l’architecture d’entreprise. Il peut alors faire tellement plus pour l’équipe architecture que compléter un fichier excel une fois par mois !
Il dispose ainsi de nombreuses compétences :
bonne connaissance du SI
maîtrise de la gouvernance de l’architecture,
bon relationnel,
compréhension de l’organisation et du rôle de l’équipe d’architecture,
compréhension des enjeux projets,
connaissance des dossiers d’architecture et des modèles,
techniques d’animation de réunions.
C’est pourquoi il est le plus à même d’animer la comitologie d’architecture et de la rendre intéressante pour l’ensemble des participants, décideurs y compris.
La première activité du PMO de l’architecture : sélectionner et vérifier les dossiers d’architecture
C’est lui qui propose un ordre du jour en fonction de la maturité et du niveau d’urgence des dossiers d’architecture. Il vérifie que ceux-ci sont bien complets avant leur passage en comité. Il comprend les enjeux et peut donc appuyer les différents architectes dans la préparation de leurs dossiers. Il dispose aussi de templates de dossiers d’architecture afin de guider les architectes nouvellement arrivés dans la rédaction de leurs premiers dossiers.
Une bonne préparation avec des attendus précis, dont le PMO de l’architecture est le garant, permet d’éviter bien des désillusions en comité… Et de devoir à de nombreuses reprises rapporter les mêmes éléments complémentaires devant des participants qui ont oublié une bonne partie du sujet…
Le PMO de l’architecture est aussi en charge de l’animation des comités le jour J
L’animation des comités en tant que tels fait également partie de son rôle : il partage l’ordre du jour, suit le bon déroulement du comité, recueille les avis en séance et prend les notes explicatives. Il établit le relevé de décision et partage le compte-rendu aux différents participants.
Il peut aider à remettre le comité sur le droit chemin quand les échanges s’enlisent.
Un suivi est mis en place par le PMO pour que les décisions ne restent pas lettre morte
Suite aux comités, il réalise le suivi des dossiers en fonction des décisions :
passage en mode projet,
programmation d’un deuxième passage du dossier,
études à refaire ou à compléter.
Il établit donc les ordres du jour des prochains comités.
Ce suivi fin des ordres du jour permet d’éviter ce que l’on voit parfois :
un ordre du jour déformé car il a été mal compris par la personne chargée du suivi,
la présentation d’un sujet devant des décideurs qui ont oublié l’avoir demandé.
Il peut identifier les décisions qui donnent lieu à de la dette et en faire le suivi.
De plus, connaissant les différents dossiers en cours, il maîtrise les dépendances entre les sujets. Il est donc à même de prévenir les architectes dont les sujets peuvent être impactés par les décisions du comité. Le PMO de l’architecture ayant une vision globale de l’avancement des sujets, il peut créer du lien entre les architectes. Cela permet aussi d’assurer que l’ensemble des décisions prises lors des comités restent cohérentes.
Le PMO de l’architecture participe également à l’amélioration continue de la gouvernance de l’architecture
Enfin, son rôle transverse lui permet de construire le reporting de la comitologie : il suit le nombre de dossiers qui passent en comité, les décisions et les avis émis… Il peut alors proposer des améliorations de la comitologie afin d’optimiser la gouvernance de l’architecture. Il pourra donc vous aider à ajuster la comitologie si nécessaire en fonction de ce qu’il observe en comité et des issues des présentations.
J’ai tenu ce rôle pendant 1 an et eu la chance de travailler avec des collègues qui avaient aussi tenu ce rôle. J’espère que cette synthèse vous sera utile et que vous connaissez désormais mieux le PMO de l’architecture, cet acteur qui garantit le succès de vos comités. N’hésitez pas à nous contacter pour échanger sur vos retours d’expérience.
Savez-vous que lancer les développements d’une solution sans modélisation de données, c’est comme construire une maison sans en avoir fait les plans ?
Si vous voulez avoir des solutions performantes et pérennes pour vos projets de transformation de vos SI, utilisez la modélisation de données, et en particulier la modélisation de données conceptuelle, comme un levier de performance.
Stocker des données n’est pas modéliser des données
Très souvent après avoir validé vos projets de transformation des SI pour atteindre les enjeux métier d’entreprise, l’objectif est de rapidement importer les premières données pour pouvoir les rendre ‘visibles’ et avoir des premiers résultats ‘concrets’.
Des développements sont donc lancés, sans l’étude préalable des données et des concepts nécessaires pour faire le lien avec le métier de l’entreprise. Ces développements conduisent à définir des tables et des jointures avec pour objectif de stocker des données. C’est la modélisation de données dite physique. L’objectif n’est pas le bon à ce stade. C’est une vision de solution court-termiste.
Une notion importante à appréhender est que le stockage des données et la structure de la base de données impactent directement la restitution, et donc l’usage des données. Cette structure est développée au travers du modèle de données physique.
Si vous mélangez les notions de modèle de données physique et de modèle de données conceptuel, et si vous ne comprenez pas bien les concepts fonctionnels manipulés, alors le modèle de données physiques ne répondra pas à tous les besoins adressés.
Toutes ces questions sont adressées au travers de la modélisation de données et en particulier la modélisation de données conceptuelle.
Dès lors, quels sont les objectifs de la modélisation de données ?
Nous avons vu que lorsque nous pensons modélisation de données, nous pensons tables, jointures, clefs étrangères. En réalité, cela revient à penser, tuyaux en PVC ou en cuivre, briques ou parpaings, avant même de savoir si nous souhaitons une maison de plain-pied ou à étages. La modélisation de données conceptuelle est donc une obligation.
Le modèle de données conceptuel conceptuel permet de définir des concepts (étonnant, non ?) transverses à l’entreprise, clairement définis entre les parties prenantes. Ces concepts sont liés pour répondre à un ensemble d’usages, qui lorsqu’ils sont regroupés dans des fonctions (définies au travers de l’architecture fonctionnelle), constitueront la solution informatique répondant aux besoins.
Le modèle de données conceptuel doit d’abord répondre à des usages propres au métier de l’entreprise. Prenons un modèle de données client par exemple. Il sera différent pour un assureur ou pour un industriel. Il sera également différent entre deux assureurs du fait de leur positionnement sur le marché. Le modèle conceptuel est donc basé sur l’utilisation des données qu’il contient : les usages valident le modèle.
La modélisation de données : une démarche à valeur ajoutée pour la DSI et surtout pour le métier
Le modèle de données conceptuel décrit les données stockées dans la solution de manière compréhensible par les métiers. D’autre part, il impose une démarche rigoureuse de conception concourant à la réussite du projet.
La modélisation de données doit ainsi commencer par lister les usages et les données sous-jacentes ou associées. S’entourer à la fois d’experts des données et d’experts métier est donc la clé. En effet, nous avons mis en évidence plus haut que le modèle de données conceptuel doit répondre aux deux enjeux à la fois :
Les experts des données sont responsables de découvrir et connaître les données, leur qualité réelle et leur utilisation réelle.
Les experts métiers sont responsables eux de décrire les usages actuels et cibles de ces données. Les usages étant les processus métiers de l’entreprise dans lesquels vont être utilisées ces données, mais aussi les contraintes liées à la mise à disposition de ces données (réglementaires, sécurité, etc.).
Construire et valider le modèle de données conceptuel est donc une démarche itérative afin d’échanger très régulièrement entre le métier, les experts de la donnée et la DSI.
Un modèle de données conceptuel performant est avant tout un modèle métier qui traduit des besoins métiers : on ne peut modéliser sans avoir une expression de besoin décrivant les usages.
La modélisation conceptuelle s’inscrit également dans une démarche de gouvernance des données. En effet, les premières questions posées naturellement quand le modèle de données se construit sont par exemple : quelle est la définition de ce concept ? dans quel cycle de vie s’inscrit-il ? etc. Les métiers définissent les concepts, les périmètres et les responsabilités avec le modèle de données conceptuel.
Avec cette démarche, en tant que DSI, vous minimisez les risques de choix court-termistes et de complexité de la solution développée. Vous bénéficierez ainsi d’une solution évolutive, maintenable, documentée et qui minimise également le shadow IT.
En tant que métier, cela vous permet d’être au plus proche des développements et vous comprenez grâce au modèle de données conceptuel, les données manipulées dans la solution. Vous minimisez ainsi les risques d’inadéquation avec les attentes métier.
En tant que responsable projet, product owner, ou responsable SI, imposez donc d’avoir une démarche de modélisation de données qui commence par un modèle conceptuel dans tous vos projets SI. Il est un facteur clef de réussite !
La modélisation de données : une compétence clé
La gestion du cycle de vie du modèle de données conceptuel et des impacts sur le stockage des données (base de données), doivent être suivis et validés par une personne experte en modélisation de données. Le cycle de vie du modèle de données est un processus lent dont les évolutions ne se voient pas forcément.
Une modélisation de données performante doit garantir une cohérence, une intégrité et une interopérabilité des données et des solutions. Une mauvaise modélisation de données crée ainsi lentement des blocages SI pour de futurs usages. Une illustration simple de cette mauvaise modélisation de données, est de laisser en attributs des données qui ont des cycles de vie différents de l’objet auquel ils sont rattachés. Multipliés par le nombre de données à l’échelle de l’entreprise et ajoutés à la complexité d’un modèle, ces problèmes de modélisation de données rendent le SI rigide.
La modélisation de données est donc une compétence spécifique. C’est une expertise qui s’acquiert au fur et à mesure des projets. Elle est nécessaire aux équipes de conception telles que les Business Analysts et les Architectes de données.
La modélisation de données, un facteur clef de succès de la transformation des SI
La modélisation des données est donc indispensable à un projet de développement de solution informatique. Comme évoqué précédemment, avec le modèle de données conceptuel, elle manipule des concepts métier de l’entreprise. Elle doit donc se projeter et anticiper les nouveaux concepts nécessaires aux nouvelles demandes client. Elle garantit ainsi l’agilité et l’évolutivité de votre solution face à la diversité des usages à adresser pour répondre aux demandes client en perpétuelle évolution.
Une question reste alors : la modélisation de données dépendant de la qualité des données des concepts métier, est-ce que les processus métier actuels de l’entreprise peuvent être modifiés pour fournir la qualité des données nécessaires aux nouvelles demandes client ?
