Construction d’une solution logicielle dans le cadre d’une démarche d’urbanisation

survie dans un environnement économique, technologique et social changeant et instable. Les organisations ont besoin d’un SI qui leur permet d’atteindre plusieurs objectifs difficiles à réaliser et parfois contradictoires. Compte tenu des délais rapides de mise sur le marché de biens et services innovants, le SI d’une organisation doit être suffisamment agile pour supporter efficacement les processus innovants. Depuis la fin des années 90, l’urbanisation des SI a été proposée par de nombreux spécialistes des SI pour répondre à la demande des organisations en termes de SI agile. Toutefois, malgré intérêt, les travaux concernant l’urbanisation des SI demeurent descriptifs présentent plusieurs faiblesses. En particulier, elles ne proposent pas de démarche de conception et d’évolution de solutions informatiques dans un cadre urbanisé. Dans cet article, nous proposons une démarche de conception de solution logicielle qui constitue une tentative pour remédier à cette faiblesse des travaux actuels sur l’urbanisation des SI.

Mots clefs:

Système d’information, Solution logicielle, Urbanisation, Fonction, Entité informationnelle, Processus, Plan d’Urbanisme

❒ ❒ ❒

❒ Abstract

Information Systems (IS) play a critical role in modern organizations. They are nowadays a necessary condition for organizations survival within an unstable and continuously changing economic and technology environments. Indeed, organizations need IS which help them reaching various difficult and often conflicting goals. To support innovation processes and, short time-to-market constraints, organization’s IS must be agile and flexible. The concept of IS urbanization has been proposed since the late 90’s in order to help organizations building agile IS. Nevertheless, despite the advantages of this concept, it remains too descriptive and presents many weaknesses. In particular, there is no useful approach dedicated to urbanized IS construction. In this paper, we propose a development approach of computer solutions which is compliant with the IS urbanization rules.

Key-words:

Information System, Computer solution, Urbanization, Function, Informational entity, Process, Target Urbanization Plan

solution logicielle dans

le cadre d’une

démarche

d’urbanisation

Software Solutions

Construction

According to

Enterprise

Architecture Principles

Salem Ben Dhaou Dakhli

Paris-Dauphine University

Place du Maréchal de Lattre de Tassigny 75775 Paris Cedex 16

Introduction

Le Système d’Information (SI) joue un rôle critique dans les organisations modernes et conditionne leur survie dans un environnement économique, technologique et social changeant et instable. Les organisations ont besoin d’un SI qui leur permet d’atteindre plusieurs objectifs difficiles à réaliser et parfois contradictoires. Tout d’abord, le SI d’une organisation doit supporter des processus organisationnels de plus en plus complexes et interdépendants. Qu’il s’agisse de processus métier à valeur ajouter ou de processus décisionnels ou de support, les processus organisationnels doivent s’appuyer sur les technologies de l’information et de la communication pour être mis œuvre dans des conditions acceptables d’efficience et d’efficacité. Ensuite, la fréquence élevée des changements induits par l’environnement externe des organisations entraîne des modifications dans les processus organisationnels et des applications informatiques qui les supportent. Ces modifications sont d’autant plus difficiles à réaliser qu’elles sont souvent soumises à des conditions drastiques de coût, de délai et de qualité. Enfin, l’évolution croissante de l’économie vers les services entraîne des modifications aussi bien institutionnelles que juridiques et conditionne l’acquisition de la valeur par l’innovation. Ainsi, pour survivre, les organisations doivent innover aussi bien au niveau de leurs catalogues de produits et de services qu’au niveau des pratiques de vente et de livraison de ces produits et services. L’ère de la production de masse semble laisser la place progressivement à l’ère des produits et services adaptés aux goûts et aux exigences d’une clientèle de plus en informée et de plus en plus disputée par la concurrence. De nouveaux processus organisationnels doivent donc être créés au sein des organisations et supportés par les technologies de l’information et de la communication. Compte tenu des délais rapides de mise sur le marché de biens et services innovants, le SI d’une organisation doit être suffisamment agile pour supporter efficacement les processus innovants. Depuis la fin des années 90, l’urbanisation des SI a été proposée par de nombreux spécialistes des SI pour répondre à la demande des organisations en termes de SI agile. Toutefois, malgré leur intérêt, les travaux concernant l’urbanisation des SI demeurent descriptifs et présentent deux faiblesses. D’une part, elles n’offrent pas un ensemble cohérent de règles d’architecture facilitant la gouvernance du SI. D’autre part, elles ne proposent pas de démarche de conception et d’évolution de solutions informatiques dans un cadre urbanisé. Dans cet article, nous présentons une approche de construction de solution logicielle qui constitue une

