Eine Ontologie für die ganze Organisation, nicht je Anwendung.

Jede Anwendung beschreibt, was sie braucht, und das ist vernünftig. Die Summe ist es nicht. Dieselbe Person heißt in einem System Kunde, im zweiten Debitor, im dritten Kontakt, mit je einer eigenen Kennung, und niemand weiß, ob es dieselbe ist. Die Regeln für Rechte, Fristen und Aufbewahrung stehen mehrfach, leicht verschieden, und jede Änderung muss an mehreren Stellen nachgezogen werden.

Die Verbindung zwischen den Anwendungen wird dann zu einer Aufgabe für Schnittstellen, Exporte und Menschen. Das Wissen, welche Zeile in welchem System zu welcher gehört, ist nirgends festgehalten, sondern steckt in den Köpfen derer, die die Systeme pflegen.

Eine gemeinsame Ontologie führt die Dinge einmal: ein Objekt mit Typ, Identität und Herkunft, Beziehungen mit Verb und Kardinalität, Regeln und Handlungen als Daten. Anwendungen und Agenten lesen und schreiben dieselbe Beschreibung, und was sie ändern, ändert sich für alle.

Drei Dinge entstehen dabei nebenbei. Rechte und Markierungen hängen einmal am Feld und gelten überall, auch in der Suche und im Kontext eines Agenten. Der Verlauf ist ein einziger und nicht einer je Anwendung. Und ein neuer Bereich beginnt nicht bei null, sondern schließt an das an, was es schon gibt.

Dagegen steht ein berechtigter Einwand: Ein einziges Begriffsgerüst für alles zwingt jedem Bereich Begriffe auf, die er so nicht benutzt. Die Softwarearchitektur kennt das als Bounded Context: Derselbe Begriff bedeutet in der Abrechnung etwas anderes als im Kundendienst. Das ist keine Schwäche, sondern ein Merkmal von Organisationen, und eine gemeinsame Beschreibung muss es aushalten.

Die Ontologie hält es aus, weil sie keine Einheitsbegriffe erzwingt. Ein Bereich führt seine eigenen Typen und nennt ihre Beziehung zu den gemeinsamen: Der Debitor der Abrechnung ist eine Rolle der Person, die auch der Kundendienst führt, und die Beziehung dazwischen ist selbst ein Objekt. Gemeinsam sind Kern und Regeln der Übersetzung. Die Pflege bleibt verteilt, mit Zweigen für Änderungen, Versionen und einem Verantwortlichen je Typ.

Niemand beginnt mit der ganzen Organisation. Man wählt einen Bereich, in dem zwei oder drei Systeme dieselben Dinge führen, und bildet sie ab. Die Quellen bleiben führend, die Ontologie liest, und Handlungen schreiben zurück, wo es sich lohnt. Aus dem ersten Bereich wächst der zweite, denn alles, was die beiden teilen, steht schon da.

Der Aufwand liegt in der Identität und in den Regeln, nicht in der Technik. Welche Zeilen aus welchen Systemen dasselbe Ding sind, muss jemand entscheiden, der es weiß. Das System hilft mit Ähnlichkeit und Bestätigung, entscheidet aber nicht selbst.

Vier Zeichen sprechen dafür, dass die Ontologie falsch gebaut ist. Sie hat einen Einheitsbegriff für etwas, das Bereiche verschieden verstehen. Sie hat Typen, die niemand verantwortet. Sie wird neben den Quellen gepflegt und nicht aus ihnen gespeist. Oder sie braucht für jede Frage eine neue Abbildung, statt dass sich Fragen aus den Beziehungen ergeben.