Simple Sound Guide

4 Bonnes pratiques pour déployer un référentiel d’architecture du SI

MP900401610 150x150 4 Bonnes pratiques pour déployer un référentiel d’architecture du SI

Pourquoi déployer un référentiel d’architecture ?

Selon les principes d’urbanisation (de type UrbaEA), le système d’information est constitué d’un ensemble d’architectures (fonctionnelle, applicative et technique) qui permet de supporter les objectifs stratégiques et les processus métiers de l’organisation.

ArchitectureSI 4 Bonnes pratiques pour déployer un référentiel d’architecture du SI

  • L’architecture fonctionnelle apporte une réponse à la question suivante : 

Quelles sont les éléments fonctionnels supportés par le système d’information ? Le QUOI ?

Cette architecture décrit les fonctionnalités (services) offertes par le système d’information pour supporter les processus métiers. Elle est constituée généralement de services métiers ou fonctionnels.

 

  • L’architecture applicative apporte une réponse à la question suivante :

Comment les éléments fonctionnels sont ils implémentés ? Le COMMENT ?

Cette architecture représente l’implémentation des services fonctionnels sous forme d’éléments applicatifs.

Elle est composée d’éléments applicatifs (ex : composants Java, .net, objets BDD,…). L’architecture applicative représente le premier niveau d’une projection entre une architecture fonctionnelle (et ses services métiers) et des technologies qui vont devoir supporter ces services. Elle est une instanciation de l’architecture fonctionnelle.

 

  • L’architecture technique apporte une réponse  la question suivante :

Avec quels éléments techniques, les éléments applicatifs sont ils déployés ? Le AVEC QUOI ?

Cette architecture décrit l’infrastructure sur laquelle les éléments applicatifs ont été déployés.

Elle est décomposée en deux couches :

- Une couche de logiciels médiateurs (ou middleware)  qui est composée des progiciels : moteurs des bases de données, serveur d’application, serveur web, annuaire LDAP, ordonnanceur, gestionnaires de flux (EAI, ESB, ETL, …), etc.

- Une couche matérielle qui est composée des logiciels de base (systèmes d’exploitation), des serveurs et des réseaux.

 

Qu’est ce qu’un référentiel d’architecture d’entreprise ?

Le référentiel d’architecture représente la cartographie du  système d’information. Elle est centralisée et partagée au sein de l’organisation.

Quels sont les objectifs d’un référentiel d’architecture d’entreprise ?

Un référentiel d’architecture peut répondre à plusieurs objectifs, en voici quelques exemples, il peut :

  • Être utilisé pour permettre à une organisation de maitriser les transformations du SI, au travers d’analyses d’impacts macro (étude stratégique  d’opportunités) ou micro (changements opérationnels – Request For Change – RFC  au sens ITIL)

  • Être exploité par la production informatique en centralisant des informations essentielles à la maintenance du parc informatique (les contrats de support, les SLA et les cycles de vie des produits)
  • Être employé tel un support de communication pour échanger  sur des projets à venir
  • Fournir un cadre de partage entre MOA, MOE, partenaires et actionnaires
  • Offrir un moyen de mettre en évidence les optimisations du SI (redondance, simplification)

4 bonnes pratiques pour déployer un référentiel d’architecture

Pratiques1 4 Bonnes pratiques pour déployer un référentiel d’architecture du SI

Lister les cas d’utilisation opérationnels du référentiel d’architecture

Jumelles 150x150 4 Bonnes pratiques pour déployer un référentiel d’architecture du SICette étape vise à lister et à définir les cas d’utilisation du référentiel. Ce recensement va permettre d’ajuster le niveau de détails utile du référentiel (« le  grain pour la photo de l’architecture »), qui permettra de répondre aux cas d’utilisation.

Ci-dessous quelques exemples de cas d’utilisation du référentiel :

  • Quels sont les composants dont la maintenance doit être renouvelée dans un mois ?
  • Quelles sont les niveaux de maintenance (24/7, 8-18 5/7, …) associés à chaque serveur ?
  • Quels sont les impacts d’un arrêt / relance d’un serveur sur le(s) service(s) métier(s) ?
  • Quelles sont les versions des composants applicatifs déployées sur chaque serveur ?
  • Quels sont les impacts macroscopiques sur le système d’information d’une évolution ou d’un ajout d’une fonctionnalité métier ?

Identifier les gisements de données d’architecture existants

