urbanisation-si.com

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’interopé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 Graphs 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étadonné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 métamodèles génériques à spécialiser ou étendre.

Un métamodè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étamodè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 se 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ù l’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étamodè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étamodè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 l’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 l’on part sur l’usage des technologies RDF et OWl, l’interopé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 Graphs 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 ?

Sabine BOHNKÉ

"Le vrai signe d'intelligence n'est pas la connaissance, c'est l'imagination."
Albert Einstein

Compléments de lecture

• Knowledge Graph et Architecture d’Entreprise (1/2)
    
• Comment vérifier un modèle ? Exemple de simulation d’un processus métier BPMN
   
• Quel outil ArchiMate pour modéliser vos architectures d’entreprise sources et cibles, évaluer les écarts, analyser les impacts et élaborer des trajectoires de transformation ? Obeo SmartEA S.1 Ep.1
   
• Comment consolider un référentiel centralisé TOGAF rassemblant les autres référentiels Stratégie, Métier, Applications, Infrastructure… ? Obeo SmartEA S.1 Ep.2

• Exemple de méthode d’Architecture d’Entreprise d’un grand cabinet de conseil : EAM Enterprise Architecture Management de McKinsey