TOGAF, Phase C2 : Architecture Applicative

La phase C (Architecture des Systèmes d’Information) se découpe en sous sous-phases: l’architecture data (C1) et l'architecture applicative (C2). Cet article se penche sur l'architecture applicative, qui consiste à modéliser la manière dont seront conçues et développées les applications au sein de l'entreprise. L'architecture applicative vise à créer des applications cohérentes et interopérables, afin de conserver une architecture la plus homogène possible et de rester en alignement avec la stratégie et les besoins de l'entreprise.

Note: Les points décrits ci-dessous sont volontairement simplifiés par rapport à la documentation officielle pour gagner en lisibilité et en compréhension.

Objectif

Définir et décrire comment l’entreprise doit adapter ses applications pour atteindre ses objectifs et répondre à l’ensemble des moteurs stratégiques mis en évidence dans l'analyse de l'architecture business, de manière à satisfaire les préoccupations des acteurs concernés.

Étapes clés

• Sélectionner les points de vue, les vues et les artefacts qui seront utilisés pour décrire l'architecture.
• Développer une description de l’architecture Applicative initiale.
• Développer une description de l’architecture Applicative cible.
• Effectuer une analyse des écarts (initiale / cible).
• Identifier les potentiels "building-blocks architecturaux" (ABB) de la roadmap.
• Analyser les impacts de la transformation sur tout le paysage architectural.
• Identifier et mitiger les risques associés à la transformation (y compris les risques de sécurité).
• Vérifier formellement que l’architecture cible reflète les préoccupations des acteurs concernés.

Entrées

• La définition du chantier d’architecture (approuvé)
• L'architecture Business initiale (détaillée)
• L'architecture Business cible (détaillée)
• L'architecture Applicative initiale (draft)
• L'architecture Applicative cible (draft)

Sorties

• L'architecture Applicative initiale (détaillée)
• L'architecture Applicative cible (détaillée)

Artefacts utiles

• Business Processes Models
• Diagramme des Interfaces/Schnittstelle
• Matrice Applications / Fonctions
• Matrice des interactions entre applications
• Diagramme des communications
• Use-Cases
• Diagrammes de séquence
• Plan de migration applicative
• Diagrammes de flux
• Diagramme de sécurité des applications

Notes personnelles

Les Phases C1 (Architecture Data) et C2 (Architecture applicative) peuvent être réalisées en parallèle. Il est par contre important de bien séparer l'analyse des données de celle des applications, et d'essayer de garder une séparation claire entre les deux mondes. En effet, les données sont souvent le cœur de l'entreprise, alors que les applications sont amenées à être remplacées avec le temps.

Parfois, on choisit une application juste parce qu'elle est cool et à la mode:

Je viens de tester chatGPT 4.0 ! If faut absolument qu'on intègre ca chez nous !

Ou parce qu'il s'agit d'un quasi-standard:

Il nous faut FME. Avec ce choix on ne peut pas se tromper.

Ou parce qu'on l'a toujours utilisée dans notre ancienne boite, et qu'on la connaît bien:

Chez nous on faisait utilisait Visual-Cron pour gérer nos jobs. Ca fonctionnait vraiment bien !

Parfois encore, elle est imposée par un décideur quelconque:

On fera du SAP, point final. Faites-en sorte de l'intégrer.

Et puis souvent, on a de vieilles applications legacy qu'il faut continuer à maintenir et à garder interopérables car elles sont centrales dans l'organisation:

Je sais, ça fait 5 ans qu'on dit qu'il faut remplacer cette application Access, mais on a d'autres priorités.

Bref, un SI va inévitablement grandir, s'étoffer, se complexifier. Si on y fait pas attention, on va vite se retrouver avec une usine à gaz, et les evolutions d'architecture deviendront de plus en plus complexes, jusqu'à à point où il faudra tout remplacer en même temps et le coût sera alors pharaonique.

La phase C2 est là pour nous aider à voir plus clair dans l'architecture applicative, à mieux comprendre les interactions entre les applications, et les possibles points d'accroche. Cela permet de mieux prévoir les impacts d'une évolution applicative, et d'avoir toutes les cartes en main pour définir les contraintes lors de la définition d'un cahier des charges ou lors de la rédaction d'un appel d'offre par exemple.