urbanisation-si.com

urbanisation-si.com

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


Les meilleurs articles sur l’architecture d’entreprise, ses méthodes et ses outils, découvrez quels sont les articles les plus lus de notre blog

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

 

meilleurs-articles-architecture-entreprise-methodes-outils

 

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

 

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

 

10

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

 

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

 

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

 

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

 

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

 

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

 

 

9

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

 

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

 

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

 

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

 

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

 

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

 

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

 

8

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie UML de notre blog :

 

7

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

 

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

 

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

 

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

 

6

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

5

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie BPMN de notre blog :

 

4

ArchiMate pour les nuls : les fondamentaux - 1

 

ArchiMate pour les nuls : les fondamentaux - 1

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie ArchiMate de notre blog :

 

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

 

3

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

 

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

 

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

 

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

 

Voir la catégorie ArchiMate de notre blog :

 

2

SysML : le diagramme d'exigence (requirement diagram)

 

SysML : le diagramme d'exigence (requirement diagram)

 

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

 

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

 

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

 

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

 

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

 

Voir la catégorie SysML de notre blog :

 

Dans cet article se trouvent les articles traitant : 

 

1

TOGAF pour les nuls

 

And the winner is...

 

TOGAF pour les nuls

 

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

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

 

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

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

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

 

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

 

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

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

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

 

Voir les catégories de notre blog :

  • Architecture Orientée Services (SOA)

 

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

 

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

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

 

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

 

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

 

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

 

Voir la catégorie TOGAF de notre blog :

 

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

 

 

Rhona Maxwel

@rhona_helena

 

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

 

Références des principaux articles du blog

 

TOGAF

 

  1. TOGAF pour les nuls.

  2. Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  3. La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  4. Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

  5. Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)

  6. Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)

  7. Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  8. Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  9. Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  10. La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  11. La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  12. Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  13. Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  14. L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  15. L’extension « Services » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  16. L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  17. L’extension « Modélisation des données » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  18. L’extension « Consolidation d’infrastructure » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  19. L’extension « Motivation » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

  20. Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

  21. Le référentiel TOGAF, le patrimoine des informations et des bonnes pratiques pour toute l’entreprise

  22. Gouvernance d’entreprise, Gouvernance technologique, Gouvernance informatique et Gouvernance de l’architecture : mais où se situe la Gouvernance TOGAF ?

  23. Le cadre de gouvernance de l'architecture : identifier les processus et les structures organisationnelles efficaces

  24. Gouvernance de l'architecture en pratique : principaux facteurs de succès et éléments d'une stratégie efficace

ArchiMate

 

  1. ArchiMate pour les nuls : les fondamentaux - 1

  2. ArchiMate la synthèse : les éléments de motivation - 2

  3. ArchiMate en condensé : les éléments de stratégie - 3

  4. ArchiMate l’essentiel : les éléments de la couche métier - 4

  5. ArchiMate mémento : les éléments de la couche application - 5

  6. ArchiMate aide mémoire : les éléments de la couche technologique - 6

  7. ArchiMate en abrégé : les éléments physiques de modélisation - 7

  8. ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8

  9. ArchiMate : modélisation de l’alignement des couches d'application et de technologie - 9

  10. ArchiMate : les éléments d'implémentation et de migration - 10

  11. ArchiMate : vues et points de vue - 11

  12. ArchiMate : guide complet des éléments de modélisation - 12

 

BPMN

 

  1. BPMN 2 : les concepts de base des processus métiers

  2. BPMN pour les nuls : les collaborations

  3. BPMN pour les nuls : les chorégraphies (Choreographies)

  4. BPMN pour les nuls : les conversations

  5. BPMN : norme OMG - synthèse des éléments graphiques

  6. BPMN : l'antisèche pour rester incollable en modélisation de processus

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

  8. BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza

  9. BPMN : mais que dit la norme sur les sous-processus et la gestion des événements d'interruption et de remontée d'incidents ?

  10. BPMN : processus exécutables, comment s'y prendre ? (1/3)

  11. BPMN : processus exécutables, comment s'y prendre ? (2/3)

  12. BPMN : processus exécutables, comment s'y prendre ? (3/3)

  13. Comment identifier, simuler, améliorer et modéliser les processus métiers ?

  14. Comment mettre en place un jeu de rôles pour modéliser un processus métier ?

 


19/01/2021
0 Poster un commentaire

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

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

 

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

 

 

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

 

