urbanisation-si.com

Voici la seconde partie de notre exploration des architectures catholiques du S.I. (commencée ici "Les architectures catholiques du S.I. (1/2)"), étant entendu que celle-ci ne se prétend en aucune manière exhaustive.

Illustration créée par ChatGPT - DALL-E pour cet article

L’Architecture orientée Bidouille (AoB)

Cette architecture très populaire est guidée par la recherche systématique d’une solution à court terme facile à trouver, facile à réaliser, et peu coûteuse, le sacro-saint « quick win ». Bref, l’idéal quand on n’a pas affaire à un système (d’information), et quand le périmètre du sujet traité a une durée de vie courte… ce qui n’est quasiment jamais le cas. Ce style d’architecture du S.I. aboutit ainsi à mettre de la bidouille sur de la bidouille sur de la bidouille (vous me rajouterez un peu de bidouille pour corriger les effets d’une bidouille précédente…), jusqu’à ce que, étonnamment, le coût de l’ensemble devienne insupportable, sa qualité devienne déplorable et son évolutivité quasi nulle.

Cette architecture a quelques caractéristiques qui méritent que l’on s’y attarde. Premièrement, elle n’est quasiment pas documentée. Normal, puisque sa logique est systématiquement court-termiste alors que la documentation, par essence, s’effectue dans une démarche d’héritage, de transmission, donc de moyen / long terme — paradoxe savoureux, cette logique court-termiste peut courir pendant des années ; c’est même pour cela qu’elle est douloureuse.

Deuxièmement, elle se construit par des bonds réalisés par un individu. En effet, comme chaque évolution est petite, elle n’est réalisée que par une seule personne, celle qui la plupart du temps l’aura d’ailleurs préalablement proposée (« Je peux le faire » annonce ainsi fièrement celui qui pourra ensuite se targuer d’être celui qui aura « solutionné le problème » si efficacement, faisant ainsi le bonheur du chef de projet ou du responsable hiérarchique qui aura ainsi « tenu le budget »). Ce phénomène renforce d’ailleurs l’absence de documentation (« la documentation est dans le code », en fait dans sa tête), car celui qui réalise devient également celui qui maintient. Et ce dernier va se faire un plaisir, au gré des évolutions demandées, de faire grossir son paquet de bidouilles (d’autres termes moins fleuris, mais tout aussi pertinents, pourraient venir à l’esprit du lecteur espiègle, mais je lui en laisserais l’entière responsabilité).

Précisons bien que cela ne signifie pas qu’un seul individu est à l’origine de toute la bidouille présente dans le S.I. On peut parfaitement y trouver plusieurs paquets de bidouilles, chacun ayant son propre auteur. Et pour boire le calice jusqu’à la lie, un paquet de bidouilles peut parfaitement traiter de sujets qui n’ont rien à voir entre eux. Simplement, comme ils ont été traités par une même personne qui ne veut pas s’embêter à faire un autre paquet (dans tous les cas, c’est son « quick win »), ils se retrouvent intriqués, interdépendants.

Il y a alors une seconde phase dans cette architecture : la vitrification. Le temporaire s’éternise. Car, certes, le coût de l’ensemble devient exorbitant, mais le coût du remplacement l’est également (avec en plus un certain degré d’incertitude). Un consensus s’établit alors pour décider que, même s’il fallait le remplacer, il est urgent d’attendre, d’autant que l’on souhaite réaliser des dépenses d’investissement sur un autre sujet un peu plus glamour (la même décision, basée sur le même constat et la même envie, sera donc prise l’année suivante, et la boucle est bouclée). Il est à noter que, bizarrement, personne ne songe à demander au créateur et mainteneur du tas de bidouilles de mettre à profit l’année perdue pour le documenter et ainsi faciliter son remplacement.

Eh oui, l’existant coûte, mais il s’agit là d’un « coût de fonctionnement », donc peu sexy, qui n’intéresse personne ou presque, tant qu’il reste en dessous d’un certain seuil de douleur.
Le « build » (et son coût) est surveillé, l’affectation de son budget pour l’année à suivre peut faire l’objet d’innombrables réunions pendant des mois, mais le « run », lui, est subit. Voici une illustration de plus que la psychologie a un impact fondamental sur l’architecture d’un Système d’Information.

Il est valorisant de construire, mais pas de maintenir, ni encore moins de détruire. Nos écoles d’ingénieurs forment des bâtisseurs, pas des nettoyeurs. Qui a déjà été félicité pour avoir nettoyer les écuries d’Augias : décommissionner n logiciels inutiles, redondants, voire dangereux, ou pour avoir supprimer des flux illogiques [5] et optimiser des communications en point-à-point ? Alors qu’ajouter (ou remplacer) un logiciel entraîne facilement une bonne publicité interne.

Autre biais psychologique, un tas de bidouilles étant l’émanation d’une seule personne, il devient son bébé. Elle l’aura créé, elle l’aura fait grandir, elle est la seule à vraiment le connaître (il assoit sa légitimité), et il peut même devenir pour cette raison son activité principale. À partir de là, on comprend bien qu’elle aura donc du mal à accepter d’en faire la critique et à le voir disparaître. Autrement dit, encore une fois, cette architecture crée une tension entre l’intérêt général et des intérêts individuels.

[5] Pour le coup, j’ai quand même eu cette chance une fois dans ma carrière.

L’Architecture par Népotisme (ApN)

Les liens interpersonnels qui se créent dans une société en débordent : les personnes qui changent d’organisation ou qui passent d’une société à une autre conservent des liens avec de précédents collègues (d’autant que les autres sociétés vers lesquelles aller assez facilement participent logiquement d’un même écosystème ; elles sont soit clientes, soit fournisseuses, soit concurrentes, de la première : on a donc une certaine probabilité de retrouver d’anciens collègues quand on en quitte une), les anciens élèves d’une même école nourrissent leur réseau, les liens familiaux s’en mêlent, des couples se créent, ou encore d’aucuns utilisent leur proximité avec certains collègues pour créer leur société avec la certitude que celle-ci aura comme premier (seul ?) client celle qu’ils viennent précisément de quitter.

On comprend mieux ainsi pourquoi toute analyse architecturale tentant, par exemple, de démontrer l’absurdité de payer un fournisseur proposant une technologie de chaînes de blocs à localisation centralisée et contribution unique sera peine perdue si son dirigeant possède des liens très étroits avec les « bonnes » personnes de la société cliente, et l’auteur de cette analyse sera logiquement gentiment prié de la mettre sous le boisseau.

Ce style d’architecture possède des variantes : l’Architecture sur Canapé
et l’Architecture par Corruption.

L’Architecture orientée Éditeur / Intégrateur (AoE)

Architecture que l’on pourrait également appeler l’Architecture par Délégation. Pour intégrer un nouveau logiciel dans un S.I., son éditeur va naturellement être sollicité (soit directement soit indirectement, via un intégrateur). Et celui-ci a naturellement envie que cette intégration soit la plus rapide possible pour que la vente lui soit la plus rentable possible. Il peut donc vouloir limiter ses risques en poussant une architecture qu’il connaît, des moyens de communication qu’il maîtrise, indépendamment du style d’architecture existant ou souhaité de son client ni de son besoin.

Si les critères d’intégration n’ont pas été pris en compte en amont, si l’équipe interne n’est pas suffisamment ferme, suffisamment volontaire et informée, ou tout simplement si une architecture S.I. n’a pas été conçue, alors chaque éditeur, selon son historique, son niveau de maturité sur telle ou telle technologie ou encore sa stratégie, va orienter localement le S.I. dans une certaine direction. Ici une communication par API REST, là par échanges de fichiers. Ici l’utilisation d’un logiciel médiateur, là une communication point-à-point, là encore l’installation d’un orchestrateur de l’éditeur, et là enfin une transmission de données par courrier électronique (les variantes sont quasi infinies).

Quand on ne sait pas où l’on veut aller, d’autres prendront la barre.

Ce type d’architecture est apparemment très bénéfique à chaque projet, car ainsi certains risques ont été maîtrisés et la probabilité de finir dans le temps et dans le budget imparti est augmentée. Voilà deux critères mesurables, et donc des indicateurs systématiquement suivis par la chefferie de projet. Mais voilà, un projet n’est pas isolé — c’est même le principe de travailler dans et pour un système, donc une optimisation locale peut très bien aboutir à une dégradation globale.

En plus de l’éditeur ou intégrateur, l’une des sources de ce style d’architecture est à trouver dans l’organisation : ceux qui participent à la phase de changement sont rarement ceux qui participent à celle du maintien en condition opérationnelle, autrement dit ceux qui « optimisent » durant un temps fini ne sont pas ceux qui vont en subir les conséquences sur le temps long de l’utilisation (pour ceux qui décident de le — laisser se — mettre en place, ce style d’architecture est bénéfique sur le court terme et indolore sur le long terme ; pour ceux qui en héritent, en revanche…).

Si les caractéristiques précédemment décrites de ce style d’architecture de S.I. le font ressembler à un paquet de confettis, il peut aussi évoluer selon une même logique sur un large périmètre lorsqu’un unique éditeur participe à tout un sous-ensemble du S.I. (c’est typiquement le cas pour les GAFAM [6] qui proposent des outils intégrés pour stocker, diffuser, traiter et représenter des données). Dans ce cas, il pourra orienter l’architecture d’une partie significative — si elle n'est pas structurante — du S.I. de ses clients simplement en changeant sa politique de licences. Ici, la perte de souveraineté de la société sur son S.I. est à peu près totale, car ce dernier appartient, de facto, à un éditeur : d’une part, il a connaissance de tout le savoir de la société (il stocke ses fichiers, données structurées et courriers électroniques) et, d’autre part, il peut piloter son patrimoine logiciel et ses choix technologiques.

Deux facteurs contribuent à ne pas sortir de cette dépendance : tout d’abord une question d’égo, car en changer reviendrait à reconnaître qu’une décision stratégique, prise à très haut niveau et impliquant des sommes colossales, a été mauvaise, et ensuite, car le coût de la prise d’indépendance est considéré comme bien supérieur au coût du maintien de l’inféodation (d’année en année, le coût de la D.S.I. doit augmenter, et/ou la part prise par l’éditeur sur le budget de la D.S.I. doit grossir ; la vache à lait n’a d’autre choix que de se laisser traire — jusqu’à ce qu’une certaine limite soit franchie, et alors des décideurs soient changés).

Tant qu’il n’y a pas de changement de décideur, il n’y a pas de changement de décision.

[6] Mais ils sont loin d’être les seuls ; citons simplement SAP.

L’influence de la SMARTabilité sur le S.I.

Coût, Délai, Qualité, Pérennité : sur ces quatre caractéristiques, 2 sont mesurables, 2 autres ne le sont pas. 2 sont faciles à définir, 2 autres sont ambiguës. 2 sont sensibles uniquement à court terme (sauf cas extrêmes), 2 sont sensibles à moyen / long terme : lesquelles seront suivies par des KPI, d'après vous ? Pour un tableau de bord, ce qui ne se mesure pas n’existe pas ; ça vous énerve ?

