urbanisation-si.com

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