urbanisation-si.com

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 Graphs 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 les concepts de connaissance 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 Graphs 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 tels ArchiMate ou la terminologie de TOGAF, a peu d’intérêt. On restreint ainsi une richesse d’expression sémantique 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. Aussi 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

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 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 strings » saluait l’arrivée du Google Knowledge Graph. Things, not strings : 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 du Gartner
« 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 Graphs. 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 Graphs

Certes, la construction et la curation desdits Knowledge Graphs nécessitent des efforts. Cependant, il existe de meilleures pratiques et des outils pour des résultats relativement rapides avec des solutions robustes et évolutives.

Deux orientations d’usages des Knowledge Graphs 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étamodè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 l’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 ?

Vous trouverez des éléments de réponses dans le prochain article
" Knowledge Graph et Architecture d’Entreprise (2/2) ".

Sabine BOHNKÉ

« La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information. »

Albert Einstein

Compléments de lecture

Métamodèle TOGAF - ArchiMate

• Méta-physique ? Non, méta-modélisation !
    
• Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
• L’extension « Modélisation de processus métier » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
   
• ArchiMate mémento : Alignement de la couche métier avec les couches inférieures - 8

Les critères d'un bon modèle

• Le PILI était-il un bon modèle ?