Si vous ne l’avez pas encore fait, découvrez les deux épisodes précédents : TOGAF IRL 1 ; TOGAF IRL 2.
La fin d’un monde sans contraintes
Ça y est, Vous avez collecté la liste des exigences ! Vous avez rencontré le métier, l’IT et la production de votre IT. Vous avez vérifié que vos exigences sont bien cohérentes les unes avec les autres, vous avez même probablement commencé à réfléchir à quoi ça pourrait ressembler, mais si vous vous dites que le reste devrait couler, vous vous trompez. Car c’est à partir de maintenant que vous allez vous confronter « au réel ».
Vous n’êtes pas le seul projet en cours (enfin normalement), les différents composants sur lesquels vous voulez apporter des modifications ont leur propre cycle de vie, leurs évolutions, leurs contraintes. Et puis votre projet également : le chef de projet a un budget, un délai et des objectifs à respecter. Alors il va falloir prendre tout cela en compte, sinon vous ne serez qu’un architecte de plus avec la réputation de « travailler dans une tour d’ivoire ».
Nous allons donc continuer à parcourir ensemble la roue ADM et au final, nous pourrons nous poser la question : TOGAF, applicable In Real Life ou pas ?
Phase E : Opportunités et solutions
L’objectif de cette phase est de construire la phase initiale de la feuille de route de l’architecture de votre projet. C’est-à-dire que l’on va créer la vision AS-Is du périmètre projet, la cible ainsi que les différents lotissements.
Pour l’existant, vous pouvez commencer en vous basant sur le contenu du référentiel d’entreprise (s’il y en a un) et de la documentation existante mais vous devrez tout de même aller voir vos différents interlocuteurs. Cela vous permettra de vous assurer de la fraîcheur de l’information que vous avez. Profitez-en pour demander si ces composants ont déjà des évolutions de prévues et quand elles auront lieu. Cela vous servira d’entrée pour définir vos trajectoires.
Pour la cible, identifiez les changements et identifiez les exigences liées à ces changements. S’il y a des exigences sans changement associé, c’est que vous avez des oublis.
Maintenant que vous avez votre point de départ et votre cible, il reste à définir le chemin… ou plutôt les étapes de votre chemin (les états stables de votre trajectoire). Pour cela, il est nécessaire de négocier avec l’équipe projet. Il y a évidemment l’enchaînement logique des évolutions (par exemple, si vous devez consommer de nouvelles données clients, vous allez mettre à jour votre référentiel en même temps que l’application consommatrice et non après), mais il est important d’intégrer les contraintes du projet (coûts et priorités) pour définir vos étapes. De la même manière, si vos contraintes ne permettent pas d’atteindre votre cible, identifiez une étape intermédiaire qui pourra servir de cible projet tout en remplissant les exigences principales du métier.
Dès que l’on parle de modélisation en architecture, arrive très vite la question de l’outil de modélisation ou d’Architecture d’Entreprise. Nous n’allons pas parler ici de quel outil utiliser ou comment le faire car ce n’est pas le sujet de notre article, mais plutôt est-ce vraiment nécessaire. De mon point de vue la réponse est non, on peut très bien faire sans et power point est largement suffisant. Par contre si c’est le choix qui est fait, cela implique plusieurs choses :
Définir un modèle de document qui sera appliqué pour chaque projet
Définir un métamodèle et une légende commune
Avoir un outil de gestion documentaire pour éviter que toutes les connaissances acquises soient perdues.
J’ai personnellement travaillé dans des grands groupes bancaires, dans des entreprises de service ou industrielles qui avaient fait ce choix et cela permet d’éprouver la démarche sans avoir à faire des investissements qui peuvent parfois être lourds pour l’entreprise ou la DSI.
Phase F : Migration et planning
Vous connaissez la direction que vous voulez prendre ainsi que le chemin, mais il reste encore une chose à savoir : quand ? Le but de cette étape est de finaliser la feuille de route d’architecture et le plan de mise en œuvre de la transformation. Jusqu’à présent vous avez intégré les contraintes de votre projet mais vous ne vivez pas seul sur une île déserte. D’autres projets touchent peut-être les mêmes composants que vous et peut-être sont-ils plus prioritaires que vous.
Dans ce cas, TOGAF préconise de voir le chef de projet ainsi que le responsable du portefeuille de projet. Il faut faire attention tout de même, certains chefs de projets, emportés par la volonté de mener à bien leurs travaux, ont tendance à minimiser les impacts de leurs collègues et les responsables de portefeuille n’ont pas toujours la vision exhaustive des impacts de tous les projets qu’ils suivent. A titre personnel, je vais toujours faire le tour de l’équipe d’architecture en plus, mais je vais également voir les responsables d’application car ce sont ceux qui ont une vue complète des évolutions à venir.
A présent votre feuille de route est terminée. pensez à bien mettre en évidence la valeur ajoutée pour le métier de chaque incrément car, quand vous communiquerez sur le déroulé de votre projet, ce sera le critère clé pour votre client : le métier. Si cela est possible, mettez cela en balance avec le risque lié à chaque étape dans un diagramme comme celui-ci :
Phase G : Implémentation et gouvernance
L’objectif de cette phase de la roue ADM est de s’assurer que les mises en œuvre sont bien conformes aux spécifications de l’architecture cible, en d’autres termes : faire le suivi de l’architecture du projet.
Cette phase est très souvent négligée par les équipes d’architecture. Cela nécessite d’investir beaucoup de temps et la valeur est souvent sous-estimée. Or, il est dommage de définir une architecture répondant au mieux aux attentes du métier, si derrière l’implémentation ne correspond pas.
Idéalement, il faudrait pouvoir faire des revues de code régulières, mais malheureusement cela est très chronophage. En réalité, il est souvent suffisant de participer aux comités projets pour les projets « en V » et d’y identifier les futurs travaux ou de relire la Sprint Back log pour les projets agiles. En toute logique, il est préférable d’intervenir avant que la réalisation commence, car il est très rare de voir un projet faire marche arrière.
Phase H : La gestion du changement
Ce n’est pas parce que le projet a démarré qu’il n’y a pas de nouveaux besoins. Dans cette phase, vous êtes censés vérifier 2 choses :
Si les nouveaux besoins collectés nécessitent de redémarrer un nouveau cycle (bref un nouveau projet) ou juste une mise à jour de l’actuel.
Si le projet est conforme ou non et si ce n’est pas le cas, si une dérogation peut être accordée ou non.
Pour les nouveaux besoins, il faut évaluer les impacts sur l’architecture et pour cela vous pouvez utiliser quelques critères tels que :
Le changement touche un ou plusieurs composants ?
Cela remet-il en cause l’architecture actuelle ?
Cela nécessite-t-il la mise en place de nouveaux flux ? De déployer de nouveaux composants ?
Pour vous donner un exemple, j’interviens actuellement sur la mise en place d’un ERP chez un client. Ce client a deux nouveaux besoins qui sont apparus. Dans un cas, il a été nécessaire de déployer un nouveau composant et cela a entraîné le lancement d’un nouveau sous-projet. Dans l’autre cas, il a fallu également déployer un nouveau composant, mais cela n’a pas nécessité de nouveau projet, car il s’agissait d’un ISV (achat du composant sur une market place de l’éditeur de l’ERP). En réalité il s’agit d’une décision collégiale entre le chef de projet et le sponsor et vous ne pouvez qu’apporter un avis.
Pour les réserves et les dérogations, on peut utiliser les mêmes critères et comme pour les nouveaux besoins, la décision se prendra entre le chef de projet et le sponsor.
Alors TOGAF, applicable IRL ou pas ?
Parmi tous les reproches que l’on entend au sujet de TOGAF, celui qui revient le plus souvent est celui de la rigidité. Reconnaissez que c’est un reproche étonnant car ce que l’on attend d’un framework : c’est un cadre, et un cadre est rarement souple.
Alors comme disent nos amis anglais : « first learn the rules then break them ». La valeur de cette démarche et qu’elle permet de comprendre les interconnexions entre toutes les décisions durant un projet et leurs impacts sur le résultat final. Une fois que l’on a compris cela, il suffit juste d’adapter TOGAF à son environnement comme nous l’avons fait lors de ces trois articles.
A titre personnel, il arrive que ma démarche soit encore plus éloignée des règles TOGAF. Il arrive même que je me passe de certaines phases de la roue mais cela est toujours propre à l’environnement dans lequel je travaille.
TOGAF in real life : sans doute pas, mais TOGAF in your own life : sans aucun doute.
Question subsidiaire : la certification, utile ou pas ?
Vous m’auriez posé la question il y a quelques années, je vous aurais dit que cela est utile, surtout si vous travailliez comme consultant. Aujourd’hui (nous sommes en 2020), cela me parait beaucoup moins nécessaire. Je suis consultant depuis bientôt 15 ans. Je suis intervenu chez une trentaine de clients et le dernier à m’avoir posé la question, c’était il y a 3 ans et c’était pour me dire que lui venait de le passer. En fait, TOGAF a irrigué beaucoup de services d’architecture. Beaucoup de gens en font sans le savoir et finalement ce n’est plus un facteur différenciant. Alors si on vous le propose, dites oui mais vérifiez que cela ne va pas être juste du bachotage, car la formation a plus de valeur que le coup de tampon.
Souvenez-vous ! Lors du dernier article, nous venions d’obtenir notre certification TOGAF et nous voulions voir comment appliquer ce framework dans la « vraie vie ». Nous avons donc mis en place Les capacités d’architecture (phase Préliminaire et phase A), et maintenant nous allons continuer en suivant la roue ADM (Architecture Development Method).
Nous allons donc parler dans cet article, de la définition des exigences propres à chaque niveau du Système d’Information (la couche métier, la couche applicative et la couche technique) et qui vont impacter le projet. Puis dans le prochain article, nous finirons avec leurs conséquences sur le design des solutions et comment fermer la roue.
La définition des exigences peut changer du tout au tout en fonction du domaine d’activité de votre entreprise / client. Culturellement, le domaine industriel a toujours été plus sensible à la rédaction des exigences que le domaine tertiaire. Vous imaginez bien que pour construire une centrale nucléaire, la liste des exigences est plus importante que pour construire une application de gestion de la solution client (CRM) car en cas de problème, les conséquences sont moins importantes.
Gestion des exigences ou le référentiel des exigences
La gestion des exigences doit permettre de s’assurer du bon suivi des exigences exprimées lors des différentes phases de la roue ADM mais également de s’assurer de leur cohérence. Pour cela, il faut 3 choses :
Un référentiel des exigences pour les stocker
Un processus de mise à jour
Un processus de revue pour la mise en cohérence des exigences.
TOGAF est un framework avec une approche « Test Driven Design ». C’est-à-dire que les exigences du système d’information ont pour but d’être testées. Il est donc primordial de bien les maîtriser de les prioriser, de connaître leur historique, de pouvoir les évaluer et de voir à la fin si le produit fini du projet y répond correctement.
Pour cela, il peut être intéressant d’outiller la gestion des exigences et de créer un référentiel. Si un outil existe déjà, utilisez-le, les plus connus sont IBM rational DOORS, Envision Requirements, JIRA ou autre. Dans le cas contraire un fichier Excel dont la gestion sera sous la responsabilité de l’architecte projet sera bien suffisant. De plus, les exigences seront gardées à la fin du projet et pourront être réutilisées lors du démarrage d’un nouveau cycle de la roue ADM. Il est alors préférable de nommer un responsable de l’administration de ce référentiel.
Maintenant que tout est prêt, nous pouvons continuer de parcourir la roue ADM et commencer à identifier les exigences auxquelles il va falloir répondre.
Phase B : Architecture métier ou comment solliciter son métier à bon escient ?
La phase B de la roue ADM doit permettre de décrire comment votre entreprise (ou le domaine métier impacté par votre projet) doit s’organiser pour atteindre les objectifs. Le travail va donc se concentrer sur la définition de la stratégie, sur la gouvernance, l’organisation métier et les informations clés des processus métier. Et comme lors des précédentes phases, le but est de ne pas surinvestir et de ne consommer que de la charge de travail avec une véritable valeur ajoutée.
La majorité du temps, les équipes d’architectes font partie de la DSI, les relations avec le métier peuvent donc être multiples :
Nous avons directement accès au métier et les impacts sur les processus sont faibles : La disponibilité du métier risque d’être faible car il a ses tâches récurrentes à effectuer (vente, gestion, comptabilité). Dans ce cas, il est nécessaire de lui prendre le moins de temps possible : traduire les enjeux métier, lister les processus et les « pain points ». Seuls quelques ateliers seront nécessaires pour collecter ces informations, il suffit ensuite d’en déduire les exigences métiers.
Nous avons directement accès au métier et les impacts sur le métier sont importants : dans ce cas, le métier doit se rendre disponible pour répondre au besoin. C’est généralement le cas préféré des architectes car cela permet de poser ses questions en toute liberté.
Nous devons passer par une MOA, qui est un intermédiaire avec le métier. L’avantage de cette relation est qu’une MOA est intégrée dans le projet et qu’elle se rendra disponible pour répondre aux besoins du projet. Le problème est que la MOA n’est pas forcément au courant des enjeux du métier, selon l’organisation mise en place entre la DSI et le métier.
Une fois que les exigences métiers sont identifiées et le référentiel mis à jour, nous pouvons passer aux exigences liées au système d’information.
Phase C : L’architecture du système informatique car même l’IT a ses propres exigences…
Les exigences du système d’informations se découpent en 2 catégories. Celles qui s’appliquent à l’intégralité du système d’information et celles qui s’appliquent au projet.
Les exigences qui s’appliquent à tout le SI sont souvent les plus faciles à appréhender pour les architectes : ce sont les exigences d’architecture que nous connaissons tous comme :
Un identifiant doit être unique et non interprétable.
Une fonction ne peut pas être implémentée plusieurs fois dans le SI…
La séparation des fonctions de production et de distribution,
Celles liées aux échanges (API, couche d’échange…),
Sur les sources de données (le terme de « Golden Source » est souvent utilisé),
Ou les réglementations comme sur la protection des données (Règlement Général sur la Protection des Données, ….).
Puis viennent toutes les exigences spécifiques au projet en lui-même comme celles liées à la confidentialité, l’intégrité, la disponibilité ou l’authentification / identification. La mise à niveau des exigences précédemment édictées par le métier est souvent négligée. Quand cette mise à niveau n’est pas faite (peu importe le formalisme), cela révèle souvent un manque de dialogue entre les équipes projet métier et IT. Cet effort est nécessaire car une partie de la valeur de l’architecte est justement de créer un pont entre ces deux mondes.
Phase D : Architecture technique
Dans les DSI importantes, des architectes dédiés ont généralement la charge de la partie technique. En effet, un architecte ne peut pas avoir le même niveau d’expertise sur toutes les couches du système d’information et la frontière se trouve historiquement à ce niveau. Dans les DSI plus petites, la césure entre les architectes techniques et les architectes fonctionnels est moins importante mais elle existe souvent malgré tout.
L’architecte technique doit avoir une bonne connaissance du catalogue des normes et standards de l’entreprise. Savoir quels sont les composants (technologies, logiciels…) à utiliser, où en est leur cycle de vie et les mettre en regard du projet. L’architecte se confronte également à la stratégie de la DSI et à sa politique fournisseurs notamment (quand elle existe).
Dans le cas de solutions hébergées en interne, l’architecte technique doit définir les exigences techniques qui permettent de dimensionner correctement l’infrastructure. Dans le cas de solutions Cloud ou d’application en SAAS, les exigences liées aux infrastructures n’ont plus de raison d’être, elles doivent être définies en termes de SLA (plus besoin de calculer le nombre de serveurs, car l’hébergeur est garant du dimensionnement). Dans ce dernier cas, s’occuper des interfaces est plus que nécessaire.
A la fin de cette phase, le référentiel d’architecture doit s’enrichir en précisant les composants à utiliser pour atteindre la cible désirée et la feuille de route provisoire avec les recommandations de mises en œuvre.
Conclusion
A ce niveau d’avancement, nous avons pu collecter et finaliser l’ensemble des exigences du projet. Nous avons également une vue assez claire d’où nous partons et où nous voulons aller, sauf que nous sommes encore dans un monde « sans contrainte ». Nous savons ce que nous voulons (ou ne voulons pas) mais il faut à présent se confronter au monde réel, fait de contraintes de planning, de budget, de disponibilités des ressources et donc sortir de cette tour d’ivoire où se sont parfois enfermés d’autres architectes avant vous. Les négociations et les arbitrages commencent et la valeur tangible apportées aux projets se mesure ici, comme nous le verrons dans le troisième et dernier article de cette série sur TOGAF In Real Life.
Je découvre un article du 2 Juillet 2019 dans le journal le Parisien, un court article intitulé « L’architecte doit établir un budget juste ». Je n’ai pas pu m’empêcher d’établir le parallèle avec notre métier d’architectes d’entreprise.
« Si vous faites appel à un architecte pour une rénovation immobilière, il est tenu d’établir une prévision exacte du coût de l’opération. C’est ce que vient de déclarer la Cour de cassation dans une affaire où un architecte avait sous-évalué le projet. Il a « failli à son devoir de conseil », ont expliqué les juges. Précédemment, la cour d’appel avait déclaré qu’un dépassement « de l’ordre de 10 % » était admissible. Mais en l’espèce, l’architecte avait fixé un budget de rénovation inférieur de 15 à 25 % au coût habituel, « standard », c’est-à-dire qu’il avait prévu un coût de moins de 900 € par mètre carré au lieu du ratio standard qui est de 1?000 à 1?100 €.
De plus, cette estimation ne comprenait pas les finitions. Résultat : le coût total avait quasiment doublé le coût estimé. La justice a au contraire souligné la responsabilité de ce professionnel qui aurait dû se renseigner sur les souhaits et possibilités financières de ses clients pour faire une évaluation exacte.
Il a été condamné à prendre en charge le dépassement, à titre de dommages-intérêts pour ses clients. »
Stick to standards
Premier reproche à l’architecte : ne pas avoir respecté les standards connus d’évaluation de son métier. Dans les métiers de l’informatique, ce n’est pas l’architecte mais le chef de projet qui fait le devis. Et il existe aussi des méthodes d’estimation des projets (points de fonction etc.) qui sont utilisées dans les entreprises. Surtout dans nos métiers, la décision ne se prend jamais seul, les évaluations sont souvent challengées par plusieurs personnes pour arriver à des devis proches de la réalité. Et dans le doute, on se raccroche à des projets déjà réalisés ou des métriques connues. Doit on afficher ou faire connaitre les standards de nos métiers ?
Comply or explain
2ème reproche : si l’architecte s’écarte des standards il a le devoir de justifier cet écart. Un des principes de construction de l’IT est « comply or explain ». Si vous n’êtes pas conformes, vous allez devoir expliquer pourquoi. Ce n’est pas interdit de sortir du cadre fixé, mais il faut alors le justifier, ce qui a manqué à l’architecte mis en cause dans l’article. Le fait de travailler à plusieurs force les échanges et donc les explications.
Quel périmètre pour évaluer le projet ?
3ème reproche : il avait oublié les finitions dans son évaluation. Ne pas bien évaluer le périmètre et ne pas l’expliciter fait bien partie des missions de l’architecte envers ses clients. L’architecte fait les plans de la transformation et doit donc bien expliquer son devis et ce qui est compris dedans ou pas. Dans nos métiers et projets, il s’agit de se mettre d’accord sur la reprise des données, la mise à jour des interfaces etc. Un credo : toujours expliquer ce qui va être fait mais aussi ce qui ne sera pas fait.
Le budget du client
Dans l’explication de la condamnation, le jugement précise que l’architecte aurait dû se renseigner sur les souhaits et possibilités financières de ces clients pour établir une évaluation exacte. Effectivement, c’est un créneau essentiel dans nos métiers. On peut rêver mais « nous avons toujours plus d’idées que de budget ou de capacité à faire ». Bien expliquer où doivent se concentrer les investissements et pourquoi. Quelle valeur va être retirée des investissements prévus.
Conclusion
Le jugement ne fait que reprendre des arguments qui relèvent du bon sens :
Justifier ses décisions et donc ses devis
Bien valider avec le client ses attentes et ses possibilités financières
Respecter les standards du métier ou expliquer les écarts
Bien décrire le périmètre du devis
Ne jamais être seul en charge des évaluations, toujours avoir quelqu’un avec qui partager / échanger
Gageons que ce rappel des bonnes pratiques ne concerne qu’une minorité de professionnels.
Il fut un temps où, pour être un bon architecte d’entreprise, il suffisait de maîtriser la modélisation (BPMN, UML, Archimate…), les activités d’architecture (TOGAF, Club Urba-EA notamment), les 4 couches (les processus, le POS, etc.), et bien sûr une bonne vision des technologies.
Un article à ce sujet, de CIO, m’a interpelé récemment. Sur les 12 certifications présentées pour un architecte d’entreprise : 5 sont orientées infrastructures et cloud, 3 sur la méthode, une sur le réseau, une sur l’open source, une sur la sécurité et la dernière sur Salesforce.
Rien, pas un mot, sur la posture de l’architecte ?
Notre contexte a évolué
Or, l’architecte évolue désormais dans un écosystème différent : plus mouvant, plus incertain et plus collaboratif. Si l’environnement de l’architecte évolue, son spectre de compétences aussi. C’est devenu une combinaison à la fois de savoir-faire techniques (voir plus haut) et des savoir-être spécifiques à ces nouvelles manières d’organiser le travail : production en cycle court, décloisonnement des métiers, bref : l’architecte TOGAF se doit aussi d’être un architecte agile. Et parce que les certifications peuvent être utiles comme gage de confiance envers votre employeur ou vos équipes, je vous propose un tour d’horizon des 6 formations devenues indispensables selon moi, pour notre métier d’architecte.
1 : Poser les bases de l’agilité – scrum master ou product owner
L’architecte d’entreprise doit impérativement connaître les bases de fonctionnement des projets Agile (les cérémonies et les daily meetings, back-log, MVP, planification, etc.). Une formation Scrum Master ou Product Owner permet de se familiariser avec les essentiels. Une petite expérience pratique dans l’un ou l’autre ne nuirait pas !
2 : Appréhender l’agilité à l’échelle – safe
Pour passer à une dimension supérieure, il faut alors s’intéresser aux cadres d’agilité à l’échelle. LeSS, DA, Scrum of Scrum sont des bons cadres. Connaître les avantages des uns et des autres permettra d’en discuter en connaissance de cause.
SAFe est le cadre qui intéresse le plus les entreprises en ce moment.
Discuter des avantages et inconvénients de ce cadre est intéressant ; en attendant il est devenu un incontournable. Une certification serait alors utile (en tant que responsable d’une équipe de consultants, je pense que nos clients vont nous le demander de plus en plus).
3 : Adopter une posture agile – management 3.0
Connaître des cadres d’agilité à l’échelle ne fait pas de nous des agilistes. Il faut comprendre la posture agile et ce qui va avec. Une formation de type Management 3.0 est un bon exemple pour comprendre les vrais fondements de l’agilité et de l’auto-organisation.
Les principes du management 3.0 sont basés sur : faire les choses justes de la bonne manière. Quelques principes que l’on peut citer : manager le système plutôt que les individus, prendre en compte les inter-actions sociales dans les relations de travail et simplifier les règles de collaboration entre individus.
Cette formation, comme son nom ne l’indique pas, s’adresse à tous, manager ou non.
4 : Savoir animer des ateliers – design thinking et lean start-up
Avec l’avènement de l’agile et aussi du digital, de nombreux types d’ateliers pour inventer / construire des solutions et des plannings, travailler l’intelligence collective, bâtir des équipes, etc. sont maintenant disponibles.
Avec un collègue coach agile, j’avais recensé plus de 40 ateliers ! Il est important pour un architecte d’entreprise, qui est amené à dialoguer avec nombre de personnes différentes dans l’entreprise, de maîtriser la pratique de ces ateliers pour les mettre en œuvre quand le besoin s’en fait sentir. Le Design Thinking et le Lean Start-up sont des essentiels de nos jours, mais les autres méritent de s’y intéresser.
Vous verrez même qu’à force, vous pourrez aussi créer / inventer vos propres jeux et animations !
5 : Savoir jouer / construire la solution – lego
Savoir présenter une synthèse des travaux, réconcilier plusieurs points de vue (merci TOGAF de nous avoir rappelé ce bon principe), construire les solutions les plus simples possibles, sont dans les fondamentaux de l’architecture. Au-delà d’une formation à la « facilitation graphique », nous pouvons même aller vers les bases du scripting et de la présentation de vidéos pour « vendre » nos solutions.
Dans les nouvelles techniques de construction de solutions, notons le Lego Serious Play qui prend une certaine importance et peut s’avérer très utile pour faire parler et converger différentes populations.
6 : Devenir un coach – process communication
Dans son/ses (nouveau(x)) rôle(s), l’Architecte d’Entreprise aura sûrement besoin d’être coaché pour l’aider dans son changement de posture et trouver sa place dans les nouvelles organisations. Mais il peut lui aussi profiter des techniques de coaching pour aider des projets, des équipes, des chefs de projet ou tout simplement des collègues architectes !
La process communication, mais aussi la PNL, sont des voies intéressantes à maîtriser.
Pour les architectes, les équipes en agilité (Product Owner, Scrum Master, membres) et aussi pour les parties prenantes. Une vue d’ensemble de l’agilité (de SCRUM à l’entreprise, en passant par les cadres d’agilité à l’échelle), une vue d’ensemble des travaux de l’architecture (selon différents référentiels), des exemples concrets de mises en œuvre et surtout un jeu participatif pour découvrir les interactions entre les architectes et les projets agiles (à une certaine échelle) font de cette formation une synthèse de l’évolution de l’architecture et des projets agile. Au-delà de la technique nous évoquons aussi les soft-skills nécessaires.
Conclusion
Voilà mes idées de méthodes et certifications d’animation, de facilitation et de co-construction pour faire évoluer notre métier complexe vers les enjeux d’aujourd’hui.
Avec l’arrivée récente de différentes réglementations impactant les données (RGPD, Bâle III, Bâle IV, BCBS 239), il est devenu primordial de connaître son patrimoine de données afin de pouvoir identifier et appliquer les bonnes politiques de gouvernance de la donnée (qualité, sécurité, accessibilité). Il faut que les entreprises voient cette contrainte comme une opportunité qui leur permettra à terme de faciliter leurs différents projets de transformation et de mieux valoriser leurs données.
Quel Data Scientist ou Responsable de Traitementmétier ne s’est pas interrogé sur la source d’une donnée à utiliser pour son cas d’usage ? Comment connaître son origine et son cycle de vie et s’assurer de sa qualité ? Comment savoir, au sein d’une entreprise, qui est le Data Owner sur une donnée en particulier ? Ou trouver le glossaire des termes métier associés à cette donnée ? Comment montrer à un RSSI, un DPO ou un Régulateur que les mesures de sécurité liées à une réglementation ont été associées à une donnée et mises en œuvre ?
C’est là où une solution de Data Catalog (ou catalogue de données) devient essentielle et peut vous aider à répondre à ces différentes questions. Celui-ci deviendra la base d’information centrale, un peu comme une bibliothèque, qui vous permettra de rechercher, trouver et connaître les bonnes sources de données pour vos cas d’usages Big Data ou vos traitements métiers. Ceci permet de regrouper les données au sein d’un même référentiel, de collecter, d’enrichir et de partager toutes les métadonnées associées.
Figure 1 – Exemple de métadonnées
Mais comment faire pour s’y retrouver ? Les différentes offres du marché se vantent toutes de pouvoir gérer et maîtriser votre patrimoine de données, générant, ainsi, de la valeur. Il faudra d’abord définir le périmètre de la gouvernance de données à mettre en œuvre et recueillir les exigences fonctionnelles et techniques. Ce qui suit vous aidera ensuite à comprendre ce que pourra couvrir une solution « Data Catalog ».
La fonctionnalité de base est déjà de pouvoir récupérer automatiquement les métadonnées techniques, c’est-à-dire les informations décrivant vos données d’un point de vue infrastructure (fichier, base de données, table, colonne, etc). Les éléments différenciant pour le choix de la solution vont dépendre de votre écosystème et des connecteurs nécessaires. Est-ce que vos données sont structurées, non structurées ou sont-elles sous format document ? Est-ce que vos données sont contenues dans des bases de données SQL ou noSQL ? Quel socle technologique Big Data utilisez-vous ? Avez-vous des données dans des Cloud Public ? Comment transporter ou partager vos données ? Via des traitements spécifiques, un ETL, un ESB ou via une API Gateway ?
Ces métadonnées décrivant vos données techniques comme un dictionnaire devraient être reliées à une donnée logique et une donnée métier qui sera elle-même à l’aide d’un glossaire métier.
Figure 2 – Architecture de Donnée
Un cadre de gouvernance des données avec une organisation, des acteurs, des processus et des livrables documentaires doit aussi pouvoir être décrit et déployé via un métamodèle opérationnel .
Ce métamodèle implémenté dans l’outil devra permettre de gérer des rôles et des organisations afin de pouvoir définir des responsabilités pour appliquer cette gouvernance de données. Celle-ci ne pouvant être mise en œuvre que si la donnée a d’abord été classifiée et que des politiques de gouvernance liées à un référentiel d’entreprise ou demandé par un Régulateur ont été identifiées et reliées à cette donnée métier. Tout ceci n’étant possible que si l’outil permet de gérer un modèle opérationnel de gouvernance des données personnalisables.
Parmi les autres fonctionnalités attendues pour cet outil il y a également la capacité de générer des états de Data Lineage.
Figure 3 – Exemple de Data Lineage
Cette fonctionnalité est majeure et permettra de traduire visuellement la vision 360° de vos données. Ceci vous habilitera par exemple à réaliser des analyses d’impact en cas de changement sur un système aval vous fournissant la donnée. Ces états peuvent vous aider également à analyser l’écart entre deux KPIs ou de répondre à une exigence réglementaire demandant de documenter de bout en bout comment tel indicateur aura été généré. L’outil vous permettra aussi d’avoir une vision sur la qualité de ces données via par exemple du data profiling ou des indicateurs. Ceci permettra de faire gagner du temps à vos Data Scientist pour sélectionner l’algorithme le plus approprié ou motivera votre Data Steward à sélectionner le jeu de données le plus approprié pour votre cas d’usage ou traitement métier.
Figure 4 – Exemple de Data profiling
Enfin pour terminer, cet outil devra être accessible via une application web, fournir un moteur de recherche et proposer un référentiel de cas d’usages avec les sources de données associés. Ceci activera le partage de la connaissance de ce patrimoine au travers de votre organisation et l’identification des sources de données critiques à vos traitements métiers. A terme, ce patrimoine permettra plus facilement aux métiers de générer de la valeur pour votre entreprise tout en maitrisant les règles de sécurité et accessibilité de cette donnée.
Voilà pourquoi le Data Management ne peut plus se faire via un tableau Excel et qu’un catalogue de donnée devient essentiel.
Ma série d’articles sur l’Architecture et l’agilité en arrive à son 5ème chapitre. J’ai fait beaucoup de recherches, échangé avec des agilistes et des confrères Architectes. Mais avais-je vraiment pris le temps d’intégrer l’agilité dans mon mode de fonctionnement ? Pris le temps d’en discuter et d’y travailler avec mes équipes ? Et qu’a fait notre cabinet de conseil pendant ce temps-là ? Voici mon retour (d’expérience) sur ce qui s’est passé dans mon écosystème dernièrement.
Avoir dans notre cabinet une équipe dédiée à la Transformation Agile est vraiment un atout dont je n’avais pas encore mesuré toute la portée. L’évolution se fait doucement mais sûrement et en profondeur. Que ce soit par des formations, des conseils ou des exemples, elle se fait sentir à tous les niveaux du cabinet. Nous sommes en train de trouver notre voie et c’est bien là le secret !
Former les managers
En tant que consultant d’abord puis manager, je suis des formations régulièrement. Depuis plus de 15 ans ces formations portent sur mon expertise, l’Architecture, mais aussi sur le métier de consultant et de manager d’équipe.
Notre équipe de Transformation Agile propose une formation au Management 3.0. Comment refuser une telle opportunité ? Prendre 2 jours de réflexion sur ma pratique de management qui n’avait pas évolué depuis quelques années. Avoir les bonnes pratiques et de nouvelles techniques autour du management à intégrer dans mon fonctionnement et celui de mon équipe.
Je pensais bien que le changement était en marche, mais là, j’ai vraiment réalisé le retard que j’avais pris. Nous sommes donc en train de changer notre fonctionnement interne, nos modes de réunions, de travail etc. L’équipe en parlera surement plus en détail dans un prochain article.
Je ressemble à ça maintenant, j’ai bien changé, non ?
La formation pour tous, mais laquelle ?
En parallèle, la réflexion m’avait mené aussi sur la formation des consultants vers l’agilité et les changements que cela implique. Quelle formation ? Pour quel but ? Pour commencer, 2 formations fondamentales tiennent la corde. Elles correspondent aux 2 rôles principaux des projets agiles aujourd’hui : le Scrum Master et le Product Owner.
Les 2 formations sont pour partie les mêmes. Les bases de l’agilité y sont présentées. La suite diffère selon le rôle que l’on est amené à jouer. Est-ce que vous allez travailler en tant que responsable du produit ou en tant qu’animateur du projet ?
Le Product Owner se focalise sur la valeur, les finances, la stratégie, et est connecté avec les différents intervenants et clients autour du projet.
Le Scrum Master est un facilitateur de l’atteinte des résultats, un leader non autoritaire qui connecte les gens et les aide à tirer le meilleur d’eux-mêmes dans la constitution de l’équipe. Il est là pour catalyser les résultats.
Pour le métier d’Architecte, les 2 aspects semblent importants. Dans ce cas, pourquoi choisir ?
Nous avons alors pris le parti de former certains architectes en Scrum Master et d’autres en Product Owner. L’avenir nous dira si nous devons compléter par la suite la formation des uns ou des autres.
L’essentiel est de se lancer.
Nous ferons au fur et à mesure des projets et des missions, les constats et les retours d’expérience des uns et des autres sur l’utilité et la spécificité de chacune des formations (par exemple, sous le format des rétrospectives présentées dans SCRUM !)
La détection des faux positifs
Maintenant que nous sommes formés à l’agilité, que nous en connaissons les principes, le 1er changement qui nous vient à l’esprit est de détecter tous les projets qui se prétendent Agile (le terme étant très galvaudé en ce moment) et qui ne le sont pas. Et surtout de pouvoir dire en quoi ils ne sont pas agiles.
Un projet qui conserve un découpage de ses travaux en lots. Un projet sans autonomie. Autant de projets avec lesquels nous travaillons, qui se prétendent agiles, voire sont convaincus de l’être.
Nombreux sont les exemples que nous voyons dans les entreprises au quotidien.
Un des principaux défauts, que j’avais souligné dans un article précédent, est qu’il est très difficile pour un projet d’être vraiment Agile si les managers ne le sont pas et ne font pas évoluer leur posture.
Même s’il est toujours aussi difficile de travailler avec ces projets, au moins nous pouvons échanger avec eux, les aider aussi et peut être trouver des axes d’amélioration ?
Et au niveau du cabinet, le LAB !
En parallèle, notre cabinet a initié une pratique de Lab : dispositif de créativité, de co-construction et d’intelligence collective aussi bien orienté vers l’interne que vers l’externe. Les initiatives sont venues, les projets ont commencé, les premiers résultats arrivent. La dynamique est en place et le mode de fonctionnement se rode.
Il y aura des réussites, des échecs, mais surtout plein de belles histoires.
Mais le plus important dans tout ça, ce n’est pas le Lab, c’est bien le symbole. Dans notre cabinet, comment trouver une place dédiée pour le Lab où nous puissions travailler avec les bons outils ? Le seul endroit qui s’y prêtait était déjà occupé. Et pas par n’importe qui, pensez donc : le président et ses 2 DG Adjoints. Ce sont eux-mêmes qui ont proposé de laisser leur bureau pour le Lab.
Si ça, ce n’est pas un changement visible !
Fini la V1, vive le MVP !
Dans l’ancien mode de fonctionnement d’un projet, nous annoncions toujours la mise à disposition d’une V1, complète et exhaustive. Elle prenait du temps et consommait des ressources. Pour un résultat rarement satisfaisant.
Avec l’agilité, nous faisons des MVP (Minimum Viable Product). Un produit suffisamment complet du 1er coup pour qu’un client y trouve de l’intérêt (juste les bonnes fonctionnalités). Pas avec toutes les fonctionnalités bien sûr mais plus qu’une V1 bancale. Une approche qui oblige à se focaliser sur l’essentiel.
Nous essayons de démocratiser cette approche pour tous nos projets, y compris pour nos projets en interne.
Et cela fonctionne mieux. Les MVP sont mieux acceptés, consomment moins de ressource, apportent plus de retours d’expérience.
Est-ce que ça change vraiment ?
Oui ça change. Surtout la perspective avec laquelle on aborde les sujets.
La mise en pratique se fait avec un plus grand partage de toutes les informations. La transparence est primordiale.
Les échecs sont permis. On apprend à marcher en tombant. Il faut essayer. Les nouveaux modes de fonctionnement ne marchent pas du 1er coup ? Quoi de plus normal. Apprendre de nos erreurs et continuer à avancer.
La confiance était déjà de mise dans notre cabinet mais le management agile va encore plus loin.
Ne plus imposer mais fournir les informations pour que chaque niveau puisse décider de son mode de fonctionnement, de ses actions et de ses buts.
Rome ne s’est pas faite un jour, mais les changements sont visibles et je pense maintenant que personne ne pourrai / ne voudrai retourner en arrière.
Aller très loin ou aller trop loin ?
Dans la formation Management 3.0 certains aspects bouleversent complètement nos modes de fonctionnement. « Ne pas promettre de récompense », « Récompenser des comportements pas des résultats » sont des exemples de préconisations de cette formation. Ces règles visent à valoriser le collectif plutôt que l’individu / l’individualisme.
Quel changement quand on est habitué à avoir des objectifs fixés en début d’année et d’être jugé, et récompensé, sur la base de l’atteinte ou non de ces résultats.
Imaginer des commerciaux qui ne soient plus récompensés sur l’atteinte de leurs résultats mais sur leur comportement ! Impensable de nos jours dans la plupart des entreprises. Et pourtant, on sent bien la justesse des arguments de ces nouvelles techniques de récompense.
Certaines habitudes auront la vie plus dure que d’autres, et le trajet sera d’autant plus long.
Conclusion
C’est une révolte, sire ? Non, juste une belle évolution ! En faire moins (exit les V1 fastidieuses) mais mieux (les MVP).
Le principal est que cela soit le fait d’une volonté commune et que les dirigeants (un fort niveau de sponsoring est indispensable) comme les collaborateurs y adhèrent. Nous avons tous à y gagner et à grandir dans ces nouveaux modes de fonctionnement.
Nous avons les techniques, des formations sont à disposition et des vidéos pour nous guider.
A nous de jouer !
Chapitre(s) suivant(s) ?
Je ne vais plus annoncer de suite, car cela évolue / change tellement vite ! Mais ne vous inquiétez pas, vous ne serez pas déçus.
