Architecture Building Blocks (ABBs) vs Solution Building Blocks (SBBs)

L’architecture d’entreprise souffre parfois de son propre langage. Parmi les notions qui prêtent le plus à confusion figurent les Architecture Building Blocks (ABBs) et les Solution Building Blocks (SBBs). Elles se ressemblent à l’oreille, mais renvoient à deux réalités bien distinctes, aussi bien dans le cadre du TOGAF® que dans la pratique quotidienne des architectes.

Ce guide aide à comprendre comment les ABBs et les SBBs s’articulent, en les replaçant dans une logique simple : passer d’un besoin logique à une solution concrète.

Architecture Building Blocks (ABBs): les plans et les pièces

Imaginez un plan d’architecte. Chaque mur, chaque pièce, chaque équipement y est défini avec précision : emplacement de la cuisine, taille du four, capacité du réfrigérateur. Pourtant, à ce stade, rien n’est encore construit. C’est exactement ce que sont les Architecture Building Blocks (ABBs) : des éléments logiques, structurés et réutilisables qui décrivent ce dont l’entreprise a besoin, sans entrer dans le “comment” de la mise en œuvre.

Dans le cadre du TOGAF, les ABBs définissent la structure logique de l’architecture, indépendante de toute technologie ou fournisseur. Ils traduisent les exigences, les standards et les capacités de l’organisation, ainsi que les relations entre les différents domaines.
Un ABB peut par exemple exprimer le besoin de gérer les identités clients, de structurer les données produits ou de disposer d’une plateforme d’événements en temps réel.

Ces blocs conceptuels se déclinent dans tous les domaines de l’architecture. Au niveau métier, ils représentent des processus, des rôles ou des politiques. Dans le domaine des données, ils décrivent les entités, les flux et les principes de gouvernance. Dans les couches applicative et technologique, ils formalisent les composants logiques, les interfaces, les services d’infrastructure et les standards d’intégration. Même la sécurité a ses ABBs : gestion des identités, contrôles, conformité, surveillance.

Abstraits, oui, mais jamais flous. Chaque ABB possède un objectif clair, des entrées et sorties définies, des dépendances identifiées et des exigences non fonctionnelles comme la performance, l’interopérabilité ou la résilience. Ils constituent le socle conceptuel de l’entreprise : un plan directeur qui structure l’architecture avant toute décision technique.

Solution Building Blocks (SBBs): les mises en oeuvres concrètes

Si les ABBs sont les plans d’une maison, les Solution Building Blocks (SBBs) sont l’édifice construit, avec ses briques, son béton et ses équipements réels. Ils traduisent l’intention en réalité.

Les ABBs définissent le besoin et les exigences ; les SBBs en livrent l’implémentation concrète. Ce sont des éléments tangibles, ancrés dans le monde des produits et des technologies, qui montrent comment un besoin se matérialise.
Si un ABB décrit la nécessité d’une plateforme d’événements, le SBB précisera qu’elle est mise en œuvre avec Kafka sur Confluent Cloud. Si l’ABB définit un besoin d’authentification, le SBB indiquera Azure AD B2C configuré avec authentification multifacteur et provisioning automatique.

Les SBBs sont concrets et opérationnels. Ils prennent la forme de logiciels métiers (Salesforce, SAP, Snowflake), de services d’infrastructure (Kubernetes, Azure Functions, AWS S3), d’outils d’intégration et de sécurité (MuleSoft, Okta, Apigee) ou encore d’applications développées sur mesure. Chacun dispose de ses interfaces, de ses politiques d’exploitation et de ses niveaux de service.
En somme, le SBB est la traduction physique du design logique porté par l’ABB.

Du concept à la solution : relier les points

Les ABBs et SBBs ne s’opposent pas : ils forment les deux faces d’un même processus. Les premiers définissent l’intention architecturale, les seconds en assurent la réalisation concrète.

Dans la pratique, tout commence par la conception des ABBs: le “quoi”, c'est-à-dire les capacités, les flux d’information et les structures fondamentales de l’entreprise.

Vient ensuite le choix ou la création des SBBs: le “comment” , soit les technologies, produits et configurations qui concrétisent ces besoins dans un contexte donné (budget, réglementation, compétences disponibles).

De la vision à la réalisation

Cette relation est essentielle.

• L’ABB Customer Relationship Management peut être implémenté via le SBB Salesforce CRM.
• L’ABB Event Streaming Backbone peut correspondre à Apache Kafka ou AWS Kinesis.
• L’ABB Operational Data Store peut devenir Snowflake dans un environnement et PostgreSQL dans un autre.

Maintenir cette correspondance garantit que chaque solution déployée répond à une intention d’architecture clairement identifiée, et non à une décision ponctuelle de projet.

En résumé, les ABBs expriment la stratégie, les SBBs assurent l’exécution. La relation entre les deux rend l’architecture à la fois actionnable et traçable.

Pourquoi cette distinction est essentielle

Confondre ABBs et SBBs est une erreur fréquente. Passer trop vite à la sélection de produits sans définir d’abord les ABBs, c’est risquer le verrouillage fournisseur. Rester bloqué au niveau conceptuel sans concrétisation, c’est produire de beaux schémas sans impact. Et perdre le lien entre les deux, c’est perdre la gouvernance : plus personne ne sait comment la stratégie se traduit dans le système d’information.

Une approche équilibrée permet d’éviter ces écueils. Les ABBs assurent la cohérence et la réutilisabilité, les SBBs garantissent la livraison et la responsabilité opérationnelle. Ensemble, ils rendent l’architecture traçable, rationnelle et évolutive.

TOGAF 10 le formule clairement : "les ABBs orientent et guident la conception des SBBs", et chaque SBB doit être rattaché à un ou plusieurs ABBs. Cette traçabilité est le socle de la transparence architecturale.

Pour y parvenir, les architectes devraient :

1. Commencer par définir les ABBs afin d’unifier le langage et clarifier l’intention.
2. Sélectionner les SBBs qui concrétisent ces ABBs selon les contraintes de l’entreprise.
3. Conserver les deux vues dans un référentiel commun, visible et entretenu dans le temps.

L’art de maintenir le lien entre abstraction et réalité

Une architecture mûre conjugue ces deux niveaux de pensée. Pendant la phase de conception, les architectes définissent les ABBs: un langage commun de capacités, de standards et d’interfaces. Lors de la mise en œuvre, les équipes déploient les SBBs: les technologies, configurations et intégrations qui incarnent ces capacités.

Avec le temps, les SBBs évoluent : de nouvelles solutions apparaissent, d’autres disparaissent, mais les ABBs, eux, restent le socle stable sur lequel tout repose. C’est pourquoi les organisations les plus avancées entretiennent un référentiel d’architecture vivant, où ABBs et SBBs coexistent, liés par des règles de traçabilité et des visualisations dynamiques.

Conclusion

L’architecture d’entreprise est la véritable charpente des organisations modernes. Loin d’être un concept figé, elle s’impose aujourd’hui comme une discipline collaborative, fondée sur les données et tournée vers les résultats. En combinant la rigueur des cadres comme TOGAF et la simplicité visuelle de plateformes modernes telles que Boldo, les organisations gagnent en clarté, en agilité et en cohérence.

Dans un monde où la technologie évolue plus vite que la stratégie, maintenir le lien entre ABBs et SBBs garantit que chaque système sert un objectif, et que chaque investissement s’inscrit dans une vision d’ensemble. L’architecture redevient alors ce qu’elle doit être : l’art de relier les idées à la réalité.

FAQ