Einen Context Layer für Enterprise AI aufbauen: ein prinzipienbasierter Leitfaden

Einen Context Layer für Enterprise AI aufzubauen, ist weniger ein Infrastrukturproblem als ein Problem der architektonischen Überzeugung. Die Infrastruktur – Speicher, Query-Engines, Federation-Tooling, MCP-Server, Vektorspeicher – ist ausgereift. Was Context-Layer-Programme ins Stocken bringt, ist die Reihe von Entscheidungen, die Teams treffen, bevor diese Infrastruktur überhaupt nützlich wird. Entscheidungen darüber, woher die Bedeutung der Schicht stammt. Darüber, wer sie verantwortet. Darüber, wie „fertig" für den ersten Anwendungsfall aussieht – und ob der zweite Anwendungsfall darauf aufbauen kann, ohne von vorn zu beginnen.

Dieser Leitfaden richtet sich an CTOs, Heads of Data and AI und Enterprise-Architekten, die genug über die Kategorie gelesen haben, um zu wissen, dass sie einen Context Layer brauchen – und die nun eine Abfolge suchen, der sie folgen können. Wir geben Ihnen fünf Prinzipien, die entscheiden, ob die Schicht den Produktivbetrieb übersteht, vier Phasen für ihren Aufbau und die architektonischen Entscheidungen, die in jeder Phase stecken. Falls Ihnen der Begriff selbst neu ist, beginnen Sie mit unserem umfassenden Leitfaden: Was ist ein Context Layer? Ein definitiver Leitfaden für Enterprise AI. Kommen Sie danach hierher zurück.

Eine Zahl, die den Einsatz verdeutlicht: Der Bericht State of AI in Business 2025 von MIT NANDA stellte fest, dass 95 % der generativen KI-Pilotprojekte in Unternehmen keinen messbaren Ergebniseffekt (P&L-Impact) erzielt haben – trotz Ausgaben von rund 30 bis 40 Milliarden US-Dollar. Die Technologie ist nicht der limitierende Faktor. Der Kontext ist es.

Warum Context-Layer-Projekte scheitern, bevor sie live gehen

Ein Context Layer klingt nach einem Infrastrukturprojekt, ist aber keines. Was den Aufbau ins Stocken bringt, ist die Reihe architektonischer Entscheidungen, die ein Team treffen muss, bevor die Infrastruktur nützlich wird.

Was die Schicht leisten soll, ist unmissverständlich: gesteuerte, aktuelle, verknüpfte Bedeutung zur Laufzeit an KI-Agenten liefern. Was es kostet, das gut zu tun, ist von außen nicht offensichtlich. Es kostet die Entscheidung, woher die Bedeutung der Schicht stammt, wer sie verantwortet, wie „fertig" für den ersten Anwendungsfall aussieht und wie Wiederverwendung für den nächsten aussieht. Teams, die diese Entscheidungen auslassen, lassen sie nicht wirklich aus – sie treffen sie implizit. Der Datenkatalog wird zum De-facto-Modell. Das erste Team, das etwas baut, wird zum De-facto-Eigentümer. Der erste Anwendungsfall wird zu einem maßgeschneiderten Artefakt, das das zweite Team nicht erweitern kann. Bis das jemand bemerkt, hat sich die Schicht um Entscheidungen verfestigt, die niemand bewusst getroffen hat.

Drei wiederkehrende Fehlermuster

Drei Fehlermuster treten in Context-Layer-Programmen von Unternehmen immer wieder auf, und die fünf Prinzipien im nächsten Abschnitt sind darauf ausgelegt, jedes einzelne zu verhindern.

Bedeutung aus Zufall. Teams, die mit dem Modell beginnen, das ihre Quellsysteme nahelegen, kodieren am Ende die Beschränkungen dieser Systeme in die Schicht. Der resultierende Kontext ist eine Aggregation davon, wie einzelne Systeme die Welt zufällig beschreiben – kein kohärentes Modell dessen, wie das Unternehmen funktioniert. Wie EY in seinem Beitrag über Ontologien als die fehlende Schicht in Enterprise AI darlegt, werden die teuersten Fehler hier als Modellprobleme diagnostiziert, obwohl es in Wahrheit Bedeutungsprobleme sind.