tentative pour remédier à la deuxième faiblesse des travaux actuels sur l’urbanisation des SI. La mise en oeuvre de cette approche pose le problème du respect du cadre d’urbanisation du SI. Ce problème constitue un aspect de la gouvernance du SI dont la prise en compte nécessite la définition d’un corpus minimun de règles d’architecture à respecter par les développeurs pour garantir l’agilité du SI et son évolution harmonieuse. Par conséquent, les remèdes apportés à la deuxième faiblesse des travaux actuels sur l’urbanisation des SI génèrent des solutions à la première faiblesse. La suite de cet article est organisée comme suit. La section 1 rappelle les fondements de l’urbanisation d’un SI en utilisant la métaphore de la ville. Trois sections sont consacrées aux dimensions des règles d’architecture. Dans la section 2, nous présentons la dimension spatiale. La dimension Communication est présentée dans la section 3. La section 4 est consacrée à la description des dimensions informationnelle et fonctionnelle. Dans la section 5, nous présentons un modèle en couches qui synthétise, précise et enrichit les travaux actuels sur l’urbanisation d’un SI. Ce modèle permet de décrire les liens entre la stratégie d’une organisation, les processus organisationnels et le SI. La section 6 utilise les concepts et les modèles décrits dans les sections précédentes pour présenter l’approche que nous proposons pour la construction de solutions logicielles. Dans la section 7, nous illustrons l’application de cette démarche à l’aide d’un exemple. La section 8 conclut cet article en listant les problèmes rencontrés et les futures directions de recherche.

1.

Les fondements de

l’urbanisation d’un SI

L’urbanisation du SI a été étudiée par de nombreux auteurs (Jean, 2000) (Longépé, 2006) (Sassoon, 1998). Les travaux de ces auteurs complètent les travaux relatifs à l’architecture d’entreprise (Zachman, 1987) (Zachman et al., 1992), (Kaisler et al., 2005) (Fayad et al.., 2002) (Boar, 1999) (Noran, 2003) (Evernden, 1996) (Maier et al., 2000) (Bernard, 2004). Tous ces auteurs utilisent des métaphores pour fonder la notion d’architecture d’entreprise et d’urbanisation des SI. En particulier, la métaphore de la cité est utilisée comme fondement de l’urbanisation des SI (Dieberger et al., 1998). Ainsi le SI est considéré comme la base de la cité de l’information peuplée par des applications qui doivent cohabiter et échanger conformément à un ensemble de protocoles et de règles de gouvernance. Ainsi, à l’instar d’une cité dont l’évolution progressive et harmonieuse permet l’intégration de différentes contraintes issues de l’environnement, un système d’information urbanisé

est suffisamment agile pour évoluer et intégrer les changements organisationnels et technologiques nécessaires à la survie d’une organisation. Dans la cité de l’information, les individus sont des applications informatiques dont les règles de coexistence – appelées règles d’architecture - ont cinq dimensions: spatiale, communication, dynamique, fonctionnelle, et informationnelle. La dimension spatiale décrit la localisation des applications informatiques dans la cité de l’information. Cette dimension est associée d’une part, au Plan d’Urbanisme (PU) qui décrit l’urbanisation cible de la cité de l’information et d’autre part, au Plan d’Occupation du SI (POSI) qui décrit l’état actuel de l’urbanisation du SI. La dimension Communication décrit les règles d’échange entre les applications du SI et entre les applications du SI et les SI externes. La dimension dynamique décrit la trajectoire permettant à chaque application de s’intégrer dans le PU. Il s’agit de définir les actions permettant à partir d’un diagnostic établi sur la base du POSI de faire converger l’application vers le cadre défini par le PU qui constitue l’instrument essentiel de l’urbanisation du SI. La dimension informationnelle (resp. fonctionnelle) décrit les données manipulées par les applications informatiques du SI (resp. les fonctions) dont cette application est maître. Ainsi, les dimensions informationnelle et fonctionnelle décrivent les caractéristiques propres et le patrimoine des applications informatiques. Ces

dimensions complètent la dimension

