Principe ETS dans le contexte de l'EAM
Categories:
Qu’est-ce que le principe ETS ?
Le principe ETS (en anglais IPO-model) désigne le principe fondamental du traitement des données, où les trois lettres signifient Entrée (Input), Traitement (Processing) et Sortie (Output).
Ces trois termes décrivent la logique de base du traitement de l’information.
flowchart LR
id1("Entrée") --> id2("Traitement") --> id3("Sortie")
style id1 fill:#ffff00,stroke:#333,stroke-width:2px
style id2 fill:#00ffff,stroke:#333,stroke-width:2px
style id3 fill:#ffff00,stroke:#333,stroke-width:2px
Au sens classique, cela fait référence aux composants physiques, c’est-à-dire au matériel :
| Entrée | Traitement | Sortie |
|---|---|---|
| Clavier Souris Pavé tactile Joystick Scanner Lecteur de codes-barres/QR |
Processeur principal CPU Chipset Contrôleur |
Écran Display Haut-parleurs Vidéoprojecteur Imprimante Traceur |
Cependant, le principe est beaucoup plus universel que la simple application aux composants informatiques physiques.
Où peut-il encore être appliqué ?
Le principe ETS peut être appliqué dans tous les domaines imaginables. Chaque interaction, chaque processus peut être modélisé ainsi.
Car chaque interaction, même un simple dialogue entre deux personnes, reçoit des informations, les traite et génère une réponse.
À titre d’exemple, voici un court dialogue concernant le bien-être, vu du côté de la personne interrogée :
flowchart LR
id1("Entend 'Comment ça va ?'") --> id2("Traite la question, réfléchit à la réponse") --> id3("Répond 'Très bien, merci.'")
style id1 fill:#ffff00,stroke:#333,stroke-width:2px
style id2 fill:#00ffff,stroke:#333,stroke-width:2px
style id3 fill:#ffff00,stroke:#333,stroke-width:2px
Chaque situation ou chaque processus peut être décomposé en trois étapes : Acquisition d’information, Traitement de l’information et Diffusion de l’information.
Le principe ETS dans l’EAM
Pour transposer durablement le principe ETS aux architectures d’entreprise, les éléments doivent encore être sécurisés par des questions fondamentales.
- Quoi (quelles informations sources) ai-je besoin pour démarrer ou pouvoir démarrer le processus ?
- Quoi (quelles informations cibles) ai-je besoin pour achever le processus ?
- Comment (selon quelles règles) est-ce que je transforme les informations sources en informations cibles ?
Avec ces questions, le principe ETS classique est traité. Pour les architectures, la question suivante doit impérativement être posée :
- Avec quoi (par quels moyens) est-ce que j’atteins cet objectif ?
Les questions du Quoi et du Comment sont fondamentalement traitées au niveau métier, car elles concernent principalement le processus fonctionnel.
Le Avec quoi est fourni par le niveau technique (via l’infrastructure).
Le niveau du système d’information (aussi appelé niveau applicatif) sert d’intermédiaire/traducteur et assure un soutien fluide du département métier par l’IT. Ainsi, le sens et le but des architectures d’entreprise sont remplis.
flowchart TD
id1("Architecture Métier") <--Quoi ? Comment ?--> id2("Architecture du Système d'Information") <--Avec quoi ?--> id3("Architecture Technique")
style id1 fill:#ffff00,stroke:#333,stroke-width:2px
style id2 fill:#00ffff,stroke:#333,stroke-width:2px
style id3 fill:#00ff00,stroke:#333,stroke-width:2px
Aux questions de base Quoi, Comment et Avec quoi, s’ajoutent les questions complémentaires suivantes :
- Pourquoi est-ce nécessaire ? (Sens et objectif)
- Quand (Pour quand) en a-t-on besoin ? (Délai)
- Qui en est responsable ? (Responsabilité)
Les questions complémentaires sont volontairement très générales, car elles peuvent être posées ponctuellement à n’importe quelle étape du processus.
| POURQUOI | QUAND | QUI | |
|---|---|---|---|
| QUOI | À quoi servent les informations sources/cibles ? | Quand/Dans quel délai les informations sources/cibles sont-elles nécessaires ? | Qui est responsable des informations sources/cibles ? (Data Owner) |
| COMMENT | Pourquoi les informations doivent-elles être traitées ? | Quand/Dans quel délai les informations doivent-elles être traitées ? | Qui est responsable du traitement ou du processus de traitement ? (Process Owner) |
| AVEC QUOI | Comment l’utilisation de l’outil requis est-elle justifiée ? | Quand quel outil est-il nécessaire/utilisé ? | Qui est responsable des outils requis ? |
Conclusion
Toute personne qui s’occupe depuis un certain temps de gestion de l’architecture d’entreprise (EAM) et qui a eu un aperçu d’un ou plusieurs frameworks retrouvera ces questionnements.
Le Framework Zachman connaît également six perspectives identifiées par des mots interrogatifs : Quoi (Données), Comment (Fonction), Où (Réseau), Qui (Personnes), Quand (Temps) et Pourquoi (Motivation). La seule différence dans ma représentation est que j’ai remplacé le Où par le Avec quoi. La raison en est assez simple à expliquer. Dans le monde d’aujourd’hui, nous sommes tellement numérisés et connectés que le Où physique ne joue plus qu’un rôle subordonné, voire presque plus aucun. Plus importants aujourd’hui sont les outils utilisés, c’est-à-dire le Avec quoi.
Dans ma représentation, je me suis également orienté vers TOGAF, où les questionnements ne sont pas explicitement mentionnés ainsi, mais sont couverts par les niveaux d’architecture proposés :
- Architecture Métier : Décrit les aspects “Qui” et “Pourquoi” (par ex. organigrammes, objectifs, principes).
- Architecture des Données : Se concentre sur le “Quoi” (par ex. modèles de données, flux de données).
- Architecture des Applications : Traite le “Comment” (par ex. cartographie des applications, interfaces).
- Architecture Technologique : Adresse le “Avec quoi” (par ex. infrastructure, réseaux, sites).
Ma représentation de l’ETS par rapport à l’EAM ne constitue donc pas une réinterprétation complète, mais vise plutôt à montrer, d’un point de vue pragmatique, comment cela peut être appliqué.