Toutes les fiches
Architecture Development Method8 minThéorie gratuite

Phase C : Data et Application Architecture

Dans cette fiche

L’essentiel à retenir

  • La phase C couvre deux architectures : Data et Application.
  • Leur cible doit rendre possibles la Business Architecture et l’Architecture Vision.
  • Aucun ordre imposé : données d’abord, applications d’abord, ou en parallèle.
  • L’ARS de la phase C transmet des contraintes à la Technology Architecture.
  • Chaque partie produit ses propres composants de roadmap à partir de ses écarts.
01

Une phase, deux architectures

La phase C regroupe la Data Architecture et l’Application Architecture. Le standard ne fixe pas l’ordre : on peut commencer par les données, par les applications, ou mener les deux en parallèle, selon le contexte. Les deux restent étroitement liées, car une modification du modèle de données change souvent les échanges entre applications.

Chaque partie a deux objectifs de même forme, qui suivent le modèle de la phase B.

  • Data : développer une Target Data Architecture qui rend possibles la Business Architecture et la vision, en traitant le Statement of Architecture Work et les préoccupations
  • Data : identifier des composants candidats de roadmap à partir des écarts Baseline/Target des données
  • Application : développer une Target Application Architecture qui rend possibles la Business Architecture et la vision, dans les mêmes conditions
  • Application : identifier des composants candidats de roadmap à partir des écarts Baseline/Target applicatifs
02

Data Architecture

Elle décrit les principaux types et sources de données, leur structure logique, leurs responsables et la façon dont elles sont gérées. Trois préoccupations reviennent souvent : la gestion des données, leur migration vers la cible et leur gouvernance.

  • Modèle de données métier et modèle de données logique
  • Processus de gestion des données
  • Matrice Data Entity/Business Function
  • Vues adaptées aux préoccupations des parties prenantes
03

Application Architecture

Elle décrit les applications nécessaires, leurs responsabilités, leurs interactions et leur rattachement aux fonctions métier et aux rôles. Elle reste logique : on y décrit des composants applicatifs et des services, pas encore des produits précis, choisis plus tard.

  • Portefeuille d’applications et interfaces entre elles
  • Correspondance entre applications, fonctions métier, rôles et organisations
  • Communications et échanges entre composants applicatifs
04

Entrées et livrables

La phase C part des sorties de la phase B : ADD et ARS draft, composants Business de la roadmap, ainsi que le Statement of Architecture Work, la vision et les principes, notamment les principes de données et d’applications. Elle suit les mêmes étapes que les autres phases de domaine.

Elle enrichit l’ADD avec la Baseline et la Target de chaque architecture et leurs vues, et l’ARS avec les résultats de l’analyse des écarts, les exigences d’interopérabilité, les exigences mises à jour et des contraintes sur la Technology Architecture, que la phase D devra respecter. Elle ajoute aussi les composants Data et Application de l’Architecture Roadmap.

LES MOTS À CONNAÎTRE

Le vocabulaire, avec du sens.

Data Architecture
Structure des actifs de données logiques et physiques de l’organisation et des ressources qui les gèrent.
Application Architecture
Description des applications, de leurs interactions et de leurs liens avec les processus métier.
Logical data model
Représentation des entités de données et de leurs relations, indépendante de la technologie.
Interoperability requirement
Exigence qui précise comment données et applications doivent être partagées entre systèmes.
Data Entity/Business Function matrix
Matrice montrant quelles fonctions métier créent, lisent ou modifient quelles entités de données.