Communication puisque les échanges entre applications informatiques portent essentiellement sur les données dont elles sont maîtres et sur les services qu’elles peuvent exposer. Les sections suivantes seront consacrées à l’analyse des dimensions spatiales, informationnelle, fonctionnelle et communication des règles de coexistence entre les applications informatiques d’un SI.

2.

La dimension spatiale des

règles d’architecture

Le PU définit une vision commune de ce que serait la cible c’est à dire un SI urbanisé et aligné sur la stratégie de l’organisation. Le PU est découpé en zones, quartiers et blocs pour éviter un développement anarchique du SI et accroître son agilité. Une zone est un ensemble de quartiers et un quartier est un ensemble de blocs. En cible, une application informatique occupe un et seul bloc. Il en résulte qu’un bloc du PU a un périmètre de responsabilité bien défini par les fonctions et les entités informationnelles dont l’application est maître. Un couplage faible entre les blocs - c’est à dire entre les applications informatiques du SI

-facilite leur autonomie et une meilleure gestion de leurs échanges. Ainsi, si deux applications informatiques occupent le même bloc du PU, alors elles sont redondantes. Le découpage du PU rend le SI faiblement dépendant de la technologie et de l’organisation et permet d’obtenir un SI cohérent, agile, non redondant. Le nombre de zones, de quartiers et de blocs d’un PU dépend des caractéristiques propres et des contraintes des organisations. La détermination des zones du PU au sein d’une organisation résulte d’un ensemble de règles de découpages liées au métier de cette organisation. Généralement, la première règle de découpage est liée à l’orientation client des organisations modernes. Elle consiste à diviser le PU en deux parties le front-office destiné aux échanges avec les clients et les partenaires de l’organisation et le back-office dédié aux traitements c’est à dire à la gestion des engagements de l’organisation vis à vis de ses clients. Le front-office est ainsi la vitrine de l’organisation et le back-office en constitue l’arrière boutique. La deuxième règle consiste à découper la partie back-office du PU sur la base de la typologie des processus établie par (Porter, 1998). Selon cette typologie, un processus organisationnel est soit un processus métier, soit un processus décisionnel, soit un processus de support. Les processus métier créent de la valeur au sein de l’organisation puisqu’ils lui permettent de produire les biens et les services demandés par ses clients. Les processus de support fournissent et optimisent les ressources nécessaires au fonctionnement de l’organisation et notamment l’exécution des processus métier. Les processus décisionnels sont constitués des activités de pilotage et de prise de décision aux niveaux stratégique et tactique de l’organisation. La prise en compte de cette typologie permet d’identifier dans la partie back-office du PU une ou plusieurs zones métier, une zone de support et une zone décisionnelle. La troisième règle de découpage du PU consiste à identifier les zones – autre que la zone décisionnelle - partagées par le front-office et le back-office et les zones permettant les échanges entre les différentes zones du PU. La zone des référentiels contient les informations partagées par toutes les applications informatiques du SI, en particulier par le front-office et le back-office. Par exemple, le référentiels des clients appartient à cette zone. La zone d’intégration permet aux applications informatiques appartenant à des zones différentes d’échanger des informations et des services. Un bus logiciel ou une application du type ETL sont des exemples d’applications informatiques appartenant à la zone d’intégration du PU. Le passage par cette zone contribue à la mise en œuvre du principe de couplage faible entre les applications du SI. La quatrième règle permet de découper la partie

front-office du PU en deux zones l’une dédiée aux canaux technologiques de communication avec les clients externes et les partenaires (pages web, minitel, EDI,…) et l’autre dédiée aux relations avec les tiers

(clients, partenaires) quel que soit le canal. Le schéma suivant (Figure 1) illustre le découpage du PU.

Figure 1: Le découpage du PU en zones

3.

La dimension Communication

des règles d’architecture

La dimension Communication des règles d’architecture décrit les modes d’échanges intra-SI et inter-SI. Pour les échanges intra-SI, l’objectif des règles d’architecture caractérisant cette dimension est de réduire les échanges point à point entre les applications appartenant à des zones différentes du PU et de favoriser ainsi le couplage faible entre ces applications et la réutilisation des informations contenues dans flux échangées. Il en résulte une réduction du coût de développement, de maintenance, et de mise en œuvre des applications informatiques. Ainsi, tout échange entre deux applications informatiques appartenant à deux zones différentes du PU doit passer par la zone d’Intégration. Pour les échanges avec des applications appartenant à des SI extérieurs à l’organisation, l’objectif des règles d’architecture est d’une part, de masquer la complexité du SI de l’organisation aux tiers qui sollicitent des services exposés par ce SI et d’autre part, d’assurer la sécurité du SI contre les intrusions. Ainsi, tout échange avec un SI doit passer par la zone des canaux technologiques de communication. Il en résulte que les échanges intra-SI doivent être gérés par une ou plusieurs applications appartenant à la zone d’intégration. Par ailleurs, les échanges avec les tiers passent des applications de la zone des canaux technologiques de communication.

