Les portfolios dans l'EAM, faites visible avec le principe ETS

Have a look at the possible portfolios in EAM, and how they can be derived from simple questions. Vue sur les portfolios dans l’EAM, et comment ils peuvent être dérivés de questions simples

De l’ETS à l’EAM – comment les portfolios d’architecture peuvent être dérivés de questions simples

Le principe ETS (Entrée – Traitement – Sortie) décrit un modèle fondamental du traitement de l’information.
Il est volontairement simple et précisément pour cette raison universellement applicable – bien au-delà des systèmes techniques.

Lorsque ce modèle mental est transféré à la gestion de l’architecture d’entreprise (EAM), une logique étonnamment claire émerge :
Des questions directrices fondamentales peuvent être dérivées de l’ETS, qui mènent à leur tour directement aux portfolios d’architecture bien connus.

L’ETS comme point de départ

Au cœur, l’ETS décrit trois aspects :

  • Entrée – quelles informations sont disponibles ?
  • Traitement – qu’advient-il de ces informations ?
  • Sortie – quels résultats sont produits ?

Appliqué au travail d’architecture, cela donne d’abord trois questions centrales :

  • Quelles informations sont pertinentes ?
  • Comment ces informations sont-elles traitées ?
  • Avec quels moyens ce traitement est-il mis en œuvre ?

Ces trois questions forment le cœur substantiel de la réflexion.
Elles décrivent ce qui est examiné et comment le traitement de l’information fonctionne fondamentalement.

En pratique, cependant, il apparaît rapidement :
Cette perspective seule est insuffisante pour des décisions architecturales robustes.

L’architecture n’existe pas isolément, mais plutôt :

  • au sein des organisations,
  • avec un objectif spécifique,
  • et sur une période prolongée.

Par conséquent, les trois questions de base doivent être complétées par des perspectives supplémentaires qui prennent en compte le contexte, la responsabilité et le temps.

De cet élargissement découlent trois questions directrices supplémentaires :

  • Qui porte la responsabilité ?
  • Pourquoi quelque chose est-il conçu d’une certaine manière ?
  • Quand quelque chose est-il pertinent ou valide ?

Ensemble, ces six questions directrices forment une base complète, mais simple, pour explorer systématiquement les architectures d’entreprise.

Les questions directrices dérivées

Ainsi, six questions directrices fondamentales émergent de la pensée ETS :

1. Quelles informations sont pertinentes ?

Cette question découle directement de la perspective Entrée.

Elle constitue la base pour :

  • les objets métier
  • les informations
  • les structures de données
  • les flux de données

Portfolio attribué :
Portfolio Information / Données

2. Comment les informations sont-elles traitées ?

Cette question est dérivée du Traitement.

Elle décrit :

  • les processus métier
  • les règles de gestion
  • les fonctions et services
  • leur mise en œuvre dans les applications

Portfolio attribué :
Portfolio Métier & Applications

3. Avec quels moyens le traitement est-il mis en œuvre ?

Cette question fait également partie du Traitement, mais avec un accent sur les moyens.

Elle aborde :

  • les technologies
  • les plateformes
  • l’infrastructure
  • les standards techniques

Portfolio attribué :
Portfolio Technologie / Infrastructure

4. Qui est responsable ?

Cette question complète l’ETS par la dimension organisationnelle.

Elle clarifie :

  • les rôles
  • les responsabilités
  • la propriété (ownership)

Portfolio attribué :
Portfolio Organisation / Capacités

5. Pourquoi quelque chose est-il conçu ainsi ?

Cette question établit le but.

Elle se rapporte à :

  • les objectifs
  • les principes
  • les moteurs stratégiques
  • l’argumentation de la valeur

Portfolio attribué :
Portfolio Stratégie / Motivation

6. Quand quelque chose est-il pertinent ?

Cette question introduit la dimension temporelle.

Elle décrit :

  • la validité temporelle
  • les transitions
  • les dépendances
  • les cycles de vie

Portfolio attribué :
Portfolio Feuille de route / Cycle de vie

Classification graphique

Le diagramme suivant montre comment les questions directrices peuvent être logiquement dérivées du principe ETS et attribuées aux portfolios respectifs :

flowchart TB
    ETS["Principe ETS<br/>Entrée · Traitement · Sortie"]

    Q1["Quelles informations ?"]
    Q2["Comment est-ce traité ?"]
    Q3["Avec quels moyens ?"]

    Q4["Qui est responsable ?"]
    Q5["Pourquoi est-ce fait ainsi ?"]
    Q6["Quand est-ce pertinent ?"]

    ETS --> Q1
    ETS --> Q2
    ETS --> Q3

    Q1 --> P1["Portfolio Information / Données"]
    Q2 --> P2["Portfolio Métier & Applications"]
    Q3 --> P3["Portfolio Technologie"]

    Q4 --> P4["Portfolio Organisation / Capacités"]
    Q5 --> P5["Portfolio Stratégie / Motivation"]
    Q6 --> P6["Portfolio Feuille de route / Cycle de vie"]

Le diagramme ne montre pas une hiérarchie, mais plutôt une dérivation conceptuelle :

  • L’ETS fournit le modèle de base
  • les questions directrices explorent le contexte
  • les portfolios structurent le contenu

Points communs et dépendances

En pratique, ces portfolios n’existent pas isolément :

  • Sans clarté sur les informations, les processus et les systèmes restent flous.
  • Sans compréhension du traitement, le lien entre le métier et l’IT est absent.
  • Sans technologie adaptée, les exigences ne peuvent être mises en œuvre.
  • Sans responsabilité définie, le savoir n’est pas durable.
  • Sans but stratégique, la légitimité manque.
  • Sans référence temporelle, aucun pilotage n’est possible.

Les questions directrices agissent comme l’élément de liaison entre les portfolios.

Conclusion

Le principe ETS montre comment le traitement de l’information fonctionne fondamentalement.
En en dérivant des questions directrices simples et en les attribuant aux portfolios EAM bien connus, une structure claire et compréhensible pour le travail d’architecture émerge.

La valeur ajoutée ne réside pas dans de nouveaux cadres, mais dans l’application cohérente de questions simples :

Un bon travail d’architecture commence là où
les connexions sont comprises –
et non là où une complexité supplémentaire est créée.

Parfois, il suffit de réorganiser ce qui est déjà connu.