Deuxième aparté, qui prolonge d’ailleurs celui de la première partie, sur la non-prise en compte de la qualité et la pérennité dans la construction d’un S.I. En effet, n’étant pas mesurables, ces caractéristiques ne sont par conséquent jamais dans les objectifs « SMART » de l’Entretien Individuel de Performance (E.I.P.) annuel d’un quelconque salarié. Typiquement, les chefs de projets s’y intéresseront diversement, selon les appétences des uns et des autres, alors que les coûts et les délais des projets seront observés par tous (et pourront même permettre de comparer les chefs de projets entre eux).

Par ailleurs, comment espérer avoir des actions collectives cohérentes quand les objectifs à atteindre ne sont tous qu’individuels ? Quelle société rend public (en interne) l’ensemble des objectifs individuels qu’elle donne ? Quelle société s’assure de la cohérence de ces objectifs, s’assure qu’ils n’entrent pas en conflit les uns les autres (et l’assure à ses membres) ? Quelle société, enfin, a mis en place des Entretiens Collectifs de Performance ?

L’Architecture Syncrétique (AS)

Finissons en apothéose, car tous ces styles d’architectures ne sont pas mutuellement exclusifs ! Il est donc parfaitement possible de voir une combinatoire de tous les styles d’architectures précédemment décrits dans un seul et même S.I.

Conclusion

Dans un S.I., il y a des décisions prises, parfois bien obscures pour un architecte S.I. se voulant orthodoxe. Et ce bref panorama de styles d’architecture rencontrés dans les sociétés devrait rendre modeste tout architecte du S.I. attitré. D’une part, il importe avant toute chose de voir la poutre qui est dans son œil, car sous couvert de promouvoir une architecture orthodoxe, il met probablement lui-même en place, sans s’en rendre compte, une architecture catholique. D’autre part, il n’a pas la main — et il ne l’aura jamais — sur les facteurs structurants d’un système d’information : politique RH, contrôle de gestion, structure organisationnelle, choix de nouveaux salariés, biais psychologiques, principes culturels ; tout cela est décidé ou existe sans lui.

Et, vis-à-vis de ces enjeux, pourtant incontournables comme nous l’avons vu, pour qui souhaite maîtriser la complexité d’un S.I., aucune méthode, aucun cadre d’urbanisation du S.I., ne lui sera d’aucune utilité, d’aucun secours, car aucun ne les traite de front (et à plus forte raison, aucun logiciel ni aucun langage de modélisation). En outre, appartenant le plus souvent à une organisation transverse dédiée, il n’a par conséquent à sa disposition ni carotte ni bâton vis-à-vis des directeurs, chefs de projets, développeurs, intégrateurs, etc., qui font du S.I. ce qu’il est. Tout est-il pourtant perdu pour l’esthète ? Non, mais c’est un autre sujet.

Chers confrères architectes ou urbanistes du S.I., si ce que je vous ai proposé vous parle, je vous invite maintenant à amender, enrichir ou illustrer (par de croustillantes anecdotes) les architectures présentées ici en commentaire.

"La beauté, c'est l'harmonie du hasard et du bien.
Sachons faire confiance à la jeunesse pour conserver à la vie sa valeur suprême."
Simone Veil

Les architectes et urbanistes du S.I. savent qu’il existe différents styles d’architecture possibles pour un S.I. : architecture orientée (micro) services, architecture hexagonale, architecture orientée événement, la conception par domaine, etc. Chacun va avoir son architecture privilégiée, son style architectural.

Il s’agit là des architectures orthodoxes [1], mais tout cela n’est que la partie émergée des architectures existantes en société. Il en existe en fait beaucoup d’autres, jamais identifiées, car jamais nommées, mais pourtant très présentes et très vivaces : les architectures catholiques [2] (je les tiens pour beaucoup plus répandues que les architectures orthodoxes). Je vous propose ici de combler ce manque en en décrivant quelques-unes.

Illustration créée par ChatGPT - DALL-E pour cet article

[1] Orthodoxe : « Qui est conforme à la doctrine officiellement reçue » « Qui s’accorde avec l’opinion couramment admise » (source : Dictionnaire de l’Académie française, 9e édition)
[2] Catholique : « universel » (source : Dictionnaire de l’Académie française, 9e édition)

L’Architecture orientée C.V. (AoCV)

Dans le S.I. où elle est appliquée, cette architecture va faire sourdre de manière isolée des technologies et façons de faire dans la tendance du moment.

Car ce S.I. est vu par ceux qui le font évoluer comme un moyen pour leur permettre d’ajouter des mots-clefs rémunérateurs à leur C.V.

Les composants technologiques à intégrer sont forcément nouveaux dans le S.I., puisqu’ils ont été choisis pour cela : ils sont à la mode, ils sont vendeurs.

On ne s’étonnera pas alors, une fois terminé le projet qui leur a permis de mettre en place ces technologies à la mode, de voir les personnes responsables de ces évolutions partir de leur société (le projet se terminera, car il doit se terminer coûte que coûte, contre toute évidence, non pas seulement à cause du biais d’engagement, mais aussi pour pouvoir « justifier d’une expérience réussie »). En effet, c’était bien là tout l’objectif de ceux qui ont fait les choix d’architecture en question.

Et puis, cela permet de ne pas avoir à assumer ces choix sur le long terme, laissant ainsi aux anciens collègues le soin de gérer une évolution faiblement documentée (pourquoi réaliser une documentation quand on sait dès le début que l’on ne nous la demandera jamais, qu’on ne la lira jamais, et que tout le travail effectué ne l’est que pour soi, et non pour la collectivité ?). Cette évolution est également sans cohérence avec le reste du S.I., donc en rupture avec les habitudes de ceux qui doivent le maintenir en bon état, d’autant qu’elle est facilement branlante, n’étant pas maîtrisée par ceux qui l’ont mise en place.

Ainsi vont fleurir les lacs de données là où une base de données relationnelle aurait suffi, ou encore des conteneurs et orchestrateurs de conteneurs, avec un bus d’événements, là où un développement 3 tiers tristement classique aurait parfaitement convenu, etc.

Le S.I. est (localement) vu comme un bac à sable, dont des enseignements seront tirés… pour le prochain employeur. Cette considération du S.I. comme terrain de jeux est d’ailleurs partagée par un autre style d’architecture assez proche, l’Architecture Orientée Plaisir, qui sera décrite plus après.
Il existe une variante de cette architecture, l’architecture ambitieuse, réalisée à coup de « projets ambitieux ». La montagne accouche alors d’une souris borgne et boiteuse, mais très gourmande.

L’Architecture orientée Histoire (AoH)

Cas symétrique du précédent, ici l’architecture dépend directement du passé de celui qui l'a mise en place. Celui-ci a à cœur de reproduire dans sa nouvelle société ce qu’il a déjà connu dans la précédente (autant que possible) : il ne veut pas de surprise, il sait déjà que cela marche, peut-être même a-t-il été embauché pour cela (et sait-il d’ailleurs faire autre chose ?).

Le contexte a changé, les capacités et les compétences de la D.S.I. présente (et les hommes qui la composent ou interagissent avec eux) ne sont pas les mêmes que celles de la D.S.I. précédente. Tout cela n’importe pas. On croit jouer la sécurité, alors que ce faisant on prend un risque (non identifié, non contrôlé). En fait, on a surtout envie de ne pas réfléchir.

Variante de ce style d’architecture, l’Architecture orientée Grand Éditeur, selon le fameux adage « aucun D.S.I. n’a jamais été viré pour avoir installé de l’IBM / du Microsoft / etc. ».

La société malade du contrôle de gestion

Faisons un petit aparté ici pour noter que ces deux premiers styles d’architecture S.I. ont ceci de commun qu’ils ne sont guidés que par des intérêts personnels, soit pour sortir, soit pour entrer dans une nouvelle société. Ceci étant une conséquence directe de la politique RH généralisée de quasi-non-augmentation de salaire (quant au plan de carrière…). La tension ainsi créée entre l’intérêt général et l’intérêt individuel entraîne logiquement une stratégie de contournement toute trouvée : si ma société ne m’augmente pas, alors je change de société avec une augmentation de salaire à la clef [3].

On ne saurait blâmer cette adaptation, mais il est à déplorer que les conséquences de décisions de contrôleurs de gestion et responsables RH (voire de responsables plus hauts placés) concernant la « masse salariale » et le « centre de coûts » que représente la D.S.I., sous couvert d’optimisations mesurables, entraînent des dégradations invisibles de qualité et de pérennité.

[3] C’est un peu comme si des opérateurs téléphoniques ne proposaient de promotions qu’aux nouveaux clients : forcément, cela pousse à aller voir ailleurs.

L’Architecture orientée Organisation (AoO)

Impossible de ne pas la mentionner, c’est la loi de Conway :

« Les organisations qui définissent des systèmes sont contraintes de les reproduire sous des conceptions qui sont des copies de la structure de communication de leur organisation. » [4]

Je ne m’étendrai pas sur cette loi déjà bien connue, qui a donc tout naturellement sa déclinaison au niveau du système… d’information. On obtient ainsi les fameux « silos » absolument partout dans la société, D.S.I. incluse, chaque directeur souhaitant gérer son budget comme il l’entend (comprendre : sans avoir à en discuter avec un quelconque voisin). D’où la dissémination de développeurs, de chefs de projets, d’acheteurs partout, n’importe où dans l’organisation, pour tendre vers un S.I. composé de plein de sous-S.I., à savoir un mini-S.I. par directeur. Résultat cocasse : dans une société, on pourra ainsi trouver plus de développeurs en dehors de sa D.S.I. qu’à l’intérieur.

Notons l’effet de l’égo qui participe à ce phénomène. Pour un responsable d’équipe, il est valorisant de gérer le plus grand nombre de subordonnés possible, mais également le plus grand budget possible. C’est comme cela que l’on monte dans le classement des « managers ».

Sans méthode ni volonté forte au plus haut niveau, la gestion de la complexité d’un S.I. est réalisée très simplement : il suffit de ne pas se parler. Chaque sous-organisation s’isole dès que possible et autant que possible. Au final, le système est cassé. Il en résulte plusieurs sous-systèmes isolés et, le tout ne pouvant alors être supérieur à leur somme, il n’y a pas de propriété émergente globale (raison d’être de « faire système »).

En particulier, toute organisation à vocation transverse, autrement dit cherchant à mettre du liant avec les autres, doit être, précisément pour cette raison, disqualifiée par toutes les autres par tous les prétextes possibles : trop chère, pas assez compétente, manquant de pragmatisme, pas assez réactive, trop lointaine, etc. Les intérêts étant pour une fois convergents, le consensus se fait pour crier haro sur le baudet.

