L’architecture d’entreprise en 4 frameworks

Le concept de framework n’a fait son apparition que dans la seconde moitié du 20^e siècle. Dans cet article, je souhaite me baser sur la définition de « framework » suivante :

« Un framework est la structure de base documentée et éprouvée d’une catégorie de systèmes similaires qui sert d’orientation tant dans la conception que dans l’évolution de ces systèmes. »

Un framework doit donc soutenir ses utilisateurs lors de la création initiale d’un système ainsi que dans le développement ultérieur de celui-ci. Dans le cadre de l’architecture d’entreprise, un « système » représente l’entreprise, composée de personnes, suivant un but précis, et assistée par des moyens techniques comme des systèmes informatiques. Ce qui est particulièrement important pour un framework d’architecture d’entreprise c’est qu’il est nécessaire qu’il soit applicable tout autant à l’activité de l’entreprise qu’aux outils techniques nécessaires à son fonctionnement.

Sur ce, je voudrais présenter brièvement quatre représentants typiques de frameworks d’architecture d’entreprise.

1. Le framework de Zachman

Un des premiers et des plus célèbres frameworks d’architecture d’entreprise est le framework de Zachman. En 1987 déjà, John Zachman développe la première version de son framework, aujourd’hui représenté sous forme de matrice composée de 6 colonnes et 5 lignes.

Source de l’image : Marcel Douwe Dekker based on earlier work of Phogg2 et al. (CC BY-SA 3.0)

Le framework de Zachman est un cadre réglementaire léger qui permet globalement de distinguer et mettre en lumière divers aspects d’une entreprise. Les colonnes structurent la vision d’une entreprise en 6 dimensions distinctes :

• Avec quoi travaille l’entreprise ? (quoi)
• Que fait l’entreprise ? (comment)
• Où se trouvent les activités de l’entreprise ? (où)
• Qui sont les exécuteurs de ces activités ? (qui)
• Quand sont exécutées ces activités ? (quand)
• Pourquoi ces activités sont-elles exécutées comme cela et pas autrement ? (pourquoi)

Ces 6 dimensions sont considérées de 5 perspectives différentes qui correspondent aux différents rôles dans l’entreprise. Les lignes du framework représentent ces différents rôles :

• Direction générale
• Business Analyst
• IT Analyst
• IT Designer
• Développeur

Ce qui est important de savoir, c’est que ces 5 lignes ne représentent pas un processus étape par étape, mais servent des objectifs très différents :

Alors que les lignes 1 et 2 décrivent les activités de l’entreprise, les lignes 3 à 5 décrivent la conception du système informatique permettant de soutenir les activités de l’entreprise. À la frontière des lignes 2 et 3 se trouve le « requirements engineering » (l’ingénierie des exigences) sur le plan de l’entreprise – une tâche qui joue un rôle absolument capital dans l’harmonisation Informatique/business.

En pratique, le framework de Zachman s’applique facilement comme liste de contrôle (ou checklist). D’un côté, les 30 cases du framework peuvent être conçues comme des questions qui permettent de déterminer si la dimension respective (par exemple le « quoi ») d’une entreprise pour un rôle précis (par exemple pour l’IT Analyst) est documentée, et, le cas échéant, pourquoi ce n’est pas le cas. En outre, toutes les cases ne doivent pas obligatoirement être documentées : par exemple, si une entreprise n’est présente qu’en un seul endroit, toutes les cases de la colonne « où » ne sont pas nécessaires. De l’autre côté, le framework de Zachman peut être utilisé comme grille pour les codes architecturaux : par exemple, il peut être exigé de certains projets de documenter certaines cases d’une certaine façon afin d’obtenir un aperçu homogène du paysage global de l’entreprise.

2. TOGAF

TOGAF (The Open Group Architecture Framework) est un framework global d’architecture d’entreprise qui est développé et amélioré par Open Group depuis le milieu des années 1990. Deux éléments se trouvent au cœur de TOGAF. D’une part, il y a l’Architecture Development Method (AMD) qui permet de représenter les tâches d’un architecte d’entreprise comme processus d’évolution constant tournant autour des exigences centrales d’une entreprise envers son système informatique.

Source de l’image : Stephen Marley, NASA/SCI/Public domain

D’autre part, TOGAF possède un métamodèle qui identifie les éléments centraux devant être gérés dans le cadre d’une architecture d’entreprise ainsi que les relations entre ces différents éléments. Ces éléments sont divisés en quatre architectures de base différentes :

