Formation initiale sur l'essentiel du management des systèmes d’information enjeux et pratiques
4.1 LE RÉFÉRENTIEL D'ARCHITECTURE
4.1.1 Le référentiel et I'ADM
Le référentiel d'architecture occupe une place centrale dans TOGAF, comme instrument de capitalisation, réutilisation et structuration des informations. L'objectif consiste à retrouver les pratiques accumulées au cours des cycles ADM précédents, de façon à constituer progressivement un patrimoine disponible pour toute l'entreprise. De ce point de vue, le cycle ADM TOGAF peut être considéré de deux manières : d'une part, comme un fournisseur d'informations qui alimente le référentiel au fur et à mesure de sa construction, et d'autre part comme un consommateur qui puise dans le référentiel les éléments en fonction de ses besoins.
Figure 4.1 — ADM et référentiel d'architecture (source : O 2008, The Open Group)
Pratiquement, à chaque fin de phase, certains éléments sont sélectionnés pour alimenter le référentiel. Ce cercle vertueux enrichit le savoir-faire de l'entreprise et contribue à minimiser les risques et les coûts par une réutilisation des façons de faire et des structures architecturales.
4.1.2 La structure du référentiel
Le référentiel contient des éléments divers comme des modèles, patterns, descriptions d'architecture ou livrables issus de précédents travaux, mais aussi des éléments externes issus de standards ou d'autres organisations.
TOGAF propose un partitionnement du référentiel qui se décompose de la façon suivante :
Figure 4.2 — Structure du référentiel d'architecture
4.1.3 Le paysage
Le paysage (landscape) contient les modèles de l'architecture existante, sur l'ensemble de l'entreprise. Son contenu varie d'une entreprise à l'autre. Les modèles que l'on retrouve les plus fréquemment portent sur les processus métier, les applications et les données.
Cette vision de paysage de l'architecture se retrouve dans les approches de type « urbanisation » qui se sont développées ces dernière années2. La cartographie des applications par exemple comprend l'ensemble des applications et leurs relations (flux inter-applicatif). Ce modèle est indispensable à la compréhension globale du système, et constitue un instrument majeur du pilotage de ses évolutions.
Son contenu est naturellement en constante évolution, en fonction des transformations de l'architecture.
4.1.4 Plan de classement : continuum d'architecture
Le rôle du continuum d'architecture « Architecture continuum » (partie V du document TOGAF) est de proposer un plan de classement du référentiel d'entreprise, qui porte plus précisément sur la partie « bibliothèque de référence ». Celle-ci joue en effet un rôle majeur comme réceptacle et base de réutilisation dans le cadre de l'exécution d'un cycle ADM.
Ce plan de classement comporte quatre types d'éléments, classés suivant un niveau d'abstraction décroissant les fondations, les systèmes communs, les architectures spécifiques à un domaine, les architectures spécifiques à l'entreprise. « Architecture foundation, Common system architecture, Industry architecture, Organization-specific architecture".
Le terme « continuum » d'architecture caractérise le type de découpe utilisé, qui partitionne les éléments du plus général au plus particulier : respectivement de l'architecture de fondation jusqu'aux architectures spécifiques.
Ajoutons que comme pour les building blocks, deux types d'éléments coexistent au sein de cette classification : La partie « Architecture » et la partie « Solution ». Cette dernière (Solution) étant la traduction physique de la première. La spécification d'un outil de workflow par exemple, sera positionnée dans la partie « Architecture ».
Celle-ci décrit les fonctions, les modes d'utilisation, les composantes qu'un outil de cette catégorie doit fournir. En revanche, un outil du marché, recommandé par l'entreprise aura sa place dans la partie « Solution ». On aboutit ainsi à un double plan de classement, illustré par la figure 4.3.
…
4.1.5 Les modèles de référence TOGAF®
Dans sa partie VI (TOGAF reference models), TOGAF présente deux exemples détaillés d'élément du continuum d'architecture : le TRM (Technical Reference Model) et le III-RM (Integrated Information Infrastructure Reference Model).
Le TRM (Technical Reference ModeD
Le TRM se positionne comme une architecture de fondation au sein du continuum d'architecture. Il définit les constituants d'une infrastructure de système informatique, en fournissant une terminologie, une structure et des règles d'interconnexion entre les différents composants. La figure 4.4 présente cette structure.
Le TRM se décompose en plusieurs niveaux, de l'infrastructure de communication jusqu'aux applications. Les applications s'appuient sur une interface dédiée, la plate-forme de services applicatifs (Application Pleform Interface), qui offre une collection de services communs utilisés par l'ensemble des applications du système (IHM, sécurité, transaction, etc.). Ces services communs sont construits sur deux couches de plus bas niveau : la gestion du réseau et le système d'exploitation.
Le III-RM (Integrated Information Infrastructure Reference Mode!)
Ce deuxième modèle de référence peut être considéré comme un sous ensemble du premier (le FRM), focalisé sur les applications, en détaillant les éléments suivants :
Figure 4.4 — Structure du TRM (Technical Reference Model) — TOGAF9® (source : © The Open Group)
L'accent est mis sur la recherche de mutualisation et le partage d'information par la mise en place d'interfaces entre fournisseurs et consommateurs de services, qui se rapproche de la vision SOA (architecture orientée service).
Ces deux modèles de référence sont avant tout des exemples de ce que l'on peut trouver dans le référentiel d'architecture, dans sa partie « bibliothèque de référence ».
Dans une première approche de TOGAF, ils pourront être simplement survolés, et repris dans le cadre d'un démarrage réel d'un chantier d'architecture, ou lors de la constitution du référentiel d'architecture.
4.1.6 L'outillage du référentiel
Il est difficile de concevoir un tel référentiel sans un outillage. Le choix de cet outillage fait partie des actions prévues dans la phase préliminaire de l'ADM (si celui-ci n'est pas déjà en place). Un chapitre de TOGAF est par ailleurs consacré à cette question'.
Le choix entre le « tout en un » ou la suite d'outils reste une question coutumière dans ce type de contexte.
Si le référentiel prend en compte toutes les fonctions prévues, il va être difficile de trouver l'outil unique qui va correctement répondre aux besoins. En effet, le référentiel doit comprendre aussi bien des modèles structurés, des documents, des composants logiciels, des éléments de suivi ou de communication.
Par ailleurs, il est nécessaire de distinguer les deux facettes du référentiel : la facette « construction » et la facette « communication ». Il n'est pas certain que l'outil utilisé pour la construction du référentiel soit parfaitement adapté pour la diffusion des informations. Pour ce qui concerne les modèles, on observe fréquemment un choix d'outil différent entre l'élaboration et la communication : les modèles sont construits à l'aide d'un outil de modélisation, qui est à même d'offrir une interface adaptée aux concepteurs et architectes ; en revanche, les modèles sont consultés à travers un intranet, qui procure un cadre homogène de navigation, plus simple à utiliser et indépendant du poste de travail. Dans ce cas de figure, il est nécessaire de s'assurer que l'outil de modélisation permet d'exporter ses modèles vers un environnement de type web 1 .
4.2 LA GOUVERNANCE DE L'ARCHITECTURE
4.2.1 La gestion de l'architecture
Comme toute activité de l'entreprise, la gestion de l'architecture d'entreprise demande la mise en place d'une organisation particulière : règles de gouvemance, processus, rôles et responsabilités, outillages. C'est l'objet de la partie VII de TOGAF « Architecture Capability Framework », qui décrit quelles sont les capacités nécessaires pour la gestion d'une architecture d'entreprise. Les principaux points abordés sont les suivants :
Fondamentalement, la gouvernance de l'architecture s'applique sur deux volets :
=11 ____ Chapitre 4. Le référentiel et la gouvernance
Cette double facette répond à une difficulté bien connue : comment traduire les objectifs généraux au niveau des différentes entités parties prenantes de la transformation. Les organisations complexes se constituent naturellement en entités qui doivent répondre à des objectifs propres, qui sont parfois perçus comme antinomiques avec les objectifs stratégiques.
Face à ce constat, plusieurs types de réponses sont nécessaires : la mise en place d'une organisation dédiée et centralisée (le comité d'architecture), un mode de gouvemance contractualisé, et une écoute de la réalité du terrain.
4.2.2 Le comité d'architecture
L'architecture d'entreprise par nature demande une organisation centralisée. Ce constat n'interdit pas des délégations opérationnelles ou un certain degré de fédéralisme, mais nécessite un centre décisionnel : c'est le rôle du comité d'architecture, responsable auprès de la direction de la conformité des implantations au regard des principes et des décisions relevant de l'architecture d'entreprise. Il assure également la gestion du référentiel d'architecture, et se positionne comme garant de sa cohérence et de la qualité de son contenu.
Combien de membres dans un comité d'architecture ? Il est recommandé de limiter le nombre (moins de dix) de façon à préserver son efficacité et sa réactivité. Un certain degré de rotation favorisera son dynamisme, cependant, un coeur stable sera préservé pour assurer la pérennité des actions à long terme.
Organisme transverse, responsable devant la direction, ses principales fonctions sont les suivantes :
Qui participe au comité d'architecture ? Certes des architectes expérimentés, mais pas seulement. Inclure des responsables de haut niveau facilitera l'obtention de consensus, qui reste un objectif majeur. Par ailleurs, en fonction de la nature des travaux, le comité d'architecture pourra se faire assister sur des sujets particuliers.
4.2.3 Le contrat d'architecture
Le contrat d'architecture établit les relations entre le comité d'architecture et toutes les parties prenantes impliquées dans le cadre d'un chantier d'architecture. Il formalise les attentes, les contraintes, les objectifs à respecter ainsi que les moyens de mesures appropriés.
Le contrat intervient à plusieurs points du cycle ADM :
Activité majeure du comité d'architecture, les revues de conformité permettent d'évaluer l'adéquation des solutions vis-à-vis des règles générales et des contrats passés avec les projets de mise en oeuvre. Les revues sont réalisées à l'aide de listes de contrôle précises, de façon à objectiver les résultats.
TOGAF fournit un exemple de liste de contrôle détaillée de près de 200 questions types, organisées en huit thèmes majeurs1 :
L'organisation de ces revues est également détaillée sous la forme d'un processus dédié, qui explicite la démarche et le rôle de chaque intervenant.
4.2.5 La « bonne » gouvernance
Tous ces points que l'on vient d'aborder constituent la base de travail dans la mise en oeuvre d'une gouvernance de l'architecture d'entreprise. Cependant, sa concrétisation se heurte à certaines difficultés. Nous avons évoqué plus haut la principale d'entre elles : la dichotomie entre la vision stratégique et la réalité des équipes de terrain. Une organisation « désincarnée » et inaccessible, coupée des unités opérationnelles ne fera que conforter cette tendance.
Une approche plus pragmatique favorisera une collaboration plus étroite du comité d'architecture avec les équipes. Par exemple, la participation active des architectes d'entreprise dans l'élaboration des choix, sans se limiter à un rôle de validation a posteriori. Cette participation peut aller jusqu'à l'intégration temporaire d'architectes d'entreprise au sein des équipes. Cette organisation apporte deux avantages : d'une part, le chef de projet trouve un intérêt dans le renforcement de son équipe sans grever son budget. D'autre part, le retour d'expérience vers le comité d'architecture, qui peut s'adapter et réagir en temps réel en fonction des réalités du terrain.
Une communication efficace constitue l'autre axe de travail. Un soin particulier doit être apporté à la diffusion des éléments stratégiques dans le référentiel d'architecture. La qualité des informations (lisibilité, disponibilité, pertinence, structure) conditionne l'efficacité de son utilisation. Patterns, guides, méthodes, exemples, seront d'autant plus acceptés s'ils fournissent une réelle valeur ajoutée et une aide concrète aux équipes opérationnelles.
Plus généralement, trouver les moyens pratiques pour rapprocher les points de vue est essentiel pour atteindre des résultats probants. Un véritable engagement des architectes d'entreprise dans les projets opérationnels y contribue largement : il s'agit de passer d'un mode purement contractuel à une collaboration plus dynamique.
Techniques clés de lamodélisation
Objectif
Comprendre l'intérêt et l'usage des modèles : TOGAF met un accent particulier sur les modèles et sur la construction d'un référentiel. Les langages de modélisation aident en effet à mieux formaliser les connaissances, analyser les problèmes et concevoir les solutions. Mais ils constituent une boite à outil dont il faut connaître l'usage, les bénéfices potentiels, et les limitations.
5.1 LES MODÈLES INTÉRÊTS, USAGES ET CARACTÉRISTIQUES
5.1.1 Définition
Qu'est-ce qu'un modèle ?
Selon TOGAF, un modèle est une représentation d'un sujet particulier. Le modèle fournit cette représentation sur une échelle réduite, d'une manière simplifiée ou plus abstraite, relative au sujet concerné. Dans le contexte de l'architecture d'entreprise, le sujet est l'entreprise ou certaines de ses parties. La finalité du modèle est l'élaboration de vues qui adressent les préoccupations des parties prenantes : leurs points de vue sur l'entreprise.
La notion de modèle peut être considérée de manière restrictive, le modèle étant constitué et limité à ce qui a été formalisé dans le référentiel de l'atelier de modélisation.
Elle peut être vue de manière plus extensive, le modèle incluant alors tous les éléments informels rassemblés lors de l'effort d'architecture d'entreprise : textes, graphiques, etc.
Un besoin universel
Le besoin de réaliser des modèles est universel, bien au-delà des organisations d'entreprises et des SI. On ne peut ainsi imaginer l'absence de modèles dans le domaine du bâtiment, où il faut des plans pour définir la construction, pour coordonner les problèmes des différents corps de métier, et pour définir les interventions de chacun. Les modèles dans ce domaine ont une dimension juridique, pour l'autorisation de permis de construire, pour des déclarations de surfaces imposables, ou encore pour des aspects contractuels entre le client, le maître d'ouvrage et le maître d'oeuvre. Les plans et cartes géographiques constituent un autre exemple de modèles d'une impérieuse nécessité, dont on n'imagine pas pouvoir se passer. Dans la majorité des domaines, des modèles dédiés ont ainsi été définis et se sont imposés : la mécanique, l'architecture des bâtiments, la CAO, l'avionique et l'électronique n'en sont que quelques exemples.
Si la nécessité des modèles est bien universelle, l'architecture d'entreprise et l'informatique apportent cependant des difficultés particulières, qui ont retardé et amoindri leur mise en oeuvre. Ces deux domaines sont immatériels, de nature théorique, et sont alors plus difficiles à représenter que des domaines plus concrets. Ainsi, si la représentation d'un plan de bâtiment ne pose pas de problèmes d'interprétation (tout le monde comprend ce qu'est un mur, et que celui-ci est représenté par un trait plein), il n'en va pas de même dans notre domaine : comment représenter un concept, un état, un événement, une application, une fonction ? Il faut figer des conventions dans le domaine, qui de par leur technicité ne seront pas aussi universellement partagées que celles d'un plan de bâtiment. Les normes de modélisation ne se sont stabilisées que dans la dernière décennie, ouvrant enfin la voie à un support standardisé pour bâtir des modèles d'architecture d'entreprise.
Historique
Dans le domaine de l'informatique, les modèles sont apparus dès l'origine, et ont connu une forte évolution dans les années 1980. On peut affirmer que les techniques essentielles de modélisation étaient connues dès le début des années 1990. Cependant, il existait une grande hétérogénéité des modèles, un fort cloisonnement des modèles par pays et par sous-domaine de l'informatique, ainsi qu'une coopération entre ces modèles non aboutie (Merise était une méthode et un modèle spécifique à l'informatique de gestion en France, la méthode Yourdon était très présente dans le monde anglo-saxon, le modèle IDEFO était répandu dans les systèmes techniques, les premiers modèles objet étaient très éparses et spécialisés, etc.). Les années 1990 ont vu naître les standards de modélisation (UML, puis BPMN) qui ont permis d'harmoniser les techniques de modélisation.
Les architectures types ont également évolué, leur aboutissement dans les systèmes d'information étant l'émergence des architectures SOA. Les années 2000 ont permis la maturation et la stabilisation des standards UML et BPMN, ainsi que leur déclinaison pour des applications particulières (par exemple, SysML pour les grands systèmes). Le domaine de l'architecture d'entreprise qui a progressivement émergé depuis les années 1990, peut s'appuyer sur ces standards, pour modéliser l'entreprise dans son ensemble. TOGAF recommande ainsi l'usage de UML et BPMN. Cependant, TOGAF a son propre métamodèle. Un architecte qui doit modéliser doit au préalable définir la manière d'utiliser UML pour TOGAF, et comment mettre en correspondance tes concepts UML et les concepts TOGAF. L'objectif du cparagraphe suivant est de fournir une réponse à cette question.
5.1.2 Utilité d'un modèle
Comprendre, réfléchir sur un problème
Les modèles sont utilisés pour répondre à plusieurs types de besoins. En formalisant les connaissances, ils permettent de comprendre et d'éclaircir un problème. Avec les modèles, les différents constituants d'un domaine d'étude sont représentés, différents types de liaisons permettent de les positionner, et ces constituants sont valorisés en leur affectant des propriétés. Les modèles constituent alors un support à la réflexion, et sont enrichis par les résultats de celle-ci. En matérialisant la compréhension d'un problème, un modèle décrira à la fois le contexte, le domaine ciblé, et reflétera l'intention, le projet de construction qui est imaginé.
Les modèles sont ainsi au service de deux activités essentielles : l'analyse et la conception. L'analyse précise la description du problème, et détaille les points où il faut intervenir. La conception s'attache à la solution, en décrivant comment le problème sera résolu, par quelles techniques et par quelles activités.
Communiquer, partager, collaborer
La communication est une nécessité première au sein des entreprises, pour laquelle les modèles offrent un support important. Les entreprises utilisent les modèles pour représenter leur organisation. Ceux-ci servent d'une part à cartographier les éléments de l'entreprise, comme les rôles dans l'entreprise, les sites, les processus métier, les ressources matérielles, les applications, et d'autre part à détailler ses constituants et son fonctionnement comme le déroulement d'un processus métier. Cartographier consiste à répertorier, classifier et positionner l'existant, pour partager sa connaissance et permettre à chacun de situer les constituants d'une carte.
De même que le plan du métro de Paris facilite son emploi par les usagers et est un support de réflexion pour ses évolutions par ses concepteurs, les destinataires de schémas de données savent, par exemple, comment exploiter les données ou comment les enrichir.
Les modèles facilitent également le dialogue entre des expertises différentes dans l'entreprise, comme typiquement entre MOA et MOE, ou encore entre utilisateurs et analystes métier. Ainsi, les modèles peuvent servir à représenter les besoins métier des utilisateurs, puis ils sont ensuite codifiés de manière précise pour préparer le travail des architectes et concepteurs.
Les modèles servent ainsi à partager une connaissance, et à collaborer à sa construction. Un travail collaboratif peut en effet s'appliquer sur les modèles qui sont enrichis par la contribution de chacun tout en étant partagés. Il s'agit typiquement d'un travail d'ingénierie, consistant à bâtir et consolider des modèles.
La modélisation des connaissances sur le métier, sur l'organisation, sur les processus et sur le SI permet de constituer un patrimoine pour l'entreprise pouvant être réutilisé et exploité de multiples façons. Ce partage de connaissance a une utilité dépassant les frontières d'une entreprise, puisqu'il autorise une meilleure formalisation des coopérations et échanges entre entreprises, partenaires et clients. Enfin, les modèles permettent de réutiliser des solutions métier préexistantes, en alignant le modèle d'architecture d'entreprise sur des modèles métier partagés, comme cela existe dans le domaine de l'assurance ou dans certains métiers bancaires. Cet alignement facilite également une meilleure garantie du respect de normes et standards métier imposés. Il peut s'agir par exemple des informations à conserver ou des procédures à respecter.
Prévoir, simuler
Très utilisés dans toutes sortes de projets d'ingénierie, les modèles sont également exploités pour prévoir et simuler le comportement du système à réaliser, mais aussi les travaux de construction du système. Le modèle, en fournissant une vision d'ensemble, permet plus facilement d'appliquer des changements selon une stratégie particulière. On peut aussi tester des hypothèses, imaginer des variantes : ces activités ne peuvent, en effet, pas être envisageables lors de la réalisation effective du projet, du fait de leur lourde charge en coûts et délais. Par ailleurs, les modèles sont fréquemment utilisés pour identifier des lots de travail au sein d'un projet, afin de déléguer et suivre ces travaux.
Produire
Il est des domaines, comme la CAO ou l'informatique, où les modèles permettent également de guider, contrôler et automatiser la production. Ainsi, en CAO mécanique, la modélisation des pièces permet de définir des systèmes complexes, de fournir des cahiers des charges précis aux sous-traitants, et d'automatiser la construction des pièces en atelier. L'informatique utilise les modèles aussi pour générer automatiquement des productions informatiques plus détaillées : par exemple du code, des schémas de base de données ou des documents.
Lors de leur évolution au cours du temps, depuis la vision vers la réalisation, les modèles deviennent de plus en plus précis, formels, pour guider voire automatiser le travail des architectes, concepteurs puis développeurs.
L'inconvénient de cette approche est que dès lors qu'un modèle est suffisamment précis pour être exécutable, il devient beaucoup moins utile pour comprendre et raisonner sur les systèmes complexes. L'architecture d'entreprise est davantage centrée sur la spécification et la conception que sur la construction. Elle requiert des modèles moins précis et formels.
5.1.3 Caractéristiques des modèles Abstraction
Les modèles offrent des mécanismes d'abstraction, permettant de raisonner à des niveaux plus macroscopiques, en agrégeant des éléments détaillés, en ne révélant que les parties significatives, ou en généralisant des notions et mécanismes. L'abstraction permet de gérer la complexité, qui est un frein important dans les entreprises. La complexité cause en effet la léthargie et l'inertie qui empêchent beaucoup d'entreprises d'être réactives. Quand le nombre d'applications dans une entreprise se chiffre en milliers, le nombre de référentiels en dizaines, le nombre de processus en centaines et donc le nombre de types de tâches en milliers et quand le volume de code des applications se chiffre en millions de lignes de code, le problème de complexité lié au volume et à la diversité se pose de manière criante. L'abstraction est rendue nécessaire pour des besoins primaires de gestion, de classification, et des besoins plus sophistiqués de mutualisation, de rapprochement, de rationalisation. Pour des raisons de pédagogie, l'abstraction est également utilisée pour adapter les niveaux de détails présentés selon les interlocuteurs.
Nous verrons que les modèles pour TOGAF seront structurés en points de vue différents, dédiés à des parties prenantes spécifiques. De ce fait, le niveau d'abstraction doit être défini en détail selon les objectifs et les parties prenantes ciblés par le modèle.
Standardisation
L'intérêt des modèles est décuplé par leur standardisation : celle-ci assure une notation unique, connue de tous, partagée entre tous les pays et pour tous les domaines connexes de l'architecture d'entreprise (organisation, processus métier, données, applications) et de l'informatique ; elle fournit une sémantique — c'est-à-dire une définition de l'ensemble de ses termes, mécanismes et constructions — formellement élaborée, limitant ainsi les interprétations que l'on peut avoir d'un modèle ; elle garantit un marché à un grand nombre d'outils associés (modélisation, génération...) ; elle permet une interopérabilité entre ateliers de modélisation évitant ainsi d'être prisonnier d'un atelier particulier. Les modèles réalisés pour l'entreprise ont alors une valeur patrimoniale augmentée par le fait qu'ils sont exploitables par un très grand nombre de personnes et d'outils.
Cependant, les modèles tels que UML et BPMN sont une boîte à outils très vaste. Il revient alors à chaque organisation de définir ses conventions, quelles parties de ces modèles sont utilisées et à quelles fins, quelles extensions sont apportées. Le présent ouvrage fournit ainsi un exemple de conventions et d'extensions pour TOGAF. La mise en place de ces conventions facilite le travail des intervenants, le partage d'informations et la construction d'un référentiel commun. De par la définition même de ces conventions et extensions d'UML et BPMN, nous introduisons des extensions et adaptations de TOGAF, conformément à ce qui est indiqué dans le chapitre sur la phase préliminaire.
Modèles informels ou formels
Les modèles informels n'obéissent pas à un formalisme rigoureux. Ce sont souvent des graphiques libres, des supports aux idées, des moyens de communication spontanés. Ils sont naturellement utilisés lors de réunions de travail et sont des facilitateurs de communication spontanée. Dans les phases initiales d'analyse, lorsque les données du problème ne sont pas clairement établies et qu'il faut bâtir un consensus pour cadrer le domaine d'intervention et les travaux à effectuer, ou lorsqu'il faut communiquer avec des interlocuteurs non avertis des modèles utilisés, les modèles informels peuvent être utilisés.
En phase A (vision), ces modèles informels peuvent par exemple être utilisés pour produire des diagrammes de solution conceptuelle ou des diagrammes de chaîne de valeur. Ils serviront alors de base à la construction de modèles « formels » plus précis et gérés par des ateliers de modélisation.
Par contre, lorsque l'on progresse vers la solution technique, les modèles doivent être plus précis, et fournir un grand niveau de détail sur le fonctionnement de la solution. On aboutit ainsi à des modèles plus formels, décrivant en détail la structure des données, ou la logique d'enchaînement des activités dans un processus. On s'adresse ici à des interlocuteurs plus avertis, ce qui autorise l'usage de modèles plus techniques. Les phases d'élaboration de l'ADM exploiteront ainsi davantage les modèles formels. Le point de vue associé au modèle détermine le domaine, la portée, l'horizon temporel et le niveau de détail du modèle.
5.1.4 Limitations des modèles
Le modèle n'est qu'un constituant au sein de TOGAF, le point majeur étant le cycle ADM. L'ADM fournit les processus et activités qui produisent et consomment les modèles, et qui motivent leurs évolutions dans le temps pour des objectifs déterminés. Le modèle est un outil qui doit être ciblé sur les usages pertinents dans le contexte de l'entreprise. Nous verrons en section 5.6 les limitations des modèles (incomplétude, difficulté de mise à jour, ...) qui nécessitent un calibrage et une gouvernante adaptés.
Par ailleurs, les modèles ne fournissent pas les informations de contexte nécessaires à leur bonne compréhension : Pourquoi ce modèle est-il élaboré ? Quel problème veut-on traiter ? Comment sera-t-il exploité ? Leurs spécialisations à travers les différents artefacts TOGAF de nature « diagramme », et leur structuration en point de vue permettront de résoudre cedernierpoint : pour chaque utilisation de modèle dans un artefact TOGAF (voir chapitres 6 à 11), TOGAF et le point de vue affecté nous indiquent quelles grandes préoccupations sont ciblées, et à quels participants s'adressent les modèles.
5.2 NOTION DE POINT DE VUE
5.2.1 Angle de perception d'un problème
Les systèmes complexes impliquent la mise en oeuvre d'une grande variété d'expertises et de parties prenantes. Chaque expertise nécessite un angle de vision spécifique sur le système, et ne s'intéressera qu'à une partie de son modèle selon une représentation particulière. Cet angle de vision ciblé sur certaines catégories de parties prenantes constitue un point de vue sur le modèle.
La figure 5.1 illustre bien, dans le cas d'un bâtiment, la nécessité de différentes vues, selon les interlocuteurs et les problèmes à traiter. Face à un client, futur utilisateur, on privilégie les vues liées à l'esthétique et aux aspects fonctionnels, alors que face à des corps de métier différents, on élabore des vues traitant des problèmes les concernant (plan de structure, réseaux électriques, plomberie, etc.).
Figure 5.1 — Point de vue « technique » sur un bâtiment et point de vue « marketing »
Une problématique similaire existe pour les systèmes d'information. On peut par exemple s'attacher à l'ergonomie pour les utilisateurs, à la sécurité du système pour les responsables sécurité, au déploiement technique pour les administrateurs système, aux schémas de données pour les administrateurs de données et les concepteurs de base de données, aux processus métier pour les analystes métier ou à l'architecture technique pour l'architecture des services, etc. La figure 5.2 donne l'exemple d'un analyste métier considérant un modèle de processus et d'un architecte applicatif face à une architecture applicative.
Ceci conduit à déterminer un ensemble de points de vue dans l'entreprise, qui matérialisent à la fois les grandes familles de problèmes que l'on doit traiter et les interlocuteurs concernés. Déterminer les points de vue structure fortement l'organisation et les travaux à conduire, en configurant les types de problèmes à traiter et la nature des intervenants à impliquer. C'est pourquoi cette notion a pris une importance croissante dans les méthodologies modernes depuis les années
…
5.2.2 Vue et point de vue : Définition
Un des objectifs de l'architecture d'entreprise est de produire des représentations ciblant l'ensemble des préoccupations des parties prenantes. Ces représentations spécifiques des différentes préoccupations doivent être articulées entre elles, et refléter tous les compromis et ajustements gérant les conflits potentiels entre préoccupations (par exemple performance et sécurité).
Les points de vue constituent des perspectives que l'on peut avoir sur un système, selon les préoccupations essentielles des parties prenantes. Un point de vue s'attache ainsi à une ou plusieurs préoccupations, et donc aux parties prenantes que cela concerne, et définit un ensemble de conventions pour élaborer des vues adaptées.
Une vue est une représentation du système selon la perspective d'un ensemble de préoccupations (le point de vue). Une vue est ce que l'on voit d'un système particulier, alors que le point de vue est l'angle sous lequel le système est considéré. Le point de vue est défini de manière générique (en dehors d'un système particulier). La figure 5.3 montre deux points de vue et six vues, chacune étant relative à l'un des points de vues et toutes fournissant une représentation particulière d'un même système.
Points de vue
Figure 5.3 — Points de vue, vues et système
Les points de vues (ou préoccupations) que l'on peut avoir sur une entreprise et son SI peuvent être par exemple relatifs à :
Plusieurs vues existent en général pour chaque point de vue. Le chapitre 9 présente ainsi plusieurs vues relatives à l'architecture applicative.