Effet annexe de cette architecture : c’est le bonheur pour les éditeurs qui peuvent proposer un logiciel plusieurs fois à la même société. Son outil n’a-t-il pas été retenu dans un appel d’offres d’une société ? Il pourra toujours retenter sa chance avec cette même société pour outiller le même périmètre logique à l’occasion d’un autre appel d’offres, mais cette fois-ci passé par une autre partie de son organisation. Son outil a-t-il été retenu dans un appel d’offres ? Il pourra tout aussi bien retenter sa chance dans un autre appel d’offres de la même société, avec la garantie qu’il n’y aura pas de renégociation tarifaire par le client (les clients, de facto) pour bénéficier d’un effet de volume.

Au final, gabegie financière et faiblesse capacitaire.

[4] Melvin Conway, How Do Committees Invent?

L’Architecture orientée Plaisir (AoP)

Les informaticiens sont — assez logiquement — des technophiles. Et nombreux gardent, et c’est heureux, une soif de savoir, un esprit de découverte, qui est forcément nourri par une discipline qui ne cesse d’évoluer à un rythme rapide. Ainsi, certains, qui vont être amenés à pouvoir choisir une technologie, vont succomber à la tentation d’en choisir une, parce qu’elle leur plaît, parce qu’ils ne la connaissent pas (encore), parce qu’elle va leur proposer un défi technologique, parce qu’elle va leur permettre d’explorer de nouvelles façons de faire, d’étancher un temps leur soif de savoir et de savoir-faire. Un expert d’un domaine informatique trouvera toujours une évolution de son champ de connaissance et une évolution des — forcément nombreux — domaines connexes à celui-ci.

Cela peut expliquer pourquoi on pourra observer dans un S.I. un foisonnement de technologies plus ou moins exotiques pour répondre de diverses manières à une même question qui se pose plusieurs fois - et qui, donc, ne devrait plus se poser - (plusieurs technologies de serveurs de bases de données relationnelles, plusieurs mécanismes d’échanges d’un même type de données…).

L’informatique devient alors un jouet (au lieu d’être un outil), une fin en soi (au lieu d’être un moyen), et le S.I. se transforme en un terrain de jeux.

À la décharge de ceux qui mettent en place une telle architecture, il faut dire que nous vivons dans une culture qui prône la nouveauté comme une vertu : le temps n’existe plus, puisque nous sommes dans un perpétuel présent, la dernière nouveauté faisant table rase du passé (c’est tout du moins sa promesse). « Le changement, c’est maintenant », puisque avant et plus tard n’existent pas, le changement les ayant fait disparaître. Le changement fait le présent et nous y enferme ; en fait, ce slogan est en creux une définition : maintenant est le changement. Et l’informatique est un terreau particulièrement fertile pour illustrer, encourager cette idéologie : on ne compte plus les « innovations de rupture », les technologies « disruptives ».

Cependant, si, le nez sur le guidon, seul le présent semble subsister, en prenant du recul, la perception est toute autre. Paradoxalement, c’est en fait dans un S.I. où les changements sont les plus fréquents que l’écoulement du temps est le plus visible. En effet, les technologies s’ajoutant sans complètement se remplacer, on peut voir des strates technologiques se superposer pour raconter, comme des strates géologiques, son histoire.

Rappelons aussi, à toutes fins utiles, qu’une nouveauté a émergé dans un certain contexte d’emploi, et n’est pas forcément bénéfique dans un autre. Et que, outre sa pertinence, on ne sait rien de sa pérennité (notion cardinale pour un architecte). Enfin, ce qui est vieux n’est pas forcément obsolète. Une technologie « ancienne » toujours utilisée a le bon goût d’être éprouvée, et ses capacités comme ses limites sont connues et largement documentées. Son utilisation dans son cadre correspondant sera ennuyeusement sûre et n’apportera aucune gloire, aucun frisson, tout au plus la satisfaction d’avoir simplement servi les utilisateurs du S.I. (mais n’est-ce pas là le suprême sens du service de tout informaticien ?).

Nous n’avons ici passé en revue que quelques-unes des architectures catholiques du S.I. Il nous en reste d’autres à dévoiler, que nous vous proposerons dans une seconde partie. 

"Les erreurs ne se regrettent pas, elles s'assument. 
La peur ne se fuit pas, elle se surmonte. 
L'amour ne se crie pas, il se prouve."
Simone Veil

En phase E "Opportunités et Solutions" de l'ADM TOGAF, Aya Dupuis, architecte d’entreprise, doit générer la feuille de route d'architecture, avec une analyse des écarts entre l'architecture de base et les composants candidats de la cible. Une bonne manière d'étudier et de synchroniser différentes solutions est d'utiliser un système de gestion de branches : c'est ce que propose l'éditeur français Obeo avec son outil SmartEA. 

Un acteur dûment authentifié peut accéder, via une URL, aux artefacts du référentiel d'AE.
Ses actions sont fonction des autorisations (prisme dans la terminologie Obeo SmartEA)
qui lui sont octroyées. Ici, Raphaël David, le DSI, visualise les écarts entre une solution commerciale
et une solution interne sur mesure.

Intégration de l'IA : développement sur mesure ou
solution commerciale augmentée avec des modules d'IA ?

La DG de l'institution de prévoyance ABIP doit tenir compte des menaces des pure players intégrant d’emblée l’IA dans tous leurs processus métier. Pour ne pas se laisser distancer par la concurrence et maintenir des tarifs constants, elle doit diminuer ses coûts de développement et d’exploitation.

Pour contribuer à l’atteinte de ces objectifs, il a été décidé en comité de direction, d’intégrer l'IA générative. L'exigence retenue portera sur l'automatisation complète du processus de ranking des mails pour la Relation Client, qui a mauvaise presse et qui doit redorer son blason.

Deux solutions seront à l’étude : un développement sur mesure et une solution commerciale augmentée avec des modules d’IA.

Pour que les différents acteurs puissent collaborer à ces solutions en ayant accès au référentiel partagé d'entreprise, Aya Dupuis a mis en place l’outil Obeo SmartEA associé à Obeo Information System Designer (ISD), outil open source destiné aux architectes techniques et aux concepteurs-développeurs (voir en annexe nos articles sur ISD). 

Comment travailler sur différentes versions
d’une même architecture ?

Pour ne pas se faire disrupter, une entreprise est fréquemment obligée d'innover en adaptant ses processus métier. Pour conserver l’alignement avec le Système d’Information, les architectes doivent proposer différentes branches du référentiel d’Architecture d’Entreprise. La validation d’une transformation passera par la mesure des écarts et une étude d’impacts dus aux changements.

Le meilleur moyen de gérer différentes implémentations possibles d’un même système repose sur les technologies de gestion de branches, comme on en trouve dans le framework open source Git, très populaire dans le monde du développement.

Les normes et standards de modélisation graphiques ont prévu une équivalence textuelle (voir en annexe notre article consacré aux diagrammes en tant que code). Aujourd'hui, la grande majorité des outils stockent leurs modèles dans des fichiers texte utilisant des formats exploitables, comme XML ou JSON.

Ainsi, en intégrant un système basé sur un logiciel comme Git, différents acteurs comme l’architecte d'Entreprise, l’architecte Solutions, l'architecte technique, l’expert métier… pourront accéder aux différentes branches du référentiel.

Il est possible d'avoir plusieurs versions d'un même système
qui pourront converger vers la version courante si certaines conditions sont réunies. 

Obeo SmartEA, un outil branché !

Obeo SmartEA implémente un tel système et offre donc un mécanisme de branches permettant de gérer différentes évolutions de l'Architecture d'Entreprise à l'étude, mais pas encore validées, qui pourront être fusionnées ultérieurement dans la branche principale (master) du référentiel. 

Ainsi, chaque branche donne la possibilité de modifier une version donnée de l’architecture sans impacter les autres versions. Par exemple, la branche principale peut représenter l'état courant validé de l’architecture. Les autres branches, elles, peuvent servir à travailler sur des architectures cibles et, potentiellement, sur des architectures intermédiaires.

De cette façon, il est possible à tout moment de simuler puis de valider des transformations et des évolutions du référentiel, sans perturber la branche principale.

Créez une branche

Un conseil si vous envisagez différentes évolutions d’un modèle : essayez de prévoir, dans la branche source, une disposition de vos éléments qui permettra de mettre en valeur les changements. 

Pour créer une nouvelle branche, vous devez choisir une branche source. Dans notre exemple, il s'agit de partir de l'état courant du référentiel (branche master). 

Aperçu de la strate Motivation de la branche master du référentiel d'AE.

La procédure de création est immédiate : il faut indiquer la branche source et saisir le nom de la nouvelle branche cible.

Vous récupérez ainsi dans la nouvelle branche le référentiel complet de la branche source. Vous avez alors la possibilité d'apporter toutes les évolutions que vous souhaitez.

Nouvelle branche (IA-RPA-No Code), créée à partir de la branche master modélisant,
au centre, les principes d’utilisation de l'IA générative, du RPA et du No Code
avec l’exigence, à droite, “Prioriser les messages clients”.

Analysez les écarts

Obeo SmartEA vous permet très facilement de visualiser les écarts : il suffit de dérouler le menu "Branche", qui se trouve à côté des menus Projet et Prisme.

Lancez l'analyse en sélectionnant "Analyse d’écarts", puis indiquez les deux branches à comparer et cliquez sur "Analyser".

Il est possible de répercuter les différences de la cible sur la source en sélectionnant "Synchroniser".

On retrouve dans la vue Motivation de la version à l'étude (IA-RPA-No Code)
les 3 principes et l'exigence supplémentaires (+ vert) par rapport à la version courante. 

Zoom sur les différences entre la version à l'étude (à gauche) incluant l'IA, RPA et le No Code
et l'exigence "Prioriser les messages clients" et la version de base (à droite). 

Automatisation de la priorisation des messages
de la Relation Client : ChatGPT vs Salesforce

Le besoin est d'étudier les impacts d'un premier scénario consistant à réaliser l'exigence "Prioriser les messages clients" par un développement interne utilisant les API ChatGPT, le workflow No Code Make et la plateforme de développement No code HubSpot et un deuxième scénario utilisant des modules de la solution commerciale Salesforce intégrant de l'IA en environnement cloud. 

Aya Dupuis a créé deux nouvelles branches à partir de la branche IA (IA-RPA-No Code). Elles contiennent toutes les deux la même exigence à réaliser et se distinguent par leurs modèles ArchiMate représentant les diagrammes de mesure d'impacts des deux scénarios précédents.

Scénario #1 : l'association API ChatGPT avec le workflow No Code Make
et la plateforme de développent No Code HubSpot

Scénario 1 : création de la branche "chatgpt-make-hubspot".

