Seit rund 25 Jahren habe ich ein besonderes Faible für Architektur und insbesondere Hochhäuser. Es macht mir große Freude, Informationen über Bauwerke zu erfassen und zu organisieren. Doch im Laufe der Jahre stellte ich fest, dass sich Informationen ständig verändern:

• Ein Bauwerk wird neu errichtet oder abgerissen.
• Ein Gebäude wird renoviert und seine Farbe ändert sich.
• Eine Büroimmobilie wird umgewandelt in ein Wohnhaus.
• Ein neuer Mieter zieht in eine Immobilie ein oder ein anderer zieht aus.
• Involvierte Unternehmen firmieren um, gehen bankrott, schließen sich zusammen oder teilen sich.
• Ländergrenzen verschieben sich, Städte schließen sich zusammen oder neue Quartiere entstehen.
• etc.

Doch, wie verwaltet man diese ständigen Veränderungen am besten? Was ist mit Veränderungen, von denen man nichts oder erst zeitversetzt mitbekommt? Wie bestimmt man die Anzahl der Bürogebäude in einer Stadt heute, vor fünf Jahren oder in der Zukunft? Was ist, wenn es unterschiedliche Angaben zu ein und demselben Objekt gibt? Und wann ist eine Immobilie überhaupt ein Bürogebäude?

Veränderungen im Immobilienbereich (und natürlich darüber hinaus) erfolgen ständig. Und eben diese Veränderungen sind seit rund 10 Jahren mein Forschungsfeld in der IT. In dieser Zeit habe ich mehr als 100.000 Fotos gemacht, um die Veränderungen an Gebäuden und damit zusammenhängenden Dingen zu verstehen und dokumentieren. Meine Beobachtungen lassen diese Rückschlüsse zu: Veränderung passiert ständig und ist chaotisch. Mal geschieht Veränderung abrupt, meistens aber schleichend. Und Veränderung läuft in allen Lebensbereichen nach ähnlichen Prozessen ab. Aber die Werkzeuge, mit denen wir heutzutage dieser Veränderung in der IT begegnen, sind Relikte aus der Vergangenheit. Als Ergebnis davon arbeiten quasi alle Unternehmen ohne Automatisierung mit unvollständigen, veralteten oder gar falschen Informationen. Anbieter, die diese Informationen dann als „Marktdaten“ verkaufen, sorgen in der Regel für Frustration bei zahlenden Kunden: nicht nur der „Qualität“ wegen, sondern auch weil viele Daten schlichtweg fehlen.

Mein Forschungsfeld Data Change Management zielt darauf ab, Veränderung als integralen Bestandteil der Datenverwaltung zu betrachten. Veränderung ist dabei nicht ein störender Teil bei der Datenspeicherung, sondern genauso wichtig wie die Daten selbst. Heute kommen vor allem Datenbanken zur Datenspeicherung zum Einsatz – und sie werden unzureichend verwendet. Datenbanken wurden ursprünglich gemacht, um Daten vor allem persistent und relationssicher zu speichern. Die mit Datenbanken meist implementierten Konzepte sind heute so ausgelegt, dass sie den bestmöglichen „Stand der Dinge“ desjenigen wiederspiegeln, der die Daten verwaltet. Sie werden aber nicht dafür genutzt, um

• Veränderungen an Schemata ohne Programmieraufwand vorzunehmen,
• Änderungen an allen Datensätzen integral zu versionieren,
• Daten aus sich selbst heraus fortzuschreiben, zu bewerten oder zu verändern,
• den Stand der Daten zu einem anderen Zeitpunkt als „heute“ zu zeigen.

Genau diese Punkte fließen auch in das Themenfeld Data Change Management ein. Veränderung an Daten werden so verarbeitet und angezeigt, wie sie bestmöglich zu einer bestimmten Zeit, aus einem bestimmten Blickwinkel verfügbar waren.

In den letzten Jahren habe ich die theoretischen Konzepte für eine neuartige Form der evolutionären Datenverarbeitung entwickelt, und zwar auf Basis umfangreicher Beobachtungen an Veränderungsprozessen und Erkenntnissen aus der Evolutionsforschung. Informationen werden dabei nicht konventionell in viele Datenbanktabellen gespeichert, sondern in Datenspeichern, die konzeptionell der Genetik entspringen: Nukleotide sowie die Informationsstränge RNA (einfache Informationsträger) und DNA (komplexe Erbgutträger).

Derzeit programmiere ich in meiner Freizeit eine Software namens Integrator, die einige fundamentale Probleme mit der bisherigen Weise von Datenmanagement beheben soll. Eine der Besonderheiten an dem System ist, dass eine radikal vereinfachte Organisation der Datenhaltung eine unendliche Komplexität von Elementen erlaubt, die bei der Evolution von Daten mitwirken. Die Herausforderung ist jedoch nicht die Datenspeicherung, sondern dem Integrator-System überhaupt grundlegende Funktionalität einzuhauchen.

Im ersten Schritt richte ich Integrator so aus, dass die Software zuverlässig Informationen über Hochhäuser verarbeiten kann. Andere Informationsfelder sollen hinzukommen, sobald die Software funktioniert, beispielsweise für den Bereich Versicherungen. Denn die Prozesse hinter Veränderungen sind überall sehr ähnlich. Mein Ziel ist es diesbezüglich, zuverlässige und sich selbst organisierende Datenorganismen zu schaffen.

Die reine Speicherung von Daten ist jedoch nur ein Aspekt. Vielmehr ist Integrator ein Betriebssystem für Cloudzellen. Diese Cloudzellen sollen, auf Vorlage biologischer Zellen, so in einer Cloud programmierbar werden, dass sie autarg unterschiedlichste Aufgaben übernehmen können. Dazu zählen beispielsweise die Speicherung von Informationen, die Reproduktion, Organisation oder Qualitätskontrolle. Hier gibt es jedoch das Henne-Ei-Problem: Es braucht bestimmte System-Bausteine, um das System funktionsfähig zu machen, die wiederum auf System-Bausteinen aufbauen. Es ist also wie bei echten Organismen: es muss einen Ursprung geben.

Dieses Video hier erklärt anhand der Biologie, welche Aufgaben und Bestandteile biologische Zellen aufweisen. Überträgt man diese Funktionsweise einer solchen Zelle auf die IT, dann erhält man konzeptionell gesehen eine Cloudzelle. Im Endeffekt besteht ein funktionierender Datenorganismus auf Basis des Integrators aus einer Vielzahl von steuerbaren Cloudzellen, die alle unterschiedlichste Funktionen für den Betrieb übernehmen.

Eine der weiteren Erkenntnisse aus meiner Forschungsarbeit ist, dass statische Primärschlüssel, wie sie heutzutage praktisch überall zum Datenaustausch verwendet werden, nicht den Anforderungen an Evolution genügen, weil sich praktisch alle mit einer Entität verknüpften Informationen jederzeit ändern können. Zum zuverlässigen Austausch von Informationen braucht es also ein System, dass sich von statischen IDs verabschiedet, aber gleichzeitig verschiedene alternative Formen für das Identifizieren und Matchen von Datensätzen aufweist.