Aktualität ohne Zugriffsstrategie. Jede Kontextarchitektur zahlt irgendwo einen Preis. Kopieren Teams operative Daten in ungesteuerte Speicher, zahlen sie mit veralteten Daten und Abgleichaufwand. Weigern sie sich, Kontext überhaupt vorab zu organisieren oder zu materialisieren, zahlen sie mit Latenz, Extraktion zur Laufzeit, Rechenaufwand und Token-Verbrauch. Das Fehlermuster ist nicht das Kopieren selbst. Das Fehlermuster ist das Versäumnis zu definieren, welcher Kontext live sein muss, welcher zwischengespeichert werden kann, welcher gestreamt werden sollte und welcher für wiederkehrende analytische oder agentische Zugriffsmuster materialisiert werden sollte.

Der zweite Anwendungsfall, der nie zusammenwächst. Der erste Anwendungsfall geht live. Das zweite Team startet und stellt fest, dass sich Ontologie, Mappings und Governance des ersten nicht sauber erweitern lassen. Es baut alles neu. Die Organisation hat jetzt zwei Context Layer, das Architekturkomitee tagt, um über „Konvergenz" zu beraten, und der Executive Sponsor geht nicht mehr ans Telefon.

Fünf Prinzipien für einen Context Layer, der den Produktivbetrieb übersteht

Jedes der folgenden Prinzipien ist eine Entscheidung, zu der der Aufbau das Team zwingen wird – ob es sie bewusst trifft oder nicht. Sie bewusst zu treffen, ist der Unterschied zwischen einem Context Layer und einer weiteren steckengebliebenen Initiative.

Prinzip 1: Von der Bedeutung ausgehen, nicht von Metadaten

Die folgenreichste frühe Entscheidung ist, woher das Rückgrat der Schicht stammt. Es gibt zwei Optionen: eine Ontologie, top-down modelliert danach, wie das Unternehmen funktioniert – oder eine Aggregation dessen, was in den Quellsystemen bereits existiert, also Katalogeinträge, Glossarbegriffe, Lineage-Datensätze. Beides hat seinen Platz. Nur eines gehört ins Rückgrat.

Jede nachgelagerte Fähigkeit erbt von dem, was das Rückgrat kodiert: Reasoning, Erklärbarkeit, systemübergreifende Abfragen, Entscheidungsspuren und mehr. Ein Katalog-Rückgrat kodiert, welche Daten Sie haben. Ein Ontologie-Rückgrat kodiert, wie Ihr Unternehmen funktioniert. Wir haben ausführlich dargelegt – unter anderem in unserem Beitrag über Ontologien als den intentionalen Kern eines echten Knowledge Graph –, dass dies die Entscheidung ist, die produktionsreife Context Layer von anspruchsvoller Dokumentation trennt. Die Falle besteht darin, Ontologie-Modellierung als Verbesserung für Phase zwei zu behandeln. Bis Phase zwei hat sich das implizite Modell des Katalogs in der Schicht verhärtet und ist teuer rückgängig zu machen.

Prinzip 2: Das richtige Zugriffsmuster für Kontext wählen

70 bis 80 Prozent des Unternehmenswissens leben in operativen Systemen wie SAP, Salesforce, PLM, MES, Finanzsystemen und Eigenentwicklungen. Einen Context Layer zu bauen, der blindes Kopieren operativer Daten in einen anderen Speicher erfordert, schafft Risiken bei Aktualität und Governance. Doch Kopien vollständig zu vermeiden, ist nicht das Ziel. Bis die Kopie fertig ist, hat sich die Quelle bereits weiterbewegt.

Die architektonische Entscheidung lautet: föderierte Abfrage (Federated Query) und In-Place-Zugriff, wobei die Ontologie das vereinheitlichende Modell liefert. Nutzen Sie Federation dort, wo Live-Zugriff wertvoll und bezahlbar ist. Materialisieren, cachen oder streamen Sie Kontext dort, wo wiederkehrende Zugriffsmuster, Latenz, Kosten oder Governance dies zur besseren architektonischen Wahl machen. Wir haben die Abwägungen in unserem Plädoyer dafür untersucht, warum Semantik – nicht Zero-ETL – im Unternehmen gewinnt. Veralteter Kontext ist schlimmer als fehlender Kontext, und ungesteuerte Replikation erzeugt veralteten Kontext im großen Maßstab. Gesteuerte Materialisierung, Streaming und Cache-Invalidierung können valide Bestandteile einer Context-Layer-Architektur sein.

Prinzip 3: Offene Standards – sonst gehört Ihnen Ihr Context Layer nicht

Ein Context Layer ist ein Unternehmenswert für Jahrzehnte, kein Projektergebnis. Eine Schicht, die in einer proprietären Plattform gefangen ist, ist kein echter Wert – sie ist eine künftige Migration mit einem freundlichen Namen. Praktisch bedeutet das: standardbasierte Repräsentation (RDF, OWL, SHACL) für die Ontologie und offene Protokolle für die Auslieferung an Agenten.

Das Model Context Protocol (MCP) ist inzwischen die De-facto-Schnittstelle zwischen Context Layern und Agenten und verdient seinen Platz. Doch MCP ist die Verrohrung, nicht die Schicht selbst. Hinter einem nutzlosen Context Layer liefert MCP nutzlosen Kontext nur schneller. Wir haben darüber in unserem Standpunkt geschrieben, warum Einfachheit allein keine Architektur ist. Das Protokoll ist wichtig; was es transportiert, ist wichtiger.

Prinzip 4: Vom ersten Tag an steuern (Governance)

Lineage, Versionierung, semantische Zugriffskontrolle und Audit-Trails sind keine Themen für Phase drei. Der Context Layer ist das System, auf dessen Basis KI-Agenten zunehmend handeln werden, und ungesteuerter Kontext ist ein regulatorisches und operatives Risiko. DSGVO, HIPAA, der EU AI Act und angrenzende Regularien behandeln allesamt die Bedeutung rund um eine Entscheidung als Teil der Entscheidung selbst.

Die einzuplanenden Fähigkeiten sind konkret. Ontologie-Versionierung, damit eine Definition, die sich letztes Quartal geändert hat, nicht stillschweigend die Regeln überschreibt, die eine drei Quartale zuvor getroffene Entscheidung steuerten. Semantische Lineage vom Geschäftskonzept bis hinunter zur Quellspalte, damit eine Antwort verteidigt werden kann. Semantische Zugriffskontrolle, damit eine Rolle Mitarbeiter sehen kann, ohne Gehalt zu sehen. Ein Audit, welcher Kontext für welche Entscheidung zusammengestellt wurde. Jede dieser Fähigkeiten nachzurüsten, ist durchweg teurer, als sie von Anfang an einzubauen. Die Empfehlung von Anthropic zum effektiven Context Engineering macht von der KI-Seite her einen verwandten Punkt: Was an einen Agenten geliefert wird, ist ebenso wichtig wie die Art, wie der Agent darüber schlussfolgert – und Governance ist das, was diese Auslieferung verteidigbar macht.

Prinzip 5: Vom ersten Anwendungsfall an für den zweiten bauen

Die Wirtschaftlichkeit eines Context Layer kippt beim zweiten Anwendungsfall, nicht beim ersten. Muss das zweite Team die Ontologiearbeit, die Integrationsarbeit und die Governance-Arbeit erneut leisten, hat die Organisation keine Schicht. Sie hat ein Projekt, das zweimal stattgefunden hat, und diese beiden Projekte konkurrieren nun um dasselbe Architekturbudget und denselben Executive Sponsor.

Der Weg, das zu vermeiden: Gestalten Sie jedes Artefakt des ersten Aufbaus – Ontologie, Mappings, Governance-Muster, Beispielabfragen – von Anfang an für die Wiederverwendung. Dokumentieren Sie die Interaktionsmuster. Erweitern Sie die Ontologie, statt sie neu zu bauen. Der Prozess ist kumulativ: Dieselben vier Phasen wiederholen sich pro Anwendungsfall, aber Ontologie und Infrastruktur werden übertragen. Jeder Zyklus ist schneller und breiter als der vorige. In diesem Kumulieren zahlt sich die Schicht aus.

Wiederverwendung ist keine Dokumentationsübung. Sie ist eine architektonische Randbedingung: Modellierungskonventionen, Kompatibilitätsregeln, semantische Versionierung, Mapping-Muster und Zugriffsmuster müssen so gestaltet sein, dass der zweite Anwendungsfall den ersten erweitert, statt mit ihm zu konkurrieren.

Die vier Phasen des Context-Layer-Aufbaus

Die Arbeit teilt sich sauber in vier Phasen. Innerhalb jeder Phase steht das Team vor einer kleinen Zahl von Entscheidungen, die stärker ins Gewicht fallen als der Rest. Behandeln Sie die Phasen als Abfolge; überspringen Sie Phase 0 nicht.

Phase 0 – Vorbereitung: Scope festlegen und validieren, bevor Sie modellieren

Ziel der Vorbereitung ist ein hochwertiger, systemübergreifender Anwendungsfall mit klarer Verantwortung und einer validierten technischen Basis. Dies ist die Phase, die Organisationen konsequent überspringen – und deren Überspringen sie konsequent bereuen.

Die hier entscheidenden Fragen: Welcher Workflow hat häufige Ausnahmen, systemübergreifenden Kontext und ein reales Risiko, falls der Agent falsch liegt? Wer verantwortet den Aufbau von Anfang bis Ende? Welche technologische Grundlage werden Sie nutzen? Der richtige erste Anwendungsfall ist nicht der strategisch attraktivste. Es ist der am besten handhabbare – denn Mehrdeutigkeit ist teuer, die benötigten Daten liegen in zwei oder drei verbundenen Systemen vor, und der Workflow kann einen funktionierenden Agenten in einem sinnvollen Zeitrahmen tragen. Die Falle besteht darin, mit dem Workflow zu beginnen, der den Vorstand beeindruckt, statt mit dem, der ein wiederverwendbares Artefakt hervorbringt. Der Zielzustand: ein benannter Verantwortlicher, ein abgegrenzter Anwendungsfall, eine vereinbarte technologische Grundlage und Executive Sponsorship für die anstehende Modellierungsarbeit.

Validierung ist kein Tor, das sich nach Phase 0 schließt. Behandeln Sie sie wie Continuous Integration: Jede Ontologie-Änderung, jedes Mapping und jedes Retrieval-Muster sollte gegen Beispielfragen und erwartete geschäftliche Antworten getestet werden.

Phase 1: Die erste Ontologie bauen

Ziel von Phase 1 ist eine validierte Ontologie in Geschäftssprache, die die Entitäten, Beziehungen, Regeln und Einschränkungen erfasst, die für den abgegrenzten Anwendungsfall relevant sind. Dies ist das Rückgrat, das der Rest des Aufbaus erbt.

Drei Entscheidungen stehen im Zentrum:

1. Wie viel wiederverwenden versus von Grund auf modellieren: Beginnen Sie mit etablierten Upper-Ontologien und erweitern Sie diese pro Domäne.
2. Wie präskriptiv sein: genug, um Reasoning zu stützen, aber nicht so viel, dass die Modellierung selbst zum Projekt wird.
3. Wer beteiligt ist: fachliche Subject-Matter-Experten und IT gemeinsam, niemals die IT allein.

Für einen ersten Anwendungsfall lautet eine nützliche Dimensionierungs-Faustregel aus der Praxisliteratur zu Context Graphs: 8 bis 15 Entitätstypen und 15 bis 25 Beziehungstypen, in Geschäftssprache. Mehr zu dieser Disziplin haben wir in unserem Beitrag über Ontologien als das stabile Fundament eines Knowledge Graph geschrieben.

Die Falle ist nicht die Qualität. Die Falle ist der Scope. Eine erste Ontologie sollte nicht versuchen, das gesamte Unternehmen zu modellieren – aber der Teil, den sie modelliert, muss stabil, präzise und mit Blick auf Kompatibilität gestaltet sein. Wie bei APIs werden semantische Schemata schwer änderbar, sobald Anwendungen und Agenten von ihnen abhängen. Das richtige Ziel ist eine schmale, hochwertige Teil-Ontologie – kein weitläufiges Unternehmensmodell und kein wegwerfbarer Prototyp.

Phase 2: Operative Daten über die Ontologie integrieren

Ziel von Phase 2 ist ein Knowledge Graph, der die Konzepte der Ontologie mit der operativen Realität über CRM, ERP, PLM, MES, Finanzsysteme und weitere Systeme hinweg verknüpft. Das bedeutet weder, jede Quelle in einen einzigen physischen Speicher zu zwingen, noch so zu tun, als sei Live-Federation immer die Antwort. Es bedeutet, operative Daten auf die Ontologie zu mappen und das richtige Zugriffsmuster zu wählen – Federation, Streaming, Caching oder Materialisierung – abhängig von Aktualitätsanforderungen, Abfragemustern, Latenz, Kosten und Governance.

Drei Entscheidungen dominieren. Föderierte Abfrage versus Replikation – föderieren Sie, wo es technisch möglich ist. Entity Resolution – derselbe Kunde über SAP, Salesforce und das Finanzsystem hinweg muss zum selben Knoten aufgelöst werden. Datenqualitäts-Mindestmaße – welches Maß an Sauberkeit als Ausgangspunkt akzeptabel ist und was später bereinigt wird. Warum der Knowledge Graph als fundamental statt als ergänzend zu behandeln ist, legen wir in unserem Argument für Knowledge Graphs als Fundament moderner Datenarchitektur dar.

Die Falle besteht darin, diese Phase als konventionelles ETL ohne semantische Absicht zu behandeln. Datenbewegung mag notwendig sein, aber das Ordnungsprinzip muss die Ontologie und das Zugriffsmuster sein – nicht ein weiteres Warehouse-Schema. Der Zielzustand: eine mit Live-Daten verbundene Ontologie, bei der die Beispielabfragen aus Phase 1 echte Antworten liefern und Konflikte der Entity Resolution aufgelöst sind.

Phase 3: Anwendungen, KI und Agenten anbinden

Ziel von Phase 3 ist es, die Schicht den Systemen zugänglich zu machen, die sie nutzen werden – BI-Tools, LLM-basierte Assistenten, Agenten, Eigenentwicklungen –, und zwar über gesteuerte, standardbasierte Schnittstellen. Dies ist die Phase, in der die Investition für das Geschäft sichtbar wird.

Die Entscheidungen: Was wird über MCP versus eigene APIs bereitgestellt? Wo wird die Zugriffskontrolle durchgesetzt (im Context Layer, nicht in jedem Agenten – Letzteres ist fragil)? Wie werden Entscheidungsspuren zurück in die Schicht erfasst, damit sie dazulernt? Retrieval-Muster sind ebenso wichtig wie die Schnittstellen selbst; die Designentscheidungen haben wir in fünf Entscheidungen, die Ihren Schema-RAG-Agenten prägen durchgegangen. Die Falle besteht darin, den rohen Graph ohne gesteuerte Retrieval-Muster an Agenten freizugeben. Ein Agent, der SPARQL auf einen Graph mit hunderttausend Triples wirft, arbeitet schlecht. Agenten brauchen kuratierte Interaktionsmuster, die auf die Ontologie abgebildet sind. Der Zielzustand: der ursprüngliche Anwendungsfall läuft in Produktion, mindestens ein Agent oder eine Anwendung greift zuverlässig auf die Schicht zu, und die Integrationsmuster sind für die Wiederverwendung im nächsten Anwendungsfall dokumentiert.

Die Phasen kumulieren

Der Prozess ist keine einmalige Pipeline. Nachdem Phase 3 den ersten Anwendungsfall abgeschlossen hat, beginnt das Team Phase 0 erneut für den nächsten – nun aber mit dem größten Teil der Ontologie und Infrastruktur bereits vorhanden. Jeder Zyklus ist schneller, breiter und erzeugt weniger marginale Arbeit als der vorige. Die Wirtschaftlichkeit des Context Layer entspringt diesem Kumulieren, nicht einem einzelnen Projekt. Ist der zweite Zyklus genauso groß wie der erste, ist bei einem der Prinzipien aus dem vorigen Abschnitt etwas schiefgelaufen – fast immer bei Prinzip 5.

Wie d.AP diese Prinzipien operationalisiert

d.AP ist um ein Liefermodell herum aufgebaut, das die vier Phasen spiegelt. Phase 0 läuft als Scoping-Workshops mit den Business-Sponsoren und der IT, um einen hochwertigen, systemübergreifenden Anwendungsfall zu identifizieren.

In Phase 1 bringen wir grundlegende Ontologie-Muster ein und passen jedes Modell pro Unternehmen an – also top-down, geschäftsgetrieben, nicht datengetrieben.

