GrabDuck

Urbanisation pour les nuls

:

Le XKE (Xebia Knowledge Exchange) de mars a été l’occasion de présenter la démarche d’urbanisation. L’exemple présenté ne suivait pas le déroulement type : une démarche d’urbanisation est adaptée suivant les projets et organisations auxquels elle est appliquée.
Le but de ce billet est de dérouler cette démarche de manière simplifiée. Cela nous donnera l’occasion de définir le vocabulaire employé, et de faire un constat sur cette démarche.
Nous déroulerons l’exemple avec une approche TOP-DOWN, c’est-à-dire que l’analyse commence par la définition de la stratégie pour descendre ensuite au travers des différentes strates du SI. Pour l’exemple, nous prendrons le cas d’une agence de voyages qui achète et vend des voyages.


Pourquoi une démarche d’urbanisation ?

La démarche d’urbanisation est née de la volonté d’avoir un système d’information évolutif et peu coûteux. En effet, la plupart des évolutions au sein d’un SI se révèlent être coûteuses et impactent souvent les autres composants du système, entraînant ainsi des problèmes de cohérence et des freins à l’amélioration du système d’information. Par ailleurs, l’évolution constante du SI engendre des redondances de fonctionnalités et des chevauchements des flux de communication. Au final, on se retrouve avec un système d’information non conforme avec les processus métiers de l’organisation.
La démarche d’urbanisation permet de « ranger » son système d’information. Il s’agit d’établir ou de ré-établir une relation entre les systèmes informatiques et la stratégie de l’entreprise. Le but étant de pouvoir intégrer progressivement les demandes d’évolutions du système d’information par une approche rationnelle.

A quels niveaux se situe la démarche d’urbanisation ?

La démarche d’urbanisation touche tous les niveaux de l’organisation :

Précisons les fonctions des différentes couches :

  • Vue métier : cartographie des processus métiers de l’organisation.
  • Vue fonctionnelle : description des fonctionnalités (services) offertes par le système d’information pour supporter les processus métiers.
  • Vue applicative : description de l’ensemble des éléments du système informatique implémentant les services urbanisés sous forme d’éléments logiciels.
  • Vue technique : description de l’infrastructure de fonctionnement des éléments logiciels du système informatique.

Sur ce schéma, nous voyons que la démarche d’urbanisation s’applique essentiellement au niveau des vues métier et fonctionnelle. En résumé, la démarche s’applique principalement aux stratégies de l’organisation ainsi qu’à la manière dont elles seront implémentées.
Les deux dernières vues correspondent plus à des problématiques projets.

L’analyse de la stratégie

Dans cette première étape, l’objectif est de définir la stratégie principale que l’organisation veut atteindre, ainsi que les moyens d’y parvenir. Cela se fait souvent au moyen d’un ou de plusieurs diagramme(s). Nous prenons ici l’exemple d’un diagramme d’Ishikawa:

Ce diagramme permet de représenter les causes et leurs effets. La flèche centrale sert à représenter le but principal, et les causes permettant d’atteindre cet objectif sont représentées par des flèches dirigées vers l’axe central, et ainsi de suite pour les autres flèches. Ici, le but principal sera d’améliorer le fonctionnement et la rentabilité de l’agence de voyages. Par exemple, cela passera par l’amélioration de la productivité des vendeurs.

Cette ou ces stratégies s’accompagnent des analyses des fonctionnalités existantes de l’organisation en décomposant les processus métier. Prenons l’exemple avec le processus d’achat d’un voyage par une agence :

Cette analyse s’accompagne aussi de diagrammes d’activités.

Ensuite, après analyse, la démarche prévoit de définir les processus cibles :

 

Dans cet exemple, le processus existant a été décomposé en deux processus afin de mieux répondre aux problématiques de l’organisation.

Identification des zones, quartiers et îlots (= bloc fonctionnel)

Définitions :

  • Une zone représente le domaine fonctionnel.
  • Un quartier est une opération à l’intérieur d’un métier.
  • Un îlot représente une application.

Voyons sur un exemple une des façons d’identifier ceux-ci :