Ici, un diagramme d'impacts montrant les composants applicatifs réalisant l'exigence.
Suivant les 3 principes liés à l'exigence (voir précédemment la branche IA), ils doivent utiliser
des logiciels No Code, du workflow (RPA) et de l'IA générative. Les technologies choisies sont :
la plateforme de développement No Code HubSpot pour les fonctionnalités sur mesure du CRM,
le workflow No Code Make et les appels aux API ChatGPT pour l'IA générative.

Scénario #2 : Salesforce Cloud 

Scénario 2 : création de la branche "Salesforce".

Ici, un diagramme d'impacts montrant le composant applicatif réalisant l'exigence.
Les modules "Commerce Cloud" et "Service Cloud" de la solution commerciale Salesforce remplissent
bien les principes d'intégrer de l'IA, de Robotic Process Automation et  sont bien évidemment No Code !

Pour contribuer à la réalisation de l'exigence, chaque intervenant pourra accéder par exemple aux différences entre les deux scénarios, en lançant une analyse d'écarts.

Exemple : liste des écarts entre la solution ChatGPT + Make + HubSpot en développement interne
et la solution commerciale Salesforce.

Exemple : zoom sur le diagramme d'impacts, à gauche, de la solution ChatGPT + Make + HubSpot
en développement interne et, à droite, de la solution commerciale Salesforce.

Et réciproquement.

Vue inverse : liste des écarts entre la solution commerciale Salesforce
et la solution ChatGPT, Make et HubSpot en développement interne.

Vue inverse : zoom sur le diagramme d'impacts, à gauche, de la solution commerciale Salesforce
et, à droite, la solution ChatGPT + Make + HubSpot en développement interne.

La vue technologique de l’automatisation
de la priorisation des messages client

Chaque branche va pouvoir se développer en fonction de la collaboration de chacun des intervenants. Par exemple, Ethan Dubois, l'architecte applicatif, a pu accéder à la branche solution interne (chatgpt-make-hubspot) et cartographier les échanges entre les applications. 

 
Pour diminuer les coûts de développement, l’outil No Code HubSpot a été sélectionné. Grâce à cette plateforme, un composant de CRM avec des fonctionnalités sur mesure pourra être développé à moindre frais.

Après récupération des mails clients dans ce composant CRM, l’outil No Code de workflow Make enverra une requête à l’API de ChatGPT avec un prompt. Conçu par un "prompt engineer", il contiendra à la fois le message et les critères de priorisation formalisés par les experts métier. Ainsi, ChatGPT analysera le message et le classera par degré de priorité.

Ensuite, l’outil d’automatisation de process Make viendra récupérer la réponse et y ajoutera des étiquettes pour le ranking, avant de retourner l’ensemble en utilisant le composant CRM.

Aperçu d'une vue ArchiMate appartenant à la branche solution interne
et montrant les flux entre les composants applicatifs.

Répercutez la solution validée
sur la banche master de l'architecture de base

Les branches vont se développer par l'apport des différents intervenants. Une analyse des risques de chaque branche et ensuite une analyse comparative des charges de travail et des coûts permettront au comité de direction de trancher. Aya Dupuis devra alors synchroniser la branche master avec les différences de la branche validée.

Les pictogrammes surlignés permettent de sélectionner finement
les changements (à droite) à répercuter ou non sur la branche master (à gauche).

Conclusion

La phase E "Opportunités et Solutions" de l'ADM TOGAF prend en compte l'ensemble des écarts entre les architectures cible et de base dans tous les domaines d'architecture et regroupe logiquement les modifications en lots de travaux. Il s'agit d'un effort visant à élaborer une feuille de route la mieux adaptée.

Pour pouvoir gérer efficacement les exigences des parties prenantes, les opportunités, les solutions et les contraintes de mise en œuvre identifiées, Obeo SmartEA propose un référentiel collaboratif supportant un système de gestion de branches emprunté aux logiciels de versioning.

Chaque acteur peut apporter sa pierre à l'édifice en mesurant les écarts et les impacts des différentes solutions.

Après validation d'une solution en comité de direction, l'architecte d'entreprise pourra mettre à jour l'architecture de base en synchronisant la branche correspondante avec celle du scénario validé. 

Merci pour vos commentaires et peut-être serez-vous désireux de faire partager vos retours d’expérience ou vos idées sur l’architecture d’entreprise et l’art de la modélisation de système.

Alors, écrivez-nous et nous serons heureux de publier vos articles.

“Le vieux monde se meurt, le nouveau monde tarde à apparaître
et dans ce clair-obscur surgissent les monstres.”

Antonio Gramsci

Comment documenter les strates Métier et Fonctionnel, une fois que l’on a les strates Application et Technique ? Un lecteur attentif de notre blog www.urbanisation-si.com, qui monte une cellule d'urbanisation dans une grosse entreprise, nous pose beaucoup de questions pertinentes, qui peuvent être séparées en deux catégories :
des questions techniques et des questions organisationnelles, voire existentielles.

Comment documenter les 2 strates hautes du modèle Cigref ?

"The Software Architect Elevator"

Bon, autant le dire dès le début, nous n'aimons pas le terme "cellule" pour désigner une équipe qui doit être ouverte à toutes les autres, de la Direction Générale jusqu'aux spécialistes systèmes et réseaux. A moins que vous soyez attiré par la vie monacale, essayez de trouver un terme plus adéquat.

P.S. Nous n’aimons pas non plus le concept de « Centre d’Excellence », qui sous-entend que les autres équipes sont médiocres.

Plus qu'un phare qui éclaire dans la nuit, une tour de contrôle, qui donne des instructions précises aux pilotes que sont les urbanistes et les architectures d’entreprise, serait mieux appropriée. Certains proposent plus pragmatiquement l’image d’un ascenseur*, qui effectue des allers-retours incessants entre le sous-sol et le dernier étage (oui, oui, nous savons tous quelle équipe est située au dernier étage).

*The Software Architect Elevator (O’Reilly, 2020), par Gregor Hohpe, co-auteur des Enterprise Integration Patterns (Addison-Wesley, 2012).

Le modèle en strates du Cigref

Les strates de l'urbanisation, selon le Cigref

Une cartographie est déjà faite pour les 2 strates basses du modèle Cigref :

