urbanisation-si.com

urbanisation-si.com

Urbanisation SI


Architecture d'Entreprise augmentée, quelle influence de l’Intelligence Artificielle sur la gouvernance et la stratégie ?

L’omniprésence et la protéiformité de l’IA, comme le RPA (Robotic Process Automation) ou les chatbots, déclencheraient-elles une disruption et feraient-elles naître une Architecture d'Entreprise augmentée ? L’IA a-t-elle un rôle à jouer dans les décisions des comités de direction ?

 

architecture-entreprise-intelligence-artificielle-ia-hal-9000 

Un ancêtre de l'IA, pour les cinéphiles

 

APIsation, plateformisation, données “chaudes”, données “froides”, données "tièdes"...

L’APIsation et la plateformisation de l’entreprise alliées à l’urbanisation du SI participent à l’intégration de l’IA dans les applications.   
Les données “chaudes” représentent le référentiel des entités métier, les indicateurs de pilotage et sont persistantes dans des bases SQL avec un accès en quasi temps réel. Les données “froides” sont le résultat de l’archivage dans d’autres espaces de stockage, sans contrainte de temps de réponse. Entre les deux, les données "tièdes", issues du rapprochement des deux types précédents, offrant rapidité et quantité et appartiennent au domaine du Big Data qui alimente les algorithmes de l’IA.
L’Architecture Réactive, basée sur les évènements, les APIs et les microservices, fait partie des fondements pour déployer de l’IA.


Les cycles d’évolution des technologies étant de plus en plus courts, l’open source devient incontournable. De même l’open innovation permet d’innover en mettant en œuvre une collaboration entre les grandes entreprises et les start-ups avec les incubateurs, les hackathons, les financements…
L’externalisation des compétences techniques comprend des risques, notamment sur la maîtrise de la sécurité, des savoir-faire, mais aussi sur l’évaluation éthique. Intégrer une brique fournie et maintenue par un tiers dans la chaîne opérationnelle pose le souci de voir partir le savoir-faire métier, car en effet, même si les données appartiennent à l’entreprise, les algorithmes et les modèles appartiennent en général aux fournisseurs. Ils peuvent donc acquérir et consolider le savoir-faire métier de plusieurs entreprises clientes pour le vendre ensuite à des entreprises concurrentes ou l’exploiter eux-mêmes.

 

La dimension éthique pour les entreprises réside aussi en partie dans leur capacité à s'approprier le développement de solutions et à traiter le plus en amont possible les questions de traçabilité et d'explicabilité des algorithmes. La question d’acceptabilité des modèles est cruciale aujourd’hui. S’il est indispensable de faire appel à l’expertise extérieure (dynamique évolutive, sujets très pointus…), le contrôle est indispensable. Internaliser les outils d’IA demande des compétences, car il est rare de trouver un outil open source sur étagère qui réponde complètement aux besoins de l’entreprise. C’est en général une bonne base, mais elle doit être adaptée à chaque contexte. Il faut faire beaucoup d’assemblage et souvent un peu de développement, donc il faut avoir les compétences en propre.

 

Du Machine Learning dans la gestion de projet

L'analyse prédictive peut fournir des conseils au chef de projet pour atteindre le meilleur résultat possible, basé sur ce qui a fonctionné dans les projets antérieurs.
Les chatbots servent d'assistants de projet. Ils peuvent prendre en charge des tâches subalternes, telles que l'organisation des réunions, contrôler la performance en fonction des références de base, rappeler aux équipes projet les activités programmées.

La planification basée sur l'lA pourrait inclure les leçons apprises des projets antérieurs et suggérer plusieurs calendriers possibles, en fonction du contexte et des dépendances. Par ailleurs, les plans de projet pourraient être adaptés et recalibrés en quasi temps réel sur l'historique des performances de l'équipe et l'avancement du projet. Le système pourrait même alerter le chef de projet des risques et des opportunités, en utilisant l'analyse des données de projet en temps réel.

Dans son évolution, l'IA pourrait convertir les cartes mentales (mind map) créées par les équipes projet en ontologie métier, en tirer des tâches reliées entre elles et il ne resterait plus qu'un pas à faire pour arriver à des modèles BPMN.
La mise en œuvre de l'apprentissage automatique (Machine Learning) dans le management de projet permet l'analyse prédictive et corrective, visant à fournir au chef de projet des alternatives pour la prise de décision.

 

Le comité de direction augmenté, une utopie ?

Les dernières études en la matière mettent en évidence un usage de l’IA au niveau tactique, plutôt qu’au niveau stratégique de l’entreprise, c’est-à-dire essentiellement dans l’amélioration des processus opérationnels de l’entreprise.

Voir nos articles :

 