4.

Les dimensions

informationnelle et fonctionnelle

des règles d’architecture

La dimension informationnelle (resp. fonctionnelle) décrit les données ou entités informationnelles (resp. les fonctions) dont cette application est maître. Ainsi, les dimensions informationnelle et fonctionnelle décrivent les caractéristiques propres et le patrimoine d’une application informatique. Les fonctions et entités informationnelles délimitent le périmètre de l’informatisation c'est-à-dire le QUOI. Ces deux concepts décrivent avec un langage proche du métier ce qui est pris charge le SI en support aux différents processus de ses utilisateurs.

4.1 Les entités informationnelles

Une entité informationnelle est un ensemble d’informations manipulées (stockées, calculées, utilisées,…) par le SI, représentant des données, objets matériels ou concepts communément utilisés dans les processus organisationnels. C’est le cas par exemple, du client ou du contrat dans une société d’assurances. Les entités métier constituent le modèle conceptuel métier qui est indépendant de ses implémentations en base de données. Un système est maître d'une entité informationnelle lorsqu'il possède la copie officielle de cette entité. Une donnée n'est officiellement créée ou modifiée que lorsque le maître a accepté cette création ou modification. Toute entité informationnelle a une et une seul application informatique maître. Les autres

Zone des canaux technologiques de communication Zone d'échanges avec les tiers

Zone décisionnelle Zone d'inrégration Zone des référentiels Zone métier 1 Zone du support Zone métier 2 Zone métier 3 Zone métier 4

applications informatiques sont alors esclaves sur cette entité. Qu’elles soient maître ou esclave d’une entité informationnelle, les applications informatiques ont des obligations qui facilitent leur coexistence dans un SI urbanisé. Ainsi, une application informatique maître d’une entité informationnelle propose des services de lecture et de mise à jour de cette entité (publication). Elle contrôle les mises à jour de cette entité et est responsable de la détection de problèmes d’intégrité. A l’issue de chaque modification, une application informatique maître d’une entité informationnelle émet une notification aux applications informatiques esclaves sur cette entité.

4.2 Les fonctions

Une fonction est une action d’utilisation ou de transformation (recueil, création, traitement, restitution, mémorisation) des entités informationnelles du SI. Le terme fonction concerne aussi bien le métier des organisations que les activités de pilotage et de support nécessaires pour que ces organisations atteignent leurs objectifs. Ainsi, on distingue trois types de fonctions manipulées par les processus organisationnels: les fonctions métier, les fonctions décisionnelles, et les fonctions de support. Par exemple, ajouter un bénéficiaire sur un contrat d’assurances, restituer les informations d’un compte épargne, ouvrir un sinistre, régler un sinistre sont des fonctions appartenant au métier de l’assurance. Les fonctions sont indépendantes des applications informatiques qui les implémentent.

Les fonctions décrivent l’utilisation ou la transformation (recueil, création, traitement, restitution, mémorisation) des informations portées par les entités informationnelles manipulées par les processus organisationnels. Les entrées et les sorties des fonctions sont des entités informationnelles. Les fonctions identifiées dans le cadre d’un projet permettent de définir le périmètre du projet, elles sont la base de l’évaluation de la couverture fonctionnelle des scénarios de solutions envisagés. Au travers des activités et des tâches des processus organisationnels, les acteurs organisationnels manipulent des entités informationnelles et exécutent des fonctions métier, de support, ou décisionnelles. Une activité ou une tâche d’un processus organisationnel exécute une ou plusieurs fonctions. Par exemple, dans une société d’assurance, la fonction métier « Restituer l’état civil d’une personne » est exécutée par les tâches « identifier le payeur de prime », « identifier le bénéficiaire en cas de sinistre », et « envoyer la proposition d'assurance au client ». Notons qu’une fonction peut se décomposer en fonctions élémentaires. De ce fait, les processus organisationnels sont focalisés sur l’organisation et le déroulement des étapes qui les composent pour fournir la meilleure réponse à une demande émanant

