L’Architecture Flexible et l’ « Orientation Domaine »

Parmi les évolutions des Framework de conception des systèmes d’information, l’orientation domaine est particulièrement intéressante.
En effet, si l’on adopte une approche « top-down », approche somme-toute historique de l’Architecture d’Entreprise, le découpage en domaines est un sujet majeur sur lequel toute la littérature a usé ses plumes.
A contrario, si on construit l’architecture à partir du détail, qu’il soit fonctionnel, ou de services par exemple avec les micro-services, en agrégeant ces détails, on arrive à une architecture globale. A ce niveau, de fait, les détails disparaissent. Idéalement cette disparition permet de donner une compréhension globale, et de maîtriser le « système ».

Le framework fédéral FEAF

Avoir une vision du SI par domaine est donc une constante de l’Architecture d’Entreprise.

Un tel découpage, quels que soient les termes employés, a toujours eu pour objectif premier la maîtrise de la complexité :
• Pouvoir organiser une maîtrise d’ouvrage, se sourcer auprès de fournisseurs de composants, d’ERP, d’architecture technique, périmètrer les projets, urbaniser tout ou partie du SI.
• Cette maîtrise s’exerçant sur toutes les échelles de temps : dans le temps des projets, mais aussi bien au-delà avec la complexification du patrimoine par empilement des applicatifs et des « couches » technologiques.

Avec l’évolution technologique, ce sujet prend une nouvelle tournure qu’il est utile d’examiner. Il nous faut « revisiter » l’historique « découpage fonctionnel » avec, dans la culture de l’urbanisme à la française, ses « POS », son urbanisme en zones, quartiers, îlots, ou, dans d’autres écoles, ses « building block ».

En particulier, l’enjeu de maîtrise de la complexité demeure, mais les interactions entre domaines, jadis classiquement policées par les fameux « batch » d’échange, peuvent se multiplier à l’infini. Il est impératif de comprendre les pratiques qui se mettent en place : l’optimisation et l’extension harmonieuse de ces interactions sont clés pour le système global, et la pérennité de son modèle.

Quelle partition en domaines ?

Deux questions se posent :

  • Quelle est la logique qui, au-delà de l’intuition de l’analyste, préside à la partition ?
  • Comment les domaines ainsi définis interagissent, dans tous les espaces temporels ?
La logique de partition

Pour définir une partition, la logique fonctionnelle, jadis dominante, se prolonge maintenant par une logique de spécialisation des composants sous forme de services. C’est une approche similaire, devenue plus précise et se déclinant par fractales.

Cette approche se confronte à d’autres partitions du monde réel :

  • Les processus

A ce sujet, dans l’urbanisme des SI, on a institué (le Club Urba-EA a été initiateur de cette vision) un modèle « en couches » qui vise à dissocier la « couche processus » de la « couche fonctionnelle » de la « couche applicative ». La décomposition en processus serait en contradiction avec ce modèle qui demeure efficace, et n’est donc pas la bonne clé pour scinder le SI en domaines.

 

  • L’organisation

Un grand classique est de dépasser l’organisation « en silos », par « métier », qui structure le SI « historique », et de se doter de visions transverses. Cette grille d’analyse n’est donc pas non plus à reprendre.

  • Les données

On a aussi tendance à dissocier les données partagées, données de référence, des données spécifiques. Là encore cette répartition n’est pas pertinente pour identifier les domaines, car les données de référence, partagées, sont plutôt hors domaine, et classiquement les grandes bases de données sont plutôt à cheval entre des domaines très imbriqués. De plus, dans une architecture répondant de plus en plus en temps réel et sans latence, l’accès aux données doit se faire au travers de services, comme nous le verrons ci-après. La logique « services » s’impose et les données sont « encapsulées ».

  • La chaîne de valeur

La structuration de la chaîne de valeur, très fortement invariante, n’est pas prise en compte dans les framework habituels. C’est un tords. La Trame Business propose un canevas qui a fait ses preuves et reste pourtant méconnu. Il incite à associer dans un même ensemble tous les éléments qui concourent à une même transformation, ce qui permet de définir des domaines au contour très stable. L’idéal est que les domaines soient le plus indépendants possible, avec un contour « étanche ». Le fait de les spécialiser par cycle satisfait cette exigence.

En confrontant tous ces axes, on voit bien qu’il s’agit de satisfaire plusieurs objectifs, bien au-delà de l’ingénierie idéale du logiciel :

  • Gouvernance ou non de fonctions transversales,
  • Autonomie de métiers,
  • Redistributions des rôles le long de la chaîne de valeur,
  • Nouveaux modèles d’affaires fondés sur le tout numérique.

L’intégration de ces visions est clé, et la Trame Business est un outil bien adapté.

Le principe proposé pour ce découpage en domaines :

