Wie man ein Datenmodell definiert und pflegt, an dem alle Freude haben

Große Unternehmen wie die Deutsche Bahn AG tauschen Daten aus – innerhalb ihrer eigenen Systeme ebenso wie mit externen Geschäftspartnern und deren oft Cloud-basierten Systemen. Häufig führen Missverständnisse über die Bedeutung und Interpretation einzelner Datenelemente zu langen Entwicklungszeiten, unvollständigen Tests und letztendlich schlechter Datenqualität. Die Korrektur solcher Fehler ist zeit- und kostenintensiv.

Der klassische Ansatz ist von der Geschäftsprozessanalyse getrieben. Aus den Anforderungen wird von der Architektur ein logisches Modell entwickelt. Daraus folgen durch die Anwendungsentwicklung ein physisches Modell und schließlich die Implementierung und die Tests. Während des anschließenden Betriebs entwickelt sich das Geschäft weiter. In der Theorie wird der Prozess für neue und geänderte Anforderungen dann wieder und auf die gleiche Art und Weise durchlaufen. Doch die Praxis sieht meist anders aus. Die logischen Modelle haben einen so hohen Abstraktionsgrad, dass sie für Details gar nicht erst geändert werden.  Anpassungen sind zeitkritisch, das Budget ist begrenzt und Dokumentation wird nur gepflegt, wenn Zeit ist.

Plötzlich stehen mehrere Artefakte miteinander in Konflikt und jede Abteilung schaut auf „ihre“ Version der Wahrheit.

Was ist der Mehrwert?

Ein integrierter Ansatz pflegt ein Modell, aus dem alle weiteren Artefakte vollautomatisch abgeleitet werden. Der Schlüsselbegriff ist hier „vollautomatisch“: Bei jeder (zeitkritischen) Änderung muss es einfacher sein, das zentrale Modell zu pflegen als nachgelagerte Artefakte per Hand anzupassen. Somit hat jede Abteilung ein originäres Interesse daran, das Modell aktuell zu halten, um sich später ineffiziente Nacharbeiten zu ersparen.

Der gewünschte Nutzen stellt gewisse Anforderungen an das Modell:

  • Die Fachabteilungen müssen es verstehen können, so dass es als Werkzeug zur System- und Anforderungsanalyse taugt.
  • Es muss genügend Fachinformationen enthalten, um das Verständnis für die Daten auf nachgelagerten Ebenen zu fördern und häufige Rückfragen überflüssig zu machen.
  • Es muss automatisiert zu verarbeiten sein, um andere Artefakte daraus automatisch ableiten zu können.
  • Es muss genügend technische Details enthalten, um technische Artefakte wie Datenbankmodelle und Datenaustauschformate ohne manuellen Eingriff generieren zu können.

Ein solches Modell und die begleitenden Werkzeuge führen dazu, dass alle Beteiligten – von der Fachabteilung über die Analystinnen und Analysten, Architektinnen und Architekten, Entwicklerinnen und Entwickler bis zu den Testerinnen und Testern und dem Helpdesk – auf demselben Stand der Informationen sind.

Wie soll das funktionieren?

Ein häufiges Gegenargument ist, dass jede Technologie so spezielle Fähigkeiten habe, dass es nicht möglich sei, alles exakt automatisch aus einem Metamodell abzuleiten. 

Das stimmt.

In sehr vielen Fällen sind aber überhaupt nicht alle besonderen Möglichkeiten erforderlich. Eine Transportbestellung oder ein Frachtbrief beispielsweise sind einer Rechnung oder einem Kontoauszug dahingehend ähnlich, dass sie eine Reihe von einmal vorhandenen Kopfelementen und eine Reihe von sich wiederholenden Zeilenelementen besitzen, jeweils mit zu überprüfenden Datentypen. Eine solche Struktur kann man in jeder aktuell für den Datenaustausch genutzten Technologie abbilden. Während es also sicherlich Geschäftsdaten gibt, auf die der integrierte Ansatz nicht anwendbar ist, funktioniert er jedoch in der Praxis zu einem sehr großen Prozentsatz.

Wer profitiert bereits von einem solchen Ansatz?

CGI konnte bereits einen großen internationalen Handelskonzern dabei unterstützen, seine IT-Landschaft für Transportmanagement und -abrechnung zu erneuern. Die Plattform, über die jährlich Transportaufträge für mehr als eine Milliarde Euro abgewickelt werden, ist mit über 100 internen und externen Systemen vernetzt. Während zu Beginn nur relationale Datenbanktabellen und XML als Austauschformate verwendet wurden, ist die Lösung – ausgehend vom selben kanonischen Datenmodell – nun um das moderne JSON-Format als gleichberechtigte Alternative erweitert worden. Sowohl die Dokumentation als auch die physischen Modelle und Schemata werden vollständig automatisiert synchron gehalten.

Neugierig geworden?

Um mehr über dieses Thema zu erfahren, lesen Sie unser Whitepaper oder kontaktieren Sie uns.