d’un client. Les activités et les tâches décrivent ce que font des acteurs dans le processus pour répondre à cette demande. D’un point de vue du SI, les entrées et les sorties des processus sont des flux informationnels. Notons que, les fonctions ne sont pas des concepts décrivant les processus organisationnels. Autrement dit, les activités et les tâches d’un processus ne se décomposent pas en fonctions. Qu’elles soient métier, de support, ou décisionnelles, les fonctions sont orthogonales aux processus (Dakhli, 2008). Elles peuvent être utilisées dans plusieurs processus et sont indépendantes des acteurs et de l’organisation. De telles fonctions sont dites réutilisables. C’est le cas, par exemple, des fonctions métier associées aux clients. D’autres fonctions sont spécifiques à un domaine (par exemple le domaine épargne) ou à un processus (par exemple le processus rachat partiel d’un contrat d’assurance-vie dans une société d’assurance).

La fonction métier est une notion de référence qui n'est pas informatique. Elle correspond à une exigence fonctionnelle du métier, du pilotage, ou du support au sein d’une organisation. Ainsi, elle est indépendante de la solution logicielle. Les fonctions sont automatisées par des services logiciels, exposés par les applications informatiques. On distingue deux types de services logiciels: les services applicatifs et services utilisateurs. Afin d’éviter les redondances entre applications informatiques, une fonction élémentaire doit être implémentée en cible par un et un seul service logiciel. Une et une seule application informatique est maître de ce service qu’elle expose aux autres applications informatiques du SI.

Les liens entre les fonctions et les services logiciels permettent de retrouver - dans les applications informatiques - les services déjà implémentés, de faire des analyses d'impact des évolutions, d'évaluer le niveau de redondance du SI, d'identifier les possibilités de réutilisation des services existants, les besoins d'évolution et les nouveaux services à créer.

5.

Le modèle en couches de

l’architecture d’un SI

Dans cette section, nous proposons un modèle en couches de l’architecture d’un SI synthétisant les travaux proposés dans la littérature dans le domaine de l’urbanisation d’un SI. Ce modèle – qui s’inspire du modèle proposé par (Dakhli, 2008) - est basé sur cinq couches: la couche stratégie, la couche fonctionnelle (architecture du SI), la couche processus, la couche d’architecture applicative, et la couche architecture logicielle (Figure 1). La couche « stratégie » définit les problèmes organisationnels à résoudre et leurs solutions organisationnelles. Ces problèmes résultent des contraintes externes et

internes de l’organisation. Les contraintes externes peuvent être économiques, politiques, sociales, légales ou technologiques. Les contraintes internes reflètent les impacts des contraintes externes sur les composantes de l’organisation: structure, individus, tâches, technologie de la production, technologie de l’information (Toffolon, 1996) (Leavitt, 1963). La couche « architecture des processus organisationnels » décrit les processus organisationnels (métier, décisionnel, support) au niveau d’abstraction conceptuel. L’architecture conceptuelle des processus modélise les processus organisationnels comme des nœuds d’activités et de tâches échangeant et traitant de l’information. L’architecture des processus organisationnels est mise à jour en fonction des orientations dictées par la couche stratégie.

La couche « architecture fonctionnelle » décrit l’architecture d’un SI en termes de fonctions et d’entités informationnelles. Elle est basée sur un métamodèle décrivant les fonctions métier, de pilotage et de support ainsi que les relations entre ces concepts. Ce métamodèle est mis à jour pour intégrer les impacts des solutions organisationnelles définie par la couche stratégie sur les entités informationnelles et les fonctions.

La couche « architecture applicative » fournit une carte décrivant les applications informatiques du SI de l’organisation ainsi que les flux informationnels qu’elles échangent. Une application informatique est un ensemble de logiciels qui informatisent au moins partiellement un processus organisationnel. Ainsi, une application informatique supporte directement ou indirectement le comportement de création de la valeur par les acteurs organisationnels. Ce comportement consiste à exécuter des tâches qui manipulent des entités informationnelles à travers un ensemble de fonctions. Une application informatique fournit deux types de services: service orienté utilisateurs et service orienté applications. Un service orienté utilisateurs résulte d’une interaction entre un utilisateur final et une application informatique et apporte un support aux acteurs organisationnels qui réalisent un ensemble de tâches opérationnelles ou décisionnelles. Un service orienté applications est un service intermédiaire fourni par une application informatique aux autres applications du SI ou aux SI externes dans le cadre du traitement de l’information. Il en résulte qu’une application informatique peut être considérée comme une conjonction d’un ensemble d’activités d’un processus organisationnel et d’entités

