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 .

Lire la suite

SOA sans ESB

esbUn de mes clients m’a récemment poussé cette vidéo de Martin Fowler et Jim Webber sur une présentation acide sur la SOA et son outillage. Je vous partage ma vision.

En résumé, Martin et Jim attaquent là où ça fait mal: au niveau de l’agilité des processus de construction des intermédiations et sur la complexité des outils. Leur constat est (était?) le suivant:

Middleware propriétaire Technologies Web Centriques
– Non performant
– Coûteux
– Risqué
– Echelle de l’entreprise
– Spécialisé
– Intégration est une activité à part en tiers
– Design évolutif
– Delivry continue
– Pas couteux
– Incrémental
– Croix avec internet
– Intégration contrôlée par le consommateur

En un mot, ils préconisent la mise en oeuvre d’une démarche de services sans ESB car ils portent une complexité trop importante à contrario de l’approche Web. A ce propos, est-ce l’origine de la vague d’API Management actuelle ?

Bref, je comprends complètement leurs critiques. Pour être franc, j’ai moi-même connu des mastodontes tant sur leurs besoins en ressources matérielles que sur leur incapacité à évoluer. Mais…

Lire la suite

Transformation plus agile du Système d’Information

ConferenceLors de la mise en œuvre d’une démarche SOA outillé, je fais souvent le constat que l’interconnexion est assez coûteuse en effort humain. Il faut beaucoup communiquer pour clarifier les mécanismes envisageables, identifier les contraintes, définir les capacités du système, mettre en corrélation avec les patterns existants, etc. tout ceci avec de nombreux interlocuteurs : les chefs de projets, les architectes logiciels, les architectes systèmes, les architectes SOA et les urbanistes. Malgré tous ces efforts et après d’âpre discussions, le propriétaire du système craint alors des impacts sur ses flux existants et veut donc, tout naturellement, minimiser l’impact de ces nouveautés.

Derrière ce constat se cachent 2 problématiques :

  1. le manque de confiance dans la gestion du changement
  2. le manque de contrôle vis-à-vis de cet usage imposé.

Ce constat est exaspérant car il est consommateur d’une énergie folle. Il faut constamment se réunir et se synchroniser pour expliciter les besoins, décrire les données transférées, demander l’exécution d’un service (ensemble de règles) et faire correspondre avec les patterns et les outils d’interconnexions existants. Petit ou gros changements, l’effort humain pour faire aboutir ces besoins est majeur.

Les parties techniques sont souvent les plus simples. Il convient de mettre en place des mécanismes spécialisés portés par le Bus d’entreprise 9 fois sur 10. Voici quelques exemples:

  • Les connecteurs ABAP ou IDOC SAP
  • Les pooling et CDC (Change Data Capture) des bases de données
  • Les API d’accès aux couches natives
  • Exposition de règles par des Web Services

Pour chaque système, une série d’interconnexions est définie, prototypée puis validée.

Bref, chaque système subit l’évolution de son écosystème. En fonction des demandes externes, transverses ou globales, des interfaces supplémentaires sont ajoutées au fur et à mesure.

Lire la suite

SOA as a Service

L’utilisation de ressources IaaS et PaaS posent de nombreux problèmes d’interconnexion entre les parties prenantes d’un Système d’Information. Dans cet article, je vous propose une vision simplifiée d’une démarche de transformation de votre SOA en un service externe « SOA as a Service ». Elle vous permettra de mettre en oeuvre une infrastructure AWS, Azure, etc. pour vos solutions actuelles SOA et BPM.

Outre la question financière, la principale motivation de cette évolution est de bénéficier de l’élasticité de ces offres XaaS. La SOA et le BPM, au cœur du Système d’information, doit aussi en bénéficier afin d’évoluer et de s’adapter aux contraintes de trafic et de charges exceptionnelles.

Comme exemple, j’utiliserai d’un cas d’école simple et représentatif avec ses 4 couches applicatives:

  1. Le navigateur des utilisateurs
  2. L’ application Front-End qui agrège les informations métier pour générer une vision contextualisée
  3. La partie SOA avec:
    1. le bus d’entreprise (ESB) qui virtualise et routent les services métier
    2. l’orchestrateur SOA qui gère la complexité des enchaînements entre les services du SI
    3. le moteur BPM qui porte les workflows métier
  4. Le Back-Office qui expose des services techniques, métier ou utilitaires sur des technologies variées.
Architecture du cas d'exemple
Architecture du cas d’exemple

Cette représentation reste valable pour N applications web dans la partie Front-End et N applications dans la partie Back-End. Les technologies sous-jacentes sont sans impact tant qu’elles communiquent avec des protocoles standards HTTP comme SOAP ou REST.

La démarche d’externalisation des solutions SOA s’articule autour de 2 contraintes fortes: la sécurité et la performance. Il est évident que les flux qui transitent en dehors des réseaux de l’entreprise doivent être sécurisés. Par exemple, la sécurité des flux provenant du Front-End et du Back-End doit être maximale… même au détriment de la performance. Cette dernière bien qu’importante, se doit d’être acceptable pour l’utilisateur.

Lire la suite