Doctrine de l’Architecture d’Entreprise

Au cours de mes missions en Architecture d’Entreprise, je rencontre souvent la difficulté à expliquer cette activité. Entre méthode, objectifs, enjeux, implémentations, patterns, je perds vite mes interlocuteurs. J’ai cherché comment simplifier mon discours. J’ai bien trouvé de nombreux ouvrages sur TOGAF, Zachman ou Federal EA. Ils décrivent comment dérouler ces méthodes… mais leur compréhension est délicate, les concepts présentés sont théoriques et il faut une solide expérience pour bien les appréhender. Je n’ai finalement rien trouvé de mieux que la description du CIGREF sur le sujet.

J’en reprends d’ailleurs la définition suivante. A mes yeux, elle résume bien le scope de l’EA.

« L’Architecture d’Entreprise est la logique structurante pour les processus métiers et l’infrastructure informatique, reflétant les exigences d’intégration et de standardisation du modèle opératoire de l’entreprise. L’architecture d’entreprise fournit une vision à long terme des processus, des systèmes et des technologies de l’entreprise afin que les projets individuels puissent construire des capacités et non pas simplement répondre à des besoins immédiats. »
J. W. Ross, P. Weill (MIT) et D. C. Robertson (IMD) “Enterprise Architecture as Strategy”, HBS Press, 2006

Mon expérience et mes clients m’ont amené à être très pragmatique dans mon quotidien et dans mon approche. De part mes appétences techniques, j’aime comprendre les aboutissements et l’atterrissage des concepts. D’autre part, il est coûteux et long de propager une démarche méthodologique. C’est en plus assez antinomique avec l’agilité actuelle des projets. Pour quelques clients, j’ai synthétisé une vision personnelle dans un ensemble réduit de règles. Elles forment ma Doctrine de l’Architecture d’Entreprise. Sa diffusion vers les MOA, les Chefs de projets et la Direction est de ce fait plus aisée. Concrètement, les détails sont explicités lors des workshop projets et disponibles dans un Wiki annexe. Je cherche ici à réduire la complexité de la démarche. A rendre le discours de l’EA très concret. Le blabla et les détails techniques sont volontairement cachés. Bref, ces règles sont pour moi la face visible de l’iceberg de l’Architecture d’Entreprise.

Je suis conscient qu’elles demanderaient des explications et des éclaircissements. De ces règles, qui sont presque des objectifs pour certaines, il en découle des concepts, des certitudes et des implémentations pragmatiques. J’espère en tout cas vous démontrer que l’Architecture d’Entreprise n’est pas une idée de l’esprit ou une démarche de de théoriciens lunatiques mais que TOUS les acteurs de l’Entreprise y sont gagnants :-O .

Règle 1: Le Maître de la donnée

« Les données appartiennent à un système principal qu’il convient de solliciter pour obtenir tout ou partie de la donnée. La copie de copie est interdite. »

Un système unique est maître de 1 à n notions métier. Il en maîtrise le cycle de vie.

Un système peut consommer des données en les demandant à celui-ci. Il peut les stocker temporairement pour faciliter leur usage en lecture.

Règle 2: Minimiser l’embonpoint

« Seules les données nécessaires et suffisantes sont stockées. »

A chaque donnée, correspond des traitements. A chaque donnée redondante, il existe des traitements redondants. Pour réduire les coûts induits par cette duplication, il ne faut pas de données  redondantes, voir inutiles.

« Seules les données nécessaires sont véhiculées. »

Les échanges entre systèmes sont coûteux pour le SI. La réutilisation prévaut pour éviter le transports, les transformations, le stockages, les synchronisations et les rejets inutiles.

Règle 3: Maîtriser les interactions

« Un cadre d’échanges clair pour le métier ».

Un ensemble réduit de patterns fonctionnels d’échange définit un cadre simple pour le métier. Ils sont compréhensibles et sont la base des spécifications avec :

  • la propagation de données,
  • l’émission d’événements métier,
  • l’appel d’opérations ou de règles fonctionnelles.

Ces patterns d’échange régissent les flux d’informations dans et en périphérie de l’entreprise.

Règle 4: Faciliter l’accès à l’information

« L’information doit être accessible rapidement. »

Afin de proposer des offres innovantes et s’adapter rapidement au marché, les données doivent être accessibles. Les workflows et cadres applicatifs sont donc séparés des données.