informationnelles et de fonctions permettant de contribuer à la production de biens et de services au sein de l’organisation. La couche « architecture applicative » résulte de l’interaction entre la couche « architecture fonctionnelle » et la « couche architecture des processus organisationnels » qui supporte l’espace des problèmes et l’espace d’opération (Toffolon et al. 2002). Elle permet de livrer une description globale d’une solution logicielle qui sera implémentée sous la forme d’une application informatique interagissant avec les autres applications informatiques du SI.

La couche « architecture logicielle » décrit chaque solution logicielle comme un ensemble de composants logiciels et de connecteurs distribués conformément à un modèle d’architecture logicielle (par exemple MVC). Une solution logicielle peut appartenir à deux catégories. D’une part, elle peut définir l’architecture d’une nouvelle application informatique supportant un nouveau processus organisationnel ou un ensemble d’activités qui n’étaient pas informatisées et appartenant à un processus organisationnel existant. D’autre part, elle peut aussi décrire l’architecture d’une nouvelle version d’une application informatique existante dont l’évolution permet de prendre en compte les modifications d’un processus organisationnel existant. Malgré la richesse des définitions existantes du concept de composant logiciel, nous pensons que ces définitions ne reflètent pas toutes les perspectives de l’architecture d’un SI. Pour remédier aux faiblesses de ces définitions, nous nous référons au concept de fonction pour définir un composant logiciel comme étant une unité logique et autonome qui implémente une fonction afin de fournir un service soit à un utilisateur final soit à d’autres unités logiques. Un connecteur est une unité logique et autonome qui facilite les interactions entre deux composants logiciels. Une solution logicielle est un ensemble cohérent de composants logiciels réutilisables ou spécifiques et de connecteurs. Un composant logiciel réutilisable implémente une fonction utilisée par plusieurs processus organisationnels.

Par conséquent, une solution logicielle a plusieurs facettes associées aux couches du modèle d’architecture du SI présenté ci-dessus. Chaque facette correspond à un métamodèle d’architecture qui décrit les concepts de base caractérisant cette facette et leurs liens.

Figure 2: Le modèle en couches d’architecture d’un SI

Impacts de la stratégie sur les fonctions et les entités informationnelles

Espace de construction Espace des problèmes

Solution organisationnelle Description globale d'une solution logicielle Description détallée d'une solution logicielle Solution organisationnelle Description détaillée d'une solution logicielle Espace des solutions

6

Approche de construction

d’une solution logicielle

L’approche de construction d’une solution logicielle que nous proposons s’inscrit dans le cadre d’une démarche d’urbanisation du SI d’une organisation. Elle utilise les concepts et les modèles d’architecture présentés ci-dessus. Cette approche est composée de huit phases qui sont:

Décrire le processus organisationnel

supporté et identifier les activités et les tâches à informatiser

 Identifier les fonctions et les entités

informationnelles manipulées par les activités et les tâches à informatiser

 Positionner les fonctions et les entités

informationnelles identifiées sur le PU et déterminer les applications maîtres de ces fonctions et de ces entités ainsi que les quartiers et blocs auxquels elles appartiennent

 Déterminer la zone de PU, le quartier, et

bloc de la nouvelle l’application informatique et les applications informatiques avec lesquelles elle interagit

 Identifier les fonctions réutilisables  Déterminer les différentes solutions

logicielles cibles possibles et les comparer

 Lister les règles d’architecture applicables  Préconiser une solution logicielle cible et

définir une trajectoire pour converger vers cette solution.

Ces phases ne sont pas nécessairement séquentielles. C’est le cas, par exemple, des phases
et . En effet, la description des

activités et des tâches d’un processus organisationnel peut se dérouler en même temps que l’identification des entités informationnelles et des fonctions manipulées par ce processus. Pour construire une solution logicielle acceptable qui tient compte des contraintes de l’organisation, plusieurs itérations de l’ensemble des huit phases listées ci-dessus peuvent être nécessaires.

7

Cas d’étude