Ici, nous avons un ensemble de services qui communiquent les uns avec les autres, et nous constatons tout de suite les problèmes d’échanges de flux et de redondances…
La démarche prévoit de séparer ces services et de les regrouper suivant des domaines fonctionnels. Ainsi, nous obtenons :

A ce stade, les domaines fonctionnels sont identifiés et nous voyons que les communications entre services passent par une zone de médiation (on parle alors de découplage fonctionnel). Cette zone permet de centraliser les flux de communication. La couche médiation peut, par exemple, être implémentée par des ESB. En résumé, celle-ci vise à assurer l’interconnexion en gérant la médiation, la communication et les interactions entre les services et applications d’un système d’information. Pour plus de précision, je vous invite à consulter notre livre blanc sur les ESB.
A noter, l’apparition d’un réservoir d’informations, regroupant toutes les données de l’organisation.

Les cartographies

Les cartographies permettent d’avoir une vue d’ensemble des zones, quartiers et îlots. La démarche préconise d’établir les cartographies des processus métiers, fonctionnels et applicatives existantes et cibles. La cartographie des processus métiers a déjà été évoquée précédemment. La cartographie applicative est la suite logique de la cartographie fonctionnelle et regroupe donc les éléments de cette dernière. Nous nous attarderons sur la cartographie applicative. Cette étape représente la structuration du système d’information en blocs applicatifs.
En reprenant notre exemple, nous obtenons ainsi deux cartographies :

Cartographie applicative existante :

En pointillé, nous avons les zones dans lesquelles nous avons des quartiers (en violet) et à l’intérieur de ceux-ci des îlots (en jaune). Les noms des îlots sont présents à titre indicatif.
A travers cette cartographie, nous retrouvons les problèmes vus précédemment (redondances…)

Cartographie applicative cible :

D’une part, nous avons un meilleur découpage, car un îlot appartient à un seul quartier et d’autre part nous voyons que de nouvelles zones apparaissent.
Cette cartographie est issue de la cartographie fonctionnelle cible sur laquelle des zones ont été ajoutées. Bien entendu, afin de mettre en place une telle cartographie, des bonnes pratiques existent parmi lesquelles (Le projet d’urbanisation du SI, C.Longépé):

  • Toute architecture fonctionnelle comporte une zone échange qui est en quelque sorte la prise du SI
  • Toute architecture fonctionnelle comporte une zone gisement de données : elle regroupe les informations dynamiques ainsi que les services d’accès à ces données
  • Toute architecture fonctionnelle comporte une zone référentiel de données : elle regroupe les informations communes aux différents éléments du système d’information étant relativement stables.
  • Toute architecture fonctionnelle comporte une zone de pilotage unique
  • Toute architecture applicative comporte une zone ordonnancement qui assure l’interface entre le front office, le back office et le middle office.

Les livrables

Au terme de cette démarche, un Plan d’occupation des sols (POS) est défini. C’est un rapport constitué :

  • De synthèses sur les orientations choisies ainsi que les justifications sur les options retenues.
  • D’une définition des zones, quartiers et îlots.
  • De cartographies existantes et cibles (cartographie des processus, fonctionnelle, applicative, et éventuellement technique).
  • De documents annexes (comptes rendus d’entretiens, liste des personnes et des entités organisationnelles…)

Le but est d’identifier les écarts entre l’existant et les principes d’urbanisation, mais aussi d’établir le planning des évolutions en décrivant les actions et leur coût correspondant.

Conclusion

En pratique, la démarche d’urbanisation est très lourde à mettre en place. D’une part, elle requiert la participation de beaucoup d’acteurs de l’organisation (DSI, comité stratégique, MOA décisionnaire, MOE, …), et d’autre part, l’analyse est très longue. En découle le principal problème : les besoins ont souvent évolué et le POS n’est plus forcément adapté…
En théorie, les principaux bénéfices de cette démarche sont d’optimiser le fonctionnement des processus, d’avoir un système d’information modulaire, évolutif et cohérent et de faciliter la réutilisation de composants. Bien entendu, comme vous vous en doutez, au vu des critiques précédentes, ces bénéfices sont souvent utopiques. Néanmoins, il est possible d’y parvenir en appliquant la démarche sur des périmètres réduits (un seul processus par exemple) et en itérant.

Référence