urbanisation-si.com

urbanisation-si.com

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


Quel outil ArchiMate pour modéliser vos architectures d’entreprise sources et cibles, évaluer les écarts, analyser les impacts et élaborer des trajectoires de transformation ? Obeo SmartEA S.1 Ep.1

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

 

obeo-smartea-nouveau-navigateur-url-differences-salesforce-chatgpt

   

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.

 

obeo-smartea-gestion-des-branches-git

 

   

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). 

 

obeo-smartea-nouveau-branche-master-vue-motivation

    

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.

 

obeo-smartea-creation-branches-2

 

  

obeo-smartea-creation-branches-Salesforce-Cloud-IA

 

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.

 
obeo-smartea-nouveau-branche-ia-vue-motivation

     

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.

 

obeo-smartea-nouveau-menu-analyse-ecarts

   

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".

 

obeo-smartea-nouveau-differences-ia-master

 

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. 

 

obeo-smartea-nouveau-differences-ia-master-zoom

   

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 HubSpotobeo-smartea-nouveau-branche-chatgpt-vue-technologie

    

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 

obeo-smartea-nouveau-branche-salesforce-vue-technologie

 

 

 

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.

 

obeo-smartea-nouveau-differences-chatgpt-salesforce

  

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

 

 

obeo-smartea-nouveau-differences-chatgpt-salesforce-zoom

 

 

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.

 

obeo-smartea-nouveau-differences-salesforce-chatgpt

  

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

  

obeo-smartea-nouveau-differences-salesforce-chatgpt-zoom

  

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.

 

 

obeo-smartea-branche-chatgpt-flux-entre-applications

   

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.

 

obeo-smartea-nouveau-synchronisation-master-avec-chatgpt

  

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.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

 

 

 

 

 

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

Antonio Gramsci

 

Annexe : compléments de lecture

 

 

       


28/11/2023
0 Poster un commentaire

Démarche d’urbanisation du SI : les questions techniques, organisationnelles, voire existentielles

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.

question-mark-gc469bb40d_1280

 

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.

 

processus-urbanisation-du-si 

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.

bpmn-exemple-01

 

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.

 

cartographie-fonctionnelle-urbanisation-du-si-exemple-03

 

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 ?

 

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 ?

 

ia-architecture-entreprise-hal

 

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 ?).

 

 

urbanisation-si_logo

 

Thierry Biard

& Rhona Maxwel

urbanisation-si.com

 

“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

 


22/11/2022
0 Poster un commentaire

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 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.

mckinsey-enterprise-architecture-management-6-couches

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.

 

mckinsey-enterprise-architecture-management-3-etapes

 

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

 

Première phase : le grand nettoyage de printemps

 

mckinsey-enterprise-architecture-management-nettoyage

 

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 ?

 

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

 

“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é

 

 

Compléments de lecture

 


05/05/2022
0 Poster un commentaire

Pour quelles raisons l’Architecture d'Entreprise prône la transformation ou dérivation des couches la composant ?

L'architecture d'entreprise qui inclut l'urbanisation des Systèmes d'Information ne cesse de prôner la transformation ou dérivation des couches la composant, stratégie en métier, métier en fonctionnelle, fonctionnelle en applicative et applicative en infrastructure à des fins d'automatisation, de traçabilité et de gouvernance. 

C'est la que rentre en jeu, l’Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture) qui repose sur la volonté de décrire précisément les besoins des clients par des CIM (Computational Independent Models) et la connaissance métier d’une organisation dans des modèles abstraits indépendants des plates-formes (PIM - Platform Independent Models).

 

Ayant isolé le savoir-faire métier dans des PIM, on a besoin soit de transformer ces modèles en d’autres PIM (besoin d’interopérabilité, migration vers un nouveau système, fusion de SI en cas d’acquisition d’une autre organisation, …), soit de produire ou de créer des modèles PSM (Platform Specific Models) ciblant une plate-forme d’exécution spécifique (pour améliorer la portabilité et augmenter la productivité).

 

Dans le cadre de l’IDM, les artefacts manipulés sont des modèles.

Ces types de modèles sont donc des méta-modèles.

Un méta-modèle est un modèle qui définit les concepts d'un modèle d'instance.

Cette relation est purement syntaxique. 

 

transformation-de-modèles-IDM-MDE-MDA-00.PNG

 

La Meta-Object Facility (MOF) de la norme OMG à quatre couches (M0, M1, M2, M3) est l’architecture de méta-modélisation.

 

Voir ci-dessous un article que j'avais consacré aux métamodèles :

 

 

Par exemple, le métamodèle de UML (Unified Modeling Language) est un modèle M2 du MOF.

