Concepts de rôles dans l’EAM
Categories:
Concepts de Rôles dans l’EAM
Pourquoi des Rôles dans l’EAM ?
La Gestion de l’Architecture d’Entreprise (EAM) évolue dans un champ de tensions entre la stratégie, l’organisation, les systèmes informatiques et les processus opérationnels. Sans rôles clairement définis, il existe un risque que le travail d’architecture reste purement documentaire ou soit mené de manière non coordonnée par différentes parties.
Les rôles dans l’EAM remplissent donc plusieurs fonctions centrales :
1. Clarifier les responsabilités
Les décisions d’architecture concernent de nombreux domaines de l’entreprise. Les rôles assurent qu’il est clair qui prépare, prend ou assume la responsabilité des décisions.
2. Structurer les perspectives
L’EAM examine les organisations sous différents angles (Business, Données, Applications, Technologie). Les rôles aident à ancrer organisationnellement ces perspectives.
3. Permettre la communication
L’architecture est un espace de traduction entre le métier et l’IT. Les rôles définissent qui parle quel langage et représente quels intérêts.
4. Assurer la gouvernance
Les directives d’architecture ne prennent effet que si quelqu’un est responsable de leur mise en œuvre – par exemple, via des comités d’architecture ou des processus de revue.
En bref :
Les rôles constituent le fondement organisationnel pour que l’architecture ne soit pas seulement modélisée, mais aussi vécue et pilotée.
Comment les Cadres de Référence Connus Abordent-ils Cela ?
TOGAF
Le cadre TOGAF définit une série de rôles autour du travail d’architecture, en particulier dans le contexte de la Méthode de Développement de l’Architecture (ADM).
Image de TOGAF Architecture Roles and Skills (Compte utilisateur nécéssaire).
Les rôles architect de TOGAF :
-
Enterprise Architect – Responsabilité globale de l’architecture de l’entreprise
-
Segment Architect – Responsabilité de domaines d’architecture spécifiques (Business, Données, Application, Technologie)
-
Solution Architect – Architecture d’un projet ou d’un système concret
-
Chief Architect – Organe de gouvernance et de décision pour les questions d’architecture
TOGAF considère les rôles principalement sous une perspective de gouvernance et de processus.
Ils sont étroitement liés aux phases de l’ADM et à la gouvernance de l’architecture.
Cependant, les rôles sont délibérément formulés de manière générique et doivent être adaptés par chaque organisation à sa propre structure.
Cadre Zachman
Le cadre Zachman adopte une approche différente. Il ne définit aucun rôle explicite, mais structure plutôt les artefacts d’architecture selon deux dimensions :
Image de About the Zachman Framework.
-
Questions (Quoi, Comment, Où, Qui, Quand, Pourquoi)
-
Perspectives (Planificateur, Propriétaire, Concepteur, Constructeur, Sous-traitant, Système en Fonctionnement)
Les lignes du cadre peuvent cependant être interprétées comme des perspectives de rôles implicites :
| Perspective | Rôle Typique |
|---|---|
| Planificateur | Stratégie / Direction Générale |
| Propriétaire | Responsables Métier |
| Concepteur | Enterprise ou Solution Architect |
| Constructeur | Développeur / Mise en œuvre |
| Sous-traitant | Spécialistes techniques |
La contribution du cadre Zachman réside moins dans des intitulés de rôles concrets que dans le constat :
L’architecture émerge de différentes perspectives et questionnements.
Ainsi, Zachman fournit une bonne base pour dériver systématiquement les rôles des questions fondamentales de l’architecture.
Rôles par Rapport au Principe EVA
Le principe EVA (Entrée – Traitement – Sortie) peut être utilisé comme une structure de pensée simple pour organiser les responsabilités dans le contexte de l’architecture.
Transposées aux questions d’architecture, six perspectives de base peuvent être distinguées :
-
Quoi – Objets et informations
-
Comment – Processus et fonctions
-
Avec Quoi – Outils et technologies
-
Pourquoi – Objectifs et motivation
-
Quand – Structure temporelle et planification
-
Qui – Organisation et responsabilités
Ces questions aident à définir les rôles non pas seulement par hiérarchie ou domaine fonctionnel, mais par leur responsabilité fonctionnelle dans l’espace architectural.
En Lien avec les Questions Fondamentales
Rôles/Responsabilités pour le « QUOI »
La question du « Quoi » se réfère aux objets d’information centraux d’une organisation.
Responsabilités typiques :
-
Définition des objets d’information centraux
-
Modèles de données et structures d’information
-
Qualité des données et responsabilité des données
Rôles typiques :
-
Data Architect
-
Information Architect
-
Data Owner
-
Data Steward
Ces rôles assurent que les structures de données sont cohérentes et compréhensibles à l’échelle de l’organisation.
Rôles/Responsabilités pour le « COMMENT »
Le « Comment » décrit les processus et fonctions par lesquels une organisation fournit ses services.
Responsabilités typiques :
-
Modélisation des processus métier
-
Définition des capacités (Capabilities)
-
Coordination entre le métier et l’IT
Rôles typiques :
-
Business Architect
-
Process Owner
-
Capability Manager
Ces rôles veillent à l’alignement des processus métier et des systèmes informatiques.
Rôles/Responsabilités pour le « AVEC QUOI »
La question « Avec Quoi » concerne les moyens technologiques pour la mise en œuvre des processus.
Responsabilités typiques :
-
Standards technologiques
-
Architectures de plateformes
-
Stratégies d’infrastructure
Rôles typiques :
-
Technology Architect
-
Infrastructure Architect
-
Platform Architect
Ils définissent le cadre technique dans lequel les solutions sont créées.
En Lien avec les Questions Fondamentales
Rôles/Responsabilités pour le « POURQUOI »
Le « Pourquoi » relie l’architecture à l’orientation stratégique de l’entreprise.
Responsabilités typiques :
-
Déclinaison des principes d’architecture
-
Images cibles stratégiques
-
Feuilles de route de transformation
Rôles typiques :
-
Enterprise Architect
-
Strategy Architect
-
Transformation Lead
Ces rôles assurent que les décisions d’architecture sont justifiées stratégiquement.
Rôles/Responsabilités pour le « QUAND »
Le « Quand » concerne la coordination temporelle des changements d’architecture.
Responsabilités typiques :
-
Planification de la transformation
-
Feuilles de route
-
Planification des versions et des programmes
Rôles typiques :
-
Portfolio Manager
-
Program Manager
-
Transformation Manager
Ils veillent à ce que l’architecture ne soit pas seulement conçue, mais aussi mise en œuvre dans les temps.
Rôles/Responsabilités pour le « QUI »
La question « Qui » concerne l’ancrage organisationnel du travail d’architecture.
Responsabilités typiques :
-
Structures de gouvernance
-
Rôles et responsabilités
-
Processus de décision
Rôles typiques :
-
Architecture Board
-
Domain Leads
-
Architecture Governance Lead
Ces rôles assurent que les décisions d’architecture sont institutionnellement ancrées.
Mise à l’Échelle du Concept de Rôles
Toutes les organisations n’ont pas besoin des mêmes rôles.
Le nombre et la spécialisation des rôles dépendent fortement de la taille et de la complexité de l’organisation.
Le DPBoK (Digital Practitioner Body of Knowledge) décrit quatre niveaux de contexte, sur la base desquels les rôles peuvent être mis à l’échelle de manière pertinente.
Contexte I : Individu / Fondateur
Dans les très petites organisations, une seule personne assume souvent plusieurs rôles simultanément.
Situation typique :
-
Fondateur = Stratégie, Architecture et Mise en œuvre
-
Faible séparation formelle des rôles
Caractéristiques :
-
Architecture implicite
-
Décisions rapides
-
Gouvernance minimale
Le travail d’architecture y est plutôt intuitif.
Contexte II : Équipe
Avec la croissance, les premiers rôles fonctionnels émergent.
Rôles typiques :
-
Product Owner
-
Lead Developer
-
Solution Architect
L’architecture émerge souvent au sein d’une équipe et est fortement façonnée par des produits concrets.
Contexte III : Équipe d’Équipes
À partir de ce stade, des rôles d’architecture de coordination apparaissent.
Rôles typiques :
-
Enterprise Architect
-
Domain Architect
-
Architecture Board
Tâches centrales :
-
Coordination entre les équipes
-
Principes d’architecture communs
-
Standards de plateformes et de données
L’architecture est ici pour la première fois coordonnée à l’échelle de l’entreprise.
Contexte IV : Entreprise Établie
Dans les organisations établies, l’architecture devient une fonction organisationnelle à part entière.
Structures typiques :
-
Architecture Office
-
Enterprise Architecture Practice
-
Architecture Governance
Les caractéristiques incluent :
-
Rôles clairement définis
-
Gouvernance formelle
-
Planification de transformation à long terme
Ici, l’architecture devient un instrument central de pilotage de l’entreprise.
Conclusion
Les rôles dans la Gestion de l’Architecture d’Entreprise peuvent être définis de différentes manières. Alors que des cadres comme TOGAF proposent des rôles concrets, le cadre Zachman met surtout en lumière différentes perspectives sur l’architecture.
Une dérivation systématique des rôles réussit lorsque l’architecture est structurée autour de questions fondamentales – par exemple, via les six perspectives :
-
Quoi
-
Comment
-
Avec Quoi
-
Pourquoi
-
Quand
-
Qui
Ces questions rendent visibles quelles responsabilités existent réellement dans l’espace architectural.
Quels rôles sont effectivement mis en place dépend cependant fortement du contexte organisationnel. Grâce aux niveaux de mise à l’échelle du DPBoK, il est possible de retracer comment les rôles d’architecture peuvent évoluer, d’une seule personne jusqu’à une organisation d’architecture institutionnalisée.
Cela met en évidence :
Les rôles EAM ne sont pas un ensemble rigide de titres, mais un concept organisationnel évolutif pour la responsabilité architecturale.