Dans cette section, nous illustrons – à l’aide d’un exemple - l’application de l’approche de construction d’une solution logicielle présentée ci-dessus. Cet exemple est adapté à partir de l’architecture d’une application informatique réelle appartenant au SI d’une société d’assurance. Compte tenu de l’omission de nombreux détails sur l’application informatique objet de ce cas d’étude, et pour simplifier la présentation de ce

cas d’étude, nous limitons notre raisonnement au niveau des zones du PU. Ce cas d’étude concerne le développement d’une application de reporting destinée à fournir aux clients finaux d’une société d’assurance une situation de leurs contrats d’épargne et d’assurance. D’autre part, les mêmes informations sont destinées aux conseillers de ces clients afin qu’elles servent de base lors de leurs discussions avec leurs clients pour leur proposer de nouveaux produits ou modifier leurs contrats. Notons que dans cette société d’assurance, on distingue deux types de reporting: opérationnel et décisionnel. Le premier est destiné aux acteurs organisationnels impliqués dans les processus métier et les processus de support alors que le second est destiné aux décideurs impliqués dans les processus décisionnels de pilotage de l’organisation. Ainsi, le reporting opérationnel n’est pas supporté par des applications informatiques appartenant à la zone décisionnelle du PU. De même, le PU de cette société ne comprend qu’une seule zone métier regroupant les applications informatiques qui supportent les métiers de l’assurance IARD (Incendies, Automobiles, Maison,…), de l’épargne, et de la prévoyance. Pour simplifier, on suppose qu’il existe trois applications informatiques – appelées IARD, Epargne et Prévoyance - supportant ces trois processus métier. On suppose que le reporting consiste à valoriser les contrats détenus par chaque client et à lui fournir une répartition de son patrimoine sous la forme d’un tableau et d’un graphique.

Le processus organisationnel à informatiser comprend trois activités: Identifier le contrats d’un client, Déterminer la répartition du patrimoine d’un client, Communiquer les informations au client et au conseiller. Ces trois activités manipulent les entités informationnelles suivantes: client, contrat d’épargne, contrat de prévoyance, contrat IARD, produit. Les fonctions par l’intermédiaire desquelles les trois activités manipulent les entités informationnelles sont: restituer les attributs d’un client (nom, âge, adresse, numéro de contrats), restituer les attributs d’un contrat IARD (numéro, nom du titulaire, liste des produits gérés par le contrat), restituer les attributs d’un contrat d’épargne (numéro, nom du titulaire, liste des produits gérés par le contrat), restituer les attributs d’un contrat de prévoyance (numéro, nom du titulaire, liste des produits gérés par le contrat), Restituer la valeur d’un produit, Calculer la valeur d’un contrat IARD, Calculer la valeur d’un contrat d’épargne, Calculer la valeur d’un contrat de prévoyance, Consolider le patrimoine d’un client, Restituer la répartition du patrimoine au client, Restituer la valeur du patrimoine d’un client à son conseiller. Ainsi, en plus des trois applications informatiques citées

ci-dessus, trois référentiels – appartenant à la zone des référentiels du PU - sont mis à contribution: le référentiel des Clients, le référentiel des Produits, et le référentiel des Valeurs. Finalement, la restitution des informations au client final passe par une application appartenant à la zone des canaux technologiques de communication (exemple le site web d’adresse URL

www.NomSociété.fr) alors que la restitution des informations au conseiller passe par une application informatique appartenant à la zone des échanges avec les tiers (par exemple intranet). Les applications de la zone Métier sont maîtres des contrats et des fonctions « Restituer les attributs d’un contrat ». Les référentiels sont maîtres des entités informationnelles Client, Produit, et Valeur et des fonctions « Restituer les attributs d’un client », « Restituer les attributs d’un produit ». La nouvelle application Reporting est maître des entités informationnelles valeur d’un contrat, valeur du patrimoine d’un client, répartition du patrimoine d’un client et des fonctions « Valoriser un contrat », « Valoriser le patrimoine », « Consolider le patrimoine », « Restituer la valeur du patrimoine », « Restituer la répartition du patrimoine ». La nouvelle application Reporting appartient à la zone des échanges avec les tiers. Ses échanges avec les Référentiels et avec les applications métier passent par la zone d’Intégration. Il en résulte que ses échanges avec l’application informatique www.NomSociété.fr

