Linked Data Connectivity – Graphen sind die "Crux of the Biscuit"
Der Geschäftskontext & die Herausforderung
Große Hersteller erweitern ihre Produkte um intelligente Dienste, die auf Daten basieren. Die Daten umfassen sowohl solche, die in bestehenden Anwendungen entlang der Lebenszyklen gepflegt und gespeichert werden, als auch solche, die im Feld gewonnen werden. Dies betrifft nicht nur die Produkte, sondern auch die Maschinen, welche die Produkte herstellen, denn derzeit gibt es keinen geschlossenen Kreislauf, der den gesamten Lebenszyklus abdeckt.
Dies steht im Widerspruch zu dem, was Product Lifecycle Management (PLM) einst versprach: den gesamten Produktlebenszyklus von den Anforderungen bis zur Auslieferung abzudecken. Leider ist PLM immer noch an Engineering-Prozesse gebunden, im Wesentlichen an PDM-Systeme rund um das V-Modell. Da Sensoren die Bausteine für höherwertige Service-Software sind, wird die Analyse der Auswirkungen von Felddaten auf die Produktentwicklung immer wichtiger. Wenn also OEMs (oder andere diskrete Hersteller) Dienstleistungen als neues Geschäftsmodell verkaufen wollen, sind konsistente und verknüpfte (logisch verknüpfte) Daten über alle Funktionen hinweg eine starke Anforderung. Andernfalls werden solche Nutzungsszenarien wie das Einspielen von Software-Updates über die Luft oder Feedback-Schleifen aus der Felddatenanalyse Zukunftsmusik bleiben.
Technologien, Lösungen, Lösungsansätze
Welche Technologien und Lösungen gibt es bisher? Ich möchte verschiedene Kategorien diskutieren:
Data Exchange-Lösungen sind eine naheliegende Form der Datenverfügbarkeit, bei der ein System Daten an ein anderes System liefert. Dies geschieht entweder durch direkten Datenaustausch via API oder über eine Middleware/Ressource Bus, der den Zugriff auf die angeschlossenen Autorensysteme standardisiert. Die Middleware ist jedoch nur als Datenlieferant zu sehen. Sie stellt in keiner Weise sicher, dass die Daten verschiedener Anwendungssysteme logisch miteinander verbunden oder konsistent sind. Dies geschieht typischerweise durch den Einsatz von manuell erstellten Mapping-Tabellen. Auf der Basis solcher lokaler Mapping-Tabellen sind jedoch globale Aufgaben wie die Rückverfolgbarkeit entlang der Wertschöpfungskette nur schwer zu realisieren. Dennoch könnte Middleware als Datenlieferant fungieren, wenn "on-premise"-Lösungen favorisiert werden. Trotzdem können solche Datenaustauschlösungen einen guten Job machen, wenn Daten zwischen zwei Unternehmen nur ausgetauscht werden müssen.
One Storage Place-Lösungen zielen darauf ab, entweder Daten an einem Ort zu speichern oder ganze Anwendungen an einem Ort zu hosten. Eine neue Form, die in den letzten Jahren entstanden ist, sind Data Lakes. Sie sind darauf ausgelegt, Massendaten jeglicher Art in einem Container zu speichern. Die Idee ist, Big Data in diesen Lake zu werfen und KI-Techniken anzuwenden, um wertvolle Erkenntnisse zu gewinnen. Es hat sich jedoch herausgestellt, dass dies in vielen Fällen aufgrund eines Problems, das als "Datenaufbereitung" angesprochen wird, nicht funktioniert, siehe [3]. Der Autor, Alfrick Opidi, schätzt, dass die Datenaufbereitung 80 % der Herausforderung ausmacht. Die Online-Zeitschrift industryweek [4] berichtet, dass das International Institute for Analytics schätzt, dass weniger als 10 % der KI-Pilotprojekte den vollen Produktionsumfang erreicht haben. Dies wird übrigens nicht nur in der diskreten Fertigung und in der Prozessindustrie erkannt, sondern auch im Finanzwesen, wo KI-Techniken eingesetzt werden, um Erkenntnisse über Geldwäsche oder andere Arten von Finanzkriminalität zu gewinnen [5]. Daten werden in Silos gespeichert und sind systemübergreifend inkonsistent, was verhindert, dass KI-Techniken (in der Tat maschinelles Lernen) richtig angewendet werden können. So betrachtet Allan Frank [6] von Think New Visions die Verfügbarkeit von Knowledge Graphen als einen Wettbewerbsvorteil in der KI. Aus dieser Diskussion folgt, dass Massenspeicher und KI allein nicht die gewünschten Datenerkenntnisse erzielen werden. Dennoch kann davon ausgegangen werden, dass Data Lakes oder ähnliche Technologien die zusätzlichen Big Data speichern werden, da es keine anderen etablierten Speichermedien für solche Daten gibt. Es zeigt sich auch, dass Unternehmen bereits eine ganze Reihe von Data Lakes für unterschiedliche Zwecke eingerichtet haben, was die Wahrung der Quer-Konsistenz nochmals erschwert. Aber es gibt all diese anderen Datensysteme, die sich über die gesamte Wertschöpfungskette erstrecken. Was ist mit denen? Sollen diese Daten auch in die Seen geworfen werden.
Cloud-Lösungen sind ein auf Outsourcing basierender Service, der von Anbietern angeboten wird, um die Unternehmensanwendungen entweder in private oder öffentliche Clouds zu verlagern. Wie hängt das mit der erforderlichen Konnektivität von Daten und der Verfügbarkeit von Geschäftskontexten zusammen? Warum sollten die Daten besser verbunden sein, wenn die Anwendungen in einer Cloud gehostet werden? Dies ist nicht ersichtlich. Es gibt eine Diskussion, die von Oleg Shilovitsky in seinem LinkedIn-Artikel "Oracle Cloud PLM - Unified Data Model, Frequent Upgrades And Less Integrations?" [7], in der er den Artikel "PLM - A New Hope" von Avery De Marr zitiert [8]. Folgendes Zitat finde ich interessant:
Fragen Sie sich selbst - können Sie Daten aus Ihrem Produkt, Ihrer Fertigung, aus den sozialen Medien und dem größeren Web im Allgemeinen ziehen, um schneller als Ihre Konkurrenz eine Qualitätslösung zu finden? Können Sie das in Echtzeit tun? Verfügen Sie über die Grundlage, um Informationen aus Ihrem Betrieb in Ihrem System of Record zu kombinieren und intelligent auf diese Erkenntnisse zu reagieren? Können Sie dies ohne ein Heer von Ressourcen tun, weil Ihr System Ihnen diese Erkenntnisse liefert? PLM4.0 gibt Antworten auf diese Fragen.
Ich verstehe, es geht um die Verfügbarkeit von Daten und die Aktualität. Die Verfügbarkeit der Daten kann sich entweder auf das Ziehen der Daten beziehen, um sie in der Cloud zu speichern, oder auf das Ziehen der Daten, um zur Abfragezeit Zugriff zu haben, während sie irgendwo anders gespeichert sind. Letzteres macht allerdings aus Sicht eines Cloud-Anbieters nicht viel Sinn. Wenn man sie zieht, um sie zu speichern, dann hat man sie in Anwendungen an einem Ort gespeichert. Das ist der wesentliche Sinn der Cloud, sie an einem Ort zu haben und Sie als Kunde können sie einfach konsumieren. In Bezug auf die Verfügbarkeit von Daten entlang der Wertschöpfungskette ist das Cloud-Argument also ähnlich wie das Data-Lake-Argument: Es bezieht sich auf den Speicherort, auch wenn die Daten innerhalb dieses Speicherorts immer noch verteilt und auf verschiedene Anwendungen verteilt sind. Was ist dann unter dem Gesichtspunkt der Konnektivität und Konsistenz anders als bei On-Premise? Als Zusammenfassung dieser Diskussion würde ich argumentieren, dass der gewünschte Geschäftskontext, der durch das "Herstellen von Verbindungen" zwischen Geschäftsobjekten erzeugt wird, nicht erreicht werden kann, wenn wir die Daten einfach an denselben Ort verschieben.
Data Warehouse-basierte Lösungen wurden für so genannte "monolithische Lösungen" in Betracht gezogen. Die Idee war, diese Art von Technologie als Allzweckspeicher zu verwenden, der als Datenbank für integrierte Daten fungieren würde. Die integrierten Daten könnten dann visualisiert oder an andere Anwendungen weiterverteilt werden. Da Data Warehouses auf relationalen Tabellenstrukturen basieren, wird es sehr schnell sehr komplex, wenn man ein Datenmodell erweitern oder modifizieren möchte, um viele Anwendungsfälle abzudecken. Dies ist wahrscheinlich der Grund, warum solche Projekte oft gescheitert sind. Die geschäftlichen Anforderungen der Projekte änderten sich schneller, als die IT-Teams bereit waren, die Lösungen zu implementieren. Aufgrund der Relationstabellenkomplexität solcher Warehouses gingen menschliche Experten, die die Datenmodelle verwalteten, auf dem Weg dorthin verloren. Das ist der Grund, warum Warehouses nicht als globale logische Verknüpfung fungieren können. Es ist das falsche Werkzeug für diese Aufgabe.
Data Warehouses dienen jedoch auch als zweckgebundeneDatenaggregationswerkzeuge, hauptsächlich zur Bereitstellung vonGeschäftsleistungsindikatoren. Die Daten werden aus einem oder mehrerenAnwendungssystemen extrahiert und durch Abstrahieren der Daten in höherwertigeEinheiten von Interesse aufgewertet. Diese werden in einem Data Warehousegespeichert und typischerweise mittels Cockpits, z.B. BI-Anwendungen, zumKonsum angeboten. Meistens werden solche Lösungen durch spezifische analytischeAnwendungsfälle getrieben, was sich sowohl in den zugrundeliegendenDatenmodellen als auch in den UIs widerspiegelt. Abstrahierend isttypischerweise die hierarchische Relation, die zur Implementierung derAggregation verwendet wird. Andere Arten von semantischen Relationen sind imAllgemeinen schwer zu implementieren, da dies wiederum die Komplexität derRelationstabellenstrukturen erhöht.
All-in-One-Vendor-Strategie Das Gleiche gilt für große Anbieter, die eine "All-in-One-Vendor"-Strategie propagieren, die Datenlücken verschwinden lassen würde, weil man alle seine Lösungen von nur einem Anbieter gekauft hat. Solche Strategien sind eher ein Geschäftsansatz als ein technologischer, deshalb nenne ich es "Strategie" und nicht Lösung. Typischerweise sind große Anbieter eigentlich Zusammenschlüsse von kleineren Unternehmen, die sie im Laufe der Zeit aufgekauft haben. Auf diese Weise können sie eine reiche Vielfalt an Produkten und Dienstleistungen anbieten, haben aber gleichzeitig Probleme mit ihrer eigenen Heterogenität, was sich auf das Anwendungsportfolio auswirkt, das sich gegenseitig nicht versteht. Wenn dies der Fall ist, werden Konnektivität und Konsistenz nie das Licht der Welt erblicken. Für ein kleineres Unternehmen kann es aber durchaus ein sinnvoller Ansatz sein, sich für einen Anbieter zu entscheiden, weil das Anwendungsportfolio noch überschaubar ist. Größere Unternehmen zögern in der Regel aufgrund von Risikokalkulationen, dies zu tun.
Graphen als natürliche, ganzheitliche Repräsentation der Konnektivität zwischen diskreten Entitäten
Lösungen mit nur einem Speicherort suggerieren manchmal, dass die Verfügbarkeit von Daten an einem Ort oder bei einem Anbieter bereits die Lösung ist. Dies ist leider nicht der Fall, wie wir oben dargelegt haben. Ebenso ersetzt Echtzeit-Verfügbarkeit nicht die logische Konnektivität und Konsistenz. Wenn Sie unverbundene und inkonsistente Daten haben, können Sie keine Erkenntnisse aus ihnen gewinnen, selbst wenn sie direkt vor Ihrer Nase liegen. Die wesentlichen Merkmale zur Darstellung von Lebenszyklusdaten sind logische Konnektivität und Konsistenz. Die Fähigkeit, Fakten über die gesamte Wertschöpfungskette hinweg miteinander zu verbinden, ist das grundlegende Werkzeug, das wir brauchen, um geschäftlichen Kontext zu liefern - und damit das wesentliche Merkmal, die oben erwähnte Feedback-Schleife zu schließen. Wo die Daten gespeichert werden, ist von sekundärer Bedeutung. Ebenso wie es von sekundärer Bedeutung ist, sie in Echtzeit verfügbar zu haben. Das schließt natürlich Fälle nicht aus, in denen Echtzeit-Verfügbarkeit und logische Konnektivität/Konsistenz erforderlich sind.
Wie können wir logisch verbundene und konsistente Daten herstellen? Betrachtet man die Komplexität heutiger Datenlandschaften auch in mittelständischen Unternehmen, so bleibt uns nur die Wahl, die Welt in ihrer Vielfalt zu akzeptieren. Folglich muss die logische Datenkonnektivität von der bestehenden Datenwelt entkoppelt werden. Die wichtigen Geschäftsobjekte, die sich auf Daten in Autorensystemen einschließlich Data Lakes beziehen, müssen abstrahiert und verknüpft werden. Die entstehenden Strukturen sind dann, wie oben angedeutet, Graphen (EKGen), deren Knoten Geschäftsobjekte darstellen und deren Kanten semantische Beziehungen zwischen ihnen repräsentieren. Solche Graphen sind die natürliche Repräsentation für den Digital Thread, der Objekte der realen Welt in der Fertigung oder auf der Straße mit ihren Digitalen Zwillingen verbindet. Technisch gesehen ist dies meine Vorstellung von dem, was Joe Barkai [9] meint:
Das vernetzte Unternehmen ermöglicht es jedem Stakeholder, Daten aus vielen relevanten Quellen zu analysieren, Lösungen zu entwickeln und Auswirkungsanalysen durchzuführen, die alle Funktionen und Phasen des Produktlebenszyklus berücksichtigen und so früh wie möglich zu besseren Entscheidungen führen.
Viele Forscher wie, z.B. Jens Göbel [10], argumentieren für die Notwendigkeit eines Meta-PLMs. Aus den oben genannten Gründen würde ich behaupten, dass Graphen am besten geeignet sind, als grundlegende Datenstruktur für solche Meta-PLMs zu fungieren.
Hedberg [11] bemerkt einen Mangel an Graph-basierter Forschung im PLM, was seiner Ansicht nach daran liegt, dass der Großteil der Forschung immer noch auf das Datenmanagement in der Fertigung fokussiert ist.
Ein kurzer Ausflug in die Welt der Musik zeigt, dass die gleiche Art von Konnektivität wichtig ist, um die Arbeit eines Künstlers zu verstehen. Es ist der Kontext!
...zuerst scheinen die Dinge unverbunden zu sein, aber langsam beginnt sich ein Muster herauszukristallisieren, da immer mehr der Stücke zu interagieren scheinen...".
Das ist eine schöne Darstellung von Frank Zappas "konzeptioneller Kontinuität", die ich auf der Webseite von Dweezil Zappa gefunden habe [12]. Dort heißt es, dass die Arbeit des Künstlers im "Frank Zappa art work context" dargestellt wird, wobei der Apostroph ("Symbol für das Zusammenfügen zweier Wörter") das Bindeglied ist, das seine Kunstwerke zusammenklebt, das Bindeglied ist die "crux of the biscuit", das der Kombination eine höhere Bedeutung verleiht [13]. Diese Art der ganzheitlichen Betrachtung lässt sich analog auch auf unseren geschäftlichen Kontext anwenden. Denkt man in Graphen, kann man den Digitalen Zwilling relativ zur Aufgabe des Anwenders oder zu den Erkenntnissen, die man gewinnen will, definieren. Ein persistenter EKG ermöglicht die Rückverfolgbarkeit, ein wesentliches Merkmal des Systems Engineering, und es könnte daher eine Diskussion darüber auslösen, wie datengetriebene vs. modellgetriebene Entwicklung am besten erreicht werden kann. Wie können solche Graphen erstellt werden und was sind die wichtigsten Voraussetzungen für pragmatische Lösungen?
Very Large Graphs – Scalability of Graph Computation
Aus der schieren Menge an heterogenen Daten, die in größeren Unternehmen gespeichert werden, ist ersichtlich, dass EKGen in der Regel sehr große Graphen sind, konkret schnell mal etliche Billionen von Objekten zusammen mit einem Vielfachen an Verknüpfungen. Folglich müssen automatische Techniken zur Berechnung und Aktualisierung des/der Graphen zum Einsatz kommen.
Natürlich gibt es auch Möglichkeiten zur manuellen Erstellung von Domänen-Ontologien, Topic Maps und Standardisierungsmaßnahmen mit Hilfe von Beschreibungssprachen wie OSLC, RDF oder OWL, wie Nicolas Figay [14] im Zusammenhang mit PLM diskutiert. Die manuelle Bearbeitung und Pflege solcher Strukturen ist jedoch aufwändig, erfordert Harmonisierungsaufwand und skaliert daher meiner Meinung nach nicht mit den Unternehmensdaten. Zudem ist der wesentliche Innovationstreiber bei den Prozessen die Automatisierung und die Automatisierung erfordert vernetzte Lebenszyklen. Und das wiederum erfordert, dass sowohl existierende Datenlandschaften als auch die Felddaten so schnell wie möglich einbezogen werden. Wer will schon das braune Feld mit OSLC-Tags markieren? Und nebenbei bemerkt, wenn Sie wirklich den Aufwand betreiben wollen, OSLC zu implementieren, wird dies wieder nur zu einer standardisierten lokalen Konnektivität zwischen den Systemen führen. Und warum? Weil der Instanzgraph nicht wirklich von den Autorensystemen entkoppelt ist, sondern nur die Beschreibungssprache.
Andere Ansätze versuchen, der steigenden Datenkomplexität durch die Einführung standardisierter Objektmodelle zu begegnen. Im Jahr 2019 schlugen die NIST-Forscher Thomas Hedberg et.al. [11] vor:
Eine Architektur für unternehmensübergreifende Verbindungen auf Basis des Lifecycle Information Framework and Technology (LIFT)-Konzepts [12]. Die Definition der Global Handle Registry, Intermediate Handle Registry und Local Handle Services stammen aus [35] und sind gemäß RFC 3650 [36], RFC 3651 [37] und RFC 3652 [38] standardisiert
Die Grundidee ist, Daten mittels eines globalen Objektmodells zu speichern, in dem die Knoten und die Kanten des EKGen standardisiert sind. Dieser Ansatz würde auf der Basis von automatischen Generierungstechniken gut funktionieren. Die Erfahrung in unseren Kundenprojekten hat uns jedoch gezeigt, dass dieser Ansatz aus akademischer Sicht zwar sehr sinnvoll, aber angesichts der Komplexität der Daten in großen Unternehmen unserer Erfahrung nach kaum zu realisieren ist. Die Daten so zurechtzuschneiden, dass sie in ein starres Standardmodell passen, um die Komplexität zu reduzieren, kostet viel Zeit und Mühe und ist letztlich weitaus aufwändiger, als die Welt in ihrer Komplexität zu akzeptieren und Lösungen auf Basis intelligenter Analytik bereitzustellen.
Automatisierte Berechnung des Graphen
Im Hinblick auf die voraussichtliche Größe des Graphen ist seine automatische Berechnung aus vorhandenen Firmendaten unumgänglich. Dieser Prozess kann jedoch nicht vollautomatisch erfolgen. Dafür gibt es eine Reihe von Gründen, von denen ich die wichtigsten nenne:
- Die Erstellung des semantischen Graphenmodells folgt einem Interessenprofil, eine Maschine kann nicht entscheiden, was interessant ist (zumindest noch nicht)
- Das intellektuelle Wissen über die Datenverarbeitungsprozesse steckt in den Köpfen von Experten und muss erst in analytische Regeln umgesetzt werden.
- Die Entscheidung, welche Daten für den konkreten Fall in Frage kommen oder welche Art von Informationen für den Benutzer relevant sind, bleibt eine menschliche Entscheidung, etc.
Graph-basierte Produktlebenszyklus-Lösungen
Deloitte [15] behaupten, dass Semantische KI der Schlüssel zu kollektiver Intelligenz ist. Sie sehen eine symbiotische Verbindung zwischen EKGen und KI-Technologie, die notwendig ist, um leistungsfähige KI-basierte Entscheidungsfindung zu etablieren. Genau das habe ich oben argumentiert, als ich über das Problem der Datenaufbereitung gesprochen habe. EKGen liefern Kontext, sie sind das Langzeitgedächtnis der KI. Abgesehen von der KI-basierten Entscheidungsfindung gibt es jedoch eine ganze Reihe von Herausforderungen, die entlang des Produktlebenszyklus mit Hilfe von Produktgraphen (PG) gelöst werden können, einer speziellen Art von EKG, die alle relevanten Artefakte für eine Traceability-Lösung entlang des Produktlebenszyklus verbindet. Im Folgenden werde ich eine Reihe von Anwendungen vorstellen, die bestimmte Aspekte der Rückverfolgbarkeit lösen, ohne Anspruch auf Vollständigkeit. Wichtig ist jedoch, dass es sich bei diesen Anwendungen um Aufgaben handelt, die bereits mit erheblichem manuellem Aufwand bewältigt werden. Dies deckt sich mit den Erkenntnissen von Thomas Hedberg et.al. [11], die eine Studie eines anderen NIST-Forschers, Gary Anderson [16], zitieren, der den "Economic Impact of Technology Infrastructure for Smart Manufacturing" betrachtet und dabei die nahtlose Übertragung digitaler Informationen als einen wesentlichen Treiber nennt.
Für den Teil des Produktlebenszyklus, der von der Konstruktion bis zur Produktion reicht, ergab eine Studie, dass allein der Übergang von papierbasierten Prozessen zu (digitalen) modellbasierten Prozessen eine Reduzierung der Zykluszeit um etwa 75 Prozent bewirken würde [2]. Darüber hinaus könnten Hersteller durch verbesserte Sensorik und Überwachung, nahtlose Übertragung digitaler Informationen und Fortschritte bei der Analyse von Daten und TrendsSeite 2JCISE-19-1116, Hedberg jährlich 30 Milliarden US-Dollar einsparen
Rückverfolgbarkeitslösung (Transparenz, Replizierbarkeit, Bestätigbarkeit)
- Impact Analysis bezieht sich auf Änderungen und deren Auswirkungen auf nachfolgende Prozesse
- Coverage Analysis untersucht, wie Anforderungen in nachfolgenden Prozessen erfüllt werden
- Projektstatusanalyse nutzt die Traceability-Funktion des PG, um Transparenz über Status und Fortschritt eines Entwicklungsprojekts zu schaffen
- Wiederverwendung von Produktkomponenten bietet Trace-Links, die es ermöglichen, Aggregationen von Anforderungen zusammen mit den zugehörigen operativen Artefakten für neue Produkte wiederzuverwenden
- Testoptimierung ermöglicht die Bewertung von Tests auf Basis von verknüpften Anforderungen, Quellcode, Testfällen und Testergebnissen. Im Falle von Änderungen und Fehlern kann entschieden werden, welche Tests durchgeführt werden müssen und welche redundanten Tests vermieden werden können.
- Mit der Zertifizierung lässt sich nachweisen, ob alle Anforderungen erfüllt sind
- Reengineering nutzt Trace-Links, um einen Teil der Erkenntnisse aus dem Reverse Engineering eines Systems zu erfassen
- Risikomanagement sichert das Wissen durch die Verknüpfung von Komponenten und reduziert das Risiko, falls ein Teammitglied mit substantiellem Wissen das Projekt verlässt
Neben Traceability-Lösungen, die vorwiegend Engineering-Aufgaben abdecken, können EKGen sehr effektiv eingesetzt werden, um die Lücke zwischen Engineering und Fertigung zu schließen. In der Fertigung liegt der Fokus jedoch weniger auf Traceability als vielmehr auf der Produktionsplanung. Interessante Forschungen werden von den Fraunhofer-Forschern Oliver Riedel [17] "Trends towards Engineering Excellence" und Rainer Stark [18] durchgeführt, der sich auf
eine vollständige Digitalisierung der Produktentwicklungs- und Planungsprozesse - damit Sie als Hersteller oder Anwender die späteren Phasen des Lebenszyklus Ihres Produkts frühzeitig berücksichtigen können.
Neben Engineering und Fertigung können auch andere Teilprozesse wie Produktportfolio-Planung, Aftersales und Beschaffung von der vernetzten Wertschöpfungskette deutlich profitieren.
Konfigurierbare Lösungen
Die Datensignatur eines Unternehmens ist individuell, daher muss auch der Analyseprozess, der den Graphen berechnet, individualisiert werden. Gleichzeitig muss das semantische Graphenmodell leicht erweiterbar und im laufenden Betrieb modifizierbar sein. Dies erfordert eine low-code konfigurierbare Lösung. Sowohl das semantische Graphenmodell als auch die Analytik, die den Graphen auf Basis des Modells berechnet und aktualisiert, werden so spezifiziert, dass der Graph bottom-up aus den gegebenen Daten berechnet werden kann. Die Konfiguration ist auch deshalb wichtig, weil die Kunden produktive Lösungen in Wochen und nicht in Jahren haben wollen.
Inkrementelles Aufsetzen des Graphen: Graphenfälle beziehen sich auf Nutzungsszenarien, in denen ein Satz von Benutzerrollen bestimmte Informationsanforderungen enthält, die erfüllt werden müssen. Typischerweise werden die zu verknüpfenden Daten für einen ersten Fall in einer definierten Anzahl von relevanten Datenquellen gespeichert. Da die Generierung des Graphen nach einem erweiterbaren semantischen Datenmodell erfolgt, können weitere Anwendungsfälle hinzugefügt werden, indem der Umfang des semantischen Modells sowie die Analytik erweitert werden. Ein solcher inkrementeller Aufbau des Graphen garantiert einen schnellen Nutzen für den Kunden und damit die Akzeptanz bei den Anwendern. Auf diese Weise kann das relevante Unternehmenswissen kontinuierlich um zusätzliche Prozesse und Lebenszyklen erweitert werden.
Zusammenfassung & Schlussfolgerungen
In diesem Artikel habe ich mich mit dem Thema der logischen Konnektivität, angewandt auf den Produktlebenszyklus, befasst, indem ich behauptete, dass Graphen - als Lingua Franca - die natürliche Repräsentation zur Erfassung von Unternehmenswissen sind. Ich habe bestehende Technologien, Lösungen und Ansätze entlang der kritischen technischen Merkmale Konnektivität und Konsistenz verglichen. Natürlich lassen sich die Lösungskategorien in der Realität nicht genau trennen, da wir Mischformen finden. Graphen könnten zum Beispiel sehr gut in einer Cloud gehostet und betrieben werden. Das würde das Leben z. B. aus Sicht des Betriebs sehr erleichtern. Allerdings ist ein EKG eine logische Darstellung von Unternehmenswissen, kein Speicherplatz. Der Graph existiert als eigenständige Entität, entkoppelt von den Autorensystemen, aber wieder verbunden mit den Originaldaten. Er dient als leistungsfähige Basis für Inferenzprozesse, die für die Automatisierung von Geschäftsprozessen als einer der Haupttreiber für Innovationen wichtig sind. Mit Hilfe solcher Graphen ist es einfach, den Digital Thread, der den gesamten Produktlebenszyklus verbindet, zu modellieren und Traceability-Lösungen jeglicher Art zu ermöglichen. Darüber hinaus geht der Einsatz von Knowledge Graphen mit einer Methodik einher, die durch konfigurierbare Lösungen eine schnelle Realisierung von Anwendungsfällen ermöglicht. Dies ist besonders wichtig im Hinblick auf den zu modellierenden Analyseprozess zur Berechnung und Aktualisierung der Grapheninstanz aus den angeschlossenen Autorensystemen und Datenbanken. So möchte ich mit einem mir sympathischen Zitat von Oleg Shilovitsky [19] schließen:
Graphen sind schön und faszinierend. Man kann denken, dass alle erfolgreichen Unternehmen des 21. Jahrhunderts auf dem Netzwerkeffekt aufgebaut wurden. Graphdatenbanken bergen in den nächsten Jahren viel unausgeschöpftes Potenzial, da sich die Unternehmen in Richtung einer besseren Analyse und Datenexploration bewegen werden.
Disclaimer
Ich bin Mitgründer und CEO von CONWEAVER. Mit unserer Linksphere Low Code Big Graph Platform befähigen wir unsere Kunden, schnell und flexibel Knowledge Graph-Lösungen über verschiedene Datenquellen hinweg zu konfigurieren. Meine Meinung kann ungewollt voreingenommen sein.