Les récents progrès pourraient laisser penser que de tels modèles pourraient trouver une application dans la prise de décision stratégique, voire prendre les décisions stratégiques elles-mêmes lorsqu’on les utilise dans un conseil d’administration.
La perspective qu’une IA puisse influer dans les décisions stratégiques appartient encore au monde de l’utopie. Comme tout un chacun, la compréhension des décideurs d’un problème, de son contexte et de sa résolution, s’appuie notamment sur leurs connaissances, leurs expériences et leurs énactions.

L’essence même de la prise de décision stratégique est définie par un manque d’informations, une incertitude élevée et une forte interdépendance avec les acteurs de la décision : autant de caractéristiques qui rendent assez improbable le fait de confier les décisions stratégiques d’une entreprise à une IA.
Les biais des DG seraient alors remplacés par les biais des jeux de données, qu’ils proviennent de biais cognitifs, du surapprentissage, d’échantillons, de sélection, de valeurs aberrantes ou surreprésentées.


Les disruptions tous domaines confondus impactant le décisionnel relèvent par nature même de l’imprévisibilité et sont inmodélisables. Aucun modèle prédictif n’a pu, ne serait-ce qu’entrevoir, l’ubérisation. Sûrement parce qu'ils sont basés sur des données qui ne sont plus de premières fraîcheurs, tombant rapidement dans l’obsolescence.
Les entreprises entamant leur transition numérique doivent composer des équipes aux triples compétences : métier, informatique et mathématiques, sous la direction d’un CDO (Chief Data Officer).


La gouvernance doit constamment faire de la prospective, afin de maintenir ses informations sur l’IA devenu 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. Il apparaît ainsi nécessaire que le CDO possède une solide culture en matière d’IA, afin d’éclairer les discussions de la gouvernance sur ce sujet stratégique.

 

Conclusion

En termes de recherche fondamentale, les avancées et les percées se succèdent, aboutissant peu à peu à des applications opérationnelles. La veille, la vision et la prospective stratégique sur ces sujets de recherches technologiques restent essentielles pour se préparer aux disruptions majeures à venir.
Nous avons déjà pris l’habitude d’utiliser notre smartphone comme "prothèse cognitive", et cette capacité ne va faire que s’étendre et sûrement aux instances décisionnelles des entreprises.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“Sur la route, il y avait déjà des bandes réfléchissantes, maintenant il y roule des voitures intelligentes.”
Marc Escayrol

 

Compléments de lecture

 


09/06/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

Le rôle de la prospective pour une entreprise innovante et résiliente

“Demain ne sera pas comme hier. Il sera nouveau et dépendra de nous. Il est moins à découvrir qu’à inventer” dixit Gaston Berger, l'inventeur du terme prospective. Pour renforcer ses capacités d’innovation, sa résilience et ses processus métier, l'entreprise doit non seulement surveiller le monde qui l’entoure, mais aussi mettre en œuvre des scénarios prospectifs contribuant à établir ses stratégies.

prospective-analyse-des-futurs-possibles-1

 

Démarche transversale en plein essor, la prospective offre une capacité d'analyse qui simule des avenirs possibles sur une question donnée et dans un champ spatio-temporel délimité.

 

Compte tenu de la mouvance d’un monde empli d’incertitudes, la survie d’une entreprise est étroitement liée à sa résilience. Il va s’agir de sa capacité à s’adapter rapidement aux événements néfastes, aux épreuves et aux échecs, tout en maintenant son activité économique, en protégeant son personnel et ses valeurs. Se remettre sur les rails après une situation difficile ne suffit pas, il faudra prendre de la hauteur, appréhender le contexte et lancer une démarche de prospective stratégique de manière à tourner l’entreprise vers l’avenir et à favoriser l’enclenchement d’une innovation de rupture nécessaire à son adaptation et à sa résilience.

 

De quoi parlons-nous exactement ?

Pour éviter toute confusion et pour la clarté de la suite de cet article, commençons par définir des concepts qui semblent similaires, mais en y regardant de plus près, qui présentent bien des différences tout en étant complémentaires.

 

L’anticipation

Terme générique, l’anticipation rassemble les méthodes de prédiction, de prévision et de prospective.

 

La prédiction

La prédiction concerne un futur déjà écrit en extrapolant des connaissances existantes. La méthode est une heuristique basée sur le fait qu’en première approximation le futur présentera des similitudes avec le passé. Par exemple, le Big Data et le Machine Learning permettent d’identifier des corrélations statistiques implicites dans les données, augmentant la somme de connaissances pouvant être extrapolées sur une période future. 

 

La prévision

La prévision concerne les futurs probables, où les scénarios représentent des hypothèses implicites ou explicites sur lesquelles sont basées les projections obtenues par extrapolation et/ou interpolation mathématiques faisant explicitement intervenir la variable temps. 

Prévoir un futur probable consiste alors à recueillir et à interpréter les résultats produits par le modèle en déplaçant la variable temps à une valeur située dans le futur.