Les indicateurs des processus d'urbanisation du SI

 

Rhona Maxwel

@rhona_maxwel

 

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

Daniel Desbiens

 

 

Articles conseillés :

 

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

 

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

 

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


10/12/2016
0 Poster un commentaire

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

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

 

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

 

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

  

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

 

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

 

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

 

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

 

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

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

 

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

  

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

 

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

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

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

  

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

 

Rhona Maxwel

@rhona_helena

  

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


08/12/2016
0 Poster un commentaire

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

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

 

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

  

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

 

Objectif 1 :

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

 

Objectif 2 :

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

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

 

Objectif 3 :

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

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

 

Objectif 4 :

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

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

 

Objectif 5 :

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

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

 

Objectif 6 :

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

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

 

 

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

L'indicateur de cette mesure est :

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

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

 

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

Goswin Joseph Augustin, baron de Stassart

 

Rhona Maxwel

@rhona_helena

 

 

Articles conseillés :

 

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

 

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

 

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

 

Pas de nouvelles, mauvaises nouvelles

 

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


07/12/2016
0 Poster un commentaire

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Rhona Maxwel

@rhona_helena

 

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

 

Articles conseillés :

 

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

 

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

 

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

 

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

 

Le Big-Mac de l'urbanisation SI


06/12/2016
0 Poster un commentaire

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

retour_vers_le_futur.jpg

 

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

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

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

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

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

Dés lors, le champ des préoccupations d'urbanisme débordant le monde clos de l'entreprise, il faudra raisonner sur l'entreprise et son écosystème.

Les flux, la gestion des grands référentiels, l'activation de services automatisés, de bases de connaissances, seront à situer dans un contexte élargi, où les mouvements stratégiques, partenariats, fusions, filialisations, acquisitions, externalisations, pourront redistribuer les cartes autour des composants urbanisés.

Les urbanistes devenant architecte de la chaîne de valeur, auront à étendre leurs investigations jusqu'aux limites de ces champs d'action.

 

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

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

Il faudra se préoccuper de diffuser la culture du management par les processus, de faire passer le BPM dans la réalité : instituer des propriétaires de processus, gouverner l'amélioration et piloter les performances pour que les processus répondent aux services qu'attendent les multiples parties prenantes, clients, usagers, partenaires, employés, actionnaires, sociétaires, ...

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

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

Pourtant dans le futur, il faudra fédérer les approches par les SI et celles par les processus, connecter les différentes visions transversales, réaliser la symbiose des méthodes, veiller à la cohérence des gouvernances SI et processus : les urbanistes seront les catalyseurs de cohérence, de transversalité, et de flexibilité.

 

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

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

Ils ne doivent pas ignorer les évolutions techniques.

Un miracle technologique se produira-t-il (attention aux effets de buzz) ? Une révolution technique donnera-t-elle l'agilité instantanée tant espérée ? 

 

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

 

Les grandes entreprises dotées de SI de plus en plus complexes, seront confrontées à un environnement réglementaire multiple, protéiforme, à des contraintes de marché archi-mondialisées.

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

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

 

Rhona Maxwel

@rhona_helena

 

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


02/05/2016
0 Poster un commentaire

Architecture d'entreprise : le framework de Zachman pour les nuls

urbanisation-si-arcitecture-d-entreprise-framework-zachman.jpeg

 

Le système d’information d’une organisation peut s’organiser suivant une matrice (Framework de Zachman) ou les colonnes sont les traditionnels : Quoi (inventaires des données), Comment (processus métier), Ou (localisation, distribution), Qui (Acteurs, responsabilités), Quand (temporalité, fréquence), Pourquoi (motivations, objectif stratégiques) et les lignes représentent les niveaux du plus au moins abstrait : Contexte (identification du périmètre métier, planification), Conceptuel (concepts et modèles métiers), Logique (architecture, modèles de conception), Ingénierie (réalisation des entités métiers, spécifications techniques), Perspective physique (implémentations des composants métiers, outils) , Perspective entreprise (la réalisation des différentes activités dans l’entreprise) et les cellules représentent les artefacts à réaliser.

 

