urbanisation-si.com

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

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

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

10

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

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

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

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

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

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

• Modélisation de système

9

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

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

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

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

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

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

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

• Architecture Micro-Services

8

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

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

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

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

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

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

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

Voir la catégorie UML de notre blog :

• UML

7

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

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

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

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

6

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

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

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

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

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

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

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

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

• Modélisation de système

5

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

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

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

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

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

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

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

Voir la catégorie BPMN de notre blog :

• BPMN

4

ArchiMate pour les nuls : les fondamentaux - 1

ArchiMate pour les nuls : les fondamentaux - 1

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

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

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

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

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

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

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

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

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

Voir la catégorie ArchiMate de notre blog :

• ArchiMate

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

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

3

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

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

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

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

Voir la catégorie ArchiMate de notre blog :

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

2

SysML : le diagramme d'exigence (requirement diagram)

SysML : le diagramme d'exigence (requirement diagram)

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

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

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

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

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

Voir la catégorie SysML de notre blog :

• SysML

Dans cet article se trouvent les articles traitant : 

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

1

TOGAF pour les nuls

And the winner is...

TOGAF pour les nuls

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

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

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

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

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

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

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

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

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

Voir les catégories de notre blog :

• Architecture Orientée Services (SOA)

• • Architecture technique SOA
  • Gouvernance SOA

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

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

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

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

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

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

Voir la catégorie TOGAF de notre blog :

• TOGAF

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

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

Rhona Maxwel

@rhona_helena

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

Références des principaux articles du blog

TOGAF

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

ArchiMate

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

BPMN

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

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.

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 ?

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

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.

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 ?

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

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 ?

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.

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.

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

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.

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, …)

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

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

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.

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é

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 !

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

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.

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

Le pragmatisme de CobiT vient de la fourniture de tableaux de correspondance permettant d'identifier l'ensemble des objectifs informatiques dérivant de chaque objectif métier, puis les processus CobiT liés aux objectifs informatiques.

CobiT (Control Objectives for Information and related Technology) est un référentiel c'est à dire une boite à outils contenant les meilleures pratiques, orienté dans le domaine de la gouvernance.

Comme toujours on peut appliquer une approche top-down traduisant avec efficience les objectifs stratégiques d'entreprise en un ensemble d'objectifs informatiques cohérents, eux même alimentés par un ensemble de processus CobiT.

Le pragmatisme de CobiT vient de la fourniture de tableaux de correspondance permettant d'identifier l'ensemble des objectifs informatiques dérivant de chaque objectif métier, puis les processus CobiT liés aux objectifs informatiques.

CobiT fournit la démarche concernant les technologies, les applications, les compétences, l'architecture technique, l'efficience et la conformité  des exigences métiers, la gouvernance et enfin l'analyse de la maturité des processus.

L'approche bottom-up quand à elle, permet un audit d'objectifs CobiT, d'identifier les forces et les faiblesses informatiques et les impacts éventuels sur les métiers. La DSI a donc à sa disposition, un excellent outil d'analyse de risques. 

Lors d'une mission pour un service public, la DSI avait demandé une étude sur l'efficience de la gouvernance de son SI suite à une fusion. Les processus CobiT furent passés en revue pour déterminer ceux qui étaient prioritaires. Dans le domaine "Planifier et Organiser (PO)", les processus "Définir un plan stratégique informatique (PO1)", "Définir l'architecture de l'information (PO2)", "Gestion des risques (PO9)", et dans le domaine "Distribuer et soutenir (DS)", le processus "Gérer les services de Tiers (DS2)" fut identifié.

L'étape suivante a consisté à analyser leur degré de maturité grâce à la vérification de leur mise place, leur formalisation, leur diffusion, l'outillage, les métriques et s'il existait une démarche d'amélioration continue. Une notation (0 à 5) est attribuée en fonction du modèle CobiT. Pour chaque processus, la maturité mesurée du client est mise en perspective par rapport à l’état de l’art d’une part (la moyenne constatée dans un échantillon représentatif d’entreprises) et par rapport aux entreprises les plus en avance dans le domaine (best of breed) d’autre part.

Concernant le processus "Définir un plan stratégique informatique (PO1)", les points positifs étaient qu'un schéma directeur était réalisé selon une méthode formelle avec une organisation dédiée et que le processus était formalisé, planifié, partagé par les parties prenantes et notamment les métiers qui avaient validé le fait que leurs exigences étaient bien prises en compte. Le point négatif fut que le schéma directeur devait être révisé un an après sa réalisation, ce qui ne fut pas le cas.

Pour le processus "Gérer les services de Tiers (DS2)", aucun processus formalisé fut identifié, ce qui expliqua en partie les surcoûts exorbitants de certains développements qui dépassaient de plus de 3 fois les pratiques usuelles du marché !

A chaque phase, une remise en question des objectifs définis et du niveau de maturité de chacun des processus est donc effectuée afin que le SI soit le mieux aligné avec la stratégie de l'organisation. Attention, ce n'est pas magique, vous ne trouverez pas de remèdes miracles, c'est à dire que CobiT ne précise pas le "comment" (comme le font du reste les normes !), et il faudra alors se tourner vers d'autres référentiels comme CMMi, ITIL ou eSCM et c'est du reste une tendance des plus en vogue qui est d'utiliser le meilleur de chaque référentiel, nous y reviendrons dans un prochains épisode.

Rhona Maxwel

@rhona_maxwel

"Les amoureux campent rarement sur leurs positions : ils passent vite de l’inclination du cœur à l’inclinaison des corps..."

Daniel Confland

Articles conseillés :

Mais où va ITIL ?

Donnez moi des bonnes raisons d'urbaniser mon SI ?

CMMi, un projet comme un autre ?

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

Rhona Maxwel

@rhona_maxwel

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

Daniel Desbiens

Articles conseillés :

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

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

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