Das Dilemma der Möglichkeiten

Manch einer sehnt sich bestimmt nach der guten alten Zeit der Mainframes zurück. In der IT hat man es heute nicht leicht, denn die Welt ist im Vergleich zu damals kompliziert geworden. Allein die Möglichkeit, zwischen vielen unterschiedlichen Technologien und Konzepten wählen zu können, offenbart die Herausforderung. Ein Beispiel, bei dem das besonders deutlich wird, sind Datenbanken. Bis vor 15 Jahren war es in deutschen Unternehmen nahezu undenkbar, etwas anderes, außer lizenzpflichtige relationale Datenbanken zu verwenden. Und die Zahl der dafür infrage kommenden Anbieter konnten an einer Hand abgezählt werden. Man kaufte eine Lizenz, installierte die Software, ging zur Schulung und schon konnte es losgehen.

Genau in diesem Bereich der Datenbanken führen heute viele unterschiedliche Ansätze und Konzepte nicht nur zu einer reichhaltigeren Auswahl, sondern auch dazu, dass es keine technische Standardantwort auf diverse fachliche Fragen gibt. Es sei denn, man begnügt sich mit mittelmäßigen oder suboptimalen Lösungen. In den 90er-Jahren galt es als State oft the Art, durch eine IT-Strategie, jede Anforderung mit einer Standardtechnologie zu adressieren – am liebsten mit nur noch von einem Hersteller. Und das war eigentlich immer eine relationale Datenbank, entweder von Oracle, Microsoft, IBM oder auch mal MS Access für den Hausgebrauch.

Heute wäre diese Form der Standardisierung in etwa so einzuordnen, als ob wir uns ausschließlich mit dem PKW bewegen würden. Egal, wie weit das Ziel entfernt, was zu transportieren oder ob ein ganzer Ozean zu überqueren ist. Ein seltsamer Vergleich, weil man zum Briefkasten um die Ecke besser läuft oder ein PKW nicht übers Wasser fahren und auch keinen Wandschrank transportieren kann? Absolut richtig und der Vergleich mag auch etwas überspitzt sein. Aber wie viele Projekte kennen Sie, die zu teuer, zu kompliziert oder zu langwierig waren und am Ende mit Resultaten aufwarteten, die den Erwartungen nicht gerecht wurden? Und wie viele von diesen Unterfangen mussten gegen eine starre IT-Architekturvorgabe arbeiten? Ich will nicht sagen, dass ein Standard generell schlecht ist. Schlecht ist Standardisierung in der IT nur dann, wenn man dadurch gezwungen wird, technische Potenziale einfach liegen zu lassen oder aber eine Technologie so lange zu verbiegen, bis diese endlich in eine bestimmte Schublade passt, die sich hinterher aber kaum noch öffnen lässt. Neben anderen Fehlern in IT-Projekten handelt es sich heutzutage hierbei sicherlich um eines der Hauptprobleme von technischen Projekten.

Was mit einer leistungsstarken und flexiblen IT möglich ist, zeigen uns die US-amerikanischen Tech-Unternehmen wie Google oder Amazon seit einigen Jahren. Im Vergleich zum US-Markt, muss man leider feststellen, dass der europäische Kontinent im Mittel wahrscheinlich fünf bis acht Jahre Rückstand in der technischen Entwicklung von IT-Lösungen aufzuholen hat. Um diesen Rückstand zu neutralisieren, hat sich in den letzten Jahren auch einiges getan. Ein schönes aktuelles Beispiel ist das GAIA-X Projekt, das sehr zu begrüßen ist. Noch schöner wäre es allerdings gewesen, wenn es den Startschuss dazu schon vor fünf oder gar acht Jahren gegeben hätte. Heute leistet sich jeder Konzern Think Tanks, Innovation Labs und viele PoC-Projekte. Nicht selten schwingt das Pendel dann in das andere Extrem und führt zu Projekten, bei denen per se nur die neuesten Technologien zum Einsatz gebracht werden. Eine Spielwiese für Technologie mündet aber nur selten in eine robuste und nachhaltige Fachlösung. Meist liegt dann das Resümee irgendwo zwischen „diese neuen Technologien funktionieren ja gar nicht so gut, wie immer alle sagen“ oder „spannende Ergebnisse, lassen Sie uns das Thema mal strategisch auf die Roadmap nehmen“. Etwas mehr Mut in Verbindung mit einem organisatorischen Umdenken stünde vielen Konzernen besser zu Gesicht. Um Ergebnisse zu vermeiden, die faktisch keinen Nutzen stiften, dafür aber nicht wenig Geld kosten und auch nur in den wenigsten Fällen Innovation fördern, sollte ein modernes IT-Team Folgendes berücksichtigen:

1. Scouting von technologischen Entwicklungen und Konzepten (auch Open Source)
2. Verproben von Technologien und Konzepten
3. Design von Lösungs-, Betriebs- und Wartungskonzept
4. Entscheiden, welche Technologie eignet sich für eine konkrete Anforderung

Um diese vier aufeinander aufbauenden Aspekte erfolgreich einzusetzen, sind bestimmte Rahmenbedingungen nötig. Nämlich ein neuer Typus IT-Mitarbeiter (jemand, der sich permanent mit neuen Technologien beschäftigt, Konzepte verinnerlicht, miteinander vergleicht und erprobt) und eine IT-Organisationsform, die diese Mitarbeiter auch zur Entfaltung kommen lässt. Der klassische Fach-Spezialist der 90er- oder 2000er-Jahre ist hier weniger gefragt. An dieser Stelle liegt das Potenzial vieler Unternehmen. Denn, agil arbeiten, heißt auch, stetig und aktiv Technologien zu analysieren und zu testen und am Ende auch als Team die Verantwortung für die eigenen Entscheidungen und Resultate zu tragen (you build it, you run it). Denken und Handeln zu trennen, so wie es der klassische Managementgedanke aus den 60er-Jahren praktiziert, funktioniert heute in der IT nicht mehr. Dennoch arbeiten noch zu viele Organisationen nach den alten Mustern und das Top-Management wundert sich, dass nichts vorangeht. Dies allein muss aber noch nicht das Ende der Zukunft bedeuten, denn insbesondere die ersten beiden Säulen können in Form einer Technologieberatung eingekauft werden.

Um also einen ersten Überblick über die Welt der Datenbanktechnologien zu gewinnen, sollte man sich die grundlegenden Konzepte vergegenwärtigen. Auf der obersten Ebene könnte man verschiedene Kategorien bilden, wie zum Beispiel Open Source versus kommerziell oder auch Cloud versus On-Premises. Aufgrund der mit der Big-Data-Bewegung einhergegangenen Skalierungsfrage nähern wir uns dem Thema aber mit einem wesentlichen Unterscheidungskriterium, nämlich:

1. zentrale Datenbanksysteme und
2. verteilte Datenbanksysteme

Dabei ist zu beachten, dass ein Datenbanksystem immer aus zwei Teilen besteht, nämlich den eigentlichen zu verwaltenden Daten (Datenbank) und dem darüber liegenden Datenbankmanagement System (auch DBMS). Für beide Teile eines Datenbanksystems gilt unabhängig voneinander die Frage nach der Zentralisierung oder Verteilung. Ein System ist nur dann verteilt, wenn auch wirklich beide Komponenten jeweils verteilt arbeiten und sich nach außen wie ein System verhalten.

Zentral versus dezentral. Welches der beiden Konzepte bietet Vorteile bzw. Nachteile in Bezug auf bestimmte fachliche Anwendungsfälle? Um dies zu beantworten, wollen wir die generellen Eigenschaften der beiden Konzepte im nächsten Teil dieser Serie genauer beleuchten.

Konkret wird es darum gehen, die Basis zu verstehen, auf der sich jede Datenbanklösung bewegt (Teil 2 – Fundamentals). Darauf aufbauend werden die unterschiedlichen Datenbankkonzepte erläutert und anhand von einem einfachen Datensatz gegenübergestellt. Relationale Datenbanken versus NoSQL versus NewSQL. Open Source versus Subscription versus Lizenzen. Der Teufel steckt im Detail und die Versprechen vieler kommerzieller Vermarkter sind allzu verlockend. Am Ende der Serie hoffe ich, zumindest Denkanstöße gegeben oder auch einen Grundstein für bessere Entscheidungen in dem einen oder anderen Unternehmen gelegt zu haben.