Si certaines hypothèses se vérifient avec le temps, on aura des certitudes sur des événements à venir. On pourra alors adopter une posture déterministe en planifiant des actions pour s’y préparer.

 

La projection

Les projections sont des extrapolations de tendances d’un phénomène correspondant à des estimations quantitatives sur des périodes déterminées à venir. Différents outils existent comme l’analyse de séries chronologiques basée sur la modélisation des tendances passées tenant compte d’hypothèses.

 

prospective-projections-analyse-séries-chronologiques-1-2Exemple de projections utilisant l'analyse de série chronologique (https://www.inspq.qc.ca/jasp/accueil)

 

On peut aussi utiliser la microsimulation qui a pour objectif de représenter un système dynamique composé d’entités possédant des propriétés soumises à des événements avec une certaine probabilité de modifier leurs valeurs.

 

La prospective

Se préparer à l'incertitude

Contrairement à la prévision, avec la prospective, on est dans une posture proactive, on se prépare à l’incertitude du futur en produisant des scénarios contrastés (disruptifs, de crises, de mutations, de solutions) pour le décisionnel, le management de l’innovation et le management stratégique.

La démarche prospective se situe en amont de la stratégie dont elle éclaire les choix en balayant un plus long terme, au moins 10 ans. 

En stratégie d’entreprise, la démarche de prospective consiste à réaliser des diagnostics, à élaborer des scénarios nominaux ou alternatifs et à émettre des recommandations. Les étapes de planification des risques et de proposition de visions temporelles vont aider aux décisions stratégiques sur le long terme, réduire les incertitudes face à l’avenir et enfin légitimer les actions entreprises. 

 

L’étude prospective peut être basée sur la veille consistant à identifier les données les plus seyantes sur les changements dans le monde, les mutations émergentes, les ruptures technologiques et l’ensemble des événements futurs pouvant potentiellement avoir des impacts importants.  

 

André-Clément Decouflé, prospectiviste et auteur de nombreux ouvrages, parle de néologisme créé pour définir une méthode d’analyse des problèmes de décisions basée sur les discontinuités introduisant des ruptures de tendances plutôt que de se fonder sur les expériences passées, l’analogie ou l’extrapolation. Le processus de décision doit intégrer une multitude de contextes futurs pour pouvoir intégrer à moindres risques les incertitudes susceptibles d’impacter la pertinence de la solution retenue.

 

Le but de la prospective est de raconter des histoires sur les futurs possibles issus des répercussions des choix présents, autrement dit, d'anticiper de manière la plus efficiente qui soit les évolutions d’une organisation. 

Concrètement, les scénarios prospectifs peuvent être rédigés textuellement ou être basés sur des méthodes formelles comme les matrices des impacts croisés ou la méthode DELPHI.

 

La matrice d'impacts croisés

La matrice d'impacts croisés modélise les influences directes entre des événements (éléments ou variables). Schématiquement, l’impact direct d’un événement ek sur un autre em est représenté par une flèche partant de ek et arrivant à em

 

prospective-graphe-impacts-entre-variablesExemple de graphe montrant les variables impactantes et impactées

 

