Man stelle sich man die folgende hypothetische Situation vor: Eine Firma existiert bereits seit Jahren und ist stetig über diesen Zeitraum gewachsen. Am Anfang war vielleicht ein UNIX System, ein Großrechner oder eine AS/400 auf der die ersten unternehmensweit vitalen Daten lagen. Über die Jahre hinweg tauchten andere Plattformen und Betriebssysteme wie Windows und/oder Linux, auf. Diese liefen dann auf den Rechnern der Anwender in den verschiedenen Abteilungen der Firma. Die Anwender in diesen Abteilungen adaptierten schnell die neuen Systeme und entwickelten ihre eigenen Lösungen für ihre jeweiligen Bedürfnisse. Die Anzahl der Schnittstellen zwischen den diversen System wuchs beständig und die Daten wurden redundant in zahlreichen Systemen in teilweise verschiedenen Aggregationsstufen gehalten. Da die Firma rasch wuchs, war nie genug Zeit vorhanden, die vorhandenen Systeme systematisch zu erfassen und zu dokumentieren. Niemand störte sich großartig an diesem Zustand. Falls die IT Abteilung überhaupt von diesen "Stealth" Systemen wußte, da nahezu in jeder Abteilung ein "Power User" in der Lage ist, eine Tabellenkalkulations- oder eine Desktop-Datenbank Lösung zu erstellen. So lange alles ohne Probleme läuft, stört sich niemand an diesem Chaos in der IT Infrastruktur. Aber wehe, wenn etwas mit einem Fehler abbricht. Im Zweifel haben die ursprünglichen Entwickler die Firma bereits vor Jahren verlassen und aufgrund der unzureichenden Dokumentation weiß niemand so ganz genau, was denn der Code eigentlich macht. Daher kommt es öfters mal vor, daß die Beseitigung eines Fehlers an ganz anderer Stelle nun zu einem neuen Fehler führt, da auch die Abhängigkeiten zwischen den einzelnen Systemen unbekannt sind. Die IT Abteilung ist kaum noch in der Lage, das Chaos unter Kontrolle zu halten und anstatt sich auf ihre eigentliche Aufgabe, der Optimierung von IT Prozessen, zu konzentrieren, spielt die Abteilung nur noch Feuerwehr und löscht einen Brand nach dem anderen. Wie...??? Das klingt nicht allzu hypothetisch? Das klingt vielleicht sogar bekannt?

Nun, ich glaube, daß es in der überwiegenden Mehrzahl aller Firmen mehr oder weniger so aussieht. Und genau hier setzt auch das vorliegende Buch an. Es befaßt sich nicht mit Datenbanken in dem Sinne, wie man durch Administration oder Entwicklung eines Datenbanksystems, eine Datenstrategie implementiert. Dieses Buch abstrahiert wesentlich stärker und betrachtet das Thema eher aus der Vogelperspektive. Es beschreibt die Vorteile, die eine homogene IT Infrastruktur bietet und die Vorteile, die die gesamte Firme hat, wenn man sich auf einige wenige Kerntechnologien beschränkt, um diese homogene Infrastruktur zu schaffen. Von daher sollte man auch keine spektakulären neuen Erkenntnisse erwarten. Es werden keine wirklich innovativen, tiefgreifenden Einblicke geboten, die man nicht sowieso haben sollte, sofern man als IT Mensch mit offenen Augen durch die Welt geht. Zugegebenermassen hilft es aber doch von Zeit zu Zeit immer mal wieder, darüber zu lesen.

Dieses Buch wird seine Leser polarisieren. Natürlich ist es aus der IT Perspektive heraus wünschenswert, sich auf einige wenige Kernsysteme konzentrieren zu können, um dadurch besseren allgemeinen Service leisten zu können. Dies aber in der Wirklichkeit zu erreichen ist gleichwohl äußerst schwer. Die Gründe dafür sind vielfältig. Sie beginnen mit der Nichtverfügbarkeit von IT System auf bestimmten Plattformen, bzw. falls sie verfügbar sind, bieten sie nicht die geforderte Funktionalität. Weiter geht's vielleicht damit, daß das Management nicht bereit ist, viel Geld für ein System auszugeben, welches die Kernsysteme unterstützt, wenn es auch andere Systeme gibt, die wesentlich weniger kosten, evtl. im Falle von Open Source, vielleicht sogar kostenlos sind, aber leider nur andere Technologien unterstützen. Darüberhinaus mag man vielleicht auch argumentieren, daß die Migration von System A auf System B eine nicht zu unterschätzende Aufgabe darstellt, die sehr zeit- und kostenintensiv ist und eine sorgfältige Vorbereitung erfordert. Zu guter Letzt gibt es auch gute Gründe für das Argument, daß eine Firma sich nicht 100% von einem einzigen Betriebssystem oder einem einzigen Datenbanksystem abhängig machen will und deshalb absichtlich mehrgleisig fährt. Es gibt noch viele weitere Gründe, die wahrscheinlich schon jeder mal gehört hat. Deshalb spare ich sie mir hier an dieser Stelle.

Es fällt mir nicht leicht, eine Empfehlung zu diesem Buch zu unterbreiten. Es ist sicherlich erstklassig geschrieben, gut lesbar und man merkt, daß die Autoren anerkannte Fachleute auf ihrem Gebiet sind. Der wahrscheinlich in den meisten Firmen vorherrschende Status Quo wird klar analysiert, aber die Schlußfolgerung, sich auf einige wenige Kernsysteme zu konzentrieren, ist nicht so einfach, wie in dem Buch beschrieben. Während es in der Theorie natürlich logisch und einleuchtend ist, ist die reale Welt myriadenfach komplexer in all ihren Facetten und so eine Entscheidung trifft man nicht so einfach, da sie eine Firma in ihrem Kern trifft.

Falls Sie IT Manager sind, der noch Argumente für seinen Kampf mit der Geschäftsführung sucht, werden Sie dieses Buch interessant und hilfreich finden. Falls Sie DBA oder Entwickler sind, machen Sie zwar nichts falsch, wenn Sie mal hin und wieder ein solches Buch lesen. Ich halte es aber nicht für eine notwendige Literatur, die Sie zwingend für Ihren Job brauchen. Und deshalb sollten Sie, wie eigentlich immer, sich dieses Buch vor einem Kauf genau ansehen.

Data Strategy von Adelman, Moss und Abai 2005 Addison-Wesley ISBN: 0-321-24099-5