RIO 150x150 4 Bonnes pratiques pour déployer un référentiel d’architecture du SICette étape consiste à cartographier les gisements de données existants (fonctionnels, applicatifs et techniques) au sein de l’entreprise étendue (fournisseurs inclus).

La finalité de cette opération est de s’appuyer sur les gisements existants et opérationnels pour créer et enrichir le référentiel d’architecture d’entreprise.

Pour chaque gisement, on identifiera :

  • Les modèles conceptuels de données qui sont utilisés ;
  • Les parties prenantes en charge de réaliser les mises à jour des données ;
  • Les outils utilisés ;
  • L’utilisation et la finalité du gisement ;

Ces gisements se matérialisent généralement sous formes de documents ou de systèmes de gestion. On va par exemple « rencontrer » :

a) Des spécifications fonctionnelles, des dossiers de conception ou des dossiers d’architecture qui vont définir l’architecture fonctionnelle et/ou applicative et/ou technique à mettre en œuvre ou qui est mise en œuvre.

b) Des référentiels qui contiennent:

  • Des sources logicielles et les rapports de qualité logicielle, qui sont maintenues par des TMA ou des cellules de qualité ;
  • Des indicateurs de performance de l’architecture technique ou SLA de production, ces données sont fréquemment fournies par l’hébergeur ou la direction de production ;
  • La configuration de l’architecture applicative et technique, appelée communément CMDB et mis à disposition par un service de la production ;

Définir un modèle de cartographie d’architecture

MP900433123 PuzzleMonde 150x150 4 Bonnes pratiques pour déployer un référentiel d’architecture du SI

Cette étape consiste à définir le modèle du référentiel :

  • Qui doit être standardisé (donc évolutif et partageable) : TOGAF offre des modèles ouverts par exemple
  • Qui apporte des réponses aux cas d’utilisations attendus (la bonne granularité)
  • Qui peut être outillé (pour en faciliter l’industrialisation)
  • Qui sait agréger, s’interfacer, se référer aux données et/ou aux outils provenant des  gisements identifiés

Décrire un processus pour maintenir le référentiel d’architecture

MP900410056 PoigneeMain 150x150 4 Bonnes pratiques pour déployer un référentiel d’architecture du SI
L’objet de cette activité est de décrire le processus de mise à jour des données du référentiel (Qui réalise la mise à jour ? Quand ? et Comment ?).

Cette action est vitale car elle vise à garantir, la « fraicheur » de l’information stockée dans le référentiel et donc, la véracité des analyses effectuées à partir du référentiel.

Quelques conseils !



1 / Adoptez une démarche itérative : ne voyez pas trop grand ! effectuez des itérations en réalisant un lotissement des cas d’utilisations que vous souhaitez rendre opérationnel ; faites simple au début et enrichissez votre référentiel au fur et à mesure des itérations

2/ Appuyez vous sur les forces en présence : les gisements existants et maintenus !

3/ Ne pas réinventez l’eau chaude et utilisez des modèles du marché, TOGAF en propose un certain nombre

Iterations1 4 Bonnes pratiques pour déployer un référentiel d’architecture du SI


Vous avez besoin de conseil, de formation, de soutien ou d’expertise, vous pouvez me contacter sur contact@instilia.com ou plus d’infos sur www.instilia.com


