La démarche architecture de système d’information

architecture de système d’information 

Le système d’information, tel qu’il été conçu jusqu’à présent, va se transformer en un système de plus en plus complexe qu’il faudra organiser dans un cadre architectural. L’objectif de notre blog est de réponse à ces questions :

Qu’est ce qu’une architecture ?

Comment la concevoir ?

Quelle démarche méthodologique ?

Quels en sont les composants ?

L’analyse de la situation initiale :

Rien de sérieux ne peut être entrepris sans que soit établi un bilan objectif de la situation initial de l’informatique de l’entreprise. L’expérience montre que si les utilisations ont pris possessions de l’outil informatique, les résultats sont rarement satisfaisants. Il leur manque la maîtrise technique des outils. Comment se faire une idée précise de la situation d’une entreprise ?

Jean- louis Thomas propose une classification des entreprises selon deux critères simples :

-          Le taux de couverture opérationnelle (ou CO) qui traduit la capacité à fédérer l’ensemble des processus de l’entreprise ;

-          Le degré d’intégration (ou DI) qui se définit comme la capacité à fournir aux acteurs de l’entreprise une vision unique et homogène de la partie du système d’information dont ils sont besoin pour jouer leur rôle.

Ces critères d’évaluation s’appliquent à quatre catégories d’entreprise (Voir la figure)

-         -  Les entreprises dont aucun processus n’est informatisé en dehors de la bureautique ;

-          - L’entreprise dont seuls certains processus de la base (comptabilité, paie, facturation) sont informatisés ;

-         -  L’entreprise informatisée par partie mais il n’existe pas d’intégration ;

-         +  L’entreprise totalement intégrée.

-         -  Les conclusions de l’analyse de la situation initiale vont conduire à l’élaboration d’un bilan général utile à la conception d’un modèle d’architecture car il mettra en lumière les éventuelles insuffisances informatiques de l’entreprise et ses besoins.

L’analyse des besoins :

L’analyse des besoins est effectuée par le maître d’ouvrage pour qui le système d’information est réalisé. Ce sont des besoins orientés métier que l’architecture doit compléter par des besoins orientés exploitation et administration.

La détermination des besoins repose sur l’analyse de nombreux paramètres : information. Flux de données, mode de stockage, moyens d’accès et traitements à effectuer.

La conclusion de cette phase conduit à l’élaboration d’un cahier des charges. Ce dernier formalise les relations contractuelles qui lient le maître d’ouvrage au maître d’œuvre. Que l’on se rassure, ce document essentiel est contesté pendant toutes les phases de la réalisation avec plus ou moins de mauvaise foi par les deux parties.

C’est la raison pour laquelle ce document doit être aussi précis que possible et rédigé sans précipitation.

Conception du modèle :

L’approche logique :

Lorsque l’on dispose de la liste des besoins exprimés sur les traitements, sur la nature des données, sur les flux d’informations, sur les acteurs, sur les modes de stockage et d’archivage s’ouvre la phase de conception du modèle.

Un modèle logique d’architecture se présente comme un plan d’ensemble du système ou sous-système d’information réalisé indépendamment de tout choix d’équipement. Ce document a pour ambition de fournir une explication claire des processus qui seront mis en œuvre du point de vue fonctionnel.

Les règles méthodologiques présidant à la conception d’un modèle s’appuient sur les théories des systèmes d’information. Celles-ci introduisent le concept « d’objet ». L’objet est doté d’une structure et plongé dans un environnement, il  agit en vu d’un objectif fixé dans le temps et il évolue avec lui. A partir de ce concept, J-L- Lemoigne a présenté dans sa théorie du système général une approche globale qui consiste à considérer l’objet, à travers les échanges qu’il a avec son environnement et non pas en lui-même. Il est plus important de comprendre le comportement de l’objet plutôt que sa structure.

La structure de l’objet :

Un objet plongé dans son environnement subit dans le temps des modifications à la suite d’événements générateurs de processus. On distingue les événements de transaction qui génèrent des flux d’entrée et de sortie d’information, et les événements de transformation qui provoquent une mutation du système. Ce dernier se compose d’objets déroulant des processus dits « élémentaires »

L’interconnexion de ces processus constitue un réseau, lui-même organisé en sous-réseaux. C’est la phase de détermination du modèle, dont la finalité est de réaliser un plan décrivant le fonctionnement logique de processus.

Représentation d’un modèle :

Les objets déroulent des processus d’une complexité variable, ce qui conduit à une structuration plus fine de leur définition.

Il existe une méthodologie de définition des processus, le BPML (Busines  Process Modeling Language).

Les scénarios de modèle physique :

Le modèle d’architecture fournit une indication précise sur la façon dont sont organisés les traitements des fournisseurs de services, les flux d’informations, les unités de stockage et ce que l’on attend du réseau. Il faut désormais élaborer des solutions proposant des équipements, des logiciels, et un réseau qi soient en mesure de correspondre aux besoins et au modèle. Le nombre de solutions possibles est infini. Il est d’usage de limiter le choix à trois scénarios : « d’avant-garde », qui utilise des techniques de pointe, un scénario « conservateur », qui s’inscrit dans la continuité de les solutions existantes, et un scénario « équilibré », à mi-chemin de ces deux tendances. Cette phase de conception est la plus longue et la plus éprouvante pour l’architecte car elle fait intervenir des acteurs extérieurs intéressés à la vente de leur produit, qu’il soit adapté ou non aux problèmes posés.

Les scénarios présentent, en principe, des solutions exclusivement basées sur des produits du marché provenant, si possible, de plusieurs fournisseurs.

Un certain nombre de règles sont à respecter lors de l’élaboration de cette phase :

-          L’application finale impose le choix du système d’exploitation du serveur :

-          La simplicité d’un modèle d’architecteur est une des garanties de son bon fonctionnement. Cette simplicité suppose que chaque fonction soit dédiée à un serveur spécifique.

Fixer plusieurs applications sur le même serveur a pour effet :

-          D’augmenter la complexité de fonctionnement sans contreparties ;

-          Chaque système doit être administré avec des outils dédiés :

-          La durée de vie des applications est infiniment plus longue que celle des serveurs et des composants matériels. Il faut donc garder à l’esprit l’éventualité d’un portage de la solution logicielle sur un autre système d’exploitation.

Egalement, ne pas oublier d’évaluer les risques liés au choix des fournisseurs :

-          Pérennité ;

-          Sérieux ;

-          Références ;

-          Compétence ;

-          Capacité d’installation et de maintenance ;

-          Surface financière ;

-          Déterminer son choix sur la base d’une liste de critères objectifs ;

Conclusion :

Les projets informatiques déployés dans les entreprises sont conçus à partir de produits plus ou moins paramétrés qui constituent le socle même su système d’information. Leur intégration avec les applications existants rend nécessaire la conception d’un modèle d’architecture. Celui-ci décline selon deux aspects : la conception d’un modèle logique qui a pour but d’expliquer le fonctionnement du système, et son implémentation.