De même, tous les langages spécifiques à un domaine (DSL Domain Specific Language) peuvent également être exprimé en modèles MOF.

 

Le noyau de MOF permet seulement d'exprimer des propriétés structurelles simples,

Associations similaires entre éléments, encapsulation, cardinalité, etc.

Le langage de contraintes d'objet (OCL Object Constraint Language) est un langage de contrainte déclaratif d’instructions ordonnées standard et un langage de requête, qui est utilisé pour associer des règles à des modèles.

Par exemple, on peut spécifier une structure, des invariants, des définitions et des pré/post conditions, des opérations MOF abstraites dans la langue OCL.

 

Voir mes tutoriaux sur OCL :

 

 

Le métamodèle de transformation contient trois éléments essentiels : source, cible et relation de transformation ou dérivation.

La relation de transformation est un ensemble de liens explicites entre les éléments de la source et le modèle cible.

Ces liens explicites jouent un rôle clé dans l’approche IDM.

Les relations entre les métamodèles définissent la structure des liens et des propriétés qu'ils doivent satisfaire et le méta-modèle de transformation, les liens qui doivent exister.

 

Une transformation de modèles est la génération d’un ou de plusieurs modèles cibles à partir d’un ou de plusieurs modèles sources.

 

Une transformation des entités du modèle source met en jeu deux étapes.

 

La première étape permet d’identifier les correspondances entre les concepts des modèles source et cible au niveau de leurs métamodèles, ce qui induit l’existence d’une fonction de transformation applicable à toutes les instances du métamodèle source. Cette correspondance se fait par l'établissement de règles. 
La seconde étape consiste à appliquer la transformation du modèle source afin de générer automatiquement le modèle cible par un programme appelé moteur de transformation ou d’exécution.

 

L’approche par modélisation consiste quant à elle à appliquer les concepts de l’ingénierie des modèles aux transformations des modèles elles-mêmes.

 

L’objectif est de modéliser les transformations de modèles et de rendre les modèles de transformation pérennes et productifs, en exprimant leur indépendance vis-à-vis des plates-formes d’exécution.

 

transformation-de-modèles-IDM-MDE-MDA-01.PNG

 

Une transformation endogène se situe dans le même espace technologique et les modèles source et cible sont conformes au même méta- modèle.

Par exemple transformation d'un modèle UML en un autre modèle UML

 

Une transformation exogène se situe entre 2 espaces technologique différents et les modèles source et cible sont conformes à des méta- modèles différents.

 

Par exemple transformation d'un modèle DMN ( Decision Model Notation )  en DRL (Drools Rules Language, le langage natif de règles métiers du moteur open source DROOLS).

 

taxonomie-transformation-de-modèles-IDM-MDE-MDA-02.PNG

 

Une transformation en série peut servir à réaliser une application ou un processus basé sur une série de transformations de modèles.

 

Par exemple : modèle de l'application au niveau abstrait, avec un modèle de composant abstrait, modèle PIM puis une projection du modèle vers un modèle de web services (SOAML) : PSM

 

Les types d’outils de transformation de modèles :

  • Langage de programmation « standard » : Ex : Java, pas forcément adapté pour tout, sauf si interfaces spécifiques, ex : framework Eclipse/EMF
  • Langage dédié d'un atelier de génie logiciel : Ex : MDG pour l’AGL Enterprise Architect, Langage de script de l’AGL MEGA, MDA Modeler IBM Rational, souvent propriétaire et inutilisable en dehors de l'AGL
  • Langage lié à un domaine/espace technologique : Ex: XSLT dans le domaine XML, AWK pour fichiers texte ...
  • Langage/outil dédié à la transformation de modèles : Ex : la norme QVT (Query View Transform) de l'OMG, le standard de l’industrie actuellement : ATL (Atlas Transform Language)

 

3 grandes familles de modèles et outils associés :

  • Données sous forme de séquence : Ex : fichiers textes (AWK)
  • Données sous forme d'arbre : Ex: XML (XSLT)
  • Données sous forme de graphe : Ex : diagrammes UML, outils : QVT, ATL, …

 

