Styles

dimanche 3 août 2008

Architecture des Systèmes d'Information et le framework de Zachman

Le système d'information d'entreprise est apparu petit à petit dans l'entreprise, simplifiant certaines tâches répétitives ou compliquées. Bien qu'on pourrait croire qu'elle est issue d'une volonté forte des directions des entreprises, elle a souvent été introduite par de véritables passionnés, des amateurs qui, de leur poste de travail, ont su voir des applications novatrices de l'ordinateur.

Il n'est pas rare de rencontrer encore aujourd'hui des systèmes construits il y a fort longtemps, et maintenus jusqu'à aujourd'hui. C'est souvent le cas dans le monde de la banque ou dans les gros systèmes d'informations comme, par exemple, celui de France Telecom.

Quand l'informatique ne fait pas parti de la stratégie de l'entreprise, elle s'immisce petit à petit dans son environnement, jusqu'à contrôler des parties vitales de son l'activité.

J'ai vu en 1993, dans une entreprise de l'industrie chimique, un système construit de toute pièce par un enthousiaste de l'informatique. Le système a évolué du simple programme de suivi de l'activité d'une vanne au contrôle total d'une chaîne de production chimique de l'usine. Seules une ou deux personnes connaissaient le fonctionnement du logiciel (pas de documentation, pas de formation du personnels à l'informatique). Les personnes en charge de l'ouverture/fermeture des vannes se tournaient les pouces toute la journée, n'ayant plus d'opération à réaliser à la main.

On ne sait jamais ce que va devenir du code que l'on produit dès qu'on le lâche dans un environnement (une entreprise, sur internet...). Les entreprises ont voulu maîtriser leur informatique. Est apparu alors ce que l'on appelle "l'Architecture des Systèmes d'Information" qu'on rencontre aujourd'hui sous le nom de Architecture d'Entreprise, Urbanisme...

Nombre de méthodes et de cadres de travail sont apparus au cours du temps, et ce, depuis des lustres. L'un des travaux les plus intéressants a été la définition d'un cadre de définition d'une architecture d'une système d'information par J. A. Zachman, aussi nommé le "Zachman Framework". Le but était de trouver un cadre de travail pour cerner complètement l'ensemble des aspects d'une architecture d'un système d'information, sans contraindre les méthodes de travail.
On peut dire que Zachman a emprunter la méthode du reporter, du journaliste d'investigation. Pour tout système à analyser, il faut se poser les questions : quoi, comment, où, qui, quand, pourquoi (What, How, Where, Who, When, Why). En partant de ces différents aspects, il étudie le système à tous les niveaux de détail : de la stratégie d'entreprise à l'implémentation en passant par la conception, la construction...

En fait, il construit une sorte de hiérarchie de vues basée sur les différents métier de l'entreprise : Planner, Owner, Designer, Builder, SubContractor, Functioning Entreprise. Ce qui est vraiment intéressant avec ce cadre, c'est que les vues métier découlent les unes des autres : La vue Owner découle de ce qui a été défini au niveau de la vue Planner, la vue Designer découle de la vue Owner, etc.

En France, il n'y a pas eu de cadre comme le Zachman Framework mais une méthode très générique de spécification d'un système d'information d'entreprise : Merise. Cette méthode a défini différent modèles (MCD, MPD, MCT, etc.) qui se retrouvent dans le framework de Zachman. Merise a eu beaucoup de succès en son temps, mais il faut dire qu'aujourd'hui, seul le MCD/MLD ont réussi à résister au temps (même si on appelle aujourd'hui MPD alors qu'il s'agit la plupart du temps du MLD défini dans Merise).

Le temps passe, des méthodes apparaissent et disparaissent... Mais il faut bien séparer plusieurs notion :
- un cadre de travail : vision de l'architecture d'entreprise indépendante de la méthode de travail (par exemple : Zachman Framework)

- une méthode de travail : offre une définition claire des tâches et processus de travail pour obtenir une définition de l'architecture d'entreprise (Merise).

- un répertoire de bonne pratique : pour l'organisation du SI ou pour travailler sur la définition du SI (par exemple ITIL, CMMi).
Toutes ces notions ne recouvrent pas les même objectifs, et sont donc souvent complémentaires : on peut utiliser le framework de Zachman, en définissant des modèles Merise (MCD, MPD) en suivant un processus de développement logiciel basé sur CMMi tout en structurant les services IT autour de la notion de client/contrat : ITIL.

Il est rare de voir les entreprise adhérer à tous les concepts portés par ces notions. Le poids de l'existant est souvent trop lourd à porter. En effet, dès que le nombre de personnes entrant et sortant de l'entreprise est faible (le turnover), les personnes se mettent à travailler selon un schéma plus ou moins efficace mais avec une très forte inertie.

Et puis, il est plus risqué dans une grosse entreprise de faire les choses différemment plutôt que de faire comme tout le monde fait depuis des années sans se poser de questions. Les méthodes et cadres ont l'avantage de provoquer le personnel des entreprises en confrontant une vue "idéale" au monde des processus réels de l'entreprise.

Aucun commentaire: