Im ersten Teil dieser Serie wurde die strategische Relevanz von Ontologien im Spannungsfeld von KI und Regulatorik beleuchtet (Ontologien im Asset Management: Überholt, unterschätzt oder der Schlüssel zur KI-integrierten Datenarchitektur?). Dieser Artikel geht nun einen Schritt weiter und taucht tiefer in die Materie ein. Er aggregiert die wesentlichen Prinzipien, zeigt die Vorteile sowie Grenzen auf und skizziert erste Schritte zur praktischen Umsetzung. Ziel ist es, die abstrakte Theorie in eine greifbare, operative Realität zu überführen.

Haftungsausschluss: Dieser Beitrag dient ausschließlich der allgemeinen Information und ersetzt keine individuelle Beratung.

Was ist eine Ontologie – und warum das Pizza-Beispiel nicht ausreicht

In der Theorie wirken Ontologien einfach: Sie beschreiben Objekte und deren Beziehungen zueinander. Ein klassisches Lehrbuchbeispiel ist die Pizza: Eine Pizza hat einen Belag, ein Belag kann sein Tomate oder Käse, und jede Pizza hat mindestens eine Zutat. Diese einfachen Modelle sind nützlich, um das Grundprinzip zu verstehen, aber sie scheitern an der Komplexität der Finanzwelt.

Im Asset Management geht es nicht nur darum, dass ein Fonds „Investoren“ hat. Es geht um vielschichtige, regelbasierte und oft zeitabhängige Abhängigkeiten: Ein Investor zeichnet ein Commitment. Dieses löst aus einen Kapitalabruf. Der Kapitalabruf wirkt auf die Liquidität des Fonds. Die Liquidität beeinflusst den NAV, der wiederum die Grundlage für das regulatorische Reporting ist. Eine Ontologie hilft, genau diese Zusammenhänge formal, nachvollziehbar und systemübergreifend abzubilden.

Die drei Ebenen der Ontologie: Von der Strategie zur Technik

Ontologien existieren nicht im luftleeren Raum, sondern auf verschiedenen Abstraktionsebenen, die wie eine Kette ineinandergreifen. Die Unterscheidung dieser Ebenen ist der Schlüssel zum Erfolg.

Ebene 1: Die Strategische / Konzeptionelle Ontologie

Diese Ebene beschreibt das „Warum“ und das „Was“ des Geschäftsmodells. Sie definiert die fundamentalen Akteure und ihre primären Interaktionen. Beispiel: Ein Investor stellt Kapital bereit, ein Asset Manager verwaltet es in einem Fonds, der in Assets investiert, um Erträge auszuschütten. Dies ist die Sprache des Vorstands und die Grundlage für die strategische Ausrichtung.

Ebene 2: Die Operative / Logische Ontologie

Diese Ebene ist das Herzstück für die Fachbereiche und beschreibt das „Wie“ der konkreten Geschäftsprozesse. Sie detailliert die strategische Ebene und modelliert spezifische Workflows und ihre Abhängigkeiten. Der Commitment Lifecycle, den wir im nächsten Teil dieser Serie detailliert betrachten werden, ist ein perfektes Beispiel für eine operative Ontologie.

Ebene 3: Die Technische / Physische Ontologie

Diese Ebene beschreibt das „Wo“ und „Wie genau“ der Datenhaltung. Sie ist die Brücke zur IT-Implementierung und definiert die konkreten Datenfelder, Typen und Formate, in denen die logischen Konzepte in den Systemen gespeichert werden. Sie findet ihre detaillierte Ausprägung oft im Data Dictionary.

Die entscheidende Abgrenzung: Ontologie vs. Data Dictionary

Ein häufiges Missverständnis ist die Gleichsetzung von Ontologie und Data Dictionary. Beide sind entscheidend, aber sie beantworten unterschiedliche Fragen:

• Ein Data Dictionary beschreibt die technischen Attribute von Daten. Es beantwortet die Frage: Was sind die Daten? (Beispiel: Der Datenpunkt „NAV“ ist eine Dezimalzahl mit zwei Nachkommastellen und hat die Währung EUR oder USD.)
• Eine Ontologie beschreibt die fachliche Bedeutung und die Beziehungen der Daten. Sie beantwortet die Frage: Wie hängen die Daten zusammen? (Beispiel: Der „NAV“ wird abgeleitet aus der Bewertung der Assets, gehört zu einem bestimmten Fonds und ist relevant für das Annex-IV-Reporting.)

Erst im Zusammenspiel entfalten beide ihre volle Kraft. Das Data Dictionary sichert die technische Qualität, während die Ontologie die fachliche Konsistenz und Nachvollziehbarkeit gewährleistet.

Typische Problemfelder und wie Ontologien sie lösen

Ontologien sind kein Selbstzweck, sondern ein strategisches Werkzeug zur Lösung konkreter Probleme in der Datenarchitektur von Asset Managern.

Problemfeld	Beispiel aus der Praxis	Lösung durch eine Ontologie
Uneinheitliche Begriffswelt	Verschiedene Abteilungen verwenden unterschiedliche Definitionen für den „NAV“ (z.B. mit/ohne bestimmte Gebühren).	Die Ontologie schafft eine einzige, verbindliche Definition und legt fest, wie sich der NAV aus anderen Entitäten zusammensetzt.
Hoher Initialaufwand	Die Modellierung aller Entitäten (Fonds, Investor, Tranche, etc.) erscheint als unüberwindbare Hürde.	Ein modularer Start, der sich zunächst auf die Kernbeziehung „Investor-Fonds-Commitment“ konzentriert.
Fragmentierte Tool-Landschaft	Die Daten für einen einzigen Prozess sind über ABOR, IBOR und CRM verteilt, was zu Inkonsistenzen führt.	Die Ontologie dient als Blaupause für einen zentralen API-Layer, der die Daten aus den Silos konsistent zusammenführt.
Kompetenzmangel	Die technischen Sprachen zur Beschreibung von Ontologien (z.B. OWL/RDF) sind für Fachbereiche unverständlich.	Ein Business Analyst agiert als „Übersetzer“ und Moderator zwischen den Fachexperten und den Datenarchitekten.

Lessons Learned: Wie man Ontologie-Projekte zum Erfolg führt

Pilotprojekte im Finanzumfeld haben gezeigt, dass der Erfolg einer Ontologie-Initiative weniger von der Wahl des perfekten Tools abhängt, sondern von der Governance und der Vorgehensweise. Die wichtigsten Erkenntnisse sind:

• Iterativ starten, nicht mit einem „Big Bang“: Beginnen Sie mit einem klar abgegrenzten, geschäftskritischen Bereich (z.B. dem Commitment Lifecycle) und erweitern Sie das Modell schrittweise. Dies schafft schnelle Erfolge und sichert die Akzeptanz.
• Fachliche Workshops sind wichtiger als technische Modellierung: Der größte Wert entsteht, wenn Fachexperten aus Fund Accounting, Risk und Reporting gemeinsam die Begriffe und Beziehungen definieren. Die Technik folgt der Fachlichkeit, nicht umgekehrt.
• Standard-Ontologien als Inspiration nutzen, nicht als Dogma: Branchenstandards wie FIBO (Financial Industry Business Ontology) können eine gute Ausgangsbasis sein, müssen aber fast immer an die spezifischen Bedürfnisse des Unternehmens angepasst werden.
• Governance sicherstellen: Eine Ontologie ist kein einmaliges Projekt, sondern ein lebendes Modell. Es benötigt eine klare „Ontology Manager“-Rolle und einen etablierten Change-Management-Prozess für die kontinuierliche Pflege.

Fazit und Ausblick auf den nächsten Teil

Die konzeptionelle Arbeit an einer Ontologie ist kein Selbstzweck, sondern ein strategisches Werkzeug zur Lösung konkreter Probleme in der Datenarchitektur. Sie schafft eine gemeinsame Sprache und macht implizites Wissen explizit. Mit diesem Fundament ist die Basis für eine verlässliche und zukunftsfähige Datenarchitektur gelegt.

Doch dieses konzeptionelle Gerüst ist erst der Anfang. Im nächsten und letzten Teil dieser Serie wird dieses Modell in die operative Praxis überführt. Es wird gezeigt, wie der Commitment Lifecycle Schritt für Schritt technisch modelliert, um reale Komplexität erweitert und – am wichtigsten – wie man mit diesem Modell komplexe Business-Fragen beantwortet, die mit traditionellen Systemen oft nur mühsam zu lösen sind.

---

Quellen

• OMG Financial Industry Business Ontology (FIBO)
• BaFin-Leitlinien zu Datenmanagement