3 grandes catégories de techniques de transformation :

  • Approche déclarative : recherche de certains patrons (d'éléments et de leurs relations) dans le modèle source. Chaque patron trouvé est remplacé dans le modèle cible par une nouvelle structure d'élément. L’écriture de la transformation est « assez » simple mais ne permet pas toujours d'exprimer toutes les transformations facilement.
  • Approche impérative : proche des langages de programmation usuels, on parcourt le modèle source dans un certain ordre et on génère le modèle cible lors de ce parcours. L’écriture transformation peut être plus lourde mais permet de toutes les définir, notamment les cas algorithmiquement complexes.
  • Approche hybride : à la fois déclarative et impérative. La plupart des approches déclaratives offrent de l'impératif en complément car plus adapté dans certains cas.

 

Les référentiel pour stocker les modèles et méta-modèles utilise XMI (XML Interchange, norme de l'OMG). 

 

Les principales implémentations des langages de transformation de modèles ATL et QVT utilisent le métamétamodèle Ecore d'Eclipse qui est le standard de l'industrie. On retrouve tous les principaux concepts du niveau M3 UML du MOF  de l'OMG.

 

On trouve les métamodèles Ecore à peu près pour tout, les langages de modélisation normalisés (UML, SysML, BPMN, DMN, BMM, SOAML, ...) et même des langages open source comme celui de DROOLS, le moteur de règles métier, standard de l'industrie.

 

Voir mes articles sur Ecore : 

Les cadres d'architecture d'entreprise comme TOGAF (The Open Group Architecture Framework), Praxeme, ... énoncent des principes de dérivation des différents niveaux ou aspects. Mais aucune ne précise avec quels outils.

 

Alors, la question qui me tourmente, avez-vous ou votre organisation, mis en place des transformations de modèles et avec quels outils ?  

 

Rhona Maxwel

@rhona_helena

 

"Parmi les objets répandus au hasard, le plus beau c'est le cosmos. L'harmonie invisible est plus belle que le visible."

Héraclite d'Ephèse  

 

 

Articles conseillés :

 


18/11/2022
0 Poster un commentaire

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

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 ?

 

meilleurs-articles-architecture-entreprise-methodes-outils

 

(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 :

 

 

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 :

 

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 :

 

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 :

 

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 :

 

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 :

 

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

 

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 :

 

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 :

 

Dans cet article se trouvent les articles traitant : 

 

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)

 

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 :

 

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

 

 

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 ?

 


19/01/2021
0 Poster un commentaire

Sur quels critères doivent reposer les indicateurs d'urbanisation d'un système d'information ?

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

 

processus-urbanisation-systeme-d-information-indice-urbanisation-01.png

 

 

urbanisation-systeme-d-information-tableau-processus-indice.png

 

Les indicateurs des processus d'urbanisation du SI

 

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


10/12/2016
0 Poster un commentaire

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.

 

urbanisme-systeme-d-information-methode-top-down.jpg

 

 Classiquement, le plan d'urbanisme est constitué de 4 couches qui doivent être cartographiées.

  

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. 

 

Toute intervention dans l'urbanisation du SI est opérée sur la couche n immédiatement en dessous de celle n+1 qui doit rester invariante. La couche n-1 doit subir toutes les modifications pour remplir les besoins de la couche n et ainsi de suite. Il est possible qu'une couche remplisse déjà les besoins de la couche supérieure, auquel cas elle ne subira aucune modification. 

 

Prenons l'exemple de la direction générale d'une mutuelle qui adopte une stratégie de lutte renforcée contre la fraude. Le schéma directeur défini sur 3 ans, bien qu'il puisse être révisé tous les ans, est considéré comme invariant. La première couche non invariante est la couche métier. En effet, le processus métier de remboursement d'actes de santé est modifié.

En fonction de certaines règles, comme plus de 3 consultations chez un généraliste dans la même journée, un rejet sera généré pour un traitement manuel. On voit que non seulement le processus métier est modifié mais aussi l'organisation avec un changement important pour le travail du gestionnaire. Il faudra modifié la couche fonctionnelle avec des classes et des services métiers spécifiques.

 

La couche applicatives devra implémenter ces classes et ces services et assurer la communication avec les autres blocs applicatifs comme le paiement, le juridique, ...

  

La couche technique ne sera peut être pas impactée, car elle possède déjà un ESB (Enterprise Serial Bus) permettant la communication entre les blocs.

 

La méthode bottom-up, consiste à intervenir sur une couche pour en améliorer le fonctionnement.

Cette opération peut faire émerger des opportunités de modification à la couche supérieure. Elle part du principe que dans tout système défini, il peut y avoir des évènements qui remettent en cause les principes établis. 

Généralement ces évènements sont extérieurs à l’entreprise, d’ordre technologique mais aussi économique (fusions ou acquisitions) ou réglementaire (obligation de mise en place d’une norme européenne).

  

Et comme bien souvent ce n'est pas l'une ou l'autre qui est privilégiée mais bien un mixte des 2 méthodes.

 

Rhona Maxwel

@rhona_helena

  

"Le paradoxe du travail, c'est que l'on ne travaille, en fin de compte, que pour le supprimer."
Boris Vian


08/12/2016
2 Poster un commentaire

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

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

 

processus-urbanisation-systeme-d-information-indice-urbanisation-01.png

  

Ce qu'il faut mesurer pour connaître la progression du processus d'urbanisation du Système d'Information.

 

Objectif 1 :

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.

 

Objectif 2 :

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é.

 

Objectif 3 :

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.

 

Objectif 4 :

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.

 

Objectif 5 :

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.

 

Objectif 6 :

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 ?


07/12/2016
0 Poster un commentaire

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

Un processus n'est bien défini que s'il est mesurable.

 

processus-urbanisation-systeme-d-information-indice-urbanisation-01.png

 

Et pour cela, il y a l'indice d'urbanisation : évaluer l'état de la démarche d'urbanisation de tout de le système d'information de l'entreprise ou d'une partie.

 

La démarche d'urbanisation est une tâche qui prend du temps, la communication doit être sans faille, les progrès doivent être visibles et l'on doit s'efforcer de renouveler la motivation et l'énergie nécessaire.

 

Fini le simple inventaire d'avantages qualitatifs, il faut objectiver grâce à des indicateurs servant de véritable outil de mesure.

 

L'indice est donc un outil de mesure et de management : il permet d'apprécier si l'urbanisation du SI est en "bonne voie", c'est à dire si les actions menées s'inscrivent dans une démarche de meilleures maîtrise de l'urbanisation du SI. En ce sens, il différencie l'urbanisme d'une démarche comme CMMI : cette dernière se concentre sur le pilotage du processus, alors que l'indice d'urbanisation mesure le résultat sur la base de faits démontrables correspondants aux résultats du processus mis en œuvre.  

 

Il faut mettre en œuvre la cotation de l'indice d'urbanisation et l'utiliser comme outil de pilotage de l'urbanisation de leur système d'information.

 

Rhona Maxwel

@rhona_helena

 

"C'est toute la beauté des larmes ; elles peuvent avoir deux significations opposées.
On pleure de douleur, on pleure de bonheur.
Peu de manifestations physiques ont cette identité à deux têtes, comme pour matérialiser la confusion."
David Foenkinos

 

Articles conseillés :

 

Avec un peu de métier, métamodéliser la vue métier pour assurer la traçabilité avec la stratégie

 

En urbanisation SI, comment définit-on la vue fonctionnelle et quels sont les liens avec la vue métier et applicative ?

 

En urbanisation SI, comment met on en oeuvre la traçabilité entre la vue applicative et les vues fonctionnelle et infrastructure ?

 

Visiter la "salle machine" de l'urbanisation des SI

 

Le Big-Mac de l'urbanisation SI


06/12/2016
0 Poster un commentaire

L'urbanisme des SI et architecture d'entreprise : retour vers le futur

retour_vers_le_futur.jpg

 

L'avenir de l'urbanisme de SI sera lié à 3 facteurs :

  1. La généralisation des relations en entreprise étendue, au delà des périmètres figés de la firme traditionnelle.
  2. La montée inéluctable des organisations autour des processus, du management par les processus, qui remettra en cause les fonctionnements internes, et sera reliée aux SI urbanisés.
  3. L'extension progressive des solutions techniques et conceptuelles basées sur des architectures de services pour les fonctions métiers souvent développées par les informaticiens de l'entreprise, comme pour les fonctions de support traditionnellement confiées à des ERP.

Le 1ère évolution, les relations entre les acteurs économiques, de plus en plus basées sur la technologie, gommeront les espaces traditionnels.

Les entreprises interagiront plus fortement, dans des processus plus directs et plus tendus avec leurs clients et leurs partenaires.

Ce fonctionnement en entreprise étendue qui existe déjà chez de nombreux grands comptes, deviendra la règle.

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 architecte de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action.

 

La 2ème évolution, elle aussi déjà engagée, concerne la vision processus. en effet la recherche de l'efficience, de la flexibilité et la proposition pour le client de la plus grande efficacité, continueront à bousculer les organisations. 

La déformation des entreprises organisées en silos, en des modèles orientés processus deviendra une généralité.

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, ...

L'urbanisme des SI incite à décrire les processus métiers.

C'est un début, mais 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 dans le futur, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transversales, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : les urbanistes seront les catalyseurs de cohérence, de transversalité, et de flexibilité.

 

La 3ème évolution majeure se réfère à la sphère technique.

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

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 ? 

 

Comme le montre notre X-Men John Zachman dans son modèle, pour l'instant aucune bonne fée n'est apparue avec sa baguette magique, il sera toujours nécessaire d'architecturer l'entreprise.

 

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ées.

Il leur faudra lutter férocement contre l'entropie et rechercher toujours plus d'agilité.

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.

 

Rhona Maxwel

@rhona_helena

 

"Il n'y a rien de plus parfait que de trouver du bonheur à communiquer le sien."
Henri Lacordaire


02/05/2016
0 Poster un commentaire