La métaphore de la cité : le POS (Plan d’Occupation des Sols) d’un SI a pour but :
• De définir les services et les responsabilités attachées à chaque sous-ensemble
• D’organiser le SI
• L’objet et la mission des applicatifs le composant
• Les regroupements d’applicatifs en ensemble cohérents
• Les périmètres réservés pour de futurs applicatifs à construire, notamment pour les applicatifs transversaux
Le POS d’un SI doit être compatible et s’aligné sur la stratégie de l’entreprise. Le dossier doit comporter :
• Synthèse sur les orientations et options retenues
• Un ensemble de cartographies (graphiques et commentaires associés) montrant avec précision les différentes subdivisions du SI et permettant de savoir à quels sous-ensembles du SI s’applique ou non une règle d’urbanisme donnée
• Les règles d’urbanisme ainsi que la définition de la mission et des services de chaque zone, quartier et îlot
• Annexes, CR d’entretiens, liste des personnes concernées, …
Le découpage en zones suit la typologie suivante :
• zone échange est responsable de l’acquisition/restitution du SI vis à vis de son environnement extérieur
• zone gisement de données : ensemble de toutes les informations dynamiques et pérennes ainsi que les services d’accès à ces données et assure la conservation et la valorisation du patrimoine d’informations, garantit sa cohérence et permet son enrichissement dans le temps
• zone référentielle des données de l’entreprise : regroupe l’ensemble de toutes les informations communes aux différents éléments du SI dont le cycle de vie est relativement stable
• zones opérations : on en trouve par métier principal
• zone ressource : regroupe les systèmes dédiés à la gestion des ressources internes (RH, comptabilité, …)
• zone pilotage
Les quartiers dans le SI sont des composants homogènes quant à la nature de l’information traitée. Ils correspondent à un sous-système. On a un couplage faible et une forte cohérence entre les quartiers. Ils regroupent les îlots qui sont les plus petits niveaux de décomposition du SI.
Un îlot :
• représente des entités (développées ou achetées) remplaçables du SI
• correspond à un but fonctionnel et avoir des accès à des bases de données
• reçoit ou émet des données vers d’autres îlots
• équivalent à une application ou une grande fonction applicative
• progiciel ou module d’un progiciel.
Mais à quoi peuvent bien ressembler les règles d’urbanisme ? Exemple :
• Interdictions comme d’accéder à un bloc sans passer par son port (prise)
• Limitations, par ex. une donnée doit être sous la responsabilité d’un et d’un seul bloc
• Prescription, par ex. tout bloc doit avoir un port (prise)
Parmi retours d’expérience les plus fréquemment cités :
• Les cartographies des applications existantes sont exhaustives et constituent un référentiel partagé, complet et administré de façon centralisé
• Les cartographies d’états futurs du SI sont moins fréquentes et leur niveau de détail est d’autant moins fin que l’on se projette dans un futur lointain
• La mise à jour des cartographies est réalisée dans la plupart des cas par des cellules dédiées mais la tendance est d’inscrire la mise à jour de la cartographie dans la méthodologie de conduite de projet
• La restitution des cartographies se fait par l’intermédiaire d’un intranet en général largement ouvert aux utilisateurs concernés
Néanmoins malgré sa très large généralisation, la cartographie applicative rencontre des difficultés :
• La coexistence de la cartographie de l’existant, de cartographie futures à différents horizons et d’une cartographie cible est difficile à obtenir
• La maîtrise de la cohérence du référentiel de cartographie, notamment en ce qui concerne les flux inter-applicatifs, nécessite un processus formalisé de mise à jour, qui n’est pas toujours en place ce qui nécessite d’effectuer des contrôles à posteriori
• La production de sous-ensembles cartographiques spécifiques n’est pas automatisée
• Le maintien à jour de la cartographie est difficile et nécessite organisation, suivi et support du management
Mais, la question qui intéresse tout le monde, c’est en quoi un environnement urbanisé peut-il réduire les coûts projet. Les réponses sont multiples :
• Mise à disposition d’informations sur le contexte fonctionnel et les applications
• Anticipation des impacts des autres projets
• Réduction des études amont et des études préalables
• Réduction du risque de fausse route
• Maîtrise du périmètre des projets
• Réduction des risques liés à la taille des projets
• Réduction des études, des développements et de la recette
• Existence de briques directement utilisables (composants, référentiels, EAI, ESB, données…)
• Existence de règles de construction qui permettent aux projets de se centrer sur les problèmes métier.
Pour les spécifications, on a un surcoût de l’ordre de 20% au départ pour passer à une orientation processus et une économie par la suite de 30% du à la simplification des études d’impact d’où un gain net de 10%.
Sur le développement on a un gain net de 20% car les objets métiers sont mutualisés et externalisés des processus.
L’intégration gagne en net un facteur de 40%. Il faut en effet au départ un surcoût de 30% pour acquérir le technique des bus logiciel et des adaptateurs mais une économie par la suite de l’ordre de 70% grâce à la réutilisation et au fait qu’il faille un seul adaptateur à réaliser pour se connecter au bus. 
Ce que gagne l’exploitation, environ de l’ordre de 20% du aux découplages des systèmes et la flexibilité des hébergements, est perdu à cause des logiciels à mettre en œuvre (bus, logiciel d’administration, de surveillance, …).
Bien souvent, des applications obsolètes continuent de tourner par peur de couper le « mauvais fil » tellement les liens qui la relie au SI constitue un véritable plat de spaghetti. Si le SI est bien urbanisé, un seul lien à désactiver suffit d’où un gain net estimé à 80%. 
Bien sur ces contributions continuent leurs effets dans les phases d’évolution ou de maintenance.
La gouvernance du SI optimise l’ensemble « fonctionnalités, coûts, délais » en misant sur l’urbanisation du SI. Chaque projet, lui aussi, optimise le même ensemble, mais à son échelle.
Pourquoi les projets sont-ils réticents à appliquer les règles d’urbanisme, parce qu’ils y voient une source de coûts additionnels.
La raison est que chaque projet voit les efforts de maintien ou d’amélioration de l’urbanisation comme générateurs de coûts. La raison d’être même des projets explique ce point de vue. En effet, un projet est constitué pour fournir, partant d’une situation donnée, une situation cible dans des coûts et délais déterminés. Les facilités que lui offrent son environnement, fruit des projets précédents, et les surcoûts éventuels qu’il génère aux projets suivants ne sont pas prises en compte par le projet. Un projet ne tient pas compte des efforts passés : il ne valorise pas dans son budget ce qui lui apporte un contexte urbanisé. Le projet n’a aucune nécessité de simuler quel aurait été son coût si la cartographie n’était pas à jour, s’il n’y avait pas de référentiels, si aucun mécanisme d’échange inter-applications n’était disponible, ... ce contexte à haute valeur ajoutée est considéré comme gratuit, alors qu’en fait, il s’agit d’une réduction de coût financée par les projets antérieurs. Un projet ne tient pas compte de la situation qu’il laisse: le projet ne valorise pas non plus le surcroît de travail qui sera demandé aux projets suivants et à la maintenance du produit si le projet dégrade l’urbanisation. Par contre, chaque jour de travail à maintenir ou améliorer l’urbanisation apparaît dans ses charges: tout naturellement, le projet va privilégier les ressources vers des tâches qui participent à l’atteinte de ses objectifs. Les tâches « pour la suite » apparaissent inévitablement comme des surcoûts.
Il faut se lancer dans l’urbanisation dès le départ du projet, les méthodes, les retours d’expérience et les outils existent et font qu’aujourd’hui urbaniser son SI n’est plus une aventure mais de la vulgaire routine.   

 

