Tout paysage informatique d'entreprise se compose de nombreuses applications, dont la plupart ont leurs propres bases de données. Ces bases de données stockent des objets d'information qui représentent des objets métier, des événements et des phases de processus métier. De nombreux objets de processus métier sont « reflétés » dans plusieurs bases de données à la fois : par exemple, un équipement d'une entreprise industrielle est décrit de différents points de vue dans les systèmes comptables, la gestion des réparations et de la maintenance, la gestion de la production, etc.
Pour que les applications métier qui automatisent différents processus métier puissent fonctionner ensemble d'une manière ou d'une autre, elles doivent être intégrées : implémenter des produits de la classe MDM (Master Data Management, système de gestion des données de base) et ESB (Enterprise Service Bus, bus de service permettent en quelque sorte de gérer l'échange d'informations entre une variété de solutions multi-plateformes. Ceux qui ont fait face à une telle intégration savent bien qu'il s'agit d'un travail long, difficile et ingrate.
Mais que se passe-t-il s'il existe un moyen de se débarrasser de tous les problèmes d'intégration à la fois ? Une telle "balle magique" existe, et elle s'appelle - architecture centrée sur les données. Son idée principale est de placer les données, et non les applications métier, au centre de l'architecture informatique de l'entreprise. Ce principe est décrit dans le Manifeste de l'architecture centrée sur les données et dans La révolution centrée sur les données : restaurer la santé mentale des systèmes d'information d'entreprise .
Imaginez qu'une entreprise dispose d'un seul entrepôt de données virtuel dans lequel chaque objet ou événement métier existe dans une seule instance. Pour plus de clarté, vous pouvez imaginer que l'idée du système MDM a été portée à une incarnation logique complète, et c'est MDM qui est le référentiel de toutes les données d'entreprise ; les applications métier n'ont pas leur propre SGBD et ne fonctionnent qu'avec des objets de données de MDM. Les avantages de cette architecture sont évidents :
Le besoin de procédures d'intégration est éliminé une fois pour toutes.
Les coûts de stockage des données sont réduits en éliminant plusieurs copies de chaque objet métier sur différents systèmes.
L'analyse et l'aide à la décision sont simplifiées, car désormais, pour construire n'importe quelle tranche analytique, vous n'avez plus besoin d'extraire et de coller des données de différents systèmes pendant des mois - elles sont toujours à portée de main.
, -.
- , . -- -.
« - », . - , -?
, , , -, , , -. , — , , - -. , , .
, , , «» ( ) , — - . , - .
«» (corporate data cloud) (data lake)? — , . data lake , - - , - « — ». , ...
— , . , , , ; -, . , ; , . (. OWL W3C).
, , . ( ), , , . , , .
, (corporate knowledge graph), .
, - ? :
. — , «» .
() . , . . .
API , REST, GraphQL, SPARQL.
.
.
(data provenance), (data quality), .
. - , — , , (. SHACL SHACL Advanced Functions). - low code: , - , -, , « » , .
Des plates-formes répondant à ces exigences existent déjà et sont utilisées à la fois sur les marchés russes et étrangers.