13 réponses à to “4 Bonnes pratiques pour déployer un référentiel d’architecture du SI”

  • flick:

    Superbe synthèse. Je me permets de vous poser une question relative à l’organisation projet et le type de management nécessaire pour mener efficacement le processus d’urbanisation du si sur les 4 couche. J’ai fait l’expérience d’un projet en mode collaboratif ou tout se décide par lobbying avec des luttes intestines entre Moa et Moe. Le résultat n’est pas fameux.

    • thierry Rault:

      Bonjour,

      une bonne gestion du SI repose sur un triptyque projet/architecture/production. L’urbanisation du SI passe dans un premier temps par la mise en place de règles ou méthodes incluant la gouvernance sur les 3 pôles. Je vous incite à étudier les notions d’architecture d’entreprise, et notamment togaf qui propose un cadre d’architecture composé d’un référentiel d’architecture et d’une approche méthodologique de développement architecture(ADM) intéressants.

      • Olivier Catelin:

        Bonjour,

        Il est possible aussi d’associer la méthode TOGAF avec une méthode de gestion de projet (PMI ou Prince2).

        - TOGAF s’occupant de cadrer les évolutions de l’architecture d’entreprise
        - PMI de fournir un cadre pour piloter le changement (mode projet)

    • Olivier Catelin:

      Bonjour Fabien,
      Un conseil que je peux te donner : les décisions prises sur un projet (lobbying ou pas) doivent être en phase avec les objectifs du projet à atteindre.
      Peux tu me donner plus de précisions sur la problématique « tout se décide par lobbying » ?

  • thierry Rault:

    Merci pour cette description qui permet de mettre en évidence le contexte d’architecture au sens large, qui reste encore trop méconnu et cantonné trop souvent à un domaine purement technique.
    J’ajouterais que le référentiel d’entreprise peut et devrait être utilisé pour référencer l’ensemble des processus de l’entreprise, en support à l’ensemble des projets de transformation de l’entreprise. TOGAF intègre d’ailleurs les 3 domaines: Business, si et technique.

    • Olivier Catelin:

      Merci Thierry pour ces retours, en complément, cette méthodologie permet aussi de réunir des interlocuteurs provenant de divers horizons (les fonctionnels, les architectes logiciels et les architectes techniques). Ils peuvent ainsi partager les enjeux, les impacts de part et d’autres de leurs métiers. On arrive ainsi à fluidifier la communication entre ces acteurs. Ce qui n’est généralement pas le cas, car ils travaillent souvent en vase clos.

      On arrive aussi à créer une prise de conscience collective et partager des enjeux du projet / du changement (ne pas faire de la technique pour la technique mais de la technique pour délivrer du business).

  • Flick:

    Je suis complètement en ligne sur cette présentation. Reste deux chapitres peu traité

    1) L’architecture de données dans l’architecture d’entreprise avec une approche MDM efficace

    2) Une architecture scalable. Extension de périmètre, niveau de gouvernance différents. Je recherche une expérience d’une architecture fractale ( poupées russes)

  • Flick:

    Super article
    Je partage complètement.

  • LAUR:

    4 Bonnes pratiques pour déployer un référentiel d’architecture du SI

  • ouzdagreat:

    Bonjour,

    Je suis en alternance et novice en cartographie et j’ai un projet où je suis sensé faire une carto de: tous les serveurs du SI, les VM de chaque serveur et les services de chaque VM. C’est une carto donc à granularité avec des niveaux différents et je ne sais pas comment m’y prendre quant à l’outil à utiliser, et surtout les méthodes. Je ne sais pas s’il faut séparer les niveaux et faire trois cartos différents ou pas.

    Je vous remercie d’avance de votre apport

  • cardane:

    Bonjour,

    Je ne suis pas du tout d’accord avec cette description. Architecte d’Entreprise et Urbaniste depuis des années, je fais une distinction bien stricte entre une CMDB et un référentiel d’architecture. L’analyse d’impact, les contrats, les SLAs, les composant logiciels, etc, doivent se gérer dans une CMDB (et outils associés). Utiliser un ADDM correctement configuré et géré permettra de faire cela facilement, et l’analyse d’impact en cas de panne d’un serveur, par exemple, sera gérée directement par l’équipe ITSM. Pour ce faire, un référentiel d’architecture doit être en mesure de pousser de l’info vers la CMDB et réciproquement. Si un référentiel d’architecture est considéré comme un outil opérationnel, pour moi c’est une erreur. C’est un outil de travail, un outil décisionnel, et un outil de gestion de l’évolution, mais pas un outil opérationnel.
    Donc pour répondre à la question ci-dessus de Ouzdagreat, pour moi le serveurs, VM, etc, ca doit se retrouver dans la CMDB. Eventuellement on importe tout ca dans le référentiel d’architecture et on s’amuse à faire une carte jolie avec de beaux schémas, qui seront faux dès qu’ils seront imprimés :-)

  • Jacob:

    Bonjour,

    Nouvellement promu RSI, j’essaie de me former aux bonnes pratiques de gestion du SI. J’aimerais particulièrement réaliser un référentiel d’architecture du SI, mais je ne comprend pas la différence entre processus métier et architecture fonctionnelle. Auriez vous un exemple ?

    • Olivier Catelin:

      Bonjour Jacob, mieux vaut tard que jamais :(
      Un règle simple à retenir est celle des 3P => Process, People, Product.
      Pour fonctionner un Process a besoin de Personne (les People) qui l’execute et qui s’appuie sur des solutions (les Products).
      L’architecture fonctionnelle décrit les fonctions offertes par la solution IT pour executer ce process (ce sont les features de la solution).
      En espérant avoir répondu
      Olivier

Laisser une réponse à ouzdagreat