TOGAF est le Framework de l’architecture. Sa roue ADM est un classique. Le nombre de certifiés a explosé en France et dans le monde. Le but de cette série d’article est de voir avec vous, en se basant sur mon expérience de 13 années en tant qu’architecte, si ce framework doit être appliqué ou non, et sans renier la certification, réfléchir à comment l’appliquer et avec quel niveau d’investissement.
Nous allons donc commencer par explorer, dans cet article, les 2 premières phases, puis nous aborderons les autres phases dans de prochains articles.
Enfin certifié
Imaginons un plan de transformation du système d’information, vous êtes architecte et
on vous propose une formation. Comme vous êtes curieux, vous acceptez, et comme vous êtes travailleur vous réussissez l’examen final. Une fois la certification obtenue, et la satisfaction qui va avec, chacun s’est posé cette question : Qu’est-ce que je fais maintenant ? Et trop souvent, le résultat obtenu est décevant.
Il est décevant pour les certifiés qui ne savent pas comment mettre en œuvre ce qu’ils ont appris, mais aussi pour ceux qui ont financé cette certification et tout le monde a déjà entendu « TOGAF est trop loin de la réalité, cela ne sert à rien ». Alors, comment faire pour ne pas en arriver là ?
La phase préliminaire
Une phase primordiale
La première des phases de la roue ADM est celle qui, justement, est en dehors de la fameuse roue. C’est pourtant une phase vitale pour la suite de vos travaux. Elle sert à préparer l’entreprise aux travaux d’architecture (et pas uniquement la DSI). Les questions que l’on doit se poser sont « Où allons-nous faire de l’architecture ? avec Qui et Comment ? », mais également « Pourquoi ? ». L’odbjectif principal de cette phase est donc de construire une vue succincte des besoins, pour ensuite définir les capacités d’architecture que l’on pense nécessaire. Nous sommes en train de cadrer la mise en œuvre de l’architecture.
Capitaliser sur le sponsor
Lors de la formation, nous avons appris qu’il fallait commencer par définir la structure de l’entreprise puis les éléments métiers qui poussent au lancement de ce projet, de formuler la demande de travaux, de définir les principes d’architecture s’appliquant au projet, le référentiel à utiliser et les relations avec les autres référentiels de pilotage. Mais c’est également à ce moment qu’il faut évaluer la maturité de l’entreprise sur les notions d’architecture et que l’on peut adapter la méthodologie et l’ADM au projet.
Les « entrées », informations censées être collectées avant le projet, seraient : le modèle de l’organisation de l’entreprise, le référentiel méthodologique d’architecture, les outils, les principes d’architecture, le continuum d’entreprise, le référentiel d’architecture et le cadre de capacité… mais dans les faits, ces « entrées » sont rarement présentes.
Et pourtant, TOGAF préconise une première réunion avec le sponsor / commanditaire lors de cette phase et celle-ci est obligatoire. Lors de cette première réunion, les points cruciaux sont les entités / fonctions de l’entreprise pour définir le périmètre de l’étude, la gouvernance du projet d’architecture et bien sûr, le driver de la transformation. Sans cette réunion, il n’est pas utile d’aller plus loin, et si cela est difficile à organiser, vous avez déjà votre évaluation de la maturité.
Capitaliser sur ce qui existe pour ne pas consommer trop de temps
D’après TOGAF, il est possible, lors de cette phase, de modifier la roue ADM pour répondre au mieux aux besoins du projet de l’entreprise. Attention toutefois, il peut être dangereux de remettre en cause la roue ADM à chaque itération, et il faut absolument en garder le principe (l’enchainement des phases et les liens entre elles). Il est préférable d’avoir une roue stable sur un segment fonctionnel donné.
Nous allons donc commencer par la phase préliminaire elle-même : Le but est de de capitaliser sur ce qui a déjà été fait. Lors de la réunion avec le sponsor, vous avez identifié les grandes fonctions impactées. Pour identifier la capacité d’architecture nécessaire à votre projet, 3 situations peuvent se présenter à vous :
Si vous être dans une grande entreprise, il y a déjà des architectes en charge de ces fonctions, il suffit de leur exposer les attendus métier et de collecter leurs retours.
Si ce n’est pas le cas, il est possible de se baser sur des projets précédents. De façon native, de nombreuses étapes de la roue TOGAF sont déjà mises en place au sein d’un SI : des architectures applicatives ou techniques, parfois des processus sont déjà modélisés, des plans de migration sont mis à plat avec la gouvernance associée. Cela est tout à fait normal car TOGAF est un framework pour répondre à des besoins liés à une DSI et parfois, des réponses ont déjà été apportées à des besoins apparus lors des projets. Il faut alors se baser sur ce retour d’expérience.
Si vous n’êtes dans aucun des cas précédents, Il ne reste plus qu’à construire vous-même vos hypothèses. Basez vous sur quelques concepts faciles à identifier : Combien de processus ? Sont-ils le cœur de métier de l’entreprise ou pas ? Quelle est l’application au cœur de la transformation et quelle est l’équipe qui en a la charge ? Ces hypothèses seront évidemment fausses mais cela permet de poser une première brique.
Savoir comment valider ses propositions
Pour finir cette phase, il reste à définir comment faire valider vos travaux. Pour cela rien de plus facile : Si un processus de validation existe déjà, demandez-le ainsi que le temps moyen de validation. S’il vous semble imparfait, n’essayer pas de le faire modifier. Vous allez perdre du temps qui serait utile à votre projet. Si aucun processus n’existe, faites valider vos propositions par le sponsor et les parties prenantes, comme cela est préconisé par TOGAF.
Tout le monde sur la ligne de départ
A la fin de cette phase, vous aurez la structure de votre équipe d’architecture, qui valide les étapes et les résultats de l’étude, prête à démarrer votre projet.
La phase a : la vision de l’architecture
Les choses sérieuses commencent
La phase de vision de l’architecture permet de définir les impacts du projet sur le système d’information ainsi que les chantiers d’architecture à mettre en place. Elle est précédée de la phase préliminaire ou de la roue ADM précédente (en plus clair, la précédente phase du projet).
D’après TOGAF, a liste des étapes pour construire la vision d’architecture sont : identifier les parties prenantes et leurs exigences, les enjeux métiers (les bénéfices attendus par le métier), confirmer les objectifs, évaluer le niveau de motivation et de préparation des métiers, ainsi que les capacités des dits métiers, confirmer les principes d’architecture, définir les KPI pour mesurer les bénéfices d’architecture, les risques… Bien sûr, tout cela est logique dans un monde sans contrainte, mais cela arrive peu, pour ne pas dire jamais :
Comment évaluer les capacités du métier à répondre aux attentes de l’architecture, son niveau de motivation ou de préparation ? L’architecture est habituellement intégrée à la DSI et à quoi bon faire cela ? Comment présenter au métier, qui finance la DSI et l’étude, qu’il n’est pas au niveau et quels seraient les critères pour dire cela ?
Comment estimer la capacité du métier ? A partir des chaines de valeur ? Le contrôle de gestion de l’entreprise est le seul à avoir les informations nécessaires, mais les informations sont rarement partagées.
Et pour les KPI, comment faire une évaluation des gains alors que les problèmes à résoudre sont noyés dans le reste des activités des utilisateurs ?
Se concentrer sur l’essentiel
En fait, tout cela s’ajuste au fur et à mesure de l’avancée de l’étude, car cela permet au métier de reprendre le contrôle sur ses outils et ses processus. Cependant, on peut rapidement réaliser quelques étapes de cette phase :
Construire une carte des parties prenantes permet de faire une estimation rapide des influences de chacun.
Faire une macro-cartographie pour définir les grands ensembles du projet ainsi que quelques scenarios métiers pour pouvoir « jouer » des cas pratiques lors de la conception de la solution.
Si la mise en place des KPI n’est pas possible, on peut au moins demander au métier de faire une pondération « à dire d’expert » de ses attendus. En fait, il suffit souvent de demander les différents « pain points » à résoudre ainsi que les nouveaux besoins auxquels répondre, et de demander un ordre de priorité. A la fin du projet, vous pourrez demander au métier si la solution apportée lui convient.
L’état des lieux est terminé
Au final, cela permet à chacun de faire une évaluation plus fine de l’étude à réaliser et de compléter la note de cadrage. Comme dans toutes les épreuves, tous ces éléments vont s’affiner avec le temps et il est bon de garder le document pour le confronter au réel.
La suite
La grande force de la roue TOGAF est qu’elle traite toutes les problématiques liées à l’architecture et apporte une réponse, ou au moins un Framework pour répondre, à ces problématiques. Et comme tout framework, il est important de l’appliquer à un contexte. Suivre TOGAF c’est bien, savoir le faire sans oublier pourquoi, c’est mieux. Il n’est pas utile de tout faire exactement comme cela est préconisé – tous les acteurs du projet n’en saisissent pas forcement les bénéfices – mais il est tout à fait possible d’en extraire l’essentiel. Apres avoir traité les deux premières phases, nous continuerons, dans les prochains articles, à parcourir les autres phases la roue ADM et explorer ensemble TOGAF IN REAL LIFE.
Pour fournir une vision d’ensemble du SI et de sa transformation, l’architecte doit faire émerger les principes du « vivre ensemble » partagés par l’ensemble des parties prenantes du SI.
Un SI construit sans vue d’ensemble c’est ça
Et les connexions entre applications ressemblent à ça
Construire ensemble
La cible du SI et ses paliers de transformations fournis par l’architecte d’entreprise sert à donner à chacun la vision d’ensemble dans laquelle il s’insère.
Lorsqu’une solution n’est pas compatible avec la direction donnée et les bases de la construction, elle peut avoir de grandes répercussions sur les autres, voire mettre l’ensemble de la construction en danger (ici la structure de l’immeuble a failli s’effondrer sous le poids supplémentaire).
Chacun a son point de vue sur la solution, et tout le monde a raison (de son point de vue évidemment)
Chacun imagine des solutions, même si celles-ci peuvent paraître en décalage avec l’idée qu’on s’en fait. Des dérogations peuvent être accordées tant qu’elle ne gêne pas l’ensemble de la construction l’architecte d’entreprise ou le difficile équilibre du vivre ensemble L’architecte d’entreprise ou le difficile équilibre du vivre ensemble discussion
Une fois que la cible est définie et partagée par tous, il faut alors effectivement définit les règles du vivre ensemble
L’architecte d’entreprise est là pour proposer des principes communs qui permettent de faire avancer le SI dans son ensemble. Il a pour but de faire communiquer les différentes composantes de l’entreprise et de trouver les solutions qui conviennent à tous, qui sont les plus pérennes et les plus proches des standards voulus par l’entreprise. Dans notre monde actuel, les connaissances sont fragmentées et la coopération entre toutes les parties est essentielle pour tirer le meilleur des nouvelles situations et des technologies.
L’architecture globale du SI doit permettre de laisser chacun libre d’aménager (ou pas !) son propre espace (l’intérieur de sa solution). Le but est alors que chaque solution puisse vivre selon son propre rythme en harmonie avec les autres et en garantissant un langage minimum commun pour se comprendre.
Peu importe la solution choisie pour le SI, la bonne solution est celle qui répond au problème. Elle doit être partagée par tous, construite suivant les règles de l’art et chacun doit pouvoir y trouver sa place.
Quelques grandes règles et principes suffisent pour construire ensemble un édifice solide. À tout moment, il doit être possible de justifier des principes qui nous ont amené à choisir cette solution. Ces principes peuvent (doivent) évoluer bien sûr. Ils sont là pour nous aider à se poser les (bonnes) questions. La gestion des dérogations à ces mêmes principes est un art subtil à manier avec précaution et à ne pas négliger !
La bonne architecture fournit la solution adaptée à un besoin en prenant en compte les différents paramètres de coûts, délais, qualité, esthétique, technique, évolutivité etc.
Les DSI pâtissent souvent de ne pas avoir une description claire de leur SI. Une description qu’ils puissent montrer aussi bien aux métiers pour déclencher les budgets et l’intérêt, qu’aux différents interlocuteurs (nouveaux entrants, sous-traitants, etc.). Elle permet d’expliquer le fonctionnement global du SI dans sa complexité, dans les différentes composantes majeures, dans les parties prenantes impliquées, etc. Et quand on parle de description, il ne s’agit ni de la liste des lignes budgétaires, ni de la liste des projets, ou autre. Nous parlons de la vraie description du fonctionnement du SI avec ses principales applications / domaines et les flux qui permettent de décrire un fonctionnement dynamique du SI.
Un de nos clients, une filiale d’un grand groupe bancaire nous a demandé récemment d’avoir le « poster » avec les principales applications et les flux, pour qu’il puisse comprendre et présenter le SI. Il était inquiet de ne pas savoir avec qui / quoi le SI était en interaction… Cela lui permet aussi de bien visualiser et de positionner ses enjeux en terme de transformation, d’investissements, etc.
Combien de DSI, malgré toutes leurs demandes et les missions de cartographie ne disposent toujours pas de la cartographie claire de leur SI ? Une cartographie qui leur permette de maîtriser ce qu’est leur patrimoine et leur « terrain de jeu ».
Combien de fois, les architectes sont revenus faire des dessins aux tableaux pour expliquer tel ou tel point, et au final, c’est toujours le même dessin qui est fait, mais personne ne capitalise dessus ? J’ai vu faire un architecte devenu un client, qui expliquait pendant plusieurs séances, le SI et sa transformation avec un dessin au tableau. Il rajoutait, modifiait des explications au fur et à mesure des échanges avec ses interlocuteurs. Le tableau devenait alors trop illisible et il refaisait son dessin sur un paper board, et c’était reparti pour un cycle. Nous lui avons fait le fonds de carte et maintenant, il raconte son histoire à partir de là en mettant régulièrement à jour ce dessin qui est devenu son « fonds de commerce ».
Cette démarche de description macro du SI doit être faite rapidement. Dans un esprit agile, les premières étapes doivent être celles qui apportent le plus de valeur ajoutée.
Ne pas finir une cartographie, ce n’est pas grave, à condition que l’on ait apporté le plus de valeur ajoutée dès le début.
Dans le cadre de nos interventions, notre démarche nous permet de répondre précisément et complètement à ses attentes et de fournir les vues pertinentes à la compréhension du SI. Une vue assez stable pour ne pas devoir être mise à jour à la vitesse des projets (qui se succèdent à un rythme effréné en ce moment) et qui permet de bien comprendre les grands enjeux du SI.
Définissons ensemble les vues qui vous manquent le plus et donc celles qui vous apporteront le plus de valeur. Nous allons commencer par celles-là et y mettre les moyens !
Au printemps 2017, le client a réorienté sa stratégie IT vers le Cloud et les architectures microservices. Après la mise en place durant une année d’un socle Cloud, une réécriture progressive en microservices de ses principales applications Legacy a été entamée. Les apports attendus sont une meilleure réactivité face aux évolutions du métier, la levée de limitations fonctionnelles et techniques ainsi qu’une baisse des coûts opérationnels.
Missions
Dans le cadre du revamping du progiciel IRP (application majeure d’évaluation des risques) :
Cadrage (recueil et analyse) et formalisation des besoins métiers face aux limitations du Legacy,
Réalisation des dossiers d’architecture (DA) pour les différents comités récurrents (board, investissements, steering, architecture centrale…),
Conception d’une architecture applicative urbanisée & event-driven, basée sur des microservices,
Modélisation des objets métier afin de formaliser les contrats d’échange (API REST),
Définition d’une stratégie de migration continue pour maintenir la cohérence entre Legacy et microservices afin de faciliter les bascules de responsabilité,
Validation des solutions d’implémentation (y compris l’Infrastructure as a Code) sur AWS, conçues avec les architectes techniques,
Evangélisation des principes d’architecture concernant la résilience, la robustesse, l’élasticité, la performance, la sécurité et l’observabilité,
Conception détaillée d’un module de mapping user-friendly des données métier (DaShifter) pour répondre au problème central de la disparité des sources d’information.
Bénéfices
Première livraison en 4 mois de fonctionnalités initialement prévues pour l’année suivante,
Levée de limitations techniques (volumes de données et traitements en masse),
Décorrélation des cycles métiers et des cycles de développement.
Les autres success stories qui peuvent vous intéresser
Uber en 2016, Doctolib en 2020 sont des illustrations permettant de prendre conscience de la multiplicité des attaques informatiques dans le monde.
Selon les chiffres de Cyber Malveillance (site gouvernemental), quelques 90 000 victimes ont été assistées sur la plateforme en 2019, contre 28 855 en 2018, soit une augmentation de plus de 210%. Ces attaques ont plusieurs conséquences allant de la détérioration de l’image de marque à des pertes financières colossales. La crise sanitaire a mis en évidence le besoin de sécuriser davantage les systèmes d’information avec les nouveaux usages.
Face à cette situation, il est important pour les différents acteurs, en particulier les entreprises et les administrations, de réagir efficacement et de mettre la cybersécurité comme un des piliers de la transformation des systèmes d’information (SI). L’architecture d’entreprise (AE) est un des vecteurs de l’adoption et de la mise en œuvre de la sécurité dans les SI.
Que faisons-nous aujourd’hui ?
De nos jours, il est commun dans le design d’architecture de faire passer les fonctionnalités et les processus en priorité. La sécurité est souvent reléguée à la fin de la conception avec un espoir d’obtenir le « tampon sécurité » de la personne en charge de la SSI (Sécurité des systèmes d’information). Face aux contraintes financières et de planning, la cellule sécurité n’a pas d’autre choix que de valider les architectures présentées sans avoir eu le temps de passer au peigne fin les implications de cette architecture.
Par conséquent, Il est primordial de changer de paradigme et d’adopter une réflexion fondamentale de « Security by design ».
Quelles sont les pistes d’amélioration ?
La sécurité couvre l’ensemble des systèmes d’information et sa prise en compte démarre depuis l’architecture. Ainsi, les exigences de sécurité doivent être prises en compte dès la conception des systèmes d’informations mais aussi mis au centre de la gouvernance de ces derniers. A titre d’exemple, tous les acteurs et actrices (architectes, développeurs, testeurs, UX designers, …) qui conçoivent les applicatifs doivent respecter les bonnes pratiques formalisées dans les normes de sécurité.
Dans ce contexte, plusieurs pistes permettent de faire converger la sécurité et l’innovation dans la transformation du SI et plus globalement amener à la résilience de l’entreprise.
Organisation
La personne en charge de la SSI (ou son service) devra être associé dès la phase préliminaire de conception de l’architecture (idéalement dès l’expression des besoins). Cette démarche permettra de prendre en compte les contraintes de sécurité en amont. Une autre mesure est de donner sa place et une voix forte à la personne en charge de la SSI au sein des comités de validation des architectures.
Evaluer les risques des briques du SI
Cette démarche a pour but de cartographier les SI et de donner des points de criticité aux différentes briques identifiées. De plus, cette démarche permettra de mettre en évidence l’impact d’une attaque de sécurité sur les activités, les organisations et les personnes ainsi que pour définir les axes d’amélioration associés. Cette cartographie pourra faire l’objet d’un partage à toutes les parties prenantes de l’organisation pour les embarquer et les sensibiliser sur ce sujet.
Gérer les risques
A travers la mise en place d’un plan de continuité d’activités (PCA) et d’un plan de reprise d’activités (PRA). Plusieurs actions permettent d’identifier les risques sur une organisation. Une de ces actions consiste à identifier les relations existantes entre les applications, les technologies utilisées, les processus et les équipes concernées afin d’avoir une vision claire et formalisée des impacts sur les activités de chaque unité organisationnelle, ainsi que sur leurs dépendances sur le plan technologique.
En associant l’architecture d’entreprise et ses outils à un référencement des applications, des technologies, des données et des processus, l’entreprise se donne les moyens de comprendre l’impact d’un incident sur la poursuite de son activité et sur les moyens d’y faire face. Cette visibilité renforcée sur l’environnement technologique de l’entreprise a une importance capitale en temps de crise dans la mesure où l’arrêt des logiciels non essentiels est par exemple indispensable afin d’économiser de la bande passante pour les collaborateurs en télétravail.
Conclusion
Dans un monde de plus en plus concurrentiel et innovant, La sécurité et l’architecture deviennent de plus en plus indissociables notamment dans les évolutions et les transformations des SI actuels. Au travers de différentes stratégies, Il est indispensable de renforcer les synergies entre l’architecture d’entreprise (et plus globalement toutes les facettes de l’architecture) et la sécurité afin de rendre les entreprises plus résilientes aux chocs endogènes et exogènes.
Et si l’architecture d’entreprise était plus présente dans notre vie quotidienne que nous ne le pensions ? Nous vous assurons qu’il est possible de discuter des différentes approches possibles dans l’accompagnement au développement de la solution des projets en faisant un parallèle avec l’éducation des enfants, de façon simple et basique (coucou Orelsan). Loin de nous l’idée d’infantiliser les projets, nous parlons ici de la solution / le résultat. Les projets partent d’une idée, d’une conception et vont jusqu’à l’émancipation. D’ailleurs ne dit-on pas que « l’on a accouché » d’un projet (ou qu’il accouche d’une souris) ?
Et il se trouve que nous avons tous été enfant. Certains ont même pris le risque d’en avoir à leur tour. Alors nous espérons que tous pourront se reconnaitre dans nos paroles.
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.
Note : toute ressemblance avec des projets ou des enfants existants ne serait bien entendu que fortuit.
Note 2 : 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.
De l’importance du cadre. La relation avec ses enfants.
Cadre ou pas cadre ?
Chloé : Je lis en ce moment un livre passionnant sur la parentalité positive. Je t’explique.
Dans le monde de la parentalité, les spécialistes ont pris position : aussi contradictoire que cela puisse paraitre, pour qu’un enfant grandisse libre, les parents se doivent de poser un cadre aux enfants et leur apprendre à le respecter. Le Larousse dit qu’un cadre est « Ce qui borne, limite l’action de quelqu’un, de quelque chose ».
En pratique, nous avons plusieurs tendances :
Afin de respecter la liberté de l’enfant, il existe des parents qui écoutent les envies de l’enfant et n’y oppose aucun cadre.
Pour certains, c’est évident, l’enfant a besoin de cadre. Celui-ci existe dans leur esprit avant même l’arrivée de l’enfant. Il est construit sur les principes et valeurs animant la vie de l’adulte. Parfois, il est hérité de leur propre éducation.
Enfin, pour d’autres, un parent doit apprendre en marchant avec son enfant : ce cadre se construit au fur et à mesure du développement de l’enfant.
La bonne manière de faire est celle qui permet l’épanouissement de chacun ! Est-ce que cette façon de voir est valable pour l’informatique ?
« Les parents sont le cadre, et l’enfant la peinture. »
François de Singly
Un cadre…
Olivier : C’est un très bon parallèle. Mais il n’existe pas de cadre universel, n’est-ce pas ?
Que se passe-t-il quand le cadre est très, voire trop strict ? Tu vas subir bientôt la première étape de rébellion : la période du « NON ! » vers les 2 ans de l’enfant, suivi ensuite de l’adolescence, puis cette remise en cause vers 40 ans (davantage 30 ans de nos jours). Ce sont des périodes sensibles où un cadre reste essentiel mais devient un grand point de friction.
Dans l’entreprise, un exemple très actuel de situation qui bouscule nos convictions est l’apparition des projets dits « en mode Agile ». L’ancien système étant par trop contraignant, une nouvelle façon de faire est apparue, perturbant tout l’écosystème classique : les processus, les acteurs, les principes…
Les solutions des projets qui suivaient les règles établies faisaient la fierté de leurs géniteurs car ils étaient dans le cadre et avaient « les bons tampons sur le papier » (indépendamment des résultats produits…). Depuis, les projets se sont réinventés, avec ou sans autorisation. Alors devons-nous supprimer le cadre car la rigidité empêche le Système d’Information d’évoluer ? Est-ce qu’on dit qu’un cadre empêche un enfant d’évoluer ? Tout va dépendre du cadre et comment on choisit de l’utiliser. Un cadre peut aussi être très macro et simple : du bon sens en somme !
… des principes, des règles et des dérogations
Olivier : Le cadre se décline en plusieurs étapes / niveaux et doit pouvoir s’adapter.
De manière générale, un cadre s’accompagne de principes (je veux un enfant poli, je veux un SI sécurisé) et de règles (« dis bonjour à la dame », « montre patte blanche au comité sécurité »). Une fois les règles définies, cela permet de tracer le suivi ou non des règles, via un protocole de dérogation (mon enfant n’a pas dit bonjour aujourd’hui à la dame, il était fatigué, mais demain promis, il le dira // le projet n’a pas appliqué cette règle d’urbanisme par manque de budget / temps mais promis il le fera l’an prochain). La dérogation est par définition temporaire. Attention aux abus donc ! Si l’enfant ne dit jamais bonjour parce qu’il est toujours fatigué, soit le principe n’est pas bon, soit l’enfant a un vrai souci de santé. En parlant de cela, comment se porte ton SI ?!
Ne me promets pas la lune ni les étoiles, promets moi d’être à mes côtés pour les admirer
Pas de règles ?
Chloé : aussi bien qu’un autre, j’imagine… Peut-on se contenter du niveau 1, de n’avoir que des principes ?
Il est possible d’élever un enfant sans règles, avec uniquement des principes. « Je comprends que mettre un casque t’embête, mais pour ta sécurité, tu te dois de protéger la tête. » et à l’enfant de trouver par ses propres moyens, une solution pour respecter le principe et rester dans le cadre. Il est évident qu’à 10 ans, l’enfant appréciera cette confiance accordée. Il est tout aussi évident qu’à 3 ans, l’enfant est trop immature pour saisir un tel discours. C’est une solution qui ne fonctionne qu’avec des acteurs matures et conscients des tenants et aboutissants. Si nous revenons à notre IT, cela signifie qu’il est possible de présenter des règles à tous, et seulement des principes aux acteurs qui sont sensibilisés à l’architecture et sauront d’eux-mêmes prendre les bonnes décisions car conscients des impacts et risques.
« Ne me promets pas la lune ni les étoiles. Promets-moi d’être à mes côtés pour les admirer. »
Ni cadre ni principe
Olivier : Je dirai même plus, et sans les principes il reste quoi ?
Lors de la naissance d’une entreprise, seules les valeurs sont présentes : nous œuvrons au bien-être de la planète, des animaux, des sportifs, … Il n’y a ni cadre, ni principe. Si cette entreprise a la chance de réussir et de grandir, alors les cadres et principes vont naturellement apparaitre, sinon l’entreprise deviendra ingérable. Lorsqu’on étudie les licornes, ces start-ups qui transforment l’essai, et qui grossissent rapidement, nous constatons qu’elles dérivent lorsqu’elles persistent à fonctionner « comme avant ».
Le bonheur est dans la diversité
Chloé : nous sommes fruits de la diversité et du hasard !
Le résultat de notre projet (informatique) est comme un enfant, personne ne sait, dès le départ, ce qu’il va devenir. Sera-t-il comme nous l’avions imaginé ? Va-t-il se rebeller ? Par quelles phases va-t-il passer ? Comment allons-nous gérer les crises qui ne manqueront pas de survenir ? C’est tout ce qui fait le charme de l’éducation et des projets… Ne pas savoir et apprendre en marchant.
Conclusion
Olivier : si je résume : un cadre oui obligatoirement ; des principes, très certainement ; des règles, ça s’étudie. J’élève mon enfant afin qu’il soit sociable, il doit être poli, il dira bonjour. Plus il grandit, et plus mon discours se contentera de « tu ne vis pas tout seul ». Nous voyons mieux les enjeux avec cette métaphore !
Rappelons-nous que les cadres ne sont pas présents pour brider les projets. Au contraire, ils sont là pour les aider. Le cadre permet la naissance des principes, donnant à leur tour vie aux règles qui régissent le fonctionnement du SI et des acteurs de celui-ci. Au vu du nombre d’évolutions que connaît un SI d’entreprise, l’absence de cadre serait vraiment un frein.
Les règles permettent aux projets « routiniers » (qui sont en plus grande proportion) de suivre des voies « balisées ». Puis, en fonction des différentes phases et des différents types de projet, il est intéressant d’imposer des règles, ou pas, ou moins…
Même l’idéation est aidée par des principes, certes légers ! En revanche, il est important de garder en tête qu’un principe est « au service de ». S’il perd de son intérêt, c’est qu’il est temps de le faire évoluer.
Restez connectés pour les prochains chapitres de « Architecture d’entreprise et parentalité » :
Chapitre 2 : gérer les crises (rejet de l’autorité parentale, faire la police, rupture de la confiance)
Chapitre 3 : les autres membres de la famille (grands parents, frères et sœurs, amis/voisins proches)
Chapitre 4 : les grandes transformations (arrivée d’un nouvel enfant, divorce, famille recomposée)