Les moyens techniques support aux échanges utilisent des protocoles standards, normalisés et outillés. Par opposition, les protocoles propriétaires ne sont jamais exposés et consommés par un autre système.

Règle 5: Un vocabulaire d’entreprise

« Une communication sans ambiguïté est essentielle. Les concepts métier de l’entreprise en sont les fondations. »

La richesse d’une entreprise est sa connaissance et sa maîtrise de son métier. Il doit être documenté et partagé. Le SI le met en musique dans ses bases de données et dans les échanges. Ces derniers utilisent un format très proche de ce vocabulaire. Comme il fait partie de la culture d’entreprise, il est stable et apporte une abstraction au changement.

Par opposition, la translation brute d’un format natif est interdite entre les systèmes.

Règle 6: Anticiper le changement

« Chaque application évolue indépendamment des autres ».

Afin de permettre l’évolution désynchronisée des briques du Système d’Information (applications et systèmes), les échanges sont indépendants aux technologies et contractualisés dans :

  • des API,
  • des Services,
  • des Messages.

Ce cadre contractuel facilite la communication entre les MOA et MOE sur les cycles de vie des ressources consommées: ouverture, obsolescence et fermeture.

Règle 7: Pilotage par le métier

« Le métier est le pilote ».

Le métier est le demandeur des évolutions de ses outils (ie le Système d’Information). Il les finance directement ou indirectement. Il doit être en capacité de piloter les coûts engagés et de comprendre les usages. Ils sont collectées et mis à disposition au management dans des rapports adaptés.

Tous les flux sont dits « facturables »: Qui, Quoi, Combien et Quand.

Règle 8: QoS First

« La qualité de service est anticipée, mesurée et améliorée ».

Les systèmes et leurs interactions sont conçus avec des contraintes de Qualité de Services (QoS). Les principaux critères sont :

  • la disponibilité,
  • le temps de réponse,
  • la capacité maximale,
  • le temps de transfert de la source vers la cible.

Chaque système consommateur doit avoir connaissance du contrat de service (SLA) de chaque ressource utilisée.

Enfin, Chaque système évolue en améliorant sa QoS.

Règle 9: Minimiser le coût de l’erreur

« Les erreurs et incompréhensions entre les systèmes ne complexifient pas les échanges ».

Pour simplifier la gestion des erreurs dans les échanges, les responsabilités sont claires:

  • Les applications interprètent les informations en retour.
  • La médiation assure le rejeu technique lié à des indisponibilités (SLA non égaux).
  • Les rejeux fonctionnels sont pris en charge par les systèmes sources et cibles.

Les principes simples sont partagés par tous les systèmes:

  • Il est interdit de perdre des messages ou appels transactionnels.
  • Les appels sont non garantis et ne sont pas rejoués par défaut par la médiation.
  • Les échanges fichiers (sans feedback direct) sont minimisés.

Règle 10: La sécurité est l’affaire de tous

« Chaque utilisateur n’accède qu’aux données de son périmètre ».

Toute connexion par un utilisateur au SI est identifiée et authentifiée.

Toute production d’information doit être adaptée au bon niveau d’accréditation et de confidentialité de l’utilisateur (personne, application, système, partenaire, etc.). Le producteur d’information est le garant de cette adéquation.

Règle 11: Gouvernance du SI

« Le chef d’orchestre est la Direction des Systèmes d’Information ».

Tous les projets participent au bien commun. Les efforts sont partagés et mutualisés.

La vision des systèmes et des applications est organisée et structurée dans un référentiel documentaire et cartographique accessible par tous.

La DSI gère un plan d’évolution du Système d’Information à 3 ans minimum. Les architectes d’entreprise en dressent le chemin et les détails. Ils sont les garants de la cohérence globale.

Synthèse

Voilà, seulement 11 règles. J’ai essayé de les construire avec une abstraction forte. Elles proposent un cadre pragmatique sans brider la créativité nécessaire dans les projets. Pour cela, cette doctrine est:

  1. Non adhérente à une méthode,
  2. Non adhérente à une architecture,
  3. Non adhérente à un technologie,
  4. Non adhérent à un projet.

Ces règles définissent aujourd’hui ma doctrine de l’Architecture d’Entreprise. Elle se veut efficace et pragmatique. Je suis conscient qu’elle n’est pas parfaite et que ces règles sont réductrices. Mais bon, elles sont faciles à partager, compréhensibles par tous et génératrices de changements positifs :-).