• la strate Application (quelques centaines d’applications, regroupées en zones d'urbanisme, avec les flux entre les applications),
• la strate Technique (avec l'infrastructure mise en place et les technologies utilisées).

Effectivement, pour effectuer une cartographie de l'architecture existante, on commence généralement par les strates basses, sous la forme d'un inventaire élaboré.

Questions techniques

Comment documenter les 2 strates hautes du modèle Cigref ?

Les strates hautes sont effectivement plus difficiles à représenter.
La strate Métier est peut-être la plus facile des deux (c'est très relatif).
L'approche par les processus semble être la plus consensuelle.

On pourra distinguer deux niveaux :

• les macro-processus, représentés généralement sous la forme de chevrons. Plusieurs chevrons imbriqués peuvent représenter la chaîne de valeur. On distinguera :
  • les macro-processus opérationnels, dits cœur de métier,
    qui constituent le véritable savoir-faire d'une entreprise,
  • les macro-processus de support ou de soutien
    (que l'on retrouve souvent à l'identique dans d'autres entreprises),
  • les macro-processus de pilotage, pour mesurer
    puis améliorer les macro-processus précédents.

Macro-processus de l'urbanisation du SI

• les processus détaillés au niveau de chaque activité ou tâches. La représentation conseillée est la notation BPMN et il existe de nombreux outils gratuits pour faire cela.
  
  

Exemple de diagramme de collaboration BPMN

La strate Fonctionnel est plus difficile à établir, surtout si l'on utilise des applications du marché (mais alors, cette strate sera-t-elle vraiment utile ?). Si vous développez vous-mêmes vos applications, ce sera peut-être plus aisé. C'est souvent un problème de granularité. Si vous appliquez un style d'architecture moderne comme celle des micro-services, alors ce problème est réglé : une fonction égale un micro-service. Oui, cette démarche d'urbanisation est simplifiée. En tout cas, il faudra au moins une fonction pour effectuer chaque activité ou tâche d'un processus détaillé dans la strate Métier.

Exemple de cartographie fonctionnelle du SI

Comment définir et accompagner la trajectoire ?

Pas si vite ! Il convient d'abord de définir une architecture cible. Cette fois-ci, on commence généralement les strates hautes. Quels nouveaux processus métier mettre en place pour servir la stratégie de l'entreprise ? Puis quelles fonctions sont nécessaires ? Font-elles partie d'une application toute faite ou bien faut-il les développer ? Avec quel style d'architecture, en local ou sur le cloud et avec quelles technologies ? Voilà, vous avez défini votre architecture cible, déclinée sur les 4 strates du modèle Cigref.

Nous ne sommes pas des adeptes du big bang (bien que cela nous plairait, parfois, de pouvoir faire abstraction du passé : legacy systems, dette technique, etc.). Aussi, sera-t-il raisonnable de définir des étapes intermédiaires entre l'architecture existante et l'architecture cible. Méditez la citation à la fin de cet article. Ce sont donc l'architecture existante, les étapes intermédiaires et l'architecture cible qui définissent la trajectoire à suivre.

Comment apporter de la frugalité, de la sobriété, de la sécurité et de la résilience ?

Frugalité

Ce terme est encore peu employé concernant l’urbanisation du Système d’Information et l’Architecture d’Entreprise. Sans doute un synonyme de la réduction des coûts 😉 Pas sûr que l’on arrive, grâce à la démarche d'urbanisation, à faire plus avec moins. Ce que nous visons, c’est de faire mieux : que chaque euro dépensé le soit à bon escient ; que la décision de cette dépense puisse être justifiée de façon rationnelle.

Sobriété

En informatique et plus particulièrement en développement logiciel, la sobriété est bien souvent synonyme de réutilisation (des fonctions, des composants, des modules, des interfaces, des micro-services. etc.). Pour reprendre une formule clef de la méthode Praxeme (Praxeme, la bonne (méthode) à tout faire ?), il faut bannir la redondance : cela vaut notamment pour les données enregistrées dans des bases, qui sont trop souvent multiples.

Sécurité

N.B. La question originelle indiquait la sécurité informatique uniquement. L'approche par les processus métier permet aussi de renforcer la sécurité des personnes, puis des biens.

La sécurité résultait souvent d'une dernière passe effectuée toute à la fin de chaque projet. Il semble évident désormais qu’il faut prendre en compte la sécurité le plus tôt possible dans le cycle de vie d’un projet. En fait, la sécurité devient indissociable de la gestion des risques (TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?).

Résilience

La résilience est une des réponses adaptées aux questions de sécurité et surtout à la gestion des risques (le risque zéro n’existe pas : il faut prévoir des solutions alternatives).

Questions organisationnelles

Quels sont les objectifs du processus d'urbanisation du Système d'Information ?

• Faire connaître le SI existant à travers la cartographie des processus métier et la cartographie applicative, ainsi que le plan de la gestion des risques.
  
  
• Gérer les référentiels MOA des données majeures, ainsi que la mise en place d'outils de gestion de tels référentiels.
  
  
• Elaborer des cibles fonctionnelles, applicatives, techniques, mettre en œuvre des systèmes de traçabilité et de mesure d'impact de la stratégie sur le SI.
  
  
• Aligner l’architecture technique sur l’architecture métier selon les domaines traditionnels :
  • L’architecture conceptuelle ou métier,
  • L’architecture logique ou fonctionnelle,
  • L’architecture physique ou technique.
    
    
• Maîtriser la complexité des flux en les décrivant, en normalisant les données partagées (format pivot), en mettant en œuvre un dispositif d'échange mutualisé.
  
  
• Piloter l'urbanisation du SI et communiquer.
  
  
• Maîtriser la construction du SI en intégrant l'urbanisme dans la gouvernance et les études amont, décider des règles d'urbanisme et les faire appliquer, élaborer les plans de migration.

Quelles sont les règles de l’urbanisation du SI ?

• Pour chaque domaine métier, une cartographie des applications existe et est mise à jour à chaque nouveau projet.
  
  
• Un référentiel de données d’entreprise ne doit pas être géré sans une application spécifique opérationnelle.
  
  
• Pour chaque domaine métier, une cible fonctionnelle existe et est validée par le métier.
  
  
• La construction de tout nouveau système applicatif respecte un modèle en n couches ou mieux une architecture hexagonale (Architecture Hexagonale, exemple de mise en pratique de la méthode DDD Domain Driven Design).
  
  
• Deux applications relatives à deux activités différentes ne peuvent pas gérer une même donnée en accès CRUD (Create, Read, Update, Delete).
  
  
• Une application métier utilise des services d'une architecture SOA (Service Oriented Architecture) de type micro-services par exemple (L’Architecture Micro-Services expliquée à ma fille), pour réaliser les fonctions suivantes : échanges, données référentielles, sécurité, décisionnel, gestion des ressources nécessaires aux processus métier.
  
  
• A l’intérieur d’un SI, les échanges de données entre blocs fonctionnels n’appartenant pas au même domaine ne se font pas en point à point, mais passent par un outil d’échange comme l’EAI (Enterprise Application Integration), un bus logiciel ESB (Enterprise Service Bus), l’Event Streaming (Un problème cornélien de l’EDA, Event Driven Architecture, est de s’assurer de l’exactitude sémantique de livraison d’un message, Kafka l’aurait-il résolu ?).

Questions existentielles

Quels sont les apports ?

• Une méthode pour réaliser des processus ouverts pour les directions métier (MOA)
  
  
• Des recommandations pour faciliter la réutilisabilité, l’évolutivité et la généricité des applications pour les maîtrises d'œuvre (MOE). Tout échange avec les partenaires se fait à travers un portail. La propriété de généricité d’entreprise étendue est remplie avec un seul et même portail pour les employés, les clients et fournisseurs, qu’il suffit de paramétrer selon des règles appropriées.
  
  
• Une meilleure connaissance et une vue d’ensemble de l’existant, la modélisation des objectifs et processus métier, les architectures fonctionnelles et applicatives comme cadre de référence, une meilleure connaissance des projets.
  
  
• Construire une cible fonctionnelle par une approche bottom-up, comme vu précédemment, ou top-down avec des process innovants en mode "open innovation" des startups.
  
  
• Le processus de gouvernance permet d’inscrire l’urbanisme le plus en amont possible, permettant aux architectes d’intervenir le plus tôt possible dans les projets.
  
  
• Un référentiel des processus qui est alimenté par leurs concepteurs, articulé avec le référentiel applicatif et les fonctions de la cible d’urbanisme, permettant une continuité entre les modèles de processus, fonctionnels et applicatifs.
  
  
• Une meilleure intégration MOA et MOE permettant, entre autres, l’automatisation des processus métier.

Quel est le retour sur investissement (ROI) de l’urbanisation de SI

C’est celui d’une infrastructure caractérisée par un investissement à la création, puis par un coût d’entretien. Au début des surcoûts apparaissent ; viennent ensuite les économies réalisées :

• la réduction des études amont,
  
• l’anticipation des impacts des autres projets,
• la réduction du périmètre des projets,
• la réduction des études, des développements et de la recette,
• la réutilisabilité de blocs applicatifs,
• l’existence de règles permettant aux projets de se concentrer sur les aspects métier.

Dès que l’apport de valeur dépasse le cumul des surcoûts, le ROI est atteint.

Qui suis-je ?

Un urbaniste de SI est plutôt un ancien responsable de domaine métier, généralement transverse. Il peut avoir été à ses débuts un architecte logiciel ayant acquis une solide expertise métier au bout d'une dizaine d'années d'expérience au service de grands projets réussis. Dans les grandes entreprises, l'urbaniste du SI peut être rattaché à la DG, plutôt qu'à la DSI.

S’il est interne à l’organisation, il établit sa crédibilité personnelle avec le métier et les parties prenantes, il doit montrer la valeur de la démarche d’architecture, accompagnée de sa méthode. S’il est consultant externe, il doit démontrer sa crédibilité, ainsi que celle de la société de services qu’il représente.

Il doit établir la vue des besoins métier, formuler les perspectives explicites ou implicites de l’organisation, en utilisant par exemple l’outil “business model canvas”, qui présente la manière dont une organisation crée de la valeur et se l’approprie. L’objectif est de préparer la proposition de vision et de périmètre de l’architecture.

L’urbaniste du SI décrit les avantages quantitatifs et qualitatifs de la démarche d'urbanisation. Une des tâches est de définir les concepts d’architecture. Il s’agit de modéliser l’état actuel du métier, puis l’état souhaité, ce qui va servir de base à la conception du plan de transformation de l’organisation.

Les exigences des parties prenantes sont recueillies avec les méthodes standards d’analyse de documents, d’interview, de groupe de travail, de brainstorming et d’observation. Pour faciliter l’adhésion des parties prenantes, il faudra détecter les soutiens et les résistants au changement.

Les solutions possibles sont identifiées. La panacée passe par un brainstorming, une évaluation des dépendances, une estimation des coûts et une analyse des contraintes. L’objectif est de proposer plusieurs solutions, puis de concevoir la solution choisie et la mettre en œuvre (Les étapes d'un schéma directeur).

La solution acceptée doit être déployée. La mise en œuvre pouvant s’effectuer sur une période significative, un processus de gestion des changements devra être élaboré, dans une perspective de résolution consensuelle des conflits.

Où vais-je ? Dans quel état j'erre ?

L’IA aura sûrement un rôle à jouer dans les décisions des comités de direction.

Architecte de la chaîne de valeur

L’avenir de l’architecture d’entreprise pourrait se trouver dans les patterns organisationnels modélisant les structures communes de plusieurs entreprises. Les limites du BPM (comme les processus métier dynamiques et ad hoc) sont trop souvent mises sous silence et doivent au contraire être référencées.

Dès lors, le champ des préoccupations d'urbanisme débordant le monde clos de l'entreprise, il faudra raisonner sur l'entreprise et son écosystème. Les flux, la gestion des grands référentiels, l'activation de services automatisés, de bases de connaissances, seront à situer dans un contexte élargi, où les mouvements stratégiques, partenariats, fusions, filialisations, acquisitions, externalisations, pourront redistribuer les cartes autour des composants urbanisés.

Les urbanistes, devenant architectes de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action. Il faudra se préoccuper de diffuser la culture du management par les processus, de faire passer le BPM dans la réalité : instituer des propriétaires de processus, gouverner l'amélioration et piloter les performances, pour que les processus répondent aux services qu'attendent les multiples parties prenantes, clients, usagers, partenaires, employés, actionnaires, sociétaires…

Catalyseur de cohérence

Les processus sont considérés comme une entrée, et l'urbaniste n'a pas de légitimité pour les optimiser, voire les remettre en cause.

Pourtant, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transverses, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : l'urbaniste sera le catalyseur de la cohérence, de la transversalité, et de la flexibilité.

Urbaniser le métier et architecturer l'entreprise tirent les urbanistes vers le haut, que leur référence s'appelle Urbanisme des SI, Architecture d'Entreprise ou Gestion des Processus Métier (BPM Business Process Management).

Ils ne doivent pas ignorer les évolutions techniques. Un miracle technologique se produira-t-il (attention aux effets de buzz) ? Une révolution technique donnera-t-elle l'agilité instantanée tant espérée ?

Les grandes entreprises, dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire multiple, protéiforme, à des contraintes de marché archi-mondialisé. Il leur faudra lutter férocement contre l'entropie et rechercher toujours plus d'agilité.

Architecte d'Entreprise augmentée

Dans le futur, tel un funambule, l'urbaniste devra maintenir l'équilibre sur une corde qui sera disposée malheureusement de plus en plus haut.

La gouvernance doit constamment faire de la prospective, afin de maintenir ses informations sur l’IA, devenue un domaine hautement stratégique. Le rôle de l’architecte d’entreprise peut être renforcé par celui d’un architecte des données (CDO Chief Data Officer) au service de la création de valeur et donc de l’IA.

Les entreprises entamant leur transition numérique devront composer des équipes aux triples compétences : métier, informatique et mathématiques, sous la direction du CDO.

Un jour peut-être, une bonne fée, nommée IA, apparaîtra avec sa baguette magique, et grâce à son omniprésence et sa protéiformité, comme le RPA (Robotic Process Automation) ou les chatbots, et déclenchera une disruption et fera naître une Architecture d'Entreprise augmentée.

L’IA aura sûrement un rôle à jouer dans les décisions des comités de direction (Architecture d'Entreprise augmentée, quelle influence de l’Intelligence Artificielle sur la gouvernance et la stratégie ?).

“Il n'y a pas de grande tâche difficile qui ne puisse être décomposée en petites tâches faciles.”
Shantideva, grand maître bouddhiste du VIIe siècle.

Compléments de lecture

• TOGAF 10, quelle méthodologie d’architecture de sécurité et de gestion des risques ?
   
• Architecture d'Entreprise augmentée, quelle influence de l’Intelligence Artificielle sur la gouvernance et la stratégie ?
   
• Exemple de méthode d’Architecture d’Entreprise d’un grand cabinet de conseil : EAM Enterprise Architecture Management de McKinsey L’Enterprise Architecture Management (EAM) de McKinsey est une méthode pour gérer
   
• Le rôle de la prospective pour une entreprise innovante et résiliente
   
• Méta-physique ? Non, méta-modélisation !
   
• Les meilleurs articles sur l’architecture d’entreprise, ses méthodes et ses outils, découvrez quels sont les articles les plus lus de notre blog
   
• La méthode top-down dans l'urbanisme du Système d'Information
   
• TOGAF pour les nuls.
   
• Agilité logicielle : quelle solution pour diminuer le couplage entre sous-systèmes et obtenir une architecture logicielle agile ?
   
• Architecture Hexagonale, exemple de mise en pratique de la méthode DDD Domain Driven Design
   
• Les couches de l'Architecture Microservices et la méthode de conception DDD (Domain Driven Design)
   
• ADOIT:CE pour la gestion de l’Architecture d’Entreprise

L’Enterprise Architecture Management (EAM) de McKinsey est une méthode pour gérer l’alignement de l’architecture informatique avec les besoins métier. L’EAM s’appuie sur un modèle en six couches, regroupées en trois domaines : le business model, le panorama applicatif et l’infrastructure.

Le modèle en 6 couches de l’Enterprise Architecture Management (Source McKinsey)

McKinsey et la réduction des coûts

McKinsey est un cabinet de conseil qui met son expérience, ses connaissances, ses méthodes et ses outils à la disposition de son réseau mondial, tout en développant des solutions originales et créatives, adaptées à chaque situation particulière, au service des intérêts de ses clients afin de définir et de mettre en œuvre une vision intégrée du changement.

McKinsey est mondialement connu pour ses préconisations en stratégie et plus particulièrement en méthode de réduction des coûts. Nous allons voir dans cet article que cette approche est évidemment bien intégrée dans sa méthode d’Architecture d’Entreprise.

Un peu de révision

L'architecture informatique (IT) d'une entreprise est une description formelle de ses applications et des données qui les prennent en charge, ainsi que des équipements et des services qui exécutent ces applications.

Le modèle d’Architecture d’Entreprise spécifie une solution alignée prenant en compte aussi bien l’humain que les processus, la technologie et la culture de l’entreprise, en répondant aux exigences de la transformation digitale.

L’un des enjeux de l'Architecture d’Entreprise est de simplifier la représentation du système, jugé complexe, de l’entreprise, afin de la rendre plus agile. 

Les applications sont généralement conçues et déployées pour répondre aux besoins d'une division ou d'une unité commerciale, sans tenir compte de l'impact sur l'architecture informatique globale d'une entreprise.

Les grandes entreprises possèdent un patrimoine informatique important et hétérogène, où du matériel, des applications et des processus incompatibles et souvent redondants, se multiplient d'année en année, dans tous les recoins de l'organisation, en réponse à des besoins spécifiques à court terme.

Pour créer une architecture informatique efficace, la DG doit créer un groupe de travail métier-informatique de haut niveau, qui assure la gouvernance et la responsabilité inter-organisationnelles. Les principales responsabilités de cette équipe sont d'examiner l'architecture informatique existante et de créer une base de référence pour la nouvelle initiative, de définir un processus garantissant que les systèmes et les projets seront conformes à l'architecture souhaitée, et d'identifier les opportunités à court, moyen et long termes pour des économies et des améliorations.

L'équipe doit inclure tous les groupes de parties prenantes clés, avec des représentants à un niveau suffisamment élevé pour prendre des décisions stratégiques.

Une transformation en 3 coups de baguette magique

Une approche en trois phases de la transformation digitale permet de minimiser les interruptions de l'activité de l’entreprise.

Les 3 étapes de la méthode "Enterprise Architecture Management" (Source McKinsey)

Première phase : le grand nettoyage de printemps

Décommissionnement d'applications et réduction de la complexité (Source McKinsey) 

Dans la première phase, la tâche pour le département d’Architecture d’Entreprise est d'identifier des cibles évidentes et de générer des gains rapides, grâce à des réductions de coûts qui contribuent à créer une dynamique pour des initiatives plus importantes. Comme pour un particulier ayant contracté des abonnements à des médias qu’il n’utilise plus, l’entreprise doit résilier les services et les licences dont elle n’a plus besoin.

Concernant les projets en cours, ceux qui apportent peu de valeur métier, on annule les non-conformes à la stratégie IT et l'on retarde ceux qui le sont. On doit repenser ceux qui sont liés aux objectifs majeurs métier, mais qui ne sont pas en adéquation avec la road map IT et continuer ceux qui la suivent. 

Les applications peu ou jamais utilisées doivent être décommissionnées. Différentes approches peuvent être nécessaires : en fonction de l'utilisation et des besoins, certaines peuvent être retirées immédiatement, d'autres remplacées par de nouvelles applications, et d'autres encore supprimées progressivement.

L'entreprise doit se concentrer sur les violations potentielles de l'architecture informatique au début de tout projet informatique ou lors de la sortie d'une nouvelle application. La nouvelle approche, qui consiste à évaluer les implications globales des violations, y compris leur éventuel coût supplémentaire, permet à l'entreprise de prendre en charge rapidement les nouvelles exigences métier, mais nécessite que toutes les violations qu'elles créent soient corrigées dans une phase ultérieure. L'entreprise peut donc évaluer les compromis coûts/avantages métier et informatique dans chaque cas, avant d'aller de l'avant avec les projets.

Deuxième phase : démêler les spaghettis

Réduire la complexité : la cellule d’Architecture d’Entreprise doit tout mettre en œuvre afin de simplifier l'ensemble de l'architecture informatique. Plus ambitieuse, cette étape est primordiale pour enrayer la multiplication des développements des applications sur mesure et pour initier une gouvernance pour la réalisation des objectifs d’architecture. Plutôt que d'essayer d’optimiser des éléments de la configuration informatique existante, il faut décider prioritairement s’ils sont vraiment indispensables. Une bonne pratique est de privilégier des systèmes prêts à l'emploi plus simples et la réutilisation de composants existants, qui peuvent répondre aux besoins de l'entreprise. 

Privilégier les solutions sur étagère

Des projets stratégiques entièrement développés sur mesure échouent à cause d’une sous-évaluation de la difficulté technique de réalisation. En effet, trop de projets adoptent la personnalisation comme première, option plutôt que comme dernière option.

Une entreprise ne peut pas faire en sorte que toutes ses unités métier adoptent immédiatement des applications standard et totalement non personnalisées, mais compte tenu des ressources limitées, l’entreprise devrait exiger des solutions prêtes à l'emploi dans la grande majorité des cas, permettant la personnalisation uniquement lorsque cela est absolument nécessaire, pour répondre aux exigences légales ou pour fournir des avantages concurrentiels significatifs.

Par exemple, les fonctions de support telles que la finance, la comptabilité, les ressources humaines et les achats, qui ne jouent généralement pas un rôle en concurrence directe avec d'autres entreprises, sont des candidats de choix pour réaliser des économies dans cette phase. 

Ne pas réinventer la roue

Trop d'entreprises dépensent de précieuses ressources informatiques pour réinventer la roue. Un examen sérieux du portefeuille de projets existant permettra probablement de découvrir un certain nombre d'opportunités, de réutiliser les solutions existantes et de créer un référentiel commun de services et de solutions.

Le passage à une architecture micro-services, qui décrit un système en termes de fonctionnalités métier dont il a besoin et la manière uniforme d'y accéder et d'interagir avec elles sous forme d’API (Application Programming Interface), est un élément important de cette évolution.

Standardiser les technologies

Dans de nombreuses entreprises, la grande diversité des technologies, y compris les langages de programmation, des systèmes d'exploitation et des outils d'intégration, nuit à l’efficience. Un examen attentif mettra en évidence les versions redondantes, les technologies non prises en charge et les outils non standard, qui devraient céder la place à des systèmes moins nombreux et plus universels. Les économies de coûts proviennent d'un approvisionnement plus simple et consolidé, ainsi que d'une diminution des dépenses d'assistance et de maintenance.

Supprimer la tour de Babel entre applications

Une équipe informatique peut consacrer une bonne partie de son temps à développer des interfaces de communications entre applications. Par exemple, une solution telle qu’un bus de services d'entreprise (ESB) peut améliorer l'intégration du système et minimiser la gestion fastidieuse des modifications locales.

Factoriser les systèmes qui font des traitements similaires

Différentes unités métier d'une même entreprise ont souvent leurs propres versions de systèmes fondamentaux, tels que les plateformes d'e-commerce. La conception d’une surcouche générique abstraite de ces systèmes au niveau de l'entreprise peut apporter des économies substantielles et rendre les processus plus simples et plus efficaces.

Certaines de ces opportunités de réduction des coûts nécessiteront des investissements, et chacune d'entre elles exigera une analyse de rentabilité solide.

Toutes ces bonnes pratiques ne montreront pas forcément un ROI positif. Ce qui importe, c’est que les responsables prouvent la plus-value métier de chacun de leurs projets. En moyenne on peut escompter un ROI de plus de 50 %, une réduction du time to market d'au moins 30 % et des avantages organisationnels notables, comme un meilleur alignement entre l'entreprise et l'informatique.

Troisième phase : disrupter le métier

En temps de crise, les entreprises doivent envisager de se transformer, voire de se réinventer complètement. L'informatique peut jouer un rôle central dans la mise en œuvre de grands changements, dans leur mode de fonctionnement et de mise sur le marché de produits ou de services. Les entreprises doivent envisager de changer leur informatique de manière plus radicale de manière à stimuler ou soutenir l'innovation stratégique et des domaines de croissance fondamentalement nouveaux. 

Évaluer des modèles de fonctionnement alternatifs

Un examen complet de la chaîne de valeur informatique doit identifier le niveau d'approvisionnement, d'harmonisation, de consolidation, de gouvernance et d'activation informatique nécessaires pour chaque capacité métier essentielle. Cet examen peut conduire à un nouveau modèle de plan directeur et d'architecture plus efficace pour l'informatique.

Par exemple, la gestion et la minimisation des risques, qui sont particulièrement importantes en période de ralentissement, dépendent fortement de l'obtention des bonnes données de l'ensemble de l'entreprise pour soutenir la prise de décision. Les responsables métier et informatique doivent travailler de concert pour concevoir le modèle de données qui favorisera les processus de décision les plus efficients.

Façonner l'avenir

Les chefs d'entreprise doivent travailler en étroite collaboration avec le service informatique pour explorer les investissements dans un large éventail de technologies émergentes, qui prennent en charge de nouvelles méthodes de travail, comme la gestion basée sur l’Intelligence Artificielle. 

Les déclencheurs de cette approche plus ambitieuse de la transformation architecturale peuvent varier d'une entreprise à l'autre. Pour une mutuelle par exemple, il s'agissait d'une fusion qui la propulsait dans le haut du classement de son secteur. Malgré cela, il était difficile de se maintenir avec deux modèles de fonctionnement différents reposant sur des systèmes d'information archaïques.

Après avoir défini un nouveau modèle opérationnel global intégré pour les assurés, les prestations, les cotisations, la gestion du cycle de vie des produits et les services antifraude, la mutuelle l'a mis en œuvre avec une architecture informatique rationalisée. L'impact a été considérable. Parmi de nombreux autres avantages, elle a réduit le temps nécessaire pour répondre à des appels d'offres pour les différentes branches professionnelles.

Conclusion

Au sein d’une entreprise, il peut y avoir beaucoup de gâchis.

L’EAM de McKinsey impose la recherche puis la suppression des contrats, licences et services qui ne servent plus et qui sont oubliés depuis bien longtemps. 

Les équipes projet doivent penser réutilisabilité ou progiciels du commerce, avant de se lancer dans des développements spécifiques très risqués. 

L’innovation doit être facilitée, grâce notamment à une collaboration étroite entre la DG, les responsables métier et informatique. 

Pour survivre aux disruptions, tout le monde sait qu’il faut une plus grande flexibilité, des délais de mise sur le marché plus rapides, des processus métier plus efficients. Un bon moyen d’y parvenir est de mettre de côté les méthodes du passé trop rigides et d'innover avec des méthodes en perpétuelle évolution. 

Cela a conduit les cabinets de conseils comme McKinsey, les ESN comme Capgemini (avec son IAF - Integrated Architecture Framework), ainsi que les grandes organisations à créer leur propre méthode d'Architecture d'Entreprise.

Une idée : pourquoi ne pas opérer des fusions, comme dans ce domaine des méthodes agiles avec Scrumban, en prenant ce que chacune a de meilleur ? Alors, à quand TOGEAM ?

“Durant 30 ans, en Italie, ils ont eu les Borgia, la guerre civile et la terreur. 

Cela a produit Michel-Ange, Léonard de Vinci et la Renaissance. 

En Suisse, ils ont eu cinq siècles de paix et de fraternité et qu’est-ce que ça a donné ? 

La pendule à coucou ! ”

Jean-Christophe Grangé

L’année 2020 vient de s’écouler à tout jamais. Quel est le top 10 des articles les plus visités par nos amies lectrices et amis lecteurs de notre blog consacré à l’architecture d’entreprise, aux méthodes et aux outils, ainsi qu’à l’ensemble des aspects de la modélisation ?

(Etude Accenture sur les leaders, développant les systèmes futurs et les retardataires [laggards], qui investissent dans l'innovation, mais ne parviennent pas à en tirer la pleine valeur.)

Pour entretenir le suspens, commençons par la dernière position.

10

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

ADOIT:CE pour la gestion de l’Architecture d’Entreprise

Comme le suggère le titre de notre blog, la mise en œuvre de l’Urbanisation du Système d’Information et de l’Architecture d’Entreprise doit se faire avec méthode. Mais sans outil adéquat, l’application d’une méthode s’avère vite laborieuse.

Rappelons qu’il s’agit de mettre en place un référentiel d’architecture (généralement stocké dans une base de données) contenant des objets, qui seront ensuite utilisés pour créer des modèles (diagrammes, matrices, listes et rapports).

Les articles de notre blog concernant les outils rencontrant généralement un grand succès, en voici un concernant un outil intéressant, et pas seulement parce qu’il est gratuit.

Voir la catégorie Modélisation de système de notre blog :

• Modélisation de système

9

L’Architecture Micro-Services expliquée à ma fille

L’Architecture Micro-Services expliquée à ma fille

Le nouveau style d’architecture pour concevoir des applications informatiques, voire pour urbaniser enfin le Système d’Information de l’entreprise.

Au lieu de dupliquer en entier des applications monolithiques, il s’agit désormais de distribuer, et même de dupliquer certains micro-services uniquement, sur différents serveurs. Tout en gagnant en flexibilité et en agilité, pour effectuer plus rapidement des changements, le plus souvent des améliorations.

Une application partitionnée en micro-services est plus robuste qu’une application monolithique. Un micro-service en panne ne bloque pas forcément toute l’application, qui devient alors résiliente.

C’est une évolution de la SOA (Service Oriented Architecture) : certains parlent de l’Architecture Micro-Services comme la SOA à grains fins. Elle ne remet pas en cause la SOA, mais propose des solutions techniques plus légères, souvent Open Source, comme RESTful notamment.

Voir la catégorie Architecture Micro-Services de notre blog :

• Architecture Micro-Services

8

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?

Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?

Un use case UML (cas d'utilisation) est une activité métier comme, par exemple, un acte de gestion exécuté par un acteur externe à l'application.

Un use case comporte un ou plusieurs scénarios composés d’une ou plusieurs étapes.

Les scénarios peuvent être des cas nominaux où tout se passe bien, des cas alternatifs ou des cas exceptionnels conduisant à une exception métier.

Les retours d'expérience ont permis d'élaborer la méthode dite des "10 ; 10".

Un use case doit avoir en moyenne 10 scénarios, composés chacun d'environ 10 étapes. De plus, il doit être déclenché par un unique acteur (rôle), exécuté dans une limite de temps, être transactionnel, avoir un début et une fin et pour terminer on doit avoir l'unicité de lieu.

Voir la catégorie UML de notre blog :

• UML

7

Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio

Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio

Le diagramme de contextes de projets modélise tout ce qui est nécessaire à la réalisation d’un projet : acteurs, processus métier, règles métier, services métier, entités métier, composants applicatifs.

Ce modèle est réalisé par les architectes applicatifs et experts métier avec comme référents les experts métier à destination de la Direction Générale, DSI, responsables de domaine métier.

6

Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants

Le meilleur du meilleur des outils de modélisation de Systèmes d’Information pour 2017 : les « Modsars » de « urbanisation-si.com » récompensent les plus innovants

Les Modsars de « urbanisation-si.com » récompensent les meilleurs logiciels de modélisation de Système d’Information.

Nos critères sont sans commune mesure avec les récompenses de références comme, par exemple, celles du Gartner.

Nous privilégions l’open source, la communauté et le partage d’informations, l’innovation, la fiabilité en production, la documentation.

Les domaines concernés sont ceux des catégories du site de « urbanisation-si.com » :

• les normes de l’OMG comme UML, BPMN, SysML, DMN, BMM, OCL, MDA, QVT, XMI,
• ArchiMate
• les architecture d’entreprise comme Togaf, l'urbanisation du SI, Praxeme,
• l’Ingénierie Dirigée par les Modèles avec MDE, ATL, Ecore...
• les processus métiers et le BPM
• les règles métiers et les BRMS
• la simulation et la validation de modèles
• la génération de code à partir de modèles
• la gestion de projet avec les méthodes agiles, les méthodes d’estimation et de recettes.

Voir la catégorie Modélisation de système de notre blog :

• Modélisation de système

5

BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

Voici l'exemple de référence de modélisation BPMN présentant les concepts principaux des processus métiers.

L'objectif de cet article est de montrer concrètement comment un processus métier est modélisé avec BPMN.

L'accent est mis sur les concepts de « bassins » (pool) modélisant les échanges (associations) inter organisation et de « couloirs » (lane) représentant la communication (flux de messages) explicitant la modélisation des collaborations entre des participants.

Cet article montre comment nous pouvons composer des modèles de processus avec des sous-processus et appeler des activités.

Cet exemple ne contient pas de modèles de processus exécutables, mais représente un modèle de processus se concentrant sur les aspects organisationnels de processus métiers.

Voir la catégorie BPMN de notre blog :

• BPMN

4

ArchiMate pour les nuls : les fondamentaux - 1

ArchiMate pour les nuls : les fondamentaux - 1

L'adoption du standard ArchiMate par le monde de l'architecture d'entreprise a connu une croissance rapide au cours de ces dernières années. 

Si d’autres notations sont couramment utilisées par les architectes d'entreprise comme BPMN, DMN et UML, ArchiMate se distingue par son périmètre de modélisation couvrant à la fois les métiers et l’IT, le rendant particulièrement bien adapté pour améliorer l'alignement stratégique, métiers et IT.

Le cœur du framework comprend les couches métiers, applicatives et technologiques, avec des couches supplémentaires pour la stratégie, les éléments physiques, l’implémentation et la migration.

En intégrant les métiers et l’IT, ArchiMate répond aux principales attentes des parties prenantes de l’entreprise : le standard fournit un ensemble commun de concepts et de vues qui décrit toutes les couches de l'entreprise.

D’autre part, de nombreux concepts et relations dans ArchiMate sont basés sur les notations UML et BPMN, offrant une passerelle vers ces langages de modélisation. Mais ArchiMate ne cherche pas à remplacer ces standards.

Une grande partie de son succès peut en effet être attribuée au fait qu'ArchiMate inclut uniquement les concepts et les relations qui sont utiles, ce qui résulte en une courbe d’apprentissage très rapide de ce standard.

ArchiMate répond également à l'exigence des cadres dirigeants qui est d’avoir une vue d'ensemble de l’entreprise.

Le framework utilise des vues centrées sur les besoins spécifiques des différentes parties prenantes de l’entreprise, avec des objets pouvant provenir de différentes couches.

Par exemple, il est possible de montrer les applications, les technologies et les processus dans un seul et unique diagramme. 

Voir la catégorie ArchiMate de notre blog :

• ArchiMate

Dans l’annexe de cet article se trouvent les 37 articles de l'étude de cas :

• ArchiMate : le diagramme de contextes de projets, comparaison du diagramme UML de TOGAF et celui avec ArchiMate - 37

3

La méthode top-down dans l'urbanisme du Système d'Information

La méthode top-down dans l'urbanisme du Système d'Information

La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le Système d'Information et enfin le Système Informatique.

En haut, juste en dessous de la stratégie d'entreprise qui ne fait pas partie de l'urbanisation du SI, on trouve la cartographie métier avec les processus métiers et leurs événements déclencheurs, puis en dessous, la cartographie fonctionnelle structurant le système d'information avec des blocs fonctionnels, un niveau encore en dessous, on trouve la cartographie applicative constituée de composants applicatifs du système informatique et enfin tout en bas la cartographie technique représentant l'infrastructure technique du système informatique.

Voir la catégorie ArchiMate de notre blog :

• Le processus d'urbanisation du Système d'Information

2

SysML : le diagramme d'exigence (requirement diagram)

SysML : le diagramme d'exigence (requirement diagram)

Lors de la modélisation de leur système, un grand nombre d’entreprises ont cherché à représenter les exigences afin d'assurer la traçabilité vers les modèles de conception UML.

Malheureusement, UML ne proposant pas de diagramme d’exigences, elles ont d’abord créé leurs propres profils UML ou bien utilisé des outils propriétaires. 

UML ne prévoit rien pour représenter des éléments non-logiciels, des équations mathématiques, des contraintes, des flux (énergie, fluide...), des allocations structurelles/comportementales... 

Et enfin UML utilise la terminologie orientée objet (classe, attribut, méthode...) qui si elle convient bien aux méthodes et langages de programmation objet, n'est pas celle adoptée par l'ingénierie système.

En l’absence de langage de modélisation normalisé dans le domaine des systèmes industriels complexes, l’OMG a créé un profil UML (package de stéréotypes, tags/values et contraintes OCL), nommé SysML en n'oubliant pas cette fois le diagramme d’exigences.

Voir la catégorie SysML de notre blog :

• SysML

Dans cet article se trouvent les articles traitant : 

• le contexte d'utilisation et la syntaxe des diagrammes SysML
• un exemple complet composé de 12 articles pour illustrer l'utilisation des diagrammes
• 25 articles expliquant la méthode et les bonnes pratiques accompagnées d'un nouvel exemple complet
  • SysML pour les nuls : de la modélisation des exigences à la réalisation du système

1

TOGAF pour les nuls

And the winner is...

TOGAF pour les nuls

Au tout début, dans les années 70 à 80, il y avait SOA, je veux parler bien sûr de “Silo Oriented Architecture”, où les architectures propriétaires régnaient en maître (IBM, Bull, DEC…).

Puis, dans les années 90s, toujours SOA, mais cette fois pour “Spaghettis Oriented Architecture” avec l’avènement des serveurs d’application.

Avant internet, en France on avait le Minitel, de même avant l’architecture d’entreprise, on avait l’urbanisation du Système d’Information (~1980 dans le domaine bancaire).

L’enjeu principal est de mettre l’IT en adéquation avec le métier. 

A cette époque, l’aspect stratégie est l’apanage de la DG et est négligé dans l'urbanisation du SI. 

L’alignement stratégique, la création de référentiels, la définition de scénarios de transformation et l’analyse d’impact ont commencé aux USA avec PRISM framework (1986, IBM), le framework de Zachman (1987) (Architecture d'entreprise : le framework de Zachman pour les nuls), NIST EA model (1989), puis avec DoDAF (~2000, Department of Defense Architecture Framework).

A partir de là, on commence à voir apparaître en France des méthodes. 

La Délégation Générale pour l'Armement a élaboré son cadre de référence : Agate (Atelier de gestion de l'architecture des systèmes d'information et de communication, ~2000). 

En 2003, la méthode Praxeme (PRAXEME, la bonne (méthode) à tout faire ?) voit le jour autour d’une nouvelle architecture appelée SOA Service Oriented Architecture. 

Voir les catégories de notre blog :

• Architecture Orientée Services (SOA)

• • Architecture technique SOA
  • Gouvernance SOA

Aujourd’hui en France, l’urbanisation du S.I. et Architecture d’Entreprise sont devenues synonymes. 

En 1995, la première version de TOGAF (The Open Group Architecture Framework) est publiée. La transformation de l’architecture d’entreprise a sa méthode générique avec des solutions sur étagères.

Évidemment l’objectif suprême est la réalisation d’applications opérationnelles.

Pour se faire, il faut une vision globale couvrant les aspects stratégiques, métiers, organisationnels, s’assurer de l’alignement entre le métier et la technique, rechercher constamment l’évolutivité des SI et avoir une culture de l’innovation.

Tous les métiers évoluent, le simple développeur disparaît pour devenir fullstack, DevOps voir DevSecOps, l’architecte d’entreprise se métamorphose pour préparer des scénarios d’innovation et anticiper les impacts des tsunamis que sont l’Intelligence Artificielle (Machine Learning, Deep Learning, Big Data), le Cloud [IaaS, PaaS, SaaS, FaaS], IoT, DevOps CI/CD, Microservices Architecture…

On peut continuer le parallèle entre le développeur qui n’a plus à mettre en place la chaîne de réalisation d’une application, grâce aux nouveaux outils d’automatisation DevOps CI/CD, et l’architecte d’entreprise qui n’aura plus à assurer la traçabilité métier - IT, qui se fera automatiquement avec les outils d’IA d’analyse des données.

Voir la catégorie TOGAF de notre blog :

• TOGAF

Dans l’annexe de cet article se trouvent les 41 articles de l'étude de cas :

• Le diagramme de contextes de projets de la phase E Solutions et opportunités de TOGAF - étape 41 de l’exemple Modelio

Rhona Maxwel

@rhona_helena

“Celui qui n'appliquera pas de nouveaux remèdes doit s'attendre à de nouveaux maux ; car le temps est le plus grand des innovateurs.”
Francis Bacon

Références des principaux articles du blog

TOGAF

1. TOGAF pour les nuls.
   
   
2. Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
   
   
3. La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
   
   
4. Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
   
   
5. Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
   
   
6. Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
   
   
7. Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
   
8. Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
   
9. Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
   
10. La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
11. La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
12. Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
13. Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
14. L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
15. L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
16. L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
17. L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
18. L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
19. L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
    
    
20. Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture
    
    
21. Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise
    
    
22. Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?
    
    
23. Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces
    
    
24. Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace
    
    

ArchiMate

1. ArchiMate pour les nuls : les fondamentaux - 1
   
   
2. ArchiMate la synthèse : les éléments de motivation - 2
   
   
3. ArchiMate en condensé : les éléments de stratégie - 3
   
   
4. ArchiMate l’essentiel : les éléments de la couche métier - 4
   
   
5. ArchiMate mémento : les éléments de la couche application - 5
   
   
6. ArchiMate aide mémoire : les éléments de la couche technologique - 6
   
   
7. ArchiMate en abrégé : les éléments physiques de modélisation - 7
   
   
8. ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8
   
   
9. ArchiMate : modélisation de l’alignement des couches d'application et de technologie - 9
   
   
10. ArchiMate : les éléments d'implémentation et de migration - 10
    
    
11. ArchiMate : vues et points de vue - 11
    
    
12. ArchiMate : guide complet des éléments de modélisation - 12

BPMN

1. BPMN 2 : les concepts de base des processus métiers
   
   
2. BPMN pour les nuls : les collaborations
   
   
3. BPMN pour les nuls : les chorégraphies (Choreographies)
   
   
4. BPMN pour les nuls : les conversations
   
   
5. BPMN : norme OMG - synthèse des éléments graphiques
   
   
6. BPMN : l'antisèche pour rester incollable en modélisation de processus
   
   
7. BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
   
   
8. BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza
   
   
9. BPMN : mais que dit la norme sur les sous-processus et la gestion des événements d'interruption et de remontée d'incidents ?
   
   
10. BPMN : processus exécutables, comment s'y prendre ? (1/3)
    
    
11. BPMN : processus exécutables, comment s'y prendre ? (2/3)
    
    
12. BPMN : processus exécutables, comment s'y prendre ? (3/3)
    
    
13. Comment identifier, simuler, améliorer et modéliser les processus métiers ?
    
    
14. Comment mettre en place un jeu de rôles pour modéliser un processus métier ?

La manière dont chaque composante du processus d'urbanisation est mise en œuvre est caractérisée par plusieurs axes et critères.

Rhona Maxwel

@rhona_maxwel

"Le bonheur n'accepte comme conjointe que la réalité."

Daniel Desbiens

Articles conseillés :

La démarche de l'urbanisation des systèmes d'informations : comment mesurer les progrès ?

Objectifs des indicateurs du processus d'urbanisation du Système d'Information

La méthode top-down dans l'urbanisme du Sytème d'Information

La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le système d'information et enfin le système informatique.

En haut, juste en dessous de la stratégie d'entreprise qui ne fait pas partie de l'urbanisation du SI, on trouve la cartographie métier avec les processus métiers et leurs événements déclencheurs, puis en dessous, la cartographie fonctionnelle structurant le système d'information avec des blocs fonctionnels, un niveau encore en dessous, on trouve la cartographie applicative constituée de composants applicatifs du système informatique et enfin tout en bas la cartographie technique représentant l'infrastructure technique du système informatique.

La méthode top-down part de la stratégie d'entreprise, pour en déduire les objectifs métiers, les processus métiers, le système d'information et enfin le système informatique.

Le postulat étant que la couche supérieure à celle qui est modifiée, est invariante, sinon on s'expose à un risque de divergence. 

Les 6 commandements de la démarche d'urbanisation du Système d'Information.

Connaître le SI existant. Cette connaissance, qui est indispensable pour faire évoluer le système d'information, porte à la fois sur les processus métiers et les applications du SI. Elle fait l'objet de référentiels cartographiques, dont la mise à jour doit accompagner les changements apportés au SI.

Gérer les référentiels majeurs pour l'entreprise. L'existence au sein d'un SI, de multiples bases de données ou fichiers contenant des données semblable, mais loin d'être identiques, est toujours un facteur de complexité ou de surcout.

Cet objectif permet d'évalue si les données métier de référence sont défini de façon unique et connue de tous, si la responsabilité de chaque référentiel est attribué à une maîtrise d'ouvrage identifiée. Enfin, il permet de vérifier si les dispositifs de gestion des données de référence permettent d'en assurer la qualité, la cohérence et la disponibilité.

Disposer de cibles pour l'évolution du SI. L'élaboration de ces cibles fonctionnelles, applicatives et techniques permet d'une par de s'assurer que la réalisation des nouveaux projets s'inscrit bien dans le cadre de ces cibles.

Permet de s'assurer en permanence que ces cibles sont en harmonie avec la stratégie de l'entreprise.

Maîtriser une construction du SI pour l'ensemble de l'entreprise. Pour atteindre ces cibles, il faut définir et mettre en œuvre un plan de migration ou road map, élaborer et diffuser des règles d'urbanisme applicables par les équipes de projets (maîtrises d'ouvrage et maîtrise d'œuvre).

Grâce à un accompagnement permanent des projets par les urbanistes, il faut en outre s'assurer que ces règles sont effectivement appliquées dès la première étude amont.

Maîtriser la complexité des flux d'échanges d'informations. L'indicateur portera sur la description des flux inter-applicatif, la standardisation de ces échanges, au moins pour les données majeures de l'entreprise.

Il faut vérifier la mise en place, l'administration et la maintenance de dispositifs d'échanges mutualisés.

Piloter et supporter l'urbanisation du SI. Pour mettre en œuvre le processus d'urbanisation, il faut des moyens adaptés.

L'indicateur analysera la modélisation de ressources pour l'urbanisme (définition de la fonction d'urbaniste, insertion des urbanistes dans les structures de gouvernance). Permet de vérifier la mise œuvre de dispositif de communication et de formation pour l'ensemble des acteurs projets.

Pour chaque objectif est associé un certain nombre de critère (3 à 5) et à chaque critère est associé une mesure, noté de de 0 à 4, selon une grille prédéfini associé à chaque critère.

L'indicateur de cette mesure est :

soit quantitatif : par exemple, pour les référentiels de cartographie, les notes sont attribuées selon le taux de couverture de la cartographie ;

soit qualitatif : l'indicateur caractérise des notions telles que le champ, la fréquence, la profondeur des actions associées au critère.

« Faiblesse et courage, étourderie et raison, caprice et dévouement ! la femme est un composé de tout cela. »

Goswin Joseph Augustin, baron de Stassart

Rhona Maxwel

@rhona_helena

Articles conseillés :

2/11 Projet informatique, passer du moyen âge à l'ère industrielle. Urbanisez pour mieux régner, 1ère partie : les fondations.

2/11 Projet informatique, passer du moyen âge à l'ère industrielle. Urbanisez pour mieux régner, 2ème partie : les gains et les réticences.

Quelle est l'étape la plus importante dans l'urbanisation des SI ?

Pas de nouvelles, mauvaises nouvelles

Quels sont les axes de recherche et développement de l'urbanisation ?