Knowledge graph et Architecture d’Entreprise
Un potentiel mal exploité
Champ des éléments en interaction pour l’architecture d’entreprise
L’Architecture d’Entreprise (AE) est une discipline destinée à favoriser, face à des situations en constante évolution, le développement d‘une stratégie d’entreprise conforme à ses finalités ainsi que son exécution ad hoc.
Cette discipline est profondément liée aux approches de représentation des connaissances. Il est donc curieux que le potentiel des Knowledge Graph y soit encore insuffisamment exploité. En effet, ces derniers sont pertinents pour représenter de manière expressive la sémantique d’un système. Ils offrent également des moyens de naviguer entre concepts de connaisssance et leurs interrelations. Cela en suivant des standards du Web sémantique et des modèles et ensembles de données FAIR (Findable, Accessible, Inter-operable, Re-usable).
Il est toutefois décevant, au niveau de la couche sémantique, de constater que les essais d’approche des Knowledge Graph pour l’architecture d’entreprise – à quelques exceptions près – se soient cantonnés à des traductions littérales en langage OWL de modèles ou de cadre de référence existants. Or exprimer en OWL les règles et objets de langages tel Archimate ou la terminologie de Togaf, a peu d’intérêt. On restreint ainsi une richesse d’expression sémantiques aux contraintes voire incohérences de sources existantes. Les réutiliser à un sens mais il ne faut pas confondre sources terminologiques et spécification formelle d’une conceptualisation.
Pour que l’approche des graphes de connaissances appliquée à l’architecture d’entreprise fonctionne, il ne faut pas se tromper de cible. Ainsi que suivre les bonnes pratiques de construction, tant pour la conception que l’implémentation. Cet article développe aussi bien les enjeux en la matière que les moyens d’y arriver.
Architecture d’entreprise et représentation des connaissances
Exemple de taxonomie des éléments clés à décrire
Une partie de l’Architecture d’entreprise consiste à décrire le système entreprise au juste nécessaire dans son environnement. Ce « juste nécessaire » revient à disposer d’informations clés afin de réduire l’incertitude sur les situations en développement. Il s’agit autant de décrire les objectifs stratégiques que les aspects organisationnels, les capacités, les ressources, les processus, les technologies, en d’autres termes tous les composants essentiels qui structurent l’entreprise, leurs interactions ainsi que leurs évolutions dans un monde ouvert, à des fins décisionnelles. L’idéal étant de pouvoir simuler l’impact de choix sur une représentation de l’entreprise à un instant t.
Les descriptions d’architecture servent à acquérir une connaissance utile pour comprendre, choisir et planifier les actions de transformation en continu. L’entreprise est, par ailleurs, un système dynamique complexe. Dès lors l’approche systémique est de mise. Elle conduit à se concentrer sur les interactions internes entre éléments du système ainsi que leurs relations externes avec l’environnement. Sans oublier, bien sûr, de définir clairement les finalités du système pour identifier des pistes d’évolution conformes aux enjeux stratégiques.
Tout cela nécessite de décrire explicitement ce qui est su des éléments et leurs interactions. Donc de collaborer avec des « SME » (Subject Matter Expert) pour éliciter leurs connaissances. Il faut ensuite la formaliser tout en intégrant la nécessité permanente de mise à jour. Dès lors, des outils et procédés de représentation et partage des connaissances sont nécessaires à plusieurs niveaux d’abstraction.
Things, not string
Image extraite de l’article de Amit Singhal « Introducing The Knowledge Graph: Things not strings »
Deux erreurs communes depuis des années sont prégnantes dans les systèmes d’information. Modéliser des données pour stockage avant d’expliciter les concepts manipulés et penser plus au couple problème/solution qu’aux enjeux globaux. D’où le fameux «integration spaghetti » du Gartner. C’est à dire un SI constitué d’une mosaïque de systèmes peu évolutifs, peu interopérables, avec de nombreux silos de données.
Quand on parle de concepts manipulés, ce sont les objets métiers, concrets ou abstraits de l’univers du discours de l’entreprise. Un constructeur automobile manipulera des concepts liés aux voitures, un assureur, des contrats d’assurance. Les acteurs métiers aujourd’hui évoquent des « données métiers ». En réalité les données ne sont déjà plus des objets métiers. Ce sont des traductions en formats numériques, de parties de choses utiles au métier. Et souvent, sous la seule perspective à court terme d’un fonctionnement applicatif recherché.
Dans le champ de l’architecture d’entreprise il y a nécessairement la description des objets métiers manipulés par les acteurs. Cette description sert autant à définir les capacités à développer qu’à fluidifier les échanges entre systèmes d’information.
En 2012, un article de Amit Singhal « Introducing the Knowledge graph ; things, not string” saluait l’arrivée du Google Knowledge Graph. Things, not string : tel devrait être également le slogan des échanges entre systèmes d’information.
Les choses sur lesquelles on a besoin d’information ne sont pas les chaines de caractères qui les désignent. Pas plus qu’elles ne sont la façon dont on les stocke ou on les transfère. On a besoin d’un niveau de représentation indépendant des plateformes ou des syntaxes des formats d‘échange pour dire que les données qu’on manipule sont bien liées à telle ou telle chose. Des métadonnées connectées dans un « Knowledge graph » sont typiquement une réponse à ce besoin.
Architecture d’entreprise, Virtual Knowledge Graph et Data Fabric
« Image extraite de l’article : Data Fabric Architecture is Key to Modernizing Data Management and Integration »
Un knowledge graph, consiste en une ou plusieurs ontologies formelles liées et des ensembles de données cohérents avec celles-ci. En créant les ontologies spécifiant les concepts de l’entreprise, on peut ensuite créer un « Virtual knowledge graph » (VKG). Il s’agit du concept autrefois nommé OBDA (Ontology-Based Data Access).
En utilisant des ontologies, de la fédération de requêtes SPARQL et du mapping (R2ML), cette approche offre un moyen d’interroger les différentes sources de données distribuées au sein de plusieurs systèmes en fonction des concepts métiers sur lesquels elles ont des informations. Elle permet en outre aux données de rester dans leurs bases d’origine pour une gestion plus agile et plus efficace.
Ici la description, via une spécification formelle, de composants de l’architecture d’entreprise, permet d’optimiser la construction d’autres composants d’architecture. Il existe par ailleurs des outils commerciaux et open source pour créer des VKG. Au-delà de la notion de VKG, c’est le concept de Data Fabric qui profite au mieux des Knowledge Graph. En utilisant la couche sémantique du graphe de connaissance pour établir la provenance, la qualité et le sens des données gérées dans les systèmes d’information de l’entreprise, on s’oriente vers une meilleure vue intégrée et unifiée de ces derniers. Ce que soulignait l’article publié en 2021 sur le site du Gartner“Data Fabric Architecture is Key to Modernizing Data Management and Integration” : “Data fabric must create and curate knowledge graphs”.
Architecture d’Entreprise : cas d’usage des Knowledge Graph
Certes, la construction et la curation desdits Knowledge Graph nécessitent des efforts. Cependant il existe des meilleures pratiques et des outils pour des résultats relativement rapides avec des solutions robustes et évolutives.
Deux orientations d’usages des knowledge Graph dans le domaine de l’Architecture d’Entreprise sont particulièrement intéressantes. L’une, déjà évoquée, porte sur l’interopérabilité sémantique via la spécification des concepts métiers pour cas d’usage analytique ou transactionnel. L’autre porte sur l’activation dynamique d’un méta-modèle des composants d’une entreprise pour guider des changements stratégiques. En spécifiant formellement les composants à connaître, ainsi que leurs interrelations, pour décider et suivre au mieux l’évolution des transformations, on peut construire un graphe de connaissance qui permettrait de réduire les incertitudes liées aux options de changement.
Les Knowledge Graphs aident à contextualiser les décisions liées à l’évolution du système d’information en reliant les éléments architecturaux aux facteurs d’influence externes, aux objectifs métier, aux contraintes opérationnelles et aux tendances technologiques. Cette vision holistique guide les décideurs vers des choix plus éclairés et alignés sur les objectifs stratégiques de l’entreprise. Par ailleurs, en spécifiant avec des métadonnées les relations entre les composants, les Knowledge Graphs facilitent l’analyse d’impact des changements. Cela permet de comprendre rapidement comment une modification dans une partie spécifique de l’architecture peut affecter d’autres composants, aidant ainsi à anticiper les conséquences potentielles et à simuler des scénarios pour prise de décision.
Mais si on veut un Knowledge graph d’Architecture d’Entreprise, contenant tous les composants de l’entreprise ainsi que leurs liens, comment procéder ? N’est-ce pas un travail trop complexe ?
Des ontologies modulaires pour gérer la complexité et la pluridisciplinarité
Un knowledge graph c’est une base de connaissance sous forme de graphe. Pour sa conception, il est crucial de clarifier les questions auxquelles elle devrait pouvoir répondre, ainsi que celles portant sur sa maintenance et son évolution.
Une approche clé pour assurer la flexibilité et la maintenabilité d’un knowledge graph consiste à le baser sur plusieurs ontologies modulaires inter-reliées, avec un noyau central. Chaque module peut alors être conçu pour traiter des concepts, des relations et des règles spécifiques à un sous-domaine d’expertise, ce qui en facilite la gestion et l’évolution avec les experts du domaine.
En reliant ces ontologies modulaires entre elles, on crée un réseau de connaissances. Cela permet de représenter des relations complexes entre les concepts qui transcendent les frontières des différents sous-domaines, offrant ainsi une vue globale et intégrée du domaine métier dans son ensemble. Or c’est typiquement un besoin des descriptions d’architecture de pouvoir représenter des couches d’architecture et leurs correspondances. Ou de présenter des perspectives spécifiques. Par exemple, la gestion des risques, l’architecture applicative, l’architecture des données, l’infrastructure technologique, l’évaluation de la performance …
Un noyau central définissant les fondamentaux de l’EA, via les concepts et relations réutilisables pour tous les modules, permettra l’inter-opérabilité. La référence à une ontologie de haut niveau (top-level) ou des « patrons » de conception servira à ne pas réinventer la poudre pour des problèmes généraux de conception déjà bien connus.
Bien entendu, la conception d’un Knowledge Graph d’Architecture d’Entreprise doit suivre les bonnes pratiques. En particulier, réutiliser autant que possible des ontologies existantes et des vocabulaires standards pour éviter la duplication d’efforts et promouvoir la cohérence avec les pratiques établies dans le domaine.
Des ontologies pour des Knowledge Graph agnostiques des cadres de référence
Les concepts décrits dans une ontologie d’Architecture d’Entreprise (ou module), existent indépendamment des cadres de référence ou langages de description. Car si ces derniers sont réutilisables pour les identifier et les définir, ni un glossaire, ni des textes descriptifs, ni des objets graphiques, ne spécifient formellement des concepts et des relations. « Things , not Strings « : une ontologie définit des choses et les labels donnés aux choses ne suffisent pas pour les définir. Si deux terminologies différentes désignent le même concept, on trouvera un concept et deux labels dans l’ontologie. Quand elles désignent l’une une spécialisation l’autre une généralisation, on définira les relations de subsomption et les caractéristiques propres des deux concepts. Et si au contraire elles désignent deux choses différentes et disjointes, on doit le définir également.
Une ontologie, c’est une représentation sémantique riche des entités et de leurs relations en mesure de suivre l’évolution des connaissances. En utilisant les standards du Web sémantique (RDF, RDFS, OWL), contrairement à certains langages de modélisation plus rigides, les Knowledge Graphs sont flexibles et extensibles. Ils permettent d’ajouter de nouveaux concepts, relations et attributs au fur et à mesure que l’architecture d’entreprise évolue, assurant ainsi une représentation toujours à jour et adaptable.
Pour prendre l’exemple du langage graphique de description d’architecture Archimate, les liens sont limités et certains concepts spécifiques à la stratégie d’offre, au marché, aux situations, aux aspects financiers, ne sont pas dans l’ensemble de ceux prédéfinis.
A contrario, un réseau d’ontologies modulaires peut spécifier des concepts dans tous les sous-domaines de gouvernance et de pilotage de l’entreprise et les relier aux capacités de l’entreprise et les composants qui les supportent. Tout Knowledge Graph exploitant ce réseau peut dès lors procurer une représentation plus riche, flexible et contextuelle des éléments clés éclairant les décisions qui engagent l’entreprise.
Architecture d’entreprise et continuum d’ontologies
Alliance autour de la technologie OntoPortal
La démarche de description d’architecture d’entreprise est continue, itérative et incrémentale. On peut difficilement arriver à une architecture unifiée unique qui satisferait à toutes les exigences de toutes les parties prenantes à tout moment et l’idéal d’avoir des documentations et des modèles à jour suivant toutes les perspectives est une utopie dont la mise en œuvre est dystopique.
Des plateformes pour réutiliser des ontologies consistantes et cohérentes, ou accéder à des patrons de conception et des outils de développement et de curation pour modéliser et implémenter de nouvelles spécifications, ont été mises en place dans différents secteurs d’industrie. Elles concrétisent une approche réellement FAIR des méta-données.
L’alliance ontoportal autour de l’outil éponyme (https://ontoportal.org) est significative du besoin de promotion de telles plateformes pour « le développement de référentiels d’ontologie – en science et dans d’autres disciplines ».
Le parallèle peut être fait avec la notion de Continuum d’Entreprise qu’on trouve dans Togaf. L’idée est d’organiser des artefacts d’architecture et des actifs de solutions réutilisables afin de maximiser les opportunités d’investissement dans l’architecture d’entreprise. Dans cette optique la construction de plateformes communes aux architectes d’entreprises pour recevoir, héberger, servir, aligner et permettre la réutilisation d’ontologies pour l’EA a tout son intérêt. On devrait y trouver différentes ontologies d’entreprise et des meta-modèles génériques à spécialiser ou étendre.
Un méta modèle d’entreprise générique et un langage graphique : EDGY
EDGY enterprise design facets
Si toute entreprise a sa propre dynamique, toutes les entreprises partagent le fait d’avoir des produits et/ou services, des offres portant sur ces produits, des processus supportant les opérations, des rôles, des acteurs, des applications des SI avec des composants, etc. On peut très bien s’entendre sur un vocabulaire et des axiomes logiques pour exprimer ce genre de choses et leurs liens.
Dans ce domaine, l’initiative de la communauté Intersection Group est à souligner. Car elle introduit, avec l’approche « Enterprise Design with EDGY » un langage graphique simple et expressif pour un méta-modèle d’entreprise transverse à tous les métiers. En effet, EDGY propose une vue unifiée et consolidée de l’entreprise à des fins de décision collaborative grâce à l’intersection entre trois perspectives : identité, Expérience et Architecture.
La première traite de la raison d’être de l’entreprise aussi bien que de sa culture. A ce sujet, le mantra « culture eats strategy at breakfast » illustre bien l’importance de ces concepts. La seconde focalise sur l’expérience procurée aux clients et aux autres acteurs. Une manière également pertinente de traiter dynamiquement de la valeur créée pour les parties prenantes. La dernière s’interroge sur comment orchestrer tout cela, en déclinant modèle d’affaires, modèle opératoire et composants d’architecture.
Le credo d’EDGY est d’avancer que les connecteurs nécessaires à créer entre des disciplines traitées aujourd’hui de façon trop isolée se trouvent à l’intersection desdites perspectives, où on trouvera les concepts de produit, organisation, marque.
L’approche EDGY propose les outils pour élaborer une représentation graphique commune, utile et transverse, des éléments clés de l’entreprise à des fins de décision. Cependant, il lui manque encore la dimension formelle des ontologies, pour disposer également d’une base de connaissances sémantiquement riche.
Un outil d’EA basé sur des ontologies: The Essential Project
Illustration du Meta-model d’essential avec zoom sur partie métier
Fournir pour la description des composants d’architecture, un méta-modèle à base d’ontologies, flexible et extensible, cela existe déjà. Dès 2009, «The Essential Project » a été lancé par l’équipe des consultants d’EAS (Enterprise Architecture Solutions) sur cette base, en modélisant des ontologies sous Protégé. La première version open source d’Essential (visant les capacités essentielles à une pratique d’EA) date de mars 2009. La mise en relation avec les concepts Togaf n’est arrivée qu’en 2015.
Certes, ce sont des demandes des utilisateurs qui ont conduit à la publication d’un mappage TOGAF vers Essential. Reste que, selon EAS, « le méta-modèle Essential est, en fait, plus riche en contenu et prend en charge tous les principaux frameworks EA tout en restant indépendant du framework ».
L’outil Essential a été placé « visionnaire » dans le Gartner magic quadrant 2023 des outils d’architecture d’Entreprise. Si on consulte Gartner Peer Reviews il est globalement bien noté. Avec des commentaires tels que ce dernier :” EAS has a powerful metadata repository that can cover multiple dimensions of the architecture. Also, the look and feel is very appealing, with easy to navigate reports ». Certes, à d’autres égards, notamment les représentations graphiques, il offre moins de richesse que d’autres alternatives.
Mais si l’essentiel recherché est d’avoir effectivement les bons liens entre composants, pour une bonne analyse d’impact, il correspond. Grâce à son métamodèle à base d’ontologies. Tandis que ceci est rarement capturé sans la moindre ambiguïté par un diagramme, au contraire d’un knowledge graph. De plus, si on part sur l’usage des technologies RDF et OWl, l’inter-opérabilité du référentiel d’architecture avec d’autres outils utilisés comme bases de modèles, de documentation ou d’exigence sera de-facto facilitée, éventuellement avec un VKG et des outils de conversion conformes à RML.
A quand un EAO comme OBO ?
Il manque toutefois un véritable consensus sur des spécifications formelles de conceptions partagées des domaines de connaissance en Architecture d’entreprise. I.E les ontologies du réseau modulaire évoquées précédemment, avec un moyen de généraliser ou spécialiser certaines. Tout autant qu’un moyen pour les partager (en mode FAIR) ainsi que disposer de services utiles sur tout le cycle de vie du (ou des) Knowledge Graph d’architecture qu’on peut construire à partir de ces spécifications.
On sait que dans certains domaines, cela existe, le plus connu étant l’OBO foundry pour la biologie et la biomédecine. Une communauté autour d’OBO a développé de bonnes pratiques autant pour l’évaluation, la curation, la réutilisation des ontologies que pour la constitution d’outils utiles à leur développement. On peut évoquer des outils comme ODK, ROBOT, ou OntoPortal.
Comme on peut évoquer de nombreux outils, conformes à RML, qui faciliteront le mapping en RDF de sources de données existantes pour la construction des Knowledge Graph d’EA en entreprise.
Si les bénéfices et les outils existent, une question demeure. Pourquoi nulle communauté d’architecte, éventuellement avec le financement d’une association de standardisation, n’a construit d’EA Ontology foundry ? Est-ce parce que financer une telle démarche serait contre-productif pour certains modèles d’affaires associés aux cadres de références d’EA existants ?