L’architecture métier : description formelle des objectifs, pilotes, fonctions, événements et processus, mais aussi les produits et les services, d’une entreprise.

L’architecture des données : description formelle des données importantes ainsi que des conteneurs logiques et physiques dans lesquels les données sont regroupées.

L’architecture applicative : description formelle des applications utilisées au niveau fonctionnel et technique ainsi que des interfaces qui les lient entre elles.

L’architecture technique : description formelle des composants technologiques et infrastructurels utilisés.

Au contraire du framework Zachman qui, lui, est plutôt léger, TOGAF est particulièrement complet. Il définit de manière détaillée aussi bien le « quoi » de l’Enterprise Architecture Management (EAM), donc précisément ce qui devrait être géré dans un système d’architecture, que le « comment », donc les processus, tâches, rôles et compétences nécessaires pour l’EAM.

Sa considérable ampleur et son niveau de détail extraordinaire requièrent cependant que de nombreux ajustements de TOGAF soient réalisés avant que ce framework puisse être mis en pratique de manière sensée. C’est pour cette raison notamment qu’un commerce autour de la formation et de la certification TOGAF s’est développé. Pour les architectes d’entreprise, cela fait également de TOGAF une source précieuse de connaissances, de surcroît accessible gratuitement sur le site web d’Open Group.

« Referenzarchitekturmodell Industrie 4.0 » (littéralement : modèle architectural de référence pour Industrie 4.0), RAMI 4.0 pour les intimes, est un framework d’architecture d’entreprise plus récent. Il est développé en Allemagne depuis 2013 par trois associations industrielles (Bitcom, VDMA et ZVEI) et spécifiquement conçu pour les besoins de l’industrie 4.0. La conception et la fabrication de produits industriels constituent le cœur même de RAMI 4.0. Ce framework est représenté en 3 dimensions et divisé en six couches, organisées de bas en haut comme suit :

1. La couche « Asset » représente les installations de production physiques, les machines et les appareils.
2. La couche « Integration » étend les installations physiques de la couche « Asset » de manière virtuelle et peut être comprise comme le jumeau virtuel de la première couche.
3. La couche « communication » représente les différents canaux de communication et protocoles reliant les assets virtuels entre eux.
4. La couche « information » encapsule les informations nécessaires au développement et à la production comme les plans de construction et de production.
5. La couche « functional » décrit formellement toutes les fonctions nécessaires au développement et à la production.
6. Finalement, la couche « business » intègre les fonctionnalités décrites dans la couche « functional » à des processus commerciaux complets.

Source de l’image :  RAMI 4.0 Ebenen © Plattform Industrie 4.0 et ZVEI

Ces 6 couches sont structurées en deux dimensions : d’un côté, la dimension de hiérarchie permet l’ouverture de nouveaux contextes commençant avec un produit individuel en passant par les machines et cellules de fabrication jusqu’aux sites et groupes de l’entreprises. De l’autre côté, le flux du cycle de vie comprend essentiellement la création de produits au niveau du type (développement) et la fabrication de produits au niveau de l’instance (production).

RAMI 4.0 propose une orientation complète et indépendante du secteur permettant de développer les entreprises industrielles existantes comme les nouvelles vers une industrie 4.0. Des standards fondamentaux de l’industrie manufacturière comme l’identification des composants (GS1 ou RFID) ou la communication et la gestion (p. ex. OPC UA) peuvent être rattachés à RAMI 4.0 et combinés pour former un tout. RAMI 4.0 est un framework d’architecture développé spécifiquement pour l’industrie manufacturière. Sa solide structure de base a cependant encore besoin d’être mise au point autour de détails concrets. Ce framework étant encore jeune, c’est seulement ces prochaines années que l’application profitable de RAMI 4.0 lors de projets industriels 4.0 pourra être démontrée.

4. MDEE

En 2006, chez KnowGravity, nous avons commencé à développer notre propre « vision du monde » en une architecture d’entreprise. Nous avons ainsi créé le framework Model Driven Enterprise Engineering™ (MDEE), qui intègre différents langages de modélisation d’Object Management Group (OMG) en un framework de description complète d’entreprise.

Source de l’image : KnowGravity

MDEE organise la description d’une entreprise en une matrice à quatre cases qui différencie le « quoi » et le « comment » ainsi que la description de l’activité de l’entreprise et la description des technologies utilisées :

