Un programme de transformation a été engagé afin mettre en place une nouvelle Banque en ligne. Cette nouvelle banque doit mettre en place des pratiques d’Architecture d’Entreprise afin de maitriser la mise en place de son nouveau SI et de ses futures évolutions
Solution
Assister le nouveau responsable de l’Architecture d’Entreprise dans sa prise de fonction:
Cadrer la désimbrication des SI historiques avec les nouveaux SI
Mettre en place les processus de l’Architecture d’Entreprise
Définit le rôle vis-à-vis des projets
Mettre en place le Comité d’Architecture d’Entreprise
Définir la capitalisation /modélisation nécessaire du SI
Mettre en place les outils de modélisation et de gestion de la documentation (MEGA, PowerDesigner, Confluence)
Construire les vues d’ensemble nécessaire à la maitrise de la trajectoire de la transformation du SI (Plan d’occupation des sols, Vue d’ensemble du SI et paliers, liste des applications et flux etc.)
Construire la vue des données dans le SI (Objets Métiers, SID etc.)
Bénéfices
Mise en place du Comité d’Architecture d’Entreprise pour partager les trajectoires et les décisions
Mise en place de la capitalisation pour le partage de la connaissance au sein de la banque
Mise en place des outils de capitalisation et formation des futurs utilisateurs
Les autres success stories qui peuvent vous intéresser
Celui, ou celle, que l’on appelait avant Architecte Fonctionnel et que l’on appelle à présent Architecte d’Entreprise (AE), a vu son domaine d’intervention être siloté avec une approche qui a privilégié les processus souvent au détriment des données.
La notion d’Architecte Data a donc vu le jour sur le marché, ou même Data Architect pour lui donner une aura internationale. A la manière des architectes SI ou techniques qui sont complémentaires aux AE, Est-ce la cas pour l’Architecte Data ? L’est-il ou fait-il exactement la même chose que l’AE sur les données ?
Mais pourquoi tout le monde veut ma place ?
De mon point de vue, l’architecte d’entreprise subit les conséquences d’une posture qui a fini par lui porter préjudice. Le fameux « architecte dans sa tour qui ne comprend pas les contraintes des gens qui font vraiment de l’informatique », réputation contre laquelle nous luttons tous les jours mais qui, nous devons bien nous l’avouer, existe encore parfois.
Un autre problème est lié au vocabulaire que nous utilisons. Un but de notre métier consiste à savoir si tel ou tel développement doit être fait dans telle ou telle application, et pour cela nous travaillons avec les fonctions. Alors une fonction, tout le monde pense savoir de quoi il s’agit mais ce n’est souvent pas le cas, et cela est moins parlant qu’une « Donnée ». De plus, les justifications pour regrouper des fonctions sont floues : cohérents, logiques,… sont des mots à bannir de notre vocabulaire.
Pour commencer : qu’est-ce qu’une fonction ?
Si on demande à Larousse, la définition d’une fonction est la suivante : « Ensemble d’instructions constituant un sous-programme identifié par un nom, qui se trouve implanté en mémoire morte ou dans un programme ». Personnellement, j’en ai une autre : une fonction est une instruction visant à modifier une caractéristique d’un objet.
La raison pour laquelle je préfère ma définition est que le mot objet permet de faire le lien avec un des éléments qui permettent de construire l’architecture fonctionnelle de votre SI.
Comment construisez-vous votre plan fonctionnel ?
Lorsque notre ami architecte d’entreprise définit un plan d’urbanisme fonctionnelde son système d’information, c’est qu’il veut mettre en évidence les fonctions nécessaires aux métiers. Mais quels sont les critères de regroupement ?
Le principal critère de regroupement, c’est la donnée. Pour bien comprendre, prenons l’exemple de l’objet, et donc de la donnée, « Personne » dans le cadre simplifié d’un site de distribution. Toutes les fonctions de l’objet « Personne » sont donc rangées dans le bloc Personne. Prenons ensuite les fonctions rangées dans le quartier Adresse. Ce sont des fonctions qui sont appelées, et donc des données qui sont modifiées, dans un même cas d’usage. Quand une personne déménage, les données liées aux fonctions dans le quartier Adresse sont modifiées. Enfin dans un ilot, vous allez retrouver toutes les fonctions qui peuvent modifier une information particulière : Modifier la rue, modifier le numéro, modifier la ville.
Cet exemple est concentré sur l’objet « Personne » mais cela est vrai pour la globalité de l’entreprise. Le modèle de donnée de l’entreprise est donc nécessaire pour construire un plan fonctionnel global de l’entreprise.
Mais comment parler avec les projets ?
Il faut arrêter de parler de fonctions avec vos projets, ne dites pas « quelles sont les fonctions que vous voulez ajouter » mais « quelles sont les données que vous allez impacter ». Charge à l’architecte d’identifier ensuite les fonctions. Il faut parler le même langage que lui, lui faire comprendre la valeur qu’on lui apporte et ce sera gagné.
L’Architecte Data est un architecte comme les autres. C’est son approche par les données qui met en avant les problèmes de gouvernance auxquels l’architecte fonctionnel était déjà confronté auparavant, alors « Reprenons notre dû, reprenons les data ! »
Dessiner une cible, bien sûr, mais à quel horizon ? Sous quel angle ?
Sur ces sujets, nous devons différencier plusieurs points de vue.
Formaliser la cible à long terme : l’idéal
Récemment, nous avons animé pour un client la définition d’une cible à environ 5 ans qui permettait de donner les grandes directions et surtout de mettre en avant ce qui devrait être (ou non) couvert par l’ERP central.
Cette cible a permis de partager une vision d’ensemble des projets d’étude et des grands pans applicatifs qui allaient évoluer. Et donc aussi de définir ceux qui ne feraient pas l’objet d’investissements conséquents dans les prochaines années.
A l’inverse, sur certains pans du SI, cette cible ne pouvait pas être mise en application de suite car elle était parfois trop éloignée de la réalité. Plusieurs étapes peuvent alors être nécessaires pour atteindre cette cible. Ce genre de cible étant vue comme « inatteignable ». Pourtant 5 ans cela peut être court au regard de certains autres investissements lourds (construction d’usines de production, construction d’un data center…) mais au vu de la vitesse exponentielle de l’évolution de l’IT, cela peut paraître très long.
Formaliser la cible à plus court terme : dans quel cas ?
Une cible a 2-3 ans peut à l’inverse paraître très courte car certains projets peuvent mettre du temps à se lancer. Ensuite, le temps d’organiser les équipes, de comprendre le sujet, etc., il peut déjà se passer facilement 1 an ou 2 dans certains cas. Pour un de mes clients, une grande banque, nous avons passé 6 mois à construire une cible macro, définir les principaux besoins, ce qui devait évoluer et les principales briques du systèmes (à acheter ou à développer). Puis au moment de se lancer et vu l’importance des sujets à traiter, il a fallu passer par une étape « politique » qui consistait à décider d’une structure pour ce programme (et à qui elle devait être rattachée) : nommer de nouveaux responsables ; les faire venir de leurs anciens postes ; procéder au recrutement en cascade qui va bien, aussi bien avec des internes et compléter par des consultants (pour des raisons de charge de travail, d’expertise, etc.).
Une cible à plus court terme peut permettre de faire comprendre les premières étapes de la transformation.
Comme dans tous nos travaux nous devons donc trouver le juste équilibre entre le court, moyen et le long terme. Suivant les cas, il n’y a pas une cible à décrire mais plusieurs ! Certains domaines sont à court terme car ils risquent de devoir évoluer rapidement et on parlera davantage de plateformes. Certains autres sujets doivent être pris sur le long terme (ERP) au vu des coûts et des changements qu’ils impliquent.
LA question qui se pose tout le temps dans les cartographies est : faut-il commencer par décrire la cible ou par décrire l’existant ?
2 écoles s’affrontent irrémédiablement (mais finissent toujours pas se réconcilier).
Commençons par la cible justement
Cela peut paraître difficile pour certains de ne pas parler de l’existant et de directement se projeter vers la cible. Ceux qui préfèrent commencer par la cible avancent comme argument qu’il faut pouvoir s’affranchir des contraintes du présent pour inventer une nouvelle cible qui dépasse les clivages et solutions actuelles. Faire du passé table rase !
Cette solution a souvent pour but de mobiliser les gens rapidement en allant vers une cible (les étapes de description de l’existant étant souvent vues comme coûteuses et peu porteuses de valeur).
Dernièrement c’est ce que nous a demandé un client, de commencer de suite par des ateliers sur la cible. Ce qui a effectivement permis de mobiliser les énergies vers un but commun. Une cible qu’ils ont choisi tous ensemble et où tous peuvent se projeter. L’exercice est porteur de sens.
Mais une fois la cible décrite, il faudra pour construire une trajectoire, la passerelle entre aujourd’hui et le futur, décrire l’existant. Même succinctement mais il faut bien se donner les étapes du passage d’un état à l’autre.
Je vous rassure aussi, lors des ateliers de description de la cible, nous parlerons forcément à un moment ou à un autre de l’existant pour le critiquer, le comparer : faut-il vraiment changer cette solution ? pourquoi changer ? avons-nous les moyens de changer ? etc.
Si on commençait par décrire l’existant ?
Nos clients nous disent régulièrement avoir déjà fait des cartographies. Ce fut long, ce fut coûteux et au final peu productif ! Beaucoup d’efforts pour un résultat et une valeur ajoutée non démontrée.
Pour bien faire cette étape, faisons juste ce qu’il faut.
Un des buts de la cartographie de l’existant est d’estimer là où nous allons positionner les futurs investissements. Si un domaine ou des applications sont stables et ne posent pas de problème particulier, la cartographie passe son chemin !
Comme dit au début, sélectionnons rapidement les domaines sur lesquels nous avons besoin d’une visibilité. Toutes les raisons sont bonnes ! Un de nos clients nous disait : nous venons de reprendre cette filiale, je ne connais pas du tout son SI, rien n’a été fait durant la phase d’acquisition !
Connaitre les flux ? C’est une demande récurrente de nos clients qui nous disent avoir perdu la connaissance des flux.
Un client bancaire nous demandait de regarder en premier les flux envoyés à l’extérieur. Un autre client bancaire lui aussi, nous demandait de regarder en premier les flux potentiellement porteurs d’informations sensibles : au final nous ne l’avons pas fait car une certification était passée par là ! Donc le sujet était maîtrisé et la capitalisation attendra.
L’existant permet aussi de faire émerger les problèmes et de définir des cibles qui vont solutionner ces problèmes. Et la mesure de la cible se fera sur le niveau de réponse apportée aux problèmes existants.
Oui il fut un temps (pas si lointain) ou des armées de consultants étaient utilisés pour décrire un existant. De nos jours cette approche n’est pas souhaitable. Se focaliser sur la valeur ajoutée, périmètre par périmètre. Avec le juste niveau de connaissance. Pour identifier les points d’amélioration ou de contrôle. Voilà les directives qui nous guident dans ces étapes.
Le fameux fonds de carte… Plusieurs « écoles » s’affrontent sur ce sujet car plusieurs possibilités existent qui permettent de positionner le SI et ses applications en fonction du message à faire passer
Le socle des processus ?
Il permet aux métiers de comprendre la couverture des applications / des technologies et donc l’importance qu’ils ont dans le SI (et sûrement aussi dans les budgets donc). Mais trop métier, les SI ne le comprennent pas et il n’est pas forcément pertinent pour mettre en avant les enjeux du SI. Ce socle des processus est parfois dur à construire car les processus existent déjà sous diverses formes au sein de l’entreprise (audit interne, procédures ISO 9001, etc.). Cette vision n’est pas partagée par tous et risque de porter de la confusion. L’avantage est que sur les processus on peut faire porter des stratégies et des enjeux métier. Par exemple l’ouverture vers d’autres société, des délais de réalisation ou de réponse…
Une (business) capability map ?
D’après le nom, cela ressemble fort au socle des processus. Oui mais pas forcément. Un de nos clients, grand groupe industriel, nous a récemment demandé de lui en créer une. Nous sommes partis d’un standard de son métier et nous l’avons complété avec ses spécialités. Le résultat a été une vue des grandes « activités » (donc sans chercher la transversalité comme avec les processus) de l’entreprise. Cette vue a été rapidement comprise par tous. Il est possible avec cette vue capacitaire de mettre aussi des ambitions sur des capacités : pouvoir donner une réponse à un crédit en moins de 24h, faire de la pré-acceptation de crédit dès le dossier complété…
Le plan d’urbanisation ou le pos
Toujours classique et efficace dans sa présentation. Parfois d’un niveau très fonctionnel, il nous est souvent demandé : des adaptations pour intégrer les dimensions applicatives et technologiques notamment. Suivant le niveau de détail, il peut vraiment servir à présenter le SI. Malheureusement il est maintenant surtout utilisé uniquement pour positionner les applications comme dans des boites et ne permet pas de « raconter une histoire » dans le SI. Il ne montre pas les échanges ni en interne ni avec l’extérieur. Cela limite son utilisation pour « raconter des histoires » et donner des ambitions.
Une vue des grands « domaines applicatifs »
Souvent basés sur un découpage organisationnel du SI donc en regard des responsabilités. Ce découpage peut être problématique. Quand il est bien fait, plusieurs clients ont apprécié cette présentation qui leur permet alors de montrer les échanges avec l’extérieur et entre les grands domaines puis de zoomer au fur et à mesure dans le détail de chaque domaine applicatif
Pour décrire le SI, nul doute que la vue des grands domaines applicatifs et des grands flux est un point d’entrée indispensable pour expliquer le SI et son fonctionnement. C’est souvent cette description qui manque.
Les autres vues peuvent être produites à moindre coût et son souvent la promesse des outils d’architecture d’entreprise orientés « data ».
Un fait est certain : les conflits font partie de la vie aussi bien parentale que celle de l’entreprise. Les relations évoluent et passent par différentes étapes. On a beau tout faire pour l’éviter, une crise survient inévitablement. Y a-t-il des signes annonciateurs ? Comment réagir quand certains projets ne veulent pas suivre les recommandations ? Comment faire si l’architecte fait preuve d’autoritarisme ? Comment gérer l’équilibre entre faire ses propres expériences et ne pas se mettre (trop) en danger ? Nous retrouvons à nouveau notre parallèle avec l’éducation parentale qui nous préoccupe tant.
De solution miracle, il n’est pas question ! Nous allons en revanche aborder différentes phases familières et voir ce qu’en dit la littérature et les spécialistes.
Mais qui est ce « Nous » ?
Chloé, architecte d’entreprise, interne d’une grande société qui se demande si son travail est un bullshit job (merci David Graeber). Elle est également jeune maman.
Olivier, architecte d’entreprise senior, consultant et ami de Chloé. Papa (divorcé/recomposé) de grands enfants.
Notes
Le discours s’appuie sur des raccourcis pour en faciliter la compréhension. Bien entendu, dans la réalité, aussi bien personnelle que professionnelle, c’est souvent plus complexe.
Toute ressemblance avec des projets ou des enfants existants ne serait bien entendu que fortuit.
Vous allez sûrement vous retrouver dans les lignes ci-dessous. N’hésitez pas à réagir et à nous faire parvenir vos commentaires, autant sur la forme que le fond, que nous fassions tourner la roue de l’amélioration continue ! Allez, fin du suspense, c’est parti.
En temps de crise, le sage construit des ponts, le fou construit des murs.
Introduction
Chaque crise a une raison spécifique et demande une solution adaptée. Ce que nous allons voir de nouveau dans ce chapitre, ce sont les crises qui débordent, les grandes crises, celles qui demandent un repositionnement du rôle du parent / de l’architecte.
En nous promenant le long de la vie d’une personne de 0 à 100 ans, nous trouverons des parallèles à notre vie en entreprise. Est-ce que ces réflexions vont nous conforter sur l’idée qu’un cadre est indispensable comme nous le préconisons dans le premier chapitre (L’Architecte est un parent comme les autres) ? Est-ce que la vie d’un architecte est toujours aussi simple (noter l’ironie) que celle d’un parent ?
Le rejet de l’autorité à 2 ans
Chloé : Je n’en peux plus ! J’écume toute la littérature sur la gestion de crise en ce moment. A 2 ans, c’est la mini adolescence ou « terrible two » comme on dit chez les spécialistes de la petite enfance. Je te partage ce que j’ai appris ?
Que se passe-t-il dans la vie d’un enfant pour que soudainement, vers 2 ans, l’enfant docile se rebelle ainsi ? Cette bascule surprend d’autant plus le parent que tout est paisible avant. Le premier refus interpelle donc. La raison est assez simple : l’enfant a besoin de s’affirmer. Il veut pouvoir décider. Voilà une des sources de crise : avoir besoin de plus de latitude. Il paraîtrait que c’est normal et même sain. Tu vois où je veux en venir ?
Olivier : Effectivement, je me rends compte d’avoir déjà vécu cette situation en entreprise. Il arrive qu’une personne ou une équipe réclame plus de liberté et rejette les préconisations d’architecture (et non l’architecte !). Alors que fais-tu pour y remédier ?
L’enfant comprend par la répétition les temps forts d’une journée et le rôle des personnes qui l’entourent. Le cadre, à ce moment-là, est strict et les choix sont faits à sa place. Afin de montrer à l’enfant que nous lui faisons plus confiance, car plus mature, la solution est de lui proposer plusieurs choix afin qu’il puisse exprimer sa volonté propre. Et ça fonctionne !
« Veux-tu mettre ce vêtement-ci ou plutôt celui-là, sachant qu’il fait très froid aujourd’hui ? » « Veux-tu créer une API pour ton application ou préfères-tu déverser tes données dans le Datalake, avec tes connaissances maintenant bien ancrées ? ». Le cadre est toujours là (cf Chapitre 1), en revanche les choix possibles pour rester dans ce cadre augmentent. On conseille aussi de faire des câlins, c’est là que le rapprochement avec les collègues s’arrêtent ?
Olivier : Bravo avec ton enfant ! Il est vrai que l’architecte peut adapter son discours face aux équipes et selon la maturité, proposer plus d’options. Au risque de te déprimer, des crises, il va y en avoir beaucoup d’autres, ne serait-ce que l’adolescence. Au secours !
La maladie de l’adolescence est de ne pas savoir ce que l’on veut et de le vouloir cependant à tout prix.
Philippe Sollers
La crise de l’adolescence n’est pas une crise
Chloé : Cette période m’intéresse beaucoup. Mon entreprise en ce moment vit la plus grande transformation possible dans la vie d’une entreprise. Nous redéfinissons les rôles de chacun, la gouvernance, les méthodes et la façon de travailler, nos objectifs, nos relations à nos clients, TOUT, te dis-je !
L’adolescence, c’est exactement cela : une transformation totale. Chacun doit retrouver sa place dans le foyer et se créer de nouveaux repères. La difficulté est d’autant plus grande qu’elle est humaine : remise en cause, doute, perte de confiance envers soi et envers les dirigeants.
Le parent qui savait presque tout ne sait presque plus rien : « c’est toi qui sais ce que tu voudrais faire plus tard, toi qui sais qui tu aimes ou n’aimes pas, … ». C’est effrayant. Je vois les mêmes questionnements actuellement autour de moi. Les managers ne sont plus managers, ils deviennent des (servant) leaders. Les équipes sont responsabilisées : « c’est vous les experts qui prenez vos décisions en autonomie ». Encore plus effrayant.
Alors quelle est la place du parent ou de l’architecte dans cet ouragan ? Comment accompagner ces transformations ? Le risque est grand. Si nous supprimons le cadre (plus aucune règle, plus aucun interdit), nous exposons la famille / l’entreprise à de très grands risques. Si nous restons ancrés sur le cadre historique, alors nous n’avons pas su évoluer avec lui. Comment apporter alors des réponses attendues que nous n’avons pas ?
Un des maîtres-mots de notre transformation est « ensemble ». Si je n’ai pas la réponse et que toi non plus, peut-être qu’à plusieurs, nous allons la trouver. Travailler ensemble veut également dire partager la responsabilité. Nous abattons le mode « Silo » pour un mode plus coopératif.
Est-ce que nous sommes prêts à prendre des risques ensemble et si nous échouons, à trouver de nouveau ensemble des solutions ? Est-ce que nous, architectes, sommes prêts à admettre que le cadre se construit avec ceux que nous accompagnons ? Est-ce que les équipes sont prêtes à entendre que nous n’avons pas toutes les réponses et qu’ils devront également porter une partie des responsabilités en appliquant de nouvelles règles ?
Olivier : Effectivement, la gestion humaine au sein des entreprises est arrivée à la maturité de l’adolescence. Temps délicat pour les leaders et les RH. Personnellement, j’ajouterai : attention aux adolescents silencieux ! Il faut écouter tout le monde, au risque de passer à côté d’une difficulté cachée.
Je pensais que le pire dans la vie c’était de finir seul. Non. Le pire dans la vie est de finir avec quelqu’un qui nous donne l’impression d’être seul.
La crise de la quarantaine
Olivier : Si tu veux bien, on va finir sur la crise dite « de la quarantaine », autrement dit « j’ai envie de changement ». Cette angoisse soudaine qui se profile parce que tout à coup, on se voit vieillir en faisant tout de la même façon, avec les mêmes personnes.
Sur de nombreux sujets, lorsque tout va bien, nous sommes en mode « run ». Nous faisons le strict minimum pour que cela fonctionne au quotidien. Nous prenons le café au même bistrot, achetons la même marque de dentifrice, nous avons des automatismes tels que verrouiller la porte, « d’ailleurs, l’ai-je vraiment fermée ? Je vais revérifier, on ne sait jamais ».
En informatique, la relation MOA/MOE a fait ses preuves durant de nombreuses années : la MOA écoute le client et traduit en termes informatiques / la MOE réalise les demandes. Pourtant, nous nous apercevons que ce duo arrive au terme de son efficacité. Avec la rapidité grandissante des évolutions IT, le couple MOA/MOE nuit à l’innovation de l’IT, car il faut autant entendre la stratégie IT que celle du métier.
La MOE nous fait donc une crise de la quarantaine : je m’ennuie, je veux évoluer, être valorisé. Les spécialistes situent cette crise dans la quarantaine car c’est souvent à cette période que les enfants quittent le foyer (mettons de côté les rides et les cheveux blancs). Une personne qui a fait passer le travail, le couple, les enfants avant soi tel un robot se retrouve « seul » face à une nouvelle situation qui l’angoisse et qui lui permet en même temps de, enfin, se recentrer sur lui.
Les psychologues préconisent de profiter de cette remise en question pour faire un bilan. Qu’est-ce que je sais faire ? Qu’est-ce que je veux faire ? Comment et dans quel objectif ? C’est exactement la place de l’architecte d’entreprise dans l’actualité. Son rôle est d’épauler l’entreprise dans l’évaluation de son SI : par rapport aux nouveaux objectifs que se fixent le métier et l’IT, quels sont les périmètres obsolètes ?
Comment faire évoluer les applications afin d’apporter de nouvelles valeurs ? L’architecte doit être capable de comprendre la profondeur des changements et donc de reposer les bonnes bases pour le futur.
Conclusion
Olivier : si je résume, être architecte demande autant de souplesse qu’un parent. Il se tient à l’écoute de l’entreprise et selon sa maturité et ses besoins, adapte son accompagnement et son cadre. C’est exactement ce que défend TOGAF, et l’amélioration continue. Je pense que nous sommes plutôt raccord avec l’actualité. Rémi Cocula parle de l’évolution « d’Architecte à Métarchitecte » dans une conférence Devoxx. Pour aller plus loin, voir la littérature sur l’Emergent Architecture qui pose la place de l’architecte dans une organisation agile.
Restez connectés pour les prochains chapitres de « Dessine-moi un architecte » :