"Rien ne vous emprisonne excepté vos pensées. Rien ne vous limite excepté vos peurs. Et rien ne vous contrôle excepté vos croyances."
Marianne Williamson

 

Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


17/09/2015
0 Poster un commentaire

Urbanisation du Système d'Information vs Architecture d'Entreprise

Architecture-Entreprise-Framework-Zachman-vs-Urbanisation-SI-2.png

L'architecture d'Entreprise comme le célèbre framework Zachman, couvre toutes les strates de l'entreprise. Il est alors intéressant de voir quelles sont les lignes et colonnes couvertes par l'urbanisation du système d'information. 

Le procesus d'urbanisation répond aux couches "Scope (contexte)" , "Business Model (conceptuel)" et "System Model (logique)".

La stratégie de l'entreprise (Scope) et ses processus métier (Business Model) doivent être réalisés (en partie) par le SI (System Model). Une des préoccupations de l'urbanisme du SI est de mettre en oeuvre cette implémentation et la traçabilité nécessaire.

Ainsi la structure organisationnelle,  le modèle métier avec  ses processus, ses entités et leurs cycle de vie, sont liés aux systèmes applicatifs et leurs modèles de données.

La démarche d'urbanisme descend jusque sur l'axe  de préoccupation "System Model" correspondant à la vue logique du SI.