Pour simplifier, le même poids (égal à l'unité) 1 est attribué à toutes les relations directes existantes ; l'absence de relation entre deux événements est symbolisée par le chiffre zéro. L'examen porte sur les combinaisons deux à deux de tous les événements retenus, il en résulte une matrice booléenne carrée M dont l'élément générique est :

  • ekm = 1 si l'élément ek de la k-ième ligne a une influence directe sur l'élément em de la m-ième colonne.
  • ekm = 0 si l'élément ek de la k-ième ligne n’a pas d’influence directe sur l'élément em de la m-ième colonne.
  • ekk = 0 car ek ne peut s'influencer lui-même, directement.

 

En tenant compte des influences directes, la somme (Σekm ; m-1…) de la ligne k de la matrice M comptabilise le nombre de variables influencées directement par ek : est ainsi mesuré le pouvoir moteur (ou indice d'influence) de ek.

L'indice de dépendance de em se mesure par la somme (Σekm ; k=1…) de la colonne m. C'est le nombre de variables dont em subit directement l’influence.

prospective-matrice-impacts-croises

Exemple de matrice des impacts croisés correspondant au graphe précédent

 

La méthode DELPHI

DELPHI est une méthode systématique qui a été reprise dans la méthode agile Scrum et rebaptisée “planning poker” pour réaliser les estimations des user stories.

La méthode consiste pour une problématique donnée à interroger un groupe d'experts lors de plusieurs tours. À chaque nouveau tour, le questionnaire est enrichi des réponses précédentes.

L'objectif est de mettre en évidence les consensus, mais aussi les divergences. Les consultants doivent expliciter et argumenter leur raisonnement augmentant le résultat en qualité et fiabilité.

 

La méthode des scénarios prospectifs

Michel Godet ancien titulaire de la chaire de prospective stratégique au CNAM, a conceptualisé la métaméthode des scénarios : “La méthode des scénarios vise à construire des représentations des futurs possibles, ainsi que les cheminements qui y conduisent. L’objectif de ces représentations est de mettre en évidence les tendances lourdes et germes de rupture de l’environnement général et concurrentiel de l’organisation.”

Les scénarios n’ont pas besoin d’être probables, mais ils doivent mettre en évidence des marges de manœuvre réalistes pour les acteurs qui désirent construire l’avenir qu’ils ont choisi.

Les innovations technologiques, les conflits, le climat… constituent des hypothèses disruptives contribuant à la conception des scénarios divergeant d’un scénario tendanciel, c’est-à-dire correspondant aux tendances actuelles.

 

La prospective décisionnelle fait intervenir la systémique puisqu’elle implique la comparaison, soit de solutions à efficiences identiques en faisant ressortir la moins chère, soit l’inverse.

Des récits concrets de l’avenir sont conçus en se basant autour des incertitudes principales qui modèlent la trame environnementale future.

 

Un scénario peu probable peut se révéler extrêmement productif en permettant de forcer l’imagination, de stimuler la discussion et d’attirer l’attention d’acteurs spécifiques. Souvent l’imagination et la faculté de représentation faisant défaut, l’approche scénaristique va permettre de concrétiser les futurs possibles. Ainsi les incertitudes, la complexité et les changements de paradigme peuvent être entièrement gérés. Les scénarios offrent une modélisation de situations complexes et virtuelles en les explicitant suffisamment pour, par exemple, des architectes d’entreprise, afin qu’ils puissent les analyser et mesurer les éventuels impacts sur les stratégies. Ces trames constituent de parfaits supports à la projection des acteurs dans un environnement volontairement impacté par d’importants changements. Pour que la représentation du futur soit incitative pour les experts à s’impliquer, il faut qu’elle soit plausible, cohérente et que le raisonnement inductif soit d’une grande rigueur.

 

Les scénarios tendanciels sont des scénarios de référence, ils envisagent l'évolution plausible, ils sont sans surprise. Ils correspondent à une poursuite des tendances actuelles, sans rupture majeure, et intègrent des facteurs de changements déjà connus dont la probabilité est certaine.

Partant de ces scénarios tendanciels, d'autres scénarios lui sont confrontés sur la base d'objectifs à atteindre et/ou de contraintes nouvelles prévisibles.

 

prospective-identification-des-futurs-possibles-1-1Les scénarios des futurs possibles d'après Vincent Enjalbert (https://lecercledesdeveloppeurs.files.wordpress.com)

 

Les scénarios prospectifs exploratoires partent d’une situation connue, initiale, pour explorer progressivement le futur. Les descriptions qui en sont faites, correspondent à des images très contrastées (scénario idéal, scénario catastrophique, scénario alternatif) et permettent d'étudier les processus d'évolution qui conduisent à l'une ou à l'autre de ces situations. 

Ces scénarios contrastés sont donc destinés aux hypothèses de rupture, ayant ou non un degré de probabilité faible, mais dont l'impact est potentiellement important.

 

 

 

prospective-exemples-scenarios-2

 

Exemple de modélisation de scénarios exploratoires de l'impact de l'évolution du climat sur le littoral (Alliance nationale de recherche pour l'environnement)

 

Les scénarios normatifs partent d'une norme de désirabilité (image souhaitable ou non). Le processus de modélisation est inverse aux scénarios exploratoires, puisqu’on remonte du futur vers le présent. Le cheminement est alors construit de façon rétrospective. Ils éclairent davantage les risques de ruptures et les moyens à mettre en œuvre pour parvenir à des objectifs prédéfinis (éviter telle situation ou atteindre telle autre).

 

Conclusion

Évidemment, la prospective ne consiste pas à regarder dans une boule de cristal, dans le but de deviner l'avenir, mais entend influer sur l’avenir, c’est une ouverture de l’entreprise vers l’extérieur. Une fois choisi le scénario le plus pertinent et plausible, elle oriente sur la dynamique à mettre en œuvre pour que son déroulement ait lieu.

Elle est source d’inspiration pour l’innovation dans la mesure où l’entreprise tente de s'approprier les changements du monde qui l’entoure : ruptures technologiques, nouvelles réglementations, crises, etc.

La prospective permet aux directions générales d’expliciter des domaines aux perspectives indéfinies et qui risqueraient de dégrader les processus métiers.

La résilience dépend de l’innovation et un bon moyen d’innover c’est encore de mettre en œuvre une démarche de prospective.

Mais attention, il ne faut pas oublier que l’avenir peut être très surprenant.

 

« Le pétrole est un liquide minéral dépourvu de toute utilité. De par sa nature, c’est un liquide gluant et nauséabond. Le pétrole ne peut être employé d’aucune façon, sauf à lubrifier les roues des charrettes indigènes. »

CONCLUSION DE L’ACADÉMIE DE SAINT-PETERSBOURG, après l’envoi d’une mission russe à Bakou en 1809.

 

 

urbanisation-si_logo

 

Rhona Maxwel

urbanisation-si.com

@rhona_helena

 

“Regarder un atome le change, regarder un homme le transforme, regarder l’avenir le bouleverse.”

Gaston Berger

 

Compléments de lecture

 

  1. BMM Business Motivation Model, norme OMG, les idées clés pour mieux comprendre la stratégie d'entreprise
     
  2. BMM Business Motivation Model, norme OMG, les éléments de modélisation – vision, but, objectif, stratégie, tactique, ...
     
  3. Cours complet BMM Business Motivation Model norme OMG - les concepts de base – les moyens pour parvenir à ses fins
     
  4. Cours complet BMM Business Motivation Model norme OMG - les facteurs impactants et les évaluations de leurs influences
     
  5. Positionnement des processus et règles métiers dans la norme BMM Business Motivation Model de l’OMG et autres artefacts génériques
     
  6. Modélisation métier : méthode des processus métier orientés objectifs
     
  7. Le Machine Learning est il aux moteurs de règles métiers (BRMS) ce qu’une chute d’une météorite géante fut pour l’extinction des dinosaures ?

22/03/2022
1 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

Et lorsqu'une contrainte oblige à ne pas respecter les règles d'urbanisme des SI, que se passe t'il ?

Les référencements, l'intégrations des nouvelles lois, les innovations des concurrents, la pression des clients ou des actionnaires amène à mettre en place des fonctionnalités rapidement au détriment de la conformité des règles d'urbanisme du SI.

 

concept-metamodel-urbanisation-si.png

 

Le projet doit financer la ( "quick and dirty" ) solution à court terme ainsi que la migration vers la situation cible.

Cette migration, qui n'est pas soumise aux mêmes contraintes de planning, a pour but de restaurer la capacité du système à être flexible.

De cette façon, le besoin d'être réactif est satisfait et la capacité à le rester est maintenue.

 

La rentabilité du projet ne peut être remise en cause par le financement de la situation cible, sinon on pourrait se poser la question si le projet est réellement rentable ?

Comment seront gérer les surcoûts dus aux difficultés de maintenance et d'évolution engendrés par cette solution non conforme ?

 

Rhona Maxwel

@rhona_helena

 

"Une idée fixe aboutit à la folie ou à l'héroïsme"

Victor Hugo

 

 

Articles conseillés :

 

Édicter des règles d'urbanisme du SI c'est bien, les faire appliquer c'est encore mieux.

 

Les règles d'urbanisme du SI : maîtriser les échanges inter-applications

 

Mais dans la vrai vie, qu'est ce qu'il y a dans les règles d'urbanisme du Système d'Information ?

 

Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?

 

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?


10/07/2017
0 Poster un commentaire

Édicter des règles d'urbanisme du SI c'est bien, les faire appliquer c'est encore mieux.

Plus la mise en œuvre des règles se fait en amont et apporte des solutions aux projets, plus grande est l'efficacité .

 

Urbanisation-si-management-de-l-urbanisation-de-si.gif

 

Les règles concernant le management de l'urbanisation abordent les aspect organisation, formation, mesure de la progression dans l'urbanisation, insertion de l'urbanisme dans la gouvernance et fixent les instances légitimes pour étudier les aspects d'urbanisme.

 

Règle de management de l'urbanisation de SI : chaque unité organisationnelle possède un comité stratégique d'urbanisme métier et d'un comité opérationnel pour vérifier la conformité des projets par rapport à la stratégie d'urbanisation.

 

On le sait, sans le contrôle, on risque que les règles ne soient pas appliquées, car bien souvent les chefs de projets les voient comme des contraintes et des coûts supplémentaires.

 

Voici quelques solutions pour faire appliquer les règles d'urbanisme de SI :

  • formation des acteurs projets
  • livrable spécifique d'urbanisme dans la méthodologie d'entreprise
  • coaching des équipes
  • participation des urbanistes aux phase cruciales des projets
  • bilan de fin de phase
  • utilisation comités spécifique
  • audit projet

 

Toute la subtilité, consistera dans le positionnement du curseur entre les exigences et leurs contrôles, l'incitatif et le répressif, entre la règle et les exceptions.

 

Rhona Maxwel

@rhona_helena

 

"Un moment de patience peut préserver de grands malheurs, un moment d'impatience, détruire toute une vie."

Proverbe chinois

 

 

Articles conseillés :

 

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

 

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?


10/07/2017
0 Poster un commentaire

Les règles d'urbanisme du SI : maîtriser les échanges inter-applications

A l'intérieur d'un Système d'information, 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 l'intermédiaire du domaine fonctionnel « Zone d'échanges ».

 

règles-d-urbanisme-du-système-d-information-maitriser-les-echanges-inter-applications.PNG

  

Chaque application développe une fois l'accès au système d'échanges au lieu de développer un lien de/vers chacune des autres applications.

 

Une solution consiste à mettre en place un bus logiciel ( ESB Enterprise Service Bus ).

 

Les enjeux majeurs de l'urbanisation des SI sont la flexibilité, l'évolutivité et la maintenabilité des SI.

 

Au niveau de l'architecture applicative, les blocs applicatifs issus de la cartographie applicative doivent communiquer entre eux par envoi de message traduit généralement dans un langage pivot c'est-à-dire le langage métier commun à tous les domaines de l'entreprise.

 

Une des règles de l'urbanisme des SI est qu'un bloc possède une interface offerte à l'extérieur pour qu'elle puisse communiquer avec lui.

 

Ces interfaces se traduisent bien souvent par des services. Les blocs applicatifs se branchent sur un intermédiateur bien souvent un bus logiciel (ESB Enterprise Service Bus et pas Encéphalopathie Spongiforme Bovine).

 

L'intérêt est multiple. Un seul adaptateur est requis pour connecter un bloc sur le bus et pouvoir communiquer avec les n-1 autres blocs au lieu des n x (n - 1)/2 liens si on devait les relier tous directement en point à point. Le gain est énorme sauf si cela coûte plus cher de développer un adaptateur spécifique que de mettre en place toutes les combinaisons de liens possibles.

 

Heureusement les ESB du marché (open source ou commerciaux) sont livrés avec tous les types d'adaptateurs sur étagère. Ils correspondent à tous les protocoles standards (HTTP, …) et permettent de faire des transformations faciles d'un modèle de données métier spécifique vers le langage métier pivot.

 

Les points d'attention concernent la scalabilité, la disponibilité et la redondance ainsi que les outils de monitoring (BAM Business Activity Monitoring), de diagnostique et de reprise sur erreur. Autre avantage, l'ESB permet de séparer complétement la partie logique de la partie technique. A charge de l'ESB de gérer les transformations des formats de données dans les 2 sens, l'acheminement, le routage, la sécurité, le reporting d'exploitation et les SLA (Service Level Agreement = contrat de service comme l'engagement sur les temps de réponse, …).

 

L'ESB peut être intégré avec un moteur de processus exécutable métier et un moteur de règle métier.

Le premier permet d'automatiser les enchaînement des activités humaines et informatisées et la réorchestration de ces activités de manière agile et flexible.

Le deuxième permet d'injecter des règles de routage dans le processus métier ainsi que des nouvelles règles métier liées à des évolutions du marché, de la concurrence ou légales.

 

Rhona Maxwel

@rhona_helena

 

"A ta naissance, tout le monde rit et tu es le seul à pleurer. Conduis ta vie de façon à ce qu'à ta mort tout le monde pleure et que tu sois le seul à sourire."

Confucius

 

 

Articles conseillés :

 

Urbanisation du Système d'Information : les points d'attention concernant les performances

  

Urbanisation du Système d'Information : les dangers des nouvelles technologies

 

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


10/07/2017
0 Poster un commentaire

Mais dans la vrai vie, qu'est ce qu'il y a dans les règles d'urbanisme du Système d'Information ?

Dans la démarche d'urbanisation, cela dépend de chaque organisation, les règles d'urbanisme d'un SI couvrent tout ou partie du spectre de l'urbanisation, certaines sont obligatoires et d'autres de simples recommandations.

 

regles-urbanisme-si-0.jpg

 

Des règles portent sur la manière de définir les domaines fonctionnels. Elles prévoient de respecter les propriétés d'indépendance des blocs, de séparation entre domaines métier et domaine de support, …

 

D'autres règles d'urbanisme du SI traitent les cartographies :

  • Quelles cartographies sont exigées ?
  • Quelle granularité ?
  • Quels outils doivent être utilisés ?
  • Quels acteurs en sont responsables ?
  • Quelles sont les fréquences des mises à jour ?

 

Ces règles s'appliquent aux principales cartographies :
 

  • Cartographie fonctionnelle : elle décompose le périmètre de l'entreprise en domaines métiers. En principe cette cartographie évolue peu car elle reflète l'activité de l'entreprise et non son organisation . Cette cartographie est essentielle à l'urbanisme du SI car elle sert d'ossature à toute description et action sur le SI.
     
  • Cartographie métier : elle décrit les étapes des processus métiers majeurs de l'entreprise et leurs principaux échanges. Le grain de description peut être variable. Certaines contraintes, par exemple d'ordre réglementaire, peuvent nécessiter une description fine des processus. Pour d'autres cas, un niveau plus agrégé est suffisant.
     
  • Cartographie applicative : elle reporte de manière exhaustive les applications et leurs liens.
     
  • Cartographie technique : elle reporte les infrastructure techniques qui supportent les applications (serveurs, réseaux, …).

 

Pour les projets, ces règles établissent le paysage dans lequel devront s'insérer leurs développements. Elles déterminent aussi les documentations qu'il faut mettre à jour pour actualiser ce paysage.

 

Exemple de règles d'urbanisme :
Pour chaque domaine métier, une cartographie des applications existe et est mise à jour par les projets.

 

Concernant la mise sous contrôle des référentiels, des règles d'urbanisme du SI doivent stipuler :

  • La nécessité de se raccorder aux référentiels existants
  • Dans quels cas il convient de créer un référentiel
  • Les règles de gestion de ces référentiels

 

Exemple de règles d'urbanisme :
Un référentiel de données d'entreprise ne doit pas être géré dans une application spécifique opérationnelle. Dans le cas d'un ERP (Enterprise Ressource Planning), la gestion d'un référentiel au sein de l'ERP doit être murement réfléchi pour des raisons d'interopérabilité, des risques liés à un système propriétaire, …

 

Les règles d'urbanisme du SI pour la définition des cibles s'attachent à garantir l'existence de cibles métier et cibles d'urbanisme, sans interférer sur le contenu même de ces cibles. Des règles peuvent aussi prévoir les modalités de définition, de mise à jour et de validation des cibles fonctionnelles et techniques.

 

L'élaboration des cibles SI est l'occasion de lever la tête, afin de formuler les évolutions métiers sur le moyen/long terme et en déduire les adaptations du SI. La définition des cibles est le moyen d'améliorer l'efficacité dans la prise en compte des évolutions futures.

 

Exemple de règles d'urbanisme :
Par domaine métier, une cible fonctionnelle existe et est validée par le métier.

 

Les règles de construction de SI s'adressent aux projets. Elles vont leur garantir une bonne insertion dans le SI et une bonne capacité d'évolution. Par exemple :

  • Obligation, pour un module, d'être dans un et un seul domaine métier
  • Usage des référentiels
  • Nécessité de distinguer ce qui outille les processus métiers, le décisionnel, la gestion des ressources, la sécurité, …
  • Nécessité d'isoler les mécanismes d'échanges
  • Règles d'architecture technique (technologie, composants, …)

 

règles-d-urbanisme-du-système-d-information-1.PNG
 

 

Elles simplifient les projets, leur maintenance et leur appréhension par les acteurs SI

 

Exemple de règles d'urbanisme :
- La construction de tout nouveau système applicatif respecte un modèle en n couches
- 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 pour réaliser les fonctions : échanges, données référentielles, sécurité, décisionnel, gestion des ressources nécessaires au processus métier.
 

 

 

règles-d-urbanisme-du-système-d-information-2.PNG

 

Rhona Maxwel

@rhona_helena

 

"Ayant médité la douceur et la compassion, j'ai oublié la différence entre moi et les autres."

Milarepa

 

 

Articles conseillés :

 

Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?

 

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

 

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

 

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

 

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus


02/07/2017
0 Poster un commentaire

Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?

Quand les règles d'urbanisme ont été définies dans une démarche strictement top-down, il est à craindre des situations de blocage dans la mise en œuvre.

 

règles-d-urbanisme-du-système-d-information.PNG

 

Le besoin de disposer d'un ensemble de règles provient toujours de la nécessité d'introduire une cohérence dans la construction du SI :

  • pour définir un cadre normalisé de référence pour la gouvernance du Système d'Information.
  • pour homogénéiser, si nécessaires, les méthodes de développement, lorsqu'il y a plusieurs directions fonctionnelles.
  • dans le cadre de fusion de sociétés, pour définir les règles de construction des futurs systèmes communs.
  • pour pouvoir disposer d'un ensemble de règles standardisées.

 

C'est le besoin de cohérence et d'efficacité qui assurera lui-même le rôle moteur de l'urbanisation du SI.

Quand les règles d'urbanisme ont été définies dans une démarche strictement top-down, il est à craindre des situations de blocage dans la mise en œuvre.

L'adoption des règles est un mécanisme progressif et cumulatif.

 

Les principes sur lesquels sont fondés les règles d'urbanisme sont :

  • alignement sur les métiers
  • cohérence
  • modularité
  • subsidiarité
  • progressivité

 

La bonne pratique est que l'ordre de grandeur du nombre de règles soit de 30.

 

Les règles d'urbanisme vont formuler ce qui exigé et ce qui est interdit, mais trop de contraintes n'est jamais bon et il faudra laisser suffisamment de souplesse aux chefs de projet.

 

Rhona Maxwel

@rhona_helena

 

"Nul ne sait ce qu'il peut faire avant d'avoir essayé".

Publilius Syrus 

 

 

Articles conseillés :

 

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

 

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

 

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

 

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus

 

Urbanisation du Système d'Information : créez l'évènement !


05/02/2017
0 Poster un commentaire

Quel est le budget de l'urbanisation et urbanisme du Système d'Information ?

Le niveau d'investissement en urbanisme peut se mesure par un indicateur simple.

 

budget-urbanisation-urbanisme-systeme-d-information.png

 

L'urbanisme se développe par cycles.

L'investissement dans une nouvelle infrastructure d'urbanisme est obligatoire lorsqu'il y a des dysfonctionnements, des surcoûts, des blocages ou des constats de déphasage par rapport à la stratégie.

La mise en place de cette infrastructure est progressive, car l'urbanisme ne crée pas de rupture.

 

Des investissements pour la création ou le développement d'un service d'urbanistes et les réalisations techniques sont nécessaires.

L'étape suivante est la mise en œuvre de l'urbanisme dans les projets IT, véritable consolidation de la nouvelle politique d'urbanisme.

Cette infrastructure est conçue pour une durée de vie longue, plus longue que celle des systèmes d'information qui la prennent pour base.

Un jour, il faudra la remettre en cause, pour faire face aux enjeux futurs.

 

Une nouvelle période d'investissement sera engagée, modifiant tout ou partie des bases précédentes.

Ces cycles, générations successives de politiques d'urbanisme, sont des avancées dans la maîtrise des SI.

L'urbanisme gagne en maturité :

  • 1ère étape, on se limite à cartographier le patrimoine d'un SI mal connu. Ceci permet d'éviter l'empilement systématique des composants applicatifs issus de projets opportunistes. L'urbanisme est préventif, limite la complexité, les redondances et incohérences.
  • 2ème étape, l'urbanisme, ayant gagné en crédibilité auprès des maîtres d'œuvre, peut engager la promotion des référentiels.
  • 3ème étape de maturité, l'urbanisme espère à la mise en ordre des processus, et à un meilleur alignement stratégique.

 

Les efforts budgétaires dans l'urbanisme suivent des fluctuations périodiques :

  • Instabilité incitant à privilégier le simple et jetable
  • Nécessité d'aller au plus vite pour gagner des parts de marché en phase de croissance extensive
  • Période de consolidation
  • Année de restrictions financières

 

La difficulté analytique existe car la fonction urbanisme n'a pas un périmètre immuable :

  • D'une entreprise à l'autre, il existe des variantes dans les définitions (urbaniste, architecte fonctionnel, architecte d'entreprise), dans l'organisation, dans les rôles des processus de l'urbanisme.
  • Au sein des grands groupes, des variantes existent aussi entre les diverses entités, leur organisation, et la subsidiarité ajoute un niveau de complexité pour une comptabilité analytique.
  • Les entreprises ne mettent pas en œuvre tous les processus de l'urbanisme, cela dépend du contexte et du schéma de gouvernance.

 

Un indice de maturité basé sur une échelle unique serait réducteur, car l'objectif n'est pas d'appliquer tous les processus.

Au cas par cas, l'entreprise arbitre et choisit le panier de processus pertinents.

L'indice d'urbanisation restitue mieux cette approche multiple, et ne livre aucune préconisation.

 

Le niveau d'investissement en urbanisme peut se mesurer par un indicateur simple : le rapport entre cet investissement et celui constaté dans les projets de Systèmes d'Information.

L'urbanisme ayant une nature d'infrastructure pour les Systèmes d'Information, le dénominateur est constitué uniquement du coût d'étude, de développement, de test, à l'exclusion des coûts de maintenance, et de ceux de maîtrise d'ouvrage. Il s'agit de comparer des coûts d'investissement de même nature.

 
Le ratio d'urbanisme est donc le rapport entre d'une part, les investissements en conception, développement, test dans l'urbanisme des Systèmes d'Information et, d'autre part, les frais de même type dans les projets de SI.
La fourchette est comprise entre 1 % et 5 %.

 

L'effet de levier de l'urbanisme porte sur la création de valeur.

Par son action vertueuse sur la flexibilité, la réactivité, il contribue alors directement à la stratégie.

L'urbanisme révèle et positionne certains composants du SI et objective les scénarios répondant aux aléas et stratégies du métier.

 

Si tel est le cas, un ratio d'urbanisme durablement faible, une fonction sous-configurée et incapable de répondre, en qualité, aux enjeux, pourra mettre en péril l'entreprise, bien au-delà de la performance des processus.

 

Rhona Maxwel

@rhona_helena

 

« Le courage est la première des qualités humaines car elle garantit toutes les autres. »

Aristote

 

 

Articles conseillés :

 

En Urbanisation SI, les constructions/destructions et l’entretien du POS sont réglementés

 

Urbanisme SI : les objectifs en moins de 20 lignes !

 

Urbanisation du Système d'Information : Ne vous perdez pas dans les typologies de référentiel !

 

Urbanisation du Système d'Information : créez l'évènement !

 

Dans le futur, il faudra réaliser la symbiose des méthodes et veiller à la cohérence des gouvernances SI et processus


14/01/2017
0 Poster un commentaire