• Le modèle stratégique (Strategie-Modell) réunit les réflexions stratégiques, identifie les aptitudes (Capabilities) nécessaires à celles-ci et crée une terminologie d’entreprise homogène.
• Le modèle opérationnel (Operationelles Modell) montre les processus opérationnels nécessaires à la mise en œuvre des directives stratégiques, quelle en est la réglementation et comment sont représentés les responsabilités sur la structure de l’organisation.
• Le modèle de support (Support Modell) inclut les exigences en matière d’outils technologiques devant permettre de répondre aux besoins de l’entreprise de manière optimale, les spécifications fonctionnelles de ces outils ainsi que leurs mesures de contrôle.
• Finalement, le modèle d’implémentation (Implementations-Modell) documente l’anatomie des outils technologiques utilisés ainsi que leur aspect opérationnel et leur configuration concrète.

La « cinquième case » de MDEE, le modèle de management (Management-Modell), concerne la gestion des quatre premières cases :

• Quelles variations et variantes des quatre premières cases sont connues et comment peuvent-elles être utilisées.
• Quels changements (projets et programmes) sont prévus ou sont en cours dans l’entreprise
• Quels documents sont nécessaires et sous quelle forme.
• Quelles sont les transformations qui permettent de faciliter l’évolution uniforme de toutes les descriptions.
• Quels sont les aspects qualitatifs qui doivent être observés lors du développement et l’évolution de ces descriptions.

Les frameworks complémentaires

Outre les frameworks d’architecture au sens strict du terme, il existe une multitude de frameworks « semblables » au niveau de l’entreprise, auxquels les architectes d’entreprise devraient rester attentifs :

ISO 9000

Il s’agit d’une famille de standards ISO encadrant la conception, la mise en œuvre et la maintenance d’un système de management pour l’assurance qualité orienté sur les processus à l’échelle de l’entreprise. Un tel SMQ (système de management de la qualité) est courant dans de nombreuses branches ou une preuve de certification ISO 9000 peut même être explicitement exigée pour les fournisseurs.

ISO 27000

Une famille de standards ISO qui vise à uniformiser la conception, l’implémentation ou la maintenance de systèmes de management de la sécurité de l’information (SMSI). Un tel SMSI est au moins recommandé afin de répondre à des exigences réglementaires pour la protection des données comme le RGPD européen, la loi « Informatique et Libertés » française ou encore la loi fédérale suisse sur la protection des données.

ISO 31000

Cette famille de standards ISO vise à uniformiser la conception, l’implémentation et la maintenance de système de gestion des risques à l’échelle de l’entreprise. Ce framework aborde tous les types de risques et peut être appliqué dans toutes les branches. Il s’agit d’un bon complément à la famille ISO 27000 pour tout ce qui concerne la sécurité de l’information.

ITIL et COBIT

Ces frameworks liés à la technologie de l’information (TI/IT) procurent un cadre pour le développement d’un système informatique à l’échelle de l’entreprise grâce à des processus standardisés (ITIL) ainsi que pour leur gestion et leur gouvernance alignées sur des objectifs d’entreprise liés (COBIT). Ces deux frameworks se recoupent substantiellement au niveau des processus.

GxP et en particulier GMP et GLP : dans le domaine pharmaceutique et médical, Good Manufacturing Practice (GMP) et Good Laboratory Practice (GLP) tiennent des rôles centraux. GMP assure qu’un médicament est produit en suivant des exigences qualité requises, là où GLP assure que l’examen non clinique de ces médicaments pour leur autorisation est exécuté conformément aux règles et selon un principe de traçabilité.

La plupart de ces frameworks complémentaires sont très complets et doivent être adaptés aux besoins spécifiques de l’entreprise. Et chacun de ces frameworks connaît des points d’intersection solides avec l’architecture d’entreprise, ce qui peut servir de point d’intégration pour des thèmes connexes.

Cet article fait partie d’une série sur le thème de l’architecture informatique d’entreprise :

• Partie 1 : L’architecture informatique dans le contexte de la transformation digitale
• Partie 2 : L’article présent
• Partie 3 : L’architecture technologique, qu’est-ce que c’est
• Partie 4 : Les avantages de l’architecture opérationnelle

Sources :

• https://www.zachman.com/ea-articles-reference/54-the-zachman-framework-evolution
• https://www.opengroup.org/togaf
• https://www.isa.org/intech/20190405/