Eines sie alle zu binden

Unternehmensdatenmodelle

Stabsstellen sind doch etwas schönes. Budgets scheinen keine Rolle zu spielen. Und man kann andere so schön ärgern, die von den Ergebnissen abhängig sind, denn das Management steht ja dahinter. Irgendwann vor langer Zeit ist ein kleiner Datenmodellierer auf die Idee gekommen, einem Manager das nahezubringen, was er so tut. Da sich Manager nicht mit kleinen Dingen abgeben, kamen sie auf die Idee, ein allumfassendes Unternehmensdatenmodell zu schaffen. Von nun an sollten sich alle Anwendungen im Unternehmen an dieses eine Datenmodell halten. Alle weitere Datenmodellierung wäre nicht mehr notwendig und alles würde großartig zusammenarbeiten.

Nun wäre ich der letzte, der etwas gegen Datenmodellierung sagen würde. Ein aussagefähiges Datenmodell ist nicht nur die Grundlage eines erfolgreichen Projekts, sondern besitzt in meinen Augen auch so etwas wie Schönheit.

Das Problem mit den ganz großen und alles lösenden Ansätzen ist nur, daß sie im allgemeinen zu scheitern pflegen. Dies liegt im wesentlichen an drei Dingen. Zuerst leben wir in einer Zeit, in der sich Dinge schnell ändern - schneller als man ein ganz großes Datenmodell erstellen kann. Zweitens sind die Anforderungen der einzelnen Nutzer zu individuell. Wenn für einen die Adresse nur ein Stück Text ist, das auf Adreßetiketten gedruckt werden muß, ist für einen anderen Nutzer jedes Detail interessant, da er z.B. darauf aufbauend die Kreditwürdigkeit eines Kunden bestimmen will (wie auch immer man zu diesen Methoden steht, sie sind in vielen Anwendungen implementiert). Ein gutes Datenmodell zeichnet sich dadurch aus, daß der Detailierungsgrad angemessen ist. In dem genannten Beispiel muß aber berücksichtigt werden, daß der Datenaustausch nur in eine Richtung funktioniert, da der andere Partner mit weniger Information auskommt. Der dritte Punkt ist die Beschränktheit der Beteiligten, was Kommunikation und Verständnis betrifft. Die Korrektheit eines Datenmodells beweißt sich erst durch die Benutzung. Auf der grünen Wiese erstellt, wird es sehr instabil sein.

Wenn nun ein Fehler in so einem Datenmodell festgestellt wird, müssen alle Anwendungen, die davon abgeleitet sind, korrigiert werden. Ansonsten bilden sich unterschiedliche Abkömmlinge, die genauso wenig zuverlässig miteinander kommunizieren können, wie es der Fall war vor der Einführung des einheitlichen Datenmodells.

Da die mit einer Änderung des Unternehmensdatenmodells verbundenen Kosten hoch sind, führt das zu einer Trägheit bei der Anpassung der Modelle, die die Grundlage der Anwendungen bilden. Es gibt große Konzerne, die schon früh in solche Modelle investiert haben und heute darunter leiden, daß alle ihre Anwendungen noch die Situation in den 90ern widerspiegeln, obwohl sich der Markt, in dem sich diese Unternehmen befinden, drastisch geändert hat.

SOA

Heutezutage will jeder IT-Leiter seine IT auf SOA (Service Oriented Architecture) aufbauen. Diese Services sollen zweierlei leisten. Zum einen sollen sie unabhängig entwickelt und gepflegt werden können. Zum anderen sollen sie von vielen Anwendungen genutzt werden können. Ich will hier nicht weiter darauf eingehen, inwieweit diese Ansprüche erfüllt werden können. Mich interessiert hier nur die Sicht des Datenmodelliers.

Datenmodellierung findet hier bei den in den Schnittstellen ausgetauschten Daten statt. Statt ER-Modelle für Datenbanken werden jetzt XML-Schemata modelliert, wobei es natürlich eine Frage ist, ob XML immer die beste Lösung ist.

Im Prinzip kann jeder Service sein eigenes Datenmodell entwickeln. Dies bedeutet, daß der Benutzer zuerst die Daten zwischen der Darstellung des Services und seiner internen Darstellung transformieren muß. An dieser Stelle setzt die Handlung von "Die Rückkehr des Unternehmensdatenmodellierers" ein. Der Gedanke ist doch bestechend. Wir bauen ein großes Datenmodell, auf das alle Services aufbauen. Dann entfällt diese lästige Transformiererei. Alle sprechen eine gemeinsame Sprache und die Datentypen passen aufeinander.

Leider haben wir hier wieder alle oben beschriebenen Probleme. Die Services sind hochgradig gekoppelt. Eine unabhängige Entwicklung ist nicht mehr möglich. Wenn das zentrale Datenmodell ausgetauscht wird, funktioniert zuerst einmal nichts mehr, bis alle Services angepaßt sind.

Dies widerspricht grundsätzlich der Idee, die Services zu entkoppeln.

Wenn man doch in diese Richtung gehen will, so sollte man nicht die Datenmodelle durch neue Versionen ersetzen, sondern die Versionen nebeneinander leben lassen. Eine alte Version wird erst entfernt, wenn alle Nutzer auf die neue Version gewechselt sind. Dadurch müssen zwar wieder Transformationen durchgeführt werden, wenn die kommunizierenden Services unterschiedliche Versionen eingesetzt werden, doch der Aufwand dürfte meist überschaubar sein und es ist auch eine Wiederverwendung denkbar.

Allgemein gegen präzise

Ein weiterer Aspekt ist, daß ein allgemeines Schnittstellenmodell nur den kleinsten gemeinsamen Nenner darstellen kann. Das gleiche Element mag für die eine Schnittstelle optional sein, während es für die andere notwendig ist. Die eine Anwendung braucht eine Historisierung der Daten, die andere genau das neueste Element. In einem für alle nutzbarem Modell kann das Element nur optional sein und mehrfach vorkommen dürfen. Validierungen aufgrund des Datenmodells werden dadurch ungenauer. Die individuelle Anforderungen der einzelnen Schnittstellen müssen anderweitig dokumentiert werden, was sich häufig als Fehlerquelle erweist.

Zusätzliche Aspekte, die hier zu berücksichtigen sind, sind Datensicherheit und Vertraulichkeit. Nur bestimmte Systeme dürfen mit personenbezogenen Daten umgehen. Diese sind in einer allgemeinen Schnittstelle, die von allen genutzt werden soll, mit enthalten.

Logisch gegen technisch

Es ist wichtig, daß alle miteinander sprechen können. Daher ist ein - nicht zu detailliertes - logisches Datenmodell für alle sicher sinnvoll. Die technische Umsetzung in eine konkrete Schnittstelle erfolgt aber besser individuell.