urbanisation-si.com

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.    

Voir aussi le site :

Abandonnez le classicisme, relookez votre SI