Cette comparaison avec le framework de Zachman montre bien que l'urbanisation des systèmes d'information joue le rôle de "glu" entre les processus métier et leurs dérivations logiques dans le SI.

 

"Tu dois devenir l'homme que tu es. Fais ce que toi seul peux faire. Deviens sans cesse celui que tu es, sois le maître et le sculpteur de toi-même."
Friedrich Nietzsche

  

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


13/07/2015
0 Poster un commentaire

Urbanisation du Système d'Information : MOE, boulversez vos habitudes, le changement a du bon !

urbanisation-du-systeme-d-information-accompagenement-changement-developpeur.jpg

Le changement est stimulant pour l'intellect. 

Un processus d'urbanisation s'accompagne forcément de changements dans les manières de travailler de la MOE et de la MOA.

La réticence aux changements est un comportement humain normal qui engendre une peur, un stress de ce que l'on ne connaît pas.

On a toujours le réflexe de dire "avant c'était mieux" en oubliant de préciser le contexte et quels étaient les buts à l'instant des choix.

Le plan d'urbanisme impose des modifications draconiennes dans les processus de réalisation des systèmes d'information.

Tous les acteurs de la MOE, architectes techniques, concepteurs, développeurs, ... doivent s'approprier de nouvelles technologies, se conformer à de nouvelles méthodes et assimiler de nouveaux paradigmes.

Il est donc légitime qu'ils perdent leurs repères, qu'ils critiquent sévèrement certains acteurs, qu'ils éprouvent une certaine confusion et le sentiment que tout leur échappe.

L'accompagnement au changement qui est absolument primordial dans la démarche d'urbanisation du SI, doit permettre : l'appropriation des concepts, la suppression des peurs, la mauvaise compréhension des valeurs de l'entreprise communiquées par la démarche, la reconnaissance du travail déjà accompli et enfin d'amoindrir la nostalgie du passé.

Cet accompagnement au changement doit tenir compte des fonctions occupées, des statuts, du contexte de travail et des bases des évaluations pour les évolutions de carrière. 

La capacité de la MOE à adapter son comportement et à acquérir des nouvelles compétences ne se fera que si un accompagnement du changement a été pleinement conçu et mis en oeuvre avec succès. 

 

"La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information."
Albert Einstein

 

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


07/07/2015
0 Poster un commentaire

Urbanisation du Système d'Information : la MOA fait partie d'un projet et un projet ne fait pas de politique !

urbanisation-systeme-d-information-responsabilite-MOA.png

Une des difficultés dans le processus d'urbanisation du système d'information réside dans la conception et la modélisation des processus métiers. La maîtrise d'ouvrage devrait être apolitique et créer ses processus en fonction de la seule stratégie de l'entreprise.

Or dans la réalité, la création ou l'évolution des processus métiers se font en fonction des intérêts de telle ou telle personne cherchant à prendre du galon ou à résoudre ses propres conflits.

Ceci entraîne des processus non optimisés, qui soutiennent de manière incomplète les objectifs opérationnels du SI.

De plus, la MOA ne fait pas d'efforts pour s'organiser et se rendre disponible pour le projet.

La direction Générale doit donc impliquer la MOA et la responsabiliser dans l'atteinte du bon déroulement du projet et donc dans la conception et la modélisation des processus métiers.

La modélisation des processus métiers est réalisée par la MOA opérationnelle (ou déléguée ou AMOA) en collaboration étroite avec la MOE pour la faisabilité technique et les estimations de charges, le tout sous la responsabilité de la MOA  stratégique.

La MOE  a un devoir d'alerte en cas de problèmes techniques, de performances, d'estimation de charges trop importante et est force de proposition pour tirer le meilleurs profit des avancées technologiques.

La versatilité de la MOA et sa difficulté à valider les évolutions d'un processus font partie des causes importantes d'échecs de projets d'évolution du SI.

L'assistance à MOA et avec la MOE doit fournir les techniques pour proposer un dossier de choix comportant plusieurs scénarios de solutions qui devront être partagées par l'ensemble des parties prenantes du projet.  

 

"L'égoïste n'est pas celui qui vit comme il lui plaît, c'est celui qui demande aux autres de vivre comme il lui plaît ; l'altruiste est celui qui laisse les autres vivre leur vie, sans intervenir."
Oscar Wilde

 

 Voir aussi :  

 

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/


06/07/2015
0 Poster un commentaire