Architecture et crise

 

Architecture et crise

DATE DE CREATION : 09/09/2008

 

Que fait l’architecte en période de crise…

Pour tenter de répondre à cette question, il convient de préciser ce qu’est l’architecture en se basant sur un modèle connu et reconnu des professionnels du SI.

Le modèle de « Zachman » décrit les différents objets qui composent le SYSTEME de l’entreprise. En se limitant au SI, il décrit les objets qui composent le SI et les entités qui interagissent avec ces objets et les classe en 5 couches (du contexte,… , au physique).

 

« Architecturer », c’est donc structurer et organiser les objets du SI en se basant sur le modèle ci-dessous. En fonction de la maturité des entreprises et de la politique mise en œuvre sur le sujet « Architecture » dans les années passées, ce modèle est plus ou moins bien implémenté tant en terme de concepts que de pratiques.

 

 

 

 

Interviewer 5 DSI ou 5 architectes pour décrire ce qu’est « l’Architecture », vous obtiendrez 10 réponses différentes. Pourquoi ? Parce que chacun en fonction de sa sensibilisation et/ou de sa connaissance du sujet va décrire une sous-partie du modèle comme étant de l’architecture. Le débutant qui aura mis en place une cartographie applicative déclarera avoir architecturé son SI, le MOA qui aura mis en place une certification ISO de ses processus déclarera également avoir architecturé son SI. Celui qui aura mis en place un service SOA dira que son application est architecturée.

 

Tenter de répondre à la question « Que fait l’architecte en période de crise… », c’est donc s’exposer à avoir autant de réponses que d’acteurs qui vont répondre à la question.

 

Supposons le scénario ci-dessous dans lequel :

-          des sous-parties du modèle ont déjà été implémentées,

-          les liens entre ces sous-parties n’existent pas.

 

Une partie « Function » pour la modélisation des « processus métier »

(0)

 

 

Une partie « Data » et « Function » pour la modélisation fonctionnelle du SI

(a)

 

 

Une partie « Data » pour la modélisation physique des tables des bases de données applicatives
(b)

 

Contexte :

Ces parties ont été mises en place séquentiellement, par opportunité, sans avoir eu une stratégie globale de mise en œuvre et la conjoncture fait que l’entreprise limite ses investissements en ne consacrant du budget qu’aux applications informatiques majeures.

 

Une des pistes possible pour continuer à implémenter le modèle d’architecture, c’est par exemple de focaliser son travail sur :

- une partie « Data » au niveau « Owner » pour faire en sorte de définir le modèle sémantique des données de l’entreprise. Ce travail consiste à décrire toutes les données « référentielles » utilisées dans l’entreprise et à les relier entre elles dans un MCD (Modèle Conceptuel de Données).

 Une fois ce modèle défini, il convient de définir les liens entre ce modèle (c) et les modèles précédemment mis en place (a) et (b), puis veiller à ce que chaque nouvelle implémentation physique de donnée dans une application informatique respecte les 3 modèles décrits (d).

(c)

(d)

 

Un exemple concret pour illustrer le cas décrit :

Une application informatique décrivant l’organigramme Rh de l’entreprise a été mise en place, elle a fait l’objet d’une étude fonctionnelle lors de sa mise en œuvre.

(a)    : un MCD décrit les données qu’elle gère, les fonctions qu’elle automatise sont décrites.

(b)    : le modèle de données physique décrit toutes les tables et les données gérées par l’application.

La décision de mettre en place une nouvelle application a été prise sans vision d’architecture « globale ». Cette application doit permettre de décrire ce que font les acteurs de l’entreprise dans différents processus pour optimiser leur travail respectif.

 

Le travail de l’architecte va consister à :

(c)    : compléter le modèle des données « référentielles » concernées par le projet

è les données « Fonctions » organisationnelles et « Postes » associés doivent être décrites (type, format, sémantique),

(d) : vérifier l’utilisation de ces données dans le SI

è les applications qui utilisent ces données doivent être recensées

è les données utilisées doivent être énumérées en termes d’utilisation (contextes applicatifs) et de diversité (différents formats)

 

En ce qui concerne la mise en place de la nouvelle application, l’architecte devra faire en sorte :

-          que la donnée utilisée pour décrire les processus soit la donnée « Fonction » décrite ci-dessus (ne pas autoriser la saisie d’une autre donnée sans contrôle),

-          qu’elle soit réutilisée soit par recopie en respectant le format et le contenu (règles documentaires liées au processus de mise à jour), soit par flux automatisé (fichier ou service),

-          que l’équipe projet respecte l’ensemble des contraintes d’architecture définies pour garantir la cohérence du SI.

 

« Que fait l’architecte en période de crise… » ?

En considérant l’article ci-dessus, il doit :

-          analyser ce qui est mis en place dans son entreprise au niveau de l’architecture à partir du modèle de Zachman,

-          identifier tous les sujets « business » et « SI » associés qui sont jugés fondamentaux pour l’entreprise et qui vont être mis en places dans les années futures,

-          connaître la politique et la stratégie d’architecture de son entreprise (axes prioritaires à mettre en place dans le triennal),

-          saisir toute opportunité se présentant pour développer les sous-parties et/ou les liens entre sous-parties du modèle,

-          veiller à ce que toutes évolutions du Business/SI respectent les parties du modèle déjà implémentées.

Et ce, pour assurer la cohérence (non redondance) et la flexibilité du SI (évolutivité) qui sont les 2 raisons pour lesquelles l’architecture contribue à la performance d’une entreprise.

 

© Thierry BEL