Die Datenarchitektur beschreibt als Teilarchitektur eines Informationssystems die grundlegenden Datenstrukturen. Die Datenarchitektur gibt damit einen guten Überblick über die strukturellen Zusammenhänge des betrachteten Systems. Abhängig vom Modellierungs- und Analyseziel können verschiedene Ausprägungen der Datenarchitektur auf Fachkonzept- oder Entwurfsebene unterschieden werden.
Begriffsbestimmung
Eine Architektur beschreibt die grundlegende Struktur eines Systems mit seinen Elementen, den Beziehungen zwischen diesen Elementen sowie den Beziehungen des Systems zur Umwelt (ISO 2000). Darüber hinaus sollten auch Prinzipien für die Konstruktion, Weiterentwicklung und Nutzung des Systems beschrieben werden (IEEE 2000). Eine Architektur unterscheidet sich von anderen Modellen (1) durch eine ganzheitliche Sicht auf ein System, was die Breite der betrachteten Elemente angeht, sowie (2) durch eine vergröberte Betrachtung.
Die Datenarchitektur stellt eine spezifische Teilarchitektur der Informationssystem-Architektur dar (The Open Group 2022) und beschreibt die Datenstruktur eines Informationssystems. Die Datenstruktur abstrahiert dabei von einzelnen Entitäten (z. B. „Frau Mayer“), indem gleichartige Daten zu Entitätstypen (z. B. „Kunde“) zusammengefasst werden. In der Datenarchitektur werden solche Entitätstypen und ihre Beziehungen zueinander dargestellt. Im Sinne einer vergröberten Betrachtung kann es notwendig sein, nur ausgewählte Entitätstypen in der Datenarchitektur abzubilden oder für die Datenarchitektur Entitätstypen zusammenzufassen (z. B. Boßhammer und Winter 1995).
Für die Datenarchitektur gibt es keine spezielle Darstellungsform. Allerdings sind semiformale Notationen üblich (vgl. Datenmodellierung).
Datenarchitekturen können sich als Unternehmensdatenarchitektur auf die grundlegenden Datenstrukturen eines ganzen Unternehmens beziehen oder sich als Datenarchitektur eines Anwendungssystems auf einen Ausschnitt des Unternehmens beziehen. Davon abzugrenzen sind die unternehmensweiten Datenmodelle, welche das Ziel haben, alle Daten eines Unternehmens zu dokumentieren. Dieser Ansatz aus den 90er Jahren ist allerdings mit Schwierigkeiten verbunden, da durch die ständige Veränderung eines Unternehmens ein immenser Pflegeaufwand entsteht. Im Folgenden wird darum exemplarisch die Datenarchitektur eines Anwendungssystems beschrieben.
Datenarchitektur eines Anwendungssystems
Die Datenarchitektur eines Anwendungssystems lässt sich bei der Konzeption, Entwicklung, Wartung und Außerbetriebnahme des Anwendungssystems nutzen (vgl. Lebenszyklus von Anwendungssystemen). Je nach Gestaltungsziel kann sie auf fachkonzeptioneller Ebene (vgl. Problemanalyse, Anforderungsdefinition) oder auf Entwurfsebene (vgl. Softwareentwurf) beschreiben werden. Auf fachkonzeptioneller Ebene werden die betriebswirtschaftlich relevanten Datenstrukturen dargestellt. Zur Darstellung auf fachkonzeptioneller Ebene eignen sich insbesondere semiformale Modellierungssprachen (vgl. Datenmodellierung), wie z. B. das Entity Relationship Model(Chen 1976). Auf Entwurfsebene wird die systemtechnische Umsetzung konzeptionell spezifiziert. Die Wahl einer geeigneten Beschreibungsform hängt daher vom verwendeten Datenbankmanagementsystem ab. Für betriebswirtschaftliche Anwendungssysteme sind relationale Datenbankmanagementsysteme weit verbreitet. Zur Beschreibung der Datenarchitektur einer relationalen Datenbank auf Entwurfsebene eignet sich z. B. ein relationales Datenbankschema in Tabellenform (Kemper und Eickler 2015).
Neben der Datenarchitektur lassen sich weitere Teilarchitekturen eines Anwendungssystems spezifizieren, die eine andere Sicht auf die Anwendung ermöglichen, z. B. eine ablauforientierte Sicht (vgl. Geschäftsprozessmodellierung) oder eine aufgabenorientierte Sicht (vgl. Funktionsmodellierung). Einzelne Sichten konzeptionell voneinander zu trennen ist wichtig, um die Komplexität des Systems zu reduzieren. Dennoch bestehen Abhängigkeiten zwischen einzelnen Sichten. Verschiedene Ansätze zur Anwendungsmodellierung berücksichtigen daher neben der Datensicht nicht nur weitere Sichten, sondern auch die gegenseitigen Abhängigkeiten der Sichten zueinander. Beispiele für derartige Ansätze sind die Architektur integrierter Informationssysteme oder die Multiperspektivische Unternehmensmodellierung.
Die Datensicht war und ist ein wichtiger Bezugspunkt für weitere Sichten auf ein Anwendungssystem, weil sie einen konsistenten und weitreichenden Überblick über dessen Bestandteile gibt. Hinzugekommen sind jedoch weitere Paradigmen, wie die Objektorientierung (vgl. Objektorientierte Modellierung, Objektorientierter Softwareentwurf), welche Daten in stärkerem Maße in abgeschlossene Objekte kapselt. Dadurch wird der Überblickscharakter der Datenarchitektur einschränkt, gleichzeitig aber der Forderung nach mehr Flexibilität durch das Prinzip der losen Kopplung Rechnung getragen. Objektorientierte Ansätze haben die klassischen relationalen Ansätze jedoch weder auf konzeptioneller noch auf technologischer Ebene ersetzt. Vielmehr wurden objektorientierte Konzepte (z.B. Vererbung) in objekt-relationalen Ansätzen integriert (Kemper und Eickler 2015).
Erweitert man die Perspektive über einzelne Anwendungssysteme hinaus, so spielt auch hier die Idee der Kapselung von Daten, z.B. via Application Programming Interfaces (APIs), eine wichtige Rolle für die Integration innerhalb oder zwischen Unternehmen.
Mit der wachsenden Bedeutung sowohl von «offensiven» Datenmanagement-Strategien, welche auf datengetriebene Innovationen abzielen, als auch von «defensiven» Datenmanagement-Strategien, welche mit Governance-Mechanismen Risiko- und Compliance-Ziele adressieren, ist auch die Bedeutung von architektonischen Sichten auf Daten innerhalb von Unternehmen weiter gewachsen (Schilling et al. 2020). Ausdruck findet diese Entwicklung im Aufbau von unternehmensinternen Datenkatalogen, welche Beziehungen von Entitäten wie auch deren Verarbeitung entlang unterschiedlicher Anwendungssysteme (sogenannte Data Lineage) dokumentieren.
Literatur
Boßhammer, Manfred; Winter, Robert: Formale Validierung von Verdichtungsoperationen in konzeptionellen Datenmodellen – Zur konsistenten Verdichtung von Grafiken und Textdokumentationen der Datenbasis betriebswirtschaftlicher Anwendungssysteme am Beispiel des SAP R/3 PP- und SD-Schema. In: König, Wolfgang (Hrsg.): Wirtschaftsinformatik 95. Physica, Heidelberg, S. 223-241, 1995.
Chen, Peter Pin-Shan: The Entity-Relationship Model – Toward a Unified View of Data. In: ACM Transactions on Database Systems 1 (1), S. 9-36, 1976.
IEEE: IEEE Recommended Practice for Architectural Description of Software Intensive Systems (IEEE Std 1471-2000), 2000.
ISO: ISO 15704:2000: Industrial automation systems – Requirements for enterprise-reference architectures and methodologies. Genf, 2000.
Kemper, Alfons; Eickler, André: Datenbanksysteme eine Einführung. 10. Aufl., Oldenbourg, München, 2015.
Schilling, Raphael; Aier, Stephan; Winter, Robert; Haki, Kazem: Design Dimensions for Enterprise-Wide Data Management: A Chief Data Officer’s Journey. Proc. 53rd Hawaii International Conference on System Sciences (HICSS 53). Grand Weilea, Maui, Hawaii. 2020.
The Open Group: The Open Group Architecture Framework (TOGAF) Version 10.
Methodik gestaltungsorientierter Forschung