In Phase 2 verbinden wir semantische Mappings über SAP, Salesforce, PLM, MES, Finanzsysteme und Eigenentwicklungen hinweg und nutzen dabei das Zugriffsmuster, das zur jeweiligen Quelle und zum Anwendungsfall passt: Federation, wo Live-Zugriff wertvoll ist, gesteuerte Materialisierung, wo Kontext für Performance oder Wiederverwendung neu organisiert werden muss, und Caching oder Streaming, wo wiederkehrende Zugriffsmuster es erfordern. Die Ontologie bleibt über all diese Entscheidungen hinweg das stabile Rückgrat.

In Phase 3 stellen wir die Schicht über standardisierte Schnittstellen (MCP, A2A) bereit – gemeinsam mit unserem eigenen Assistenten Aluna und dem Graph Explorer für die direkte menschliche Nutzung, mit wiederverwendbaren Dashboards, die gegen die Ontologie komponiert sind.

Drei Eigenschaften machen den Ansatz dauerhaft:

1. Ontology-first by Design: Die Ontologie ist das Rückgrat, nicht nachträglich hinzugefügte Dokumentation. Das knüpft an Prinzip 1 an.
2. Offen, portabel und zugriffsmusterbewusst (RDF, OWL, MCP, A2A), sodass der Kontext der Vermögenswert des Kunden bleibt und über Anbieter hinweg portabel ist. Das knüpft an die Prinzipien 2 und 3 an.
3. Gesteuert und kumulierend: Versionierung, semantische Lineage, semantische Zugriffskontrolle und ein Prozess, der mit jedem Anwendungsfall kumuliert. Das knüpft an die Prinzipien 4 und 5 an.

Für Leserinnen und Leser, die Optionen vergleichen, pflegen wir eine direktere Einordnung, wo wir neben anderen Anbietern stehen – in unserem Vergleich von Enterprise-Knowledge-Graph-Plattformen.

Wie ein erfolgreicher erster Aufbau aussieht

Der schwierigste Teil eines Context-Layer-Programms ist nicht die technische Arbeit. Es ist, sich selbst – und Ihren Lenkungsausschuss – davon zu überzeugen, dass der erste Aufbau tatsächlich funktioniert. Drei Signale unterscheiden eine funktionierende Schicht von einer weiteren beeindruckenden Demo.

Das erste: dieselbe geschäftliche Frage, auf dieselbe Weise beantwortet – von einem Agenten und von einem menschlichen Analysten. Liefern zwei Wege zur selben Frage unterschiedliche Antworten, hat die Schicht die Bedeutung noch nicht vereinheitlicht.

Das zweite: Der zweite Anwendungsfall erfordert spürbar weniger Aufwand als der erste. Muss das zweite Team die Ontologie, die Mappings oder die Governance erneut aufbauen, haben Sie ein Projekt, keine Schicht.

Das dritte: Sie können eine zuvor unmögliche systemübergreifende Frage beantworten. Etwa: „Liste alle aktiven Verträge für strategische Kunden auf, die von einer bestimmten Lieferkettenstörung betroffen sind." Das ist eine Frage, die den Zugriff über CRM, ERP, Vertragsmanagement und operative Daten hinweg erfordert – gesteuert durch aktuelle Regeln. Die neue Beantwortbarkeit ist der Beweis. Dasselbe Muster zeigt sich in unserem Use Case zum Lieferketten-Risikomanagement, bei dem der Wert der Schicht genau in der Fähigkeit liegt, Fragen zu stellen, die die bestehenden Systeme nicht beantworten konnten.

Wo Sie beginnen sollten

Die wichtigste erste Entscheidung ist nicht, welche Plattform Sie nutzen. Es ist, welchen Workflow Sie abgrenzen. Wählen Sie einen, bei dem die Kosten von Mehrdeutigkeit hoch sind, die Daten tatsächlich über mehrere Systeme verteilt liegen und das verantwortliche Team die Befugnis hat, auf das zu reagieren, was die Schicht ihm mitteilt. Alles Weitere folgt aus einem gut gewählten ersten Anwendungsfall.

Wenn Sie Unterstützung bei dieser Entscheidung wünschen, sprechen Sie mit dem d.AP-Team über das Scoping Ihres ersten ontologiegetriebenen Context Layer. Die Scoping-Workshops sind bewusst kurz und konkret: eine Arbeitssitzung mit Ihren Business- und IT-Verantwortlichen, um den Workflow zu identifizieren, den Ontologie-Ansatz zu validieren und zu skizzieren, wie der erste Aufbau aussieht.