sont point à point car en règle générale, les échanges entre la zone des canaux technologiques de communication et la zone des échanges avec les tiers ne passent pas par la zone d’intégration en raison de la proximité logique de ces deux zones. L’application reporting peut être implémentée à l’aide d’un progiciel ou d’un développement interne. Notons que, compte tenu du faible nombre de processus organisationnels étudiés, nous n’identifions pas de fonctions réutilisables dans ce cas d’étude. De même, nous ne préconisons pas de trajectoire permettant d’atteindre la solution

architecturale cible. En effet, de nombreuses informations relatives aux contraintes technologiques, économiques, et temporelles de l’organisation étudiée (la société d’assurances) ne sont pas disponibles.

8

Conclusion et futures directions de

recherche

Dans cet article, nous avons présenté les concepts fondamentaux de l’urbanisation d’un SI. Nous avons ensuite proposé une approche de huit phases pour construire une solution logicielle dans le cadre d’un SI urbanisé. La contribution principale de travail est d’avoir mis l’accent que l’urbanisation d’un SI peut être mise en œuvre dans la pratique à travers une adaptation des approches et méthodes de développement et de maintenance/évolution. La validation de cette approche dans une société d’assurances a permis d’identifier quelques problèmes qui constituent de futures directions de recherche. Tout d’abord, la différence entre les concepts de tâches, d’activités et de fonctions n’est pas claire. Des critères discriminants doivent être identifiés afin de permettre aux architectes et aux développeurs de comprendre la différence entre ces concepts. Ensuite, des règles de nommage et de codification des entités informationnelles et des fonctions doivent être définies. En effet, dans le cadre de la validation de l’approche proposée, nous avons constaté que des architectes et des développeurs utilisent des termes imprécis et non standards pour nommer les entités informationnelles et les fonctions. Il en résulte des incohérences et des redondances qui peuvent être un obstacle face à la réutilisation. Enfin, la réutilisation des fonctions passe par la mise en place d’un catalogue des fonctions réutilisables et d’un moteur de recherche pour trouver facilement la fonction à réutiliser.

Références

Bernard, S.A., An Introduction to Enterprises Architecture, Indiana, Author House, 2004. Boar, B.H., Constructing Bluprints for Enterprise

Architecture, New York, Wiley Computer Publishing, 1999.

Dakhli, S.B.D. (2008). The Solution Space Organisa-tion: Linking Information Systems Architecture and Reuse. In the Proceedings of the ISD’2008 Confer-ence, Paphos, Cyprus, August 25-27, 2008. Springer-Verlag.

Dieberger, D., Frank, A.U., A City Metaphor to Support Navigation in Complex Information Spaces, Journal of Visual Languages and Computing, Vol.9, pp. 597-622, 1998.

Everden, R., The Information Framework, IBM Systems Journal, Vol. 35, pp. 37-38, 1996.

Fayad, M., Henry D., Bougali, D., Enterprises Frameworks, Software Practice and Experience, , Vol. 32, 2002, pp. 735-786.

Jean G., Urbanisation du business et des SI, Paris, Editions Hermès, 2000.

Kaisler, S.H., Armour F., Valivullah M., Enterprise Architecting : Critical P, in the Proceedings of the 38th HICSS, Hawaï, IEEE, 2005.

Leavitt, H.J., (ed.), The Social Science of Organizations, Four Perspectives, Prentice-Hall,

Englewood Cliffs, New Jersey, 1963.

Longépé C., Le Projet d’Urbanisation du SI, Paris, Editions Dunod, 2006.

Maier, M.W., Rechtin, E., The Art of Systems Architecturing, CRC Press, 2000.

Noran, O., Analysis of the Zachman Framework for EA from the GERAM Perspective, Annual Reviews in Control, Vol. 27, pp. 163-183, 2003

Porter, M.E., Competitive Advantage: Creating and Sustaining Superior Performance, Avantage, New York, Free Press, 1998

Sassoon J., Urbanisation des SI, Paris, Editions Hermès, 1998.

Toffolon, C., Dakhli, S., The Software Engineering Global Model, in Proceedings of the COMPSAC’2002 Conference, August 26-28, 2002,

Oxford, United Kingdom,

Toffolon, C., L’Incidence du Prototypage dans une Démarche d’Informatisation, Thèse de doctorat, Université de Paris-IX Dauphine, Paris, Décembre, 1996..

Zachman, J.A., A Framework for Information Systems Architecture, IBM Systemps Journal, Vol. 26, 1987, pp. 276-292

Zachman, J.A., and Sowa, J., Extending and Framework for IS Architecture, IBM Systemps Journal, Vol. 31, 1992, pp. 590-616