Sommaire
Edito
Tribune
Succès
Paroles d'experts
En bref
Sondage express
Agenda
Version PDF
 

Abonnez-vous à
Bull Direct :

Votre email

Archives
n°33  |  Janvier   2009
Parole d'expert

Un modèle d’urbanisation pour faire dialoguer les parties prenantes du système d’information
Dominique Buczinski, Responsable du Secteur public au sein de du pôle conseil de Bull Management
Guillaume Forestier, Directeur du Centre de services Ile de France - Nord

G.Forestier et D. Buczinski

Pour maîtriser le système d’information et piloter efficacement son évolution, il est indispensable d’en avoir une vision à la fois claire, dynamique et partagée entre tous les acteurs impliqués. Un modèle d’urbanisation à cinq niveaux, depuis le métier jusqu’à l’infrastructure matérielle, permet d’une part de clarifier les responsabilités de chacun et d’autre part d’établir les correspondances nécessaires à l’évaluation des impacts de chaque modification du système. En choisissant le bon niveau de granularité et effectuant d’abord cette cartographie au périmètre des projets, on peut obtenir un modèle simple à mettre en œuvre, utilisable par tous et susceptible d’apporter très vite des bénéfices concrets.

Les systèmes d’information des grandes organisations deviennent si complexes qu’il est souvent difficile, même pour la DSI, de s’y retrouver. Les applications et les infrastructures sont interdépendantes, et chaque projet, chaque programme, chaque évolution métier ou technique apporte son lot de modifications. Idéalement, il serait nécessaire d’évaluer en amont de toute intervention l’ensemble des contraintes, des impacts et des besoins des différents acteurs et systèmes concernés. On éviterait ainsi les incompatibilités techniques inattendues ou les dégradations imprévues de performance, et on serait en mesure de rationaliser les ressources susceptibles d’être partagées comme les bases de contacts ou les référentiels techniques. Ou encore lorsqu’un métier déciderait de lancer un nouveau service, par exemple dans la banque, les télécoms ou l’administration, il serait possible de voir immédiatement ce que cela implique et de s’engager en connaissance de cause sur des délais de livraison. En somme, toute l’entreprise aurait à gagner à l’existence d’une carte et d’une boussole de son système d’information, l’une pour se repérer, l’autre pour s’orienter.

Malheureusement, c’est bien souvent l’urgence qui commande et il est difficile d’envisager le lancement d’un recensement exhaustif des composantes du système d’information, depuis les aspects métier jusqu’aux paramètres d’exploitation. En outre, il n’existe pas d’outil permettant d’obtenir ce type de vision complète, du processus métier au serveur. Dans ces conditions, il s’agit donc de trouver une approche qui soit à la fois pragmatique et pertinente, réalisable et utilisable. Il faut s’attacher à bâtir un modèle qui apporte la vision partagée du système d’information nécessaire à sa maîtrise, qui permette un dialogue entre toutes les parties prenantes (métier, études, exploitation) et qui demeure accessible aux personnes qui auront à le manipuler. L’expérience montre que la mise en place d’un modèle d’urbanisation à cinq niveaux peut apporter une réponse intéressante à l’ensemble de ces besoins d’échange et de visibilité autour du système d’information.

Un modèle à cinq niveaux
De façon assez classique, les cinq plans du modèle proposé restreignent chacun le système d’information à un niveau homogène de responsabilité et d’intervention.

1. Vue métier du SI
La vue métier est obtenue par l’analyse des moyens opérationnels à mettre en œuvre pour exécuter la stratégie de l’entreprise. Cette étape fondamentale permet d’identifier et de décrire les processus et les activités, de capturer la sémantique des données métier et de préciser les rôles de chacun. Il en découle un ensemble de processus cibles à créer ou à optimiser suivant la situation existante. Se dessinent alors le périmètre des différents systèmes d’information et leurs points de contact.

2. Vue fonctionnelle du SI
Par l’identification et la consolidation des tâches nécessaires au support des processus de l’entreprise, la vue fonctionnelle permet d’exprimer l’architecture fonctionnelle du système d’information. Ce modèle qui assure la transition entre le besoin métier et l’outil informatique se décline en activités, objets métier et rôles.

3. Vue applicative du SI
Tout en restant en cohérence avec l’architecture fonctionnelle (et en respectant les architectures orientées service), la vue applicative donne une représentation du système d’information en domaines et en applications métier de façon indépendante de l’infrastructure sous-jacente. Elle offre notamment une vision qui permet de dépasser les silos applicatifs. Suivant le niveau de détail désiré, on envisage les systèmes, les services, les flux ou les objets fonctionnels.

4. Vue technique du SI
La vue technique envisage l’infrastructure logicielle (bases de données, serveurs d’application, serveurs Web, intergiciels…) comme axe fédérateur des différents systèmes d’information. Elle permet la gestion, l’optimisation et le support des services d’infrastructures qui soutiennent l’architecture applicative. Suivant le niveau de granularité souhaité, elle recense les systèmes, les composants, les services ou les flux techniques.

5. Vue physique du SI
La vue physique recense l’infrastructure matérielle (serveurs, routeurs, baies de stockage…). Elle permet une gestion dynamique des ressources, leur rationalisation par la consolidation, la mutualisation et la virtualisation, et l’anticipation des évolutions technologiques, des besoins et des contraintes liés aux différents éléments.

L’intérêt de ce modèle est que chaque plan est susceptible d’interagir avec les autres. Cela permet de clarifier et d’unifier la vision du système d’information et, par exemple, d’automatiser l’évaluation des conséquences d’une exigence métier ou d’une mise à jour technique. 

Constituer, utiliser et faire vivre le modèle
Pour être véritablement utile, un tel modèle doit cependant être dynamique. On constate trop souvent que les efforts mis en œuvre pour établir un schéma du système d’information se perdent lorsqu’il s’agit de le tenir à jour. Les évolutions étant rapides et nombreuses, il est essentiel qu’un responsable soit désigné pour chaque plan et que soit définis des processus d’actualisation.

Le modèle n’est toutefois véritablement opérationnel que si l’on s’attache à cartographier les correspondances entre les différents plans. Ces correspondances sont indispensables si l’on veut, par exemple, évaluer l’impact d’un projet, définir un PRA (Plan de Reprise d’ Activité) ou fixer des engagements de niveaux de service. Par ailleurs, il convient d’y ajouter un schéma directeur qui donnera les grandes orientations de l’évolution du système en fonction de la stratégie de l’entreprise. Les deux éléments sont indispensables car l’un donne la situation actuelle et l’autre la direction à suivre, ce qui permet d’emprunter le meilleur chemin pour la transformation du système.

Qu’il s’agisse de la création du modèle ou de la cartographie des correspondances, la tâche peut apparaître colossale. Mais il faut garder à l’esprit que l’on peut agir à différents niveaux de granularité. Il n’est pas indispensable – ni très productif – de descendre jusqu’à une finesse de détails excessive. De plus, il n’est pas toujours nécessaire de se lancer dans une modélisation complète du système d’information : on peut se restreindre au périmètre d’un projet, où ce travail réalisé en amont rendra déjà de grands services, et consolider ensuite les différents schémas partiels. Enfin, il ne faut pas oublier que le modèle doit rester opérable. S’il est trop technique, trop détaillé ou trop abstrait, les responsables des différents niveaux ne se l’approprieront pas et il sera délaissé (les métiers reprochent par exemple souvent aux modèles d’être trop « informatiques » et de manier des concepts trop éloignés de leur quotidien).

Si on aborde l’urbanisation du système d’information de façon modeste, simple et rigoureuse et si le modèle est régulièrement mis à jour, on peut très vite en tirer des résultats tangibles. En mettant en place une vision unique et partagée, facilement compréhensible, qui établit un vocabulaire commun, le modèle permet d’amorcer la discussion, ce qui constitue un premier pas essentiel. Il permet par exemple de voir clairement les interactions et les contraintes qu’induisent pour les autres les exigences des uns. La vision par plans permet d’agir car elle permet de prendre en compte aussi bien les besoins métier (nouveau service) que technologiques (mise à jour d’un logiciel), et de répercuter les conséquences dans toutes les directions et à tous les niveaux. Elle permet ainsi d’améliorer la gouvernance. En segmentant la vision du SI, on peut piloter par plan (par exemple, la direction des études se charge des applicatifs) ou par schéma directeur (pilotage global avec une cible évolutive).

L’apport de Bull
Pour établir un tel modèle, il faut allier le conseil (métier, MOA), la technique (direction des études, MOE) et les responsables de l’exploitation. Or à chaque niveau les interlocuteurs sont différents et les métiers souvent très segmentés. Pour assurer l’indispensable cohérence de l’ensemble, il faut accompagner le changement profond qu’induit cette mise en commun des informations et la définition de règles de partage. Afin d’aider ses clients dans leur démarche, Bull est en mesure d’intervenir sur chacune de ces couches de façon experte, soit avec ses ressources propres sur les aspects liés à la technologie, soit en s’entourant de spécialistes métier pour les aspects plus stratégique.

schema

ENVOYER A UN AMI POUR EN SAVOIR PLUS
Contact  |  Site map  |  Legal  |  Privacy