- Urbanisation (informatique)
-
L'urbanisation du système d'information de l'entreprise est une discipline informatique consistant à faire évoluer le système d'information d'une entreprise dans son ensemble afin de garantir sa cohérence vis-à-vis des objectifs et du métier de cette entreprise, en prenant en compte ses contraintes externes et internes, tout en tirant parti des opportunités de l'état de l'art informatique. Cette discipline s'appuie sur une série de concepts calqués sur ceux de l'urbanisation de l'habitat humain (organisation des villes, du territoire), concepts qui ont été réutilisés en informatique[1] pour formaliser ou modéliser la réingénierie du système d'information (SI)[2].
L'urbanisme définit des règles ainsi qu'un cadre cohérent, stable et modulaire, auquel les différentes parties prenantes se réfèrent pour toute décision d'investissement relative au management du système d'information.
Enjeux de l'urbanisation du système d'information
L'urbanisation permet de diriger la transformation continue du système d’information.
Les évolutions des stratégies d'entreprise (regroupements et fusions, acquisitions, diversification des offres commerciales, e-commerce, gestion de la relation client, nouveaux modes ou canaux de distribution, partenariats, réorganisation, externalisation, redéploiement des fonctions de back et front office, etc.) impliquent des changements structurels importants et accroissent l’interdépendance (dépendance mutualisée) et l’imbrication des applications informatiques avec le risque de renforcer l’effet « plat de spaghettis » du système d'information ou SI.
Cette complexité croissante a des conséquences sur les coûts, les durées et les risques des projets d’évolution des SI.
Pour maîtriser progressivement l’évolution des SI avec la réactivité nécessaire et pour réduire les coûts informatiques, une réponse est apportée par la démarche d’urbanisation des systèmes d’information et par son prolongement au niveau de l’architecture des systèmes informatiques.
Cette démarche d'urbanisation vise un SI capable de soutenir et d’accompagner la stratégie d'entreprise dans le meilleur rapport coûts/qualité/délais.
Elle permet d’améliorer la réactivité et de n’investir que dans les produits et services générateurs de valeur ajoutée, tout en maîtrisant les charges informatiques et le retour sur investissement.
Les outils d'EAM favorisent cette démarche qui peut se mettre en œuvre :
- de manière opportuniste : à l’occasion d’un projet de développement, de refonte ou de maintenance,
- de manière plus volontariste : dans le cadre d’un chantier d’urbanisation.
On utilise le terme d'urbanisation plutôt que celui d'urbanisme pour mettre l'accent sur le travail progressif nécessaire pour faire évoluer le système d'information vers une cible correctement urbanisée.
Par ailleurs, cette démarche d'urbanisation rencontre une des préoccupations des maîtrises d'ouvrage : l'alignement stratégique du système d'information sur le métier.
L'urbanisation commence à faire son chemin dans d'autres disciplines, notamment le cœur de métier des architectures de télécommunications. Ce type d'urbanisation utilise les mêmes outils et méthodes que l'urbanisation du SI en se concentrant sur l'optimisation des architectures des systèmes de télécommunications (Services de voix, services audiovisuels, réseaux de transports informatique, etc.).
L'urbanisation des télécoms permet d'améliorer la qualité d'un système cible ayant vocation à évoluer.
Voir :Principe de l'urbanisation du SI
L'urbanisation répond à deux règles de bases :
- Une application doit appartenir -en cible- à un et un seul bloc.
- Les dépendances doivent respecter les notions de Cohérence Forte / Couplage Faible
- entre les applications,
- au sein d'une application : entre les différents modules,
- au sein d'un module : entre les différents composants.
Le terme -en cible- définit l'application que l'on cherche à avoir to be. Elle s'oppose à l'existant -la situation actuelle- As is. La méthode pour passer du as-is actuel au to-be souhaité est appelé la roadmap (ou feuille de route).
La notion de Cohérence Forte / Couplage Faible indique que deux applications doivent communiquer entre elles de façon simple et efficace, mais que la dépendance entre ces deux applications est minimale (idéalement inexistante). Cela permet donc de retirer un bloc pour le remplacer sans perturber le reste du SI.
Le système d'information peut donc être comparé au quartier d'une ville : si ce dernier est bien bâti et bien urbanisé, il est possible de raser un bâtiment au cœur du quartier sans mettre en péril tout le secteur, et de le remplacer par ou de reconstruire un autre bâtiment, en raccordant ce nouveau bâtiment aux différents réseaux d'échanges : voirie d'accès, électricité, évacuation des eaux usées, etc. L'urbanisation consiste donc à créer un SI agile, modulable et évolutif.
Application des concepts d'urbanisation
L’urbanisation informatique définit l'organisation d’un système d'information (SI) à l’image d’une ville.
Zone, quartier et bloc
L'urbanisation consiste à découper le SI en modules autonomes, de taille de plus en plus petite :
- les zones,
- les quartiers (et les îlots si nécessaire),
- les blocs ou les briques (blocs fonctionnels).
Entre chaque module (zone, quartier, îlot, bloc) se dessinent des zones d’échange d’informations qui permettent de découpler les différents modules pour qu'ils puissent évoluer séparément tout en conservant leur capacité à interagir avec le reste du système.
Plus particulièrement, l’urbanisation vise :
- à renforcer la capacité à construire et à intégrer des sous-systèmes d'origines diverses,
- à renforcer la capacité à faire interagir les sous-systèmes du SI et les faire interagir avec d’autres SI (interopérabilité),
- à renforcer la capacité à pouvoir remplacer certains de ces sous-systèmes (interchangeabilité).
et de manière générale pour le SI à :
- favoriser son évolutivité, sa pérennité et son indépendance,
- renforcer sa capacité à intégrer des solutions hétérogènes (progiciels, éléments de différentes plates-formes, etc.).
Règle de découpage du SI
- Règle 1 : Séparation du Back-office du Front-office.
- Règle 2 : Découpage par processus et par métier. On crée ainsi les zones Décisionnel, Support et Métier.
NB : La zone Métier peut être découpée en plusieurs blocs.
- Règle 3 : Séparation des canaux technologiques d'accès et de communication (site Web, Minitel, notification SMS, ...) des canaux du métier 'Relation Client' (CRM, Marketing). On inscrit deux nouvelles zones dans le Front-Office : Acquisition/Restitution et Relation avec les tiers.
- Règle 4 : Il faut isoler ce qui est partagé par le Back-office et le Front-office ainsi que ce qui les intègre. On définit donc les zones Intégration et Données Partagées.
Les différents types de zones
Dans le découpage d'un SI on distingue habituellement différents types de zones :
- Les zones des échanges avec l’extérieur du SI : acquisition/émission de/vers les partenaires : clients, fournisseurs, etc. ;
- Les zones des activités opérationnelles : gestion des opérations bancaires, gestion des opérations commerciales, gestion des opérations logistiques internes, etc. ;
- Les zones de gestion des données de référence communes à l'ensemble du SI : les référentiels de données structurées (données clients, catalogue de produits et services, etc.) ;
- Les zones de gestion des gisements de données : ensemble des informations produites quotidiennement, communes à l'ensemble du SI (données de production, etc.) ;
- Les zones des activités de support : comptabilité, ressources humaines, etc. ;
- Les zones des traitements pour l’aide à la décision et le pilotage : informatique décisionnelle.
Dans le cas de très grandes entreprises, il est matériellement impossible d'urbaniser la totalité du SI dans un même mouvement. Cela explique que l'on découpe le SI de l'entreprise en périmètres autonomes ; par exemple : par grandes directions. Chaque périmètre est alors considéré comme un SI autonome qui est urbanisé individuellement. Sa zone d'échange gère ainsi aussi bien les flux extra-entreprises "SI ⇔ SI extérieurs" que les flux intra-entreprises "SI ⇔ autres SI de l'entreprise".
Exemple de découpage
A titre d'illustration, une partie du découpage du système d'information d'une banque :
- ensemble des zones d'activités opérationnelles
- zone production bancaire
- quartier gestion des crédits
- îlot gestion des crédits immobiliers
- bloc fonctionnel gestion d'un impayé
- îlot gestion des crédits immobiliers
- quartier gestion des crédits
- zone production bancaire
Quatre niveaux de préoccupation
Les quatre niveaux de préoccupation indiqués correspondent à ceux du méta-modèle d’urbanisme, sauf la vue stratégique, qui toutefois doit intégrer les aspects du matériel, du contexte, des ressources humaines, etc. Le matériel se retrouve dans la vue technique du méta-modèle d’urbanisme.
La vue stratégique
Cette vue est constituée par la description
- des objectifs de l'entreprise,
- des objectifs du système d'information à urbaniser
- de la mise en correspondance entre ces deux sortes d'objectifs : l'alignement stratégique.
Ces objectifs peuvent être modélisés
- soit comme une liste hiérarchique de thèmes et de sous thèmes,
- soit comme un diagramme de causes et effets, ou diagramme d'Ishikawa (en arête de poisson), qui indique les causes (matière, matériel, méthode, ressources humaines, milieu / contexte) qui produisent des effets.
La liste de thèmes peut être obtenue par l'analyse des exigences du système.
L'étude du diagramme de causes et effets doit analyser chaque type de cause :
- Matière : cette cause comporte les enjeux de matières premières.
- Matériel : le matériel inclut les matériels informatiques et les logiciels, qui correspondent à la quatrième vue du méta-modèle d’urbanisme. Cette cause peut comporter des enjeux très importants de sécurité.
- Méthode : par exemple, comment est gérée la communication ?
- Ressources humaines : par exemple, comment le capital intellectuel est-il évalué ?
- Contexte : consulter Communication, Contexte (communication), Perception de l'environnement, Théorie des contextes.
Le système métier
Le système métier est constitué de l’ensemble des métiers et des processus de l'entreprise et des organisations qui y concourent.
La définition de la stratégie de l'entreprise conduit à répertorier :
- les métiers stratégiques qu’elle exerce vis-à-vis de son marché et autour desquels elle structure ses activités et son organisation - un métier stratégique (exemples : octroi de crédit, courtage d'assurance, ligne de fabrication, etc.) correspond à une combinaison de :
- segments de marché,
- offres commerciales ou marketing,
- techniques de distribution ;
- les métiers opérationnels qu’elle exerce dans le cadre de chacun des métiers stratégiques (exemples : production, marketing, gestion des risques, etc.)
Les activités exercées par l'entreprise, sont de plusieurs types :
- les activités opérationnelles qui contribuent à la fabrication des produits vendus ou à l’élaboration des services rendus aux clients,
- les activités de gestion,
- les activités de pilotage.
L'analyse du système métier peut s'appuyer sur les techniques de BPM (Business Process Management ou Business Process Modeling ou Gestion des processus métier) qui visent à :
- modéliser les processus de façon transversale à l'entreprise, dans le cadre d'une gestion de programme,
- outiller ces processus pour faciliter une exécution fluide (workflow, moteur de règles ou d'exécution),
- piloter l'activité de ces processus au moyen d'indicateurs (gestion de la qualité, performance).
L'un des objectifs du BPM est de porter un diagnostic sur les processus de l'entreprise et de déterminer ainsi dans quels secteurs les évolutions du SI offriront le meilleur retour sur investissement.
Le système d'information
Article détaillé : système d'information.Le système d'information (SI) est constitué de l’ensemble :
- des objets métiers,
- des fonctions,
- des informations,
- et des règles de gestion,
utilisés par les métiers et les processus mis en œuvre par une même entité organisationnelle de l'entreprise.
Un SI urbanisé doit pouvoir découpler facilement les sous-systèmes d’information supportant différents métiers et pouvant évoluer à terme vers des systèmes d’information autonomes. Par exemple, une entreprise peut vouloir se donner à terme la possibilité de séparer ses métiers de distribution (vente) de ses métiers de production (gestion des produits) dans des unités organisationnelles distinctes.
L'urbanisation d’un SI combine :
- la volonté de pouvoir isoler certaines de ses parties pour pouvoir les faire évoluer facilement
- et l'objectif de mutualiser (mettre en commun avec des SI d'autres partenaires) ou d'externaliser d’autres parties plus stables, moins stratégiques, pour réaliser des économies.
Pour ce faire, l’architecture fonctionnelle recense à l’intérieur de chaque zone, quartier et îlot, les blocs fonctionnels qui entrent dans la composition du SI pour qu’il supporte les processus métiers de l'entreprise.
Le bloc fonctionnel assure :
- une cohésion forte, cohésion entre les objets qu’il gère et les fonctions qu’il assure,
- un couplage faible, soit un nombre limité d’échanges avec les autres blocs du SI.
La granularité du bloc fonctionnel (le niveau de maille du découpage) doit :
- faciliter sa réutilisation dans différents processus et renforcer la modularité du SI
- favoriser son remplacement par un bloc offrant des fonctionnalités équivalentes.
Le bloc fonctionnel constitue l’unité échangeable du SI.
Un bloc fonctionnel est défini par :- les objets métier qu’il gère pour le compte du SI,
- les "services fonctionnels, interfaces permettant d’échanger avec les autres blocs du SI, cela inclut les flux qu'il prend en charge et ceux qu'il produit,
- les fonctions qu'il regroupe (fonctions liées aux objets métier), et les règles de production des données qu’il communique.
Le système informatique
Article détaillé : système informatique.Le système informatique est constitué d'un ensemble structuré :
permettant d’automatiser tout ou partie d’un système d'information, et dont l’administration et l’exploitation sont assurées par une même entité organisationnelle (unité d’administration et d’exploitation).
Le système informatique est décrit par :
- son architecture applicative,
- son architecture technique,
- son architecture physique.
Dans l'étude de l'existant, il faut prendre en compte ces trois types d'architecture, afin d'évaluer les vulnérabilités des sous-ensembles, ce qui ne peut être fait qu'en prenant en compte les niveaux technique et physique. Pour la définition de l’architecture cible, on peut se limiter à l'architecture applicative.
L'architecture applicative définit l’ensemble des composants logiciels constituant la partie automatisée d’un système d’information ainsi que leurs modalités d’assemblage et de communication.
Elle est une instanciation de l’architecture fonctionnelle d’un SI dans un environnement technique et d’exploitation donné.Le bloc applicatif est un ensemble de composants logiciels qui présentent une cohérence
- fonctionnelle : données et traitement sur les mêmes objets métiers,
- technique : implémentation globale mono-plateforme
Le bloc applicatif est autonome dans la mesure où son fonctionnement doit être indépendant du chemin que l'information aura suivi en amont et poursuivra en aval.
Le bloc applicatif est décrit en termes de :
- structures de données qu’il gère,
- procédures fonctionnelles qu’il exécute,
- services applicatifs qu’il met à disposition d'autres blocs ou des utilisateurs
- messages qu’il reçoit (les événements qu’il traite) et qu’il publie (les comptes-rendus d’événements ou d'opérations qu’il produit).
Les constituants du bloc applicatif (données et services) peuvent être publics (le bloc en donne la visibilité pour permettre à d’autres blocs de les utiliser) ou privés (pour les besoins internes du bloc).
Un bloc applicatif est un objet logiciel concret qui, dans un contexte technique donné, offre à l’ensemble du SI, l'implémentation des fonctionnalités des prises définies par le bloc fonctionnel correspondant. Un bloc applicatif communique avec les autres blocs par échange de messages et par appel de services.
Correspondances entre système métier, système d’information et système informatique
Le tableau ci-après présente les principales équivalences de vocabulaire entre les trois niveaux de préoccupation définis plus haut :
- système métier,
- système d'information,
- système informatique.
Système métier Système d’information Système informatique Vue métier architecture fonctionnelle architecture applicative Processus métier processus fonctionnel processus applicatif <pas d’équivalent> quartier fonctionnel quartier applicatif <pas d’équivalent> îlot fonctionnel îlot applicatif Activité bloc fonctionnel bloc applicatif <pas d’équivalent> <pas d’équivalent> application Objet métier information donnée Tâche fonction / service fonctionnel traitement / service applicatif <pas d’équivalent> prise de type question/réponse interface de service <pas d’équivalent> prise de type flux/événement événement et compte-rendu d’événement L’urbanisation du SI consiste à décrire ces trois niveaux de SI en utilisant une variété de concepts décrits précédemment. Il est d’usage de représenter ces concepts sur un diagramme appelé métamodèle d'urbanisme. Il s’agit d’un diagramme de classes UML dans lequel chaque classe représente un concept d’urbanisme.
Méthodologie d’urbanisation
La démarche d’urbanisation s’articule sur 3 axes clés qui s’alimentent mutuellement :
- la modélisation de la stratégie
- la cartographie des systèmes existants (métier, fonctionnels, applicatifs, techniques)
- la détermination des systèmes cibles (métier, fonctionnels, applicatifs, techniques)
La distinction forte entre existant et cible est un facteur de clarification essentiel.
La démarche d’urbanisation du SI consiste notamment à :
- définir un SI cible, aligné sur la stratégie de l’entreprise,
- déterminer la trajectoire à suivre pour atteindre ce SI cible.
Indépendamment des différentes approches qui, selon le contexte de l'entreprise et les options méthodologiques, peuvent être préconisées les activités d'urbanisations se classent en cinq grands domaines :
- Le "cœur" des processus d'urbanisme,
- Définir et maintenir le cadre d'urbanisme : plans d’urbanisme (cibles et scenarios de migration), règles, …,
- Réaliser et maintenir l'infrastructure fonctionnelle du SI : référentiels d’entreprise, dispositifs mutualisés d’échanges inter-applicatifs, …,
- Développer les relations avec les projets : cadrage, études amont, accompagnement des projets, …
- Les processus de support : notamment « Maintenir et diffuser les cartographies ».
- Et les processus de pilotage de l'urbanisation et de participation à l'arbitrage des projets.
Points de vue alternatifs
A) La systémique appliquée conduit à établir une corrélation forte entre la vision processus de l'entreprise et l'urbanisation. Une entreprise dispose d'une dizaine de processus si elle est de petite taille, et d'une trentaine au maximum si elle est de grande taille (exemples : un constructeur automobile ou une banque nationale). Par conséquent, un seul niveau de décomposition d'un processus suffit : c'est la notion d'étape.
L'expérience montre que l'ensemble des données propres au management d'une grande entreprise ne dépasse pas 7 à 8000 données. Il est possible, à l'aide d'une analyse sémantique appropriée, d'établir une liste de ces données de telle sorte qu'elles soient toutes différentes. S'il y a 9000 données dans l'entreprise et 30 processus, cela signifie qu'un processus génère en moyenne 300 données. Si un processus comporte 10 étapes, chaque étape est responsable de la création et de la mise à jour de 30 données en moyenne.
Chaque étape se caractérisant par une certaine valeur ajoutée, celle-ci se traduit par la mise en œuvre de règles de gestion qui lui sont propres, qui agissent sur des données qui lui sont propres. Donc chaque étape est un bloc fonctionnel autonome, avec un couplage nul avec les autres blocs fonctionnels.
Les règles de découpage décrites plus haut s'appliquent :
- règle 1 (séparation du Back Office et du Front Office) : cette séparation doit normalement se faire au niveau de la modélisation fonctionnelle du processus, des étapes distinctes étant affectées au Back Office et au Front Office ;
- règle 2 (découpage par processus) : ceci s'applique quel que soit le type de processus, processus de pilotage, processus de réalisation (aussi appelé "processus-métier") ou processus support.
Dans cette approche, et si l'on considère uniquement les processus néguentropiques (créateurs d'ordre), il n'existe pas de zones de gestion de données de référence communes à l'ensemble du SI, car chaque donnée appartient à un processus et un seul. Pour la même raison, il n'existe pas de zones de gestion de gisements de données.
Plus généralement, il n'y a pas de différenciation de types de zones car cette différenciation se fait au niveau des étapes de processus, qui sont autant de blocs fonctionnels.
Par contre, il peut y avoir, pour des raisons techniques, des gisements de données communes uniquement pour les processus de restitution (édition,impression, etc).
Bibliographie :
Ludwig von Bertalanfy : Théorie générale des systèmes
Jean-Louis Le Moigne : La théorie du système général
Jacques Mélèse : Approches théoriques des organisations
C.E. Shannon & W. Weaver : The mathematical theory of communication
CARNOT : Deuxième principe de thermodynamique
Ferdinand de Saussure : Cours de linguistique générale
Luc Boyer et Noël Equilbey : Organisation, théories et applications
B) Il existe aussi une communauté de pensée systémique qui se focalise plus sur le caractère adaptable du Système d'Information, que sur le statut adapté à une hypothétique cible. Selon eux, les systèmes complexes sont difficilement prévisibles, de sorte qu'il devient extrêmement hasardeux de prédire qu'une "cible" aura plus ou moins de valeur pour l'entreprise lorsqu'elle sera atteinte. Cette vision organique du Système d'Information est rendue possible par les méthodes agile, qui s'intéressent à produire du logiciel en continu, avec une productivité constante malgré leur inexorable montée en complexité.
En France, l'urbanisme organique a notamment été popularisé dans deux ouvrages, Une Politique pour le Système d'Information - Descartes, Wittgenstein, "XML" et L'informatique Conviviale.
Notes et références
- notamment par Jacques Sassoon dans les années 1990 dans le secteur bancaire
- Définition proposée par le Club Urba-EA : Urbaniser, c'est organiser la transformation progressive et continue du système d’information visant à le simplifier, à optimiser sa valeur ajoutée et à le rendre plus réactif et flexible vis-à-vis des évolutions stratégiques de l'entreprise, tout en s'appuyant sur les opportunités technologiques du marché.
Voir aussi
Articles connexes
- Organisation
- Méta-modèle d’urbanisme
- SOA : Service Oriented Architecture
- Système d'information
- Sécurité informatique
- Sécurité des données
- Fuite d'information
- EAI : Enterprise Application Integration
- ESB : Enterprise Service Bus
- Middleware ou intergiciel
- Architecture logicielle
- Progiciel de gestion intégrée
- Data architecture dans la Wikipedia anglophone
- Analyse décisionnelle des systèmes complexes (méthode d'urbanisation des Systèmes d'Information)
Liens externes
Bibliographie
- Jacques Sassoon, Urbanisation des systèmes d'information, Hermès Coll. Management et Informatique, 1998
- Christophe Longépé, Le projet d'urbanisation du S.I. 2e édition, Dunod, Paris, 2004, ISBN 2-10-007376-1
- Bernard Le Roux, Luc Desbertrand, Pascal Guérif, Xavier Tang, Julien Tixier, Pierre Verger, Urbanisation et modernisation du SI, Lavoisier, Paris, 2004, ISBN 2-7462-0885-7
- Yves Caseau, Urbanisation et BPM, Le point de vue d’un DSI 2e édition, Dunod, Paris, 2006
- Pierre Pezziardi, Une Politique pour le Système d'Information - Descartes, Wittgenstein, "XML", OCTO, 2006 ISBN 978-2-9525895-0-5
- Club URBA-SI, Pratiques de l'urbanisme des systèmes d'information en entreprises, Publibook, 2003, ISBN 2-7483-2942-2
- Jean-Christophe Bonne, Aldo Maddaloni, Convaincre pour urbaniser le SI, Lavoisier, Paris, 2004, ISBN 2-7462-0977-2
- Bernard Le Roux, Joseph Paumier, La gouvernance de l'évolution du SI, Lavoisier, Paris, 2006, ISBN 2-7462-1293-5
- René Mandel, De la stratégie business aux systèmes d'information: l'entreprise et son écosystème, Lavoisier, Paris, 2006, ISBN 2-7462-1297-8
- Club URBA-EA (ex Club URBA-SI), Urbanisme des SI et gouvernance : Retours d'expériences et bonnes pratiques, Dunod, Paris, 2006, ISBN 2-10-049678-6
- Michel Volle, De l'informatique : savoir vivre avec l'automate, Economica, Paris, 2006, ISBN 2-7178-5219-0
- Bernard Le Roux La transformation stratégique du système d'information, Lavoisier, Paris, 2009
- Pierre Pezziardi L'informatique Conviviale, Le Lean Management peut-il transformer l'entreprise ? Eyrolles, 2010
- Jérome Capirossi, Architecture d'Entreprise , Conduire la transformation de l'Entreprise Hermes Science Lavoisier Février 2011
- Jean-Claude Jacquiot, L'architecture d'entreprise intégrée, cahier technique CASE France 2011
Catégories :- Urbanisation du SI
- Développement logiciel
- Architecture logicielle
Wikimedia Foundation. 2010.
