Von der Datenagilität zum "Digital Business" – ICMS und die Nutzung der CortexDB
Das "digital business" ist zum Schlagwort für das geworden, was Unternehmen nach Ablauf dieses Jahrzehnts tun müssen. Trotz seiner Popularität ist seine Definition oft unklar. In seinem technischen Kern geht es um einen Wandel in der Beschaffung von Geschäftsdaten, von hauptsächlich aus internen Geschäftsprozessen zu den (weitgehend) externen Daten aus der realen Welt. Lassen Sie mich erklären...
Bereits im letzten Jahrtausend waren die Daten, die die Unternehmen für ihren Betrieb benötigten, gut strukturiert, (angemessen) gut verwaltet und stammten fast ausschließlich aus den eigenen Geschäftsbereichen. Dabei handelte es sich um prozessgesteuerte Daten: die rechtsverbindliche Grundlage des Unternehmens [1]. Relationale Datenbanken – hochgradig strukturiert, sorgfältig verwaltet, aber resistent gegen Veränderungen – beherrschten die Datenwelt. Für die Entscheidungsfindung war Data Warehousing der entscheidende Faktor.
In den letzten zehn Jahren hat sich die Datenlandschaft jedoch völlig verändert. Komplexität und Datenvolumen steigen nicht nur durch die Automatisierung von Prozessen und die Forderung nach mehr Agilität. Social Media, Click Streams und das Internet der Dinge haben riesige Mengen an Roh- und wenig vorverarbeiteten Daten hervorgebracht: extern bezogen, schlecht strukturiert, schwach reguliert und mit sich ändernder Struktur im Laufe der Zeit. Der Fokus der heutigen digitalen Unternehmen liegt auf Erkenntnissen aus diesen vom Menschen erzeugten Informationen und maschinell generierten Daten.
Relationale Datenbanken gerieten in Ungnade und wurden durch NoSQL-Datenspeicher unterschiedlicher Form ersetzt. Daten strömten in Seen ("data lakes") und drohten, die staubigen, alten Lagerhallen ("data warehouses") wegzuspülen. Aber: Das passierte nicht. Die Verwaltung der (Daten-)Grundlage eines Unternehmens, die Verwendung von prozessvermittelten Daten, ist nach wie vor obligatorisch.
Diese widersprüchlichen Anforderungen, zusammen mit der oben genannten Explosion der Datenmengen, erfordern, dass die IT heute in Bezug auf Datendesign und -management so agil werden muss wie in der Entwicklung. Daten, die in einer Umgebung erstellt werden, müssen leicht verwendet und in mehreren Kontexten wiederverwendet werden können. Dies führt uns zurück zum Information Context Management System und dessen Implementierung in CortexDB.
Datenverwaltung mit vielen Beteiligten
Im vorherigen Artikel, Adaptive Informationskontext-Management-Systeme (ICMS) und die CortexDB als erste ihrer Art, erwähnte ich einen der wichtigsten ursprünglichen Treiber für die Entwicklung von Datenbanken: die Notwendigkeit, mehrere Anwendungen aus einem einzigen Datensatz zu unterstützen. Damals, in der Flower-Power-Ära der 1960er Jahre, gehörten die verschiedenen Anwendungen, die in Betracht gezogen wurden, und tatsächlich alle Daten, die sie verwendeten, zu den spezifischen Unternehmen, die sie aufgebaut haben. Daten haben selten, wenn überhaupt, Unternehmensgrenzen überschritten. Datenbesitz, wenn überhaupt, bezogen sich auf Fachabteilungen innerhalb des Unternehmens.
Mit fortschreitender digitaler Transformation fallen diese vereinfachenden Einschränkungen heute weg. Weil Daten Unternehmensgrenzen überschreiten und wieder überschreiten, in Systemen mit gemeinsamer Nutzung gesammelt und rekonstruiert werden, werden Fragen des Dateneigentums und der Nutzungsberechtigung zwischen verschiedenen Akteuren außerhalb des Unternehmens immer komplexer. Darüber hinaus muss mit der Durchsetzung der Allgemeinen Datenschutzverordnung (DSGVO) der Europäischen Union die Privatsphäre personenbezogener Daten unter allen Umständen geschützt werden, und spezifische Regeln legen fest, wie der Zugang zu diesen Daten und deren Verwendung kontrolliert werden muss.
Diese Probleme stellen besondere Herausforderungen an die traditionellen Ansätze zur Speicherung und Verwaltung von Daten in alten Datenbanksystemen. Und so wie eine Datenbank das Problem des Datenaustauschs zwischen Anwendungen gelöst hat, bietet ein adaptives Information-Context-Management-System (ICMS) wie CortexDB die Lösung für die Verwaltung von Daten und den Informationsaustausch zwischen verschiedenen Akteuren. Die IT-Branche beginnt erst, die entstehende Komplexität zu verstehen und anzugehen, aber das deutsche CarPass-System ist ein hervorragendes Beispiel dafür, was getan werden muss und kann.
CarPass – ein digitaler Zwilling Ihres Fahrzeugs
CarPass ist ein System, das derzeit in Deutschland und schließlich in der gesamten EU eingeführt wird. Ziel ist es, eine vollständige digitale Aufzeichnung der Servicehistorie eines jeden Fahrzeugs das sich im Besitz des (derzeitigen) Eigentümers befindet zu erstellen und zu speichern. Allerdings werden die Daten von Werkstätten, Händlern und Versicherungsgesellschaften aktualisiert und schließlich beim Verkauf des Fahrzeugs an den neuen Fahrzeughalter weitergegeben. Während das langfristige Ziel darin besteht, alle Service- und Komponenteninformationen über das Fahrzeug zu erfassen – also den digitalen Zwilling des Fahrzeugs zu erstellen –, sind die anfänglichen Daten die Originalinformationen des Herstellers, die Servicehistorie, die Kilometerzahl, die Anzahl der Besitzer und jedes geänderte/reparierte Teil des Fahrzeugs seit der Produktion. Ein erster Geschäftsschwerpunkt liegt auf der Bekämpfung von Kilometergeldbetrug, der derzeit Milliarden von Euro kostet. Längerfristig soll dem derzeitigen Fahrzeughalter das Recht eingeräumt werden, eine vollständige Historie des Fahrzeugs einzusehen, ohne die Privatsphäre der Vorbesitzer zu beeinträchtigen.
Auf den ersten Blick wirkt CarPass wie eine einfache Anwendung: Erstellen Sie eine relationale Datenbank und geben Sie Autobesitzern und relevanten Organisationen einen angemessenen Zugang zu ihr. Die Realität ist aber alles andere als einfach.
Obwohl die aktuellen Daten begrenzt sind, sieht der zukünftige Umfang eine breite Palette von Datentypen vor, von denen viele von Fahrzeug zu Fahrzeug variieren werden. Die Daten sind somit über die verschiedenen Typen semi-strukturiert und variabel über die Zeit. Solche Merkmale deuten auf eine Dokumentenablage und nicht auf eine relationale Datenbank als Basistechnologie hin, um Probleme wie Schemawechsel und Nullwertverbreitung zu vermeiden. Ein herkömmlicher Dokumentenspeicher kann jedoch keine Datenschutzprobleme lösen, wenn sich alle Fahrzeugdaten, die mit einer bekannten Eigentümer-Fahrzeug-Kombination verbunden sind, in einem einzigen Dokument/Auftrag befinden. Einige oder alle diese Daten haben personenbezogene Merkmale nach der DSGVO, wie von der niedersächsischen Landesdatenschutzbehörde festgestellt wurde [2]. Darüber hinaus muss die Berechtigung zum Zugriff oder zur Aktualisierung verschiedener Teile des Fahrzeugdatensatzes verschiedenen Parteien zugewiesen und im Laufe der Zeit widerrufen werden. Selbst wenn dies in einem traditionellen Dokumentenspeicher technisch machbar wäre, wäre der administrative Aufwand für die Zugangsverwaltung nach DSGVO enorm.
Als Information-Context-Management-System (ICMS) bietet CortexDB Lösungen für all diese Probleme und liefert ein hochperformantes System zur Bereitstellung der CarPass-Anwendung. Wie oben beschrieben, werden alle Datenfelder in der Dokumentenablage CortexDB in einer 6NF-Struktur (6. Normalform/ invertierter Index) indiziert, die parallel zur Dokumentenablage angelegt und gepflegt wird. Die Berechtigung und der Zugriff auf die nackten Datensätze in der Dokumentenablage werden über diesen Index verwaltet, so dass der Zugriff auf einzelne Felder innerhalb von Dokumenten/Akten gewährt und widerrufen werden kann. Der Fahrzeughalter kann als aktueller Eigentümer des CarPass-Datensatzes für sein Fahrzeug beispielsweise einer Werkstatt, die den regulären Service am Fahrzeug durchführt, Schreibzugriff für ein neues Kilometerfeld im Datensatz gewähren, diesen widerrufen und einer anderen Werkstatt nach eigenem Ermessen gewähren. Und wenn das Fahrzeug an einen neuen Eigentümer weiterverkauft wird, können die Zugriffsrechte auf den CarPass-Datensatz problemlos an den neuen Eigentümer weitergegeben werden.
Es ist nicht nur CarPass allein…
CarPass ist nur ein Beispiel für eine neue Klasse von Informationsmanagement-Anwendungen, bei denen das Dateneigentum und die Verantwortung für die Datenerstellung und den Datenzugriff auf verschiedene Akteure verteilt sind. Da verschiedene Parteien – sowohl Menschen als auch Maschinen – Daten erstellen und über das gesamte Internet abrufen, stellen sich immer häufiger Fragen der Autorisierung und des Schutzes der Privatsphäre. Die Lösung dieser Probleme erfordert die Einführung von ICMS wie CortexDB.
Die Arbeit von "Data Scientists" ist der sexyste Job im digitalen Geschäft.
Im nächsten Beispiel werden ich zeigen, wie die einzigartige Struktur von CortexDB eine neue Möglichkeit bietet, ein weiteres häufiges Problem für digitale Unternehmen anzugehen: den Umgang mit unsauberen Daten.
Gewinnung tiefergehender Erkenntnisse aus dreckigen Daten
Dreckige Daten sind nicht das eigentliche Problem. CortexDB setzt die Herausforderung in einen neuen Rahmen: herauszufinden, welche wahren Bedeutungen in dem Dreck stecken, der entsteht, wenn Datenquellen – von Menschen bis hin zu Sensoren – Daten von geringer Qualität liefern.
Die Arbeit von "Data Scientists" ist der daten-getriebenste – und angeblich auch der sexyste – Job im digitalen Geschäft. Ziel ist es, aus den umfangreichen Daten einer digitalisierten Welt Erkenntnisse zu gewinnen. Bevor "Data Science" glamourös wurde, hieß es "Data Mining" – zweifellos ein besserer Name. Wie beim physischen Schürfen von Edelmetallen besteht die erste Herausforderung für die Data Scientists darin, relativ kleine Nuggets von Datengold aus riesigen Mengen an Rohdaten-Erz zu veredeln und, ebenso wichtig, saubere und reine Daten (Goldstandard) zu erzeugen.
Ein Großteil des Schrotts in Rohdaten stammt davon, wie wir Namen falsch schreiben, Wörter abkürzen, Werte bei der manuellen Dateneingabe oder als Sprach-zu-Text-Anwendungen unsere Sprache falsch verstehen. Weitere Probleme entstehen, wenn wir den Kontext der Daten, die von den Milliarden von Sensoren im Internet der Dinge erzeugt oder erfasst werden, nicht vollständig spezifizieren können. Die eingehenden Daten sind auf viele verschiedene Arten verschmutzt, aber die Bereinigung jeder Instanz ist nur ein Teil des Problems. Die eigentliche Herausforderung besteht darin, dass wir aus Millionen von ankommenden Datensätzen diejenigen destillieren müssen, die sich auf dieselbe reale Einheit beziehen und den Wahrheitsgehalt jedes einzelnen eindeutig spezifizieren.
Traditionell sind Namens- und Adressdaten die am häufigsten genannten Beispiel für diese Herausforderung, aber sie gelten für jede Art von schwach strukturierten Informationen.
Lösungen für diese Art von Problemen – oft als "Record Linkage" bezeichnet [3] – gehen viele Jahrzehnte zurück und zielen darauf ab, den einen "Golden Record" von bereinigten und abgestimmten Daten über jede Entität zu erstellen. Traditionell besteht der Prozess aus mehreren, sequentiellen, sich teilweise überlappenden Säuberungs- und Vergleichsschritten. Die Wahl der Schritte und die Reihenfolge wird oft manuell festgelegt, abhängig von der Art der Daten, den Kategorien der beobachteten Probleme sowie den Fähigkeiten und Erfahrungen des Mitarbeiters, der den Prozess durchführt.
Dieser Prozess, der heute oft als "Data Wrangling" [4] bezeichnet wird, fällt oft den Data Scientists zu, die bis zu 80 Prozent ihrer Zeit verschwenden. Ihre Fähigkeiten wären besser eingesetzt, Daten zu analysieren und Erkenntnisse zu gewinnen, anstatt schmutzige Daten zu bereinigen. Data Wrangling kann den Schmerz der Data Scientists sicherlich lindern, aber meistens vereinfachen und ergänzen sie visuell nur die bestehenden, manuellen Bereinigungsschritte, anstatt die zugrundeliegenden Probleme unter dem Problem der "dreckigen Daten" anzugehen.
Kontext ist die Antwort… Aber was ist die Frage?
Um dieses Problem in einem digitalen Unternehmen zu lösen – eine große Anzahl von individuell verschmutzten Datensätzen, die sich in riesigen Datensätzen aus mehreren, oft widersprüchlichen Quellen uneinheitlich unterscheiden – müssen wir außerhalb des bekannten Rahmens denken. Die eigentliche Anforderung besteht nicht darin, schmutzige Daten zu bereinigen, sondern daraus eindeutig identifizierbare Identitäten für eindeutige reale Einheiten zu destillieren, auch wenn einzelne Datensätze immer noch unvereinbare Unterschiede in ihren Daten enthalten können. Dadurch verlagert sich unser Fokus von Fehlern in den Datenwerten (nackte Daten) auf den Kontext der Datenerstellung und -nutzung (context-setting information, CSI), so dass wir diese Fehler umgehen können.
Durch die getrennte Speicherung und kontinuierliche Ausrichtung von nackten Daten und CSI, wie in "CortexDB definiert die Datenbank neu" beschrieben, ermöglicht ein Information-Context-Management-System (ICMS), wie CortexDB, die Schaffung eines integrierten und hoch automatisierten Systems zum Abgleich und zur Bereinigung von Daten aus mehreren disjunkten Quellen. Ein lebensechtes Szenario zeigt, was das bedeutet.
360°-Kundendaten-Management
Ein fiktiver großer europäischer Automobilhersteller (nennen wir ihn kurz "FiGEA") verkauft und wartet seine Fahrzeuge über ein Netzwerk vieler Händler in Fernost. Jeder Händler betreibt seine eigenen IT-Systeme, die je nach Händlergröße in Größe und Komplexität variieren. Jeder von ihnen verwaltet seine eigenen Kundendaten, Verkäufe und Dienstleistungen in seiner eigenen Sprache und nach den lokalen Gesetzen. Darüber hinaus verfügt FiGEA aufgrund von Akquisitionen und IT-Legacy-Entwicklung über mehrere, teilweise inkonsistente IT-Systeme für verschiedene Geschäftsfunktionen und/oder Regionen.
Wie kann FiGEA zu einem integrierten digitalen Unternehmen werden, das Daten aller Händler und internen Abteilungen konsolidiert, um seine Abläufe zu optimieren, KPIs auf lokaler und internationaler Ebene zu definieren und zu verfolgen und allen seinen Kunden und Partnern hervorragende Vertriebs- und Serviceleistungen zu bieten? Wie kann FiGEA nur hoffen, auch nur einen kleinen Teil dieses Ziels zu erreichen, wenn es keine vollständige, einheitliche Masterliste ihrer Kunden gibt?
Versuche, den Kundenstammsatz mit Hilfe von Data-Wrangling-Werkzeugen zu bereinigen und zu konsolidieren, scheitern frühzeitig. Die Daten jedes Händlers müssen einzeln importiert und bereinigt werden, aber dieser Ansatz kann nicht für Kunden gelten, die bei mehreren Händlern kaufen. Darüber hinaus sind solche manuellen Systeme äußerst schwierig auf sich ständig ändernde Daten anzuwenden, die Echtzeit-Betriebs- und -Berichtssysteme unterstützen müssen.
Als ICMS ermöglicht CortexDB die Erstellung eines integrierten Satzes aller Kundendaten, die destillierbar sind – gereinigt und abgestimmt – kontinuierlich und automatisch. Jeder unterschiedliche Kundendatensatz aus jedem System, sowohl intern als auch extern, wird einzeln, zeitgestempelt und in seinem Rohformat im CortexDB-Dokumentenspeicher abgelegt. Es muss keine einheitliche Struktur, Benennung oder Reihenfolge der Datenfelder im Voraus definiert werden. Neue oder geänderte Schemata können ebenso einfach behandelt werden. Jeder Datensatz, mit vollständiger historischer Sequenzierung, besteht aus einem ungeordneten und unbeschränkten Satz von Schlüssel/Wert-Paaren, die für immer gespeichert sind. Die Speicherung eines vollständigen Satzes von Kundendatensätzen in Originalform als nackte Daten ist eine Voraussetzung für die laufende Destillation und die erforderliche Auditierung.
Während jeder Datensatz in die Dokumentenablage geladen wird, fügt CortexDB seinen CSI in die zugehörige sechste Normalform – den invertierten Index – ein. Mit einer Kombination von Techniken, einschließlich deterministischer Methoden, die auf ähnlich einzigartigen Feldern wie Social-Media-IDs, probabilistischen phonetischen und linguistischen Methoden und semantischen Graphenanalysen basieren, werden Datensätze mit hoher Wahrscheinlichkeit identifiziert und markiert. Da täglich neue Datensätze hinzugefügt werden, werden sie automatisch in die Datenbank integriert und systemweite IDs mit hoher Wahrscheinlichkeit der Eindeutigkeit in Bezug auf reale Einheiten vergeben. In einem hochautomatisierten Ansatz beschränkt sich die menschliche Beteiligung auf die Überwachung und Validierung ungewöhnlicher Fälle.
Die Bedeutung des Kontexts
Das obige Szenario zeigt, wie ein ICMS die automatisierte Destillation von schmutzigen Kundenidentitätsdaten aus mehreren Quellen unterstützen kann. Es kann problemlos auf eine Reihe anderer Datentypen erweitert werden, wie z. B. Produktnamen und Produktbeschreibungen, Verträge, medizinische Diagnosen und Anrufprotokolle.
Indem wir einen Schritt zurücktreten von der üblichen, vereinfachten Sichtweise der "Reinigung verschmutzter Daten" und uns auf die kontextbestimmenden Informationen konzentrieren, können wir sehen, dass es wirklich notwendig ist, eindeutig identifizierbare Einheiten aus qualitativ schlechten Daten zu destillieren. Die einzigartige indizierte schemalose Struktur von CortexDB ermöglicht es uns, über die Daten hinauszugehen und die Bedeutung der zu speichernden und verarbeitenden Informationen zu verstehen.
CortexDB treibt die digitale Transformation agil voran
Weil die CortexDB vom kundenorientierten Projektansatz zu einem Roadmap-basierten Produktentwicklungsansatz übergeht, ist sie gut positioniert, um eine führende Position im neu entstehenden Markt für Information-Context-Management-Systeme (ICMS) einzunehmen und wichtige Funktionen zur Unterstützung der digitalen Transformation bereitzustellen.
Im vorangegangenen Artikeln habe ich CortexDB als Vorläufer einer neuen und wichtigen Klasse von Informationsmanagementprodukten positioniert – einem adaptiven Information-Context-Management-System (ICMS). Ich habe auch gezeigt, wie sie bei der Lösung einiger zentraler Probleme von Unternehmen, die eine digitale Transformation anstreben, eingesetzt wird. Das ist eine große Verantwortung, die auf den Schultern eines kleinen Softwareunternehmens liegt! Erlauben Sie mir zu erklären, warum ich glaube, dass sie diese Verantwortung tragen können.
Ein starkes konzeptionelles Fundament
Traditionelle Datenbanken basieren auf der Annahme, dass der Kontext der Daten vor der Speicherung bekannt ist. Sie beginnen daher mit einem Modell der Bedeutungen und Beziehungen der Daten, wie sie von ihren Schöpfern definiert werden. Schemalose Datenspeicher vermeiden eine solche Strukturierung und ziehen es vor, die Identifizierung von Kontext und Struktur auf die Nutzer der nackten Daten zu übertragen. Beide Ansätze haben bekannte Vor- und Nachteile. Und keine von beiden funktioniert so, wie unser Gehirn es tut. Unser Gehirn hat weder vordefinierte Schemata noch große Datenbestände. Wir bauen tatsächlich Assoziationen zwischen Fakten auf und holen und verarbeiten Informationen über diese Assoziationen.
CortexDB repliziert, wie der Name schon sagt, diesen kognitiven/assoziativen Ansatz, mit traditioneller Software – einem Dokumentenspeicher in Kombination mit einem invertierten 6NF-Index –, die es ermöglicht, dass alle Daten-"Fakten" und ihr Kontext basierend auf ihrem Wert direkt und schnell lokalisiert werden können. Ich nenne dies ein Information-Context-Management-System (ICMS). Neben dem Vorteil der Verwendung ausgereifter Software vermeidet die CortexDB so auch die Black-Box-Probleme moderner neuronaler Netze der künstlichen Intelligenz (KI), die nicht erklären können, wie sie zu ihren Schlussfolgerungen gekommen sind.
Dieser neuartige Ansatz bietet mehrere wichtige Vorteile. Daten können zunächst ohne oder mit wenig Struktur/ Kontext gespeichert werden, so dass je nach Nutzung mehrere, nützliche Schemata im Laufe der Zeit entdeckt oder entwickelt werden können. Dieses "Schema nach Nutzungsmuster" führt zu einer agilen Datenmodellierung und Anwendungsentwicklung und schließt die Lücke zwischen "Schema-on-Write" und "Schema-on-Read". Die Unterstützung mehrerer Schemata für dieselben nackten Daten ermöglicht eine Reduzierung der Anzahl der Kopien von Daten, die gespeichert und gepflegt werden müssen. Ein Paradebeispiel ist die Möglichkeit, von getrennten Betriebs- und Informationssystemen auf eine einzige Instanz zu wechseln, die manchmal als Hybrid Transactional/ Analytical Processing (HTAP) bezeichnet wird. Wie bereits erwähnt, können spezifische, hochwirksame Fragen der digitalen Transformation behandelt werden, wie z. B. verteilter Datenbesitz und Destillation von schmutzigen Daten.
Eine klare, organisatorische Denkweise
Die Entwicklung eines Datenbank-Managementsystems (DBMS) unterscheidet sich deutlich von der anderer Softwarekomponenten. Historisch gesehen können DBMSs ein Jahrzehnt oder länger dauern, bis sie so weit sind, dass Unternehmen ihnen ihre wertvollen Daten anvertrauen können. Erfolgreiche Datenbanken sind oft in Situationen gereift, in denen der Entwickler und einige wenige wichtige Partnerkunden das System in den ersten Jahren durch spezifische und vielfältige Projekte verfeinern, bevor der Anbieter zu einer typischeren Produktentwicklungs-Roadmap übergeht. Das gleiche kleine und engagierte Team von Ingenieuren leitet das Design und die Entwicklung über den gesamten mehrjährigen Entwicklungszyklus. Ihre Arbeit ist von jährlichen oder vierteljährlichen Börsenzielen abgeschirmt, so dass Entscheidungen für das langfristige Wohl des Produkts getroffen werden.
Das Team hat die Entwicklung nach der Vision vorangetrieben, die Funktionsweise des menschlichen Gehirns nachzuahmen.
Die gleichen Überlegungen gelten für die ICMS-Entwicklung, und die Cortex AG erfüllt die oben genannten Kriterien. Als kleines, privat geführtes Unternehmen kann es sich auf den längerfristigen Erfolg seines Produkts konzentrieren. In seinen fast zwei Jahrzehnten der Entwicklung hat das gleiche Team von etwa einem Dutzend Ingenieuren und Führungskräften die Entwicklung nach der Vision vorangetrieben, die Funktionsweise des menschlichen Gehirns nachzuahmen. Die Entwicklung hat eine Vielzahl von Projekten mit anspruchsvollen Kunden wie Volkswagen, der Bundesdruckerei (Hersteller von Banknoten, Ausweispapieren, Führerscheinen und anderen Bundesdokumenten), Airbus, BMW und anderen kleinen und mittleren Unternehmen durchgeführt.
Mit mehreren erfolgreichen kundenorientierten Projekten, die zur Finanzierung und Ausrichtung von CortexDB beitragen, ist das Unternehmen bereit, die nächste Phase seiner Entwicklung einzuleiten: den Übergang zur Entwicklung, die durch eine formalere Roadmap getrieben wird.
Ein aufstrebendes Mainstream-Produkt
Die Cortex AG hat nun den Übergangspunkt von der projektbezogenen Entwicklung zur Umsetzung der Produkt-Roadmap erreicht. Dabei wird die Produktausrichtung auf eine Reihe von vordefinierten Zielen ausgerichtet und direkt auf die spezifischen Bedürfnisse der wichtigsten Partnerkunden eingegangen. Ein wichtiger Schritt in diesem Übergang ist die Identifizierung eines übergeordneten strategischen Bereichs mit Entwicklungsschwerpunkten. Im Falle von CortexDB ist dies nun als Information Context Management System definiert.
Der Datenbankmarkt – sowohl strukturiert als auch unstrukturiert – ist voll von buchstäblich hunderten von Wettbewerbern, vom Start-up bis zum Mega-Anbieter. Der Fokus von CortexDB auf das kognitive/assoziative Modell der Erstellung, Sammlung, Speicherung und Verwaltung von kontextbezogenen Informationen in enger Verbindung mit den zugrundeliegenden nackten Daten ermöglicht es, in einem relativ neuen Raum zu wachsen und zu gedeihen, der jedoch breite Aufmerksamkeit erfährt, da Data-Governance-Themen im Mittelpunkt der digitalen Unternehmen stehen und die Agilität der Daten eine zwingende Voraussetzung für die digitale Transformation wird.
Eine englische Version dieses Artikel finden Sie hier:
Managing Data on Behalf of Different Actors
- Dr. Barry Devlin, 2013: Business unIntelligence: Insight and Innovation beyond Analytics and Big Data
- Die Landesbeauftragte für den Datenschutz Niedersachsen: 10 Fragen und Antworten zum Thema Datenschutz im Kfz
- Wikipedia: Record Linkage (Duplikaterkennung)
- Wikipedia: Data Wrangling (englisch)