Principe (Trame Business) : la décomposition doit respecter une spécialisation des domaines par cycle

Ce principe renvoie au « polygone de Mandel » qui assemble les différents cycles de l’ensemble, entreprise, écosystème, … étudié.

La spécialisation par cycle a l’avantage :

  • D’être objective, facilement identifiable dans la vie du monde réel,
  • De minimiser les interrelations, en masquant en particulier les boucles détaillées d’un cycle, qui n’ont pas d’implications avec les autres cycles,
  • D’englober toutes les formes de transformation (processus, « cerveau d’œuvre » au sens « iconomique », industrie, SI,… dans une même logique qui les transcende,
  • D’amener naturellement au monde de la mobilité, du connecté, …
  • D’être fortement invariante au travers des évolutions économiques, organisationnelles ou du SI.

De fait, dans les exemples présentés dans la littérature sur les micro-services, celui de la réservation aérienne (voir l’article de C. Porta), ou celui de l’achat en ligne (voir l’article de C. Richardson), on constate aisément cette séparation.

Les principes d’architecture de micro-services

La décomposition en domaines est typiquement une approche « top down ». L’architecture de micro-services se construit dans une approche inverse, bottom up.

Premier niveau d’agrégation de micro-services

Les micro-services les plus fins n’ont pas en général de finalité aboutie, au sens du traitement à réaliser : chacun correspond à une partie, ou une étape intermédiaire, de traitement.

L’assemblage, par un premier niveau d’agrégation, permet de donner à cet ensemble un sens correspondant à une étape significative de traitement, à un changement d’état d’un objet.

En terme d’équipe de développement, on peut, avec une équipe de petite taille, gérer facilement la complexité des relations internes, entre ces micro-développements de micro-services (cf règle des pizzas team). Chaque équipe est indépendante et gère son homogénéité.

Pour ce premier niveau d’agrégation, il faut bien sûr opter pour une solution architecturale. La solution la plus simple est d’opter pour des interactions synchrones au travers d’API : chaque micro-service peut invoquer directement ses « collègues » en fonction des besoins, et sans attendre.

Deuxième niveau d’agrégation de micro-services

Sans donner de règle absolue et générale, il arrive un moment, fatalement, où il devient très difficile :

  • de cordonner une grande masse de développeurs,
  • de coordonner les évolutions d’un grand nombre de composants, de maintenir leur intégration, de ne pas régresser, …
  • de gérer la qualité de service, en agissant sur les paramètres de production,
  • de rester flexible pour acheter des composants du marché, et répondre clé en main à des besoins business,

Pour répondre à ces défis, il faut un autre type de solution d’architecture, poussant encore plus loin l’isolement des services :

  • ignorant leurs correspondants, et jusqu’à leur adresse, et tolérer des réponses asynchrones,
  • résistant aux arrêts et incidents (tolérance aux fautes),
  • pouvant admettre des clones, concurrents sur les fonctions qu’ils ont pourtant vocation à assurer,
  • abandonnant toute velléité de garantir une cohérence inter-service (contrairement aux caractéristiques des bases de données classique et des critères ACID),

La standardisation induite permettant des mécanismes de gouvernance, d’exploitation automatiques, industrialisant les cycles de vie des services.

Le schéma ci-dessous présente un exemple d’une telle architecture, où les communications entre les services ne se font plus par API, mais par envoi et réception de grains d’information, qualifiés d’événements.

D’après C. Posta

L’archétype de ce type d’architecture est celui proposé par l’event sourcing.

 

Le point de rencontre entre les visions globales et détaillées : le traçage immuable des faits

Cette figure de style a beaucoup de points communs avec celle des « puits d’événements » décrite ici. L’event sourcing est un log d’événements avec persistance.

En particulier, les efforts de conceptualisation mis dans la définition du « puits » sont directement utilisables : notion de grain, identification des grains, caractère immuable sans état, tri-datation, rôle de porte d’accès aux différents SI, intégration des empilements technologiques (mode Janus),…

En somme, « event sourcing » et « puits d’événements » convergent, bien qu’issus de 2 approches radicalement distinctes. Le puits apporte la relation avec les cycles du monde réel, donc avec le chaînes de valeur, le business, les métiers. L’event sourcing apporte la relation avec les technologies de demain, du monde agile, des architectures scalables, nativement événementielles de la société numérique et du monde connecté.

Une évolution des modèles d’architecture sans rupture forte

La convergence de ces concepts, si elle est bien anticipée, permet d’envisager une évolution naturelle des modèles d’architecture, sans rupture, grâce à la définition de formats de données compatibles, au niveau des « grains de faits ».

Phase 1 :

Phase 2 :

Phase 3 :

 

Voir aussi sur ce site : Architecture Flexible et Micro-services