Die Unvermeidbarkeit von Konflikten

Us and Them: Datenbank-Admins versus Entwickler

| Autor / Redakteur: Jan Karremans* / Ulrike Ostler

Wright/Waters: „Us and them - and after all we're only ordinary men.“ Das Motto aus eibem Pink-Floyd-Song nimmt der Autor, Jan Karremans von EnterpriseDB, her, um zu erläutern, dass sich Entwickler und Databank-Administratoren nicht immer verstehen, aber verständigen können, sollen und müssen.
Wright/Waters: „Us and them - and after all we're only ordinary men.“ Das Motto aus eibem Pink-Floyd-Song nimmt der Autor, Jan Karremans von EnterpriseDB, her, um zu erläutern, dass sich Entwickler und Databank-Administratoren nicht immer verstehen, aber verständigen können, sollen und müssen. (Bild: gemeinfrei: kalhh auf Pixabay)

„Us and Them" ist, wie viele wissen, ein kraftvoller Song der Rockband Pink Floyd über Konflikte. Ebenso sind Konflikte in der Geschäftswelt ein endloses und konstantes Thema: Vertrieb versus Marketing; CFO (Geld sparen) versus COO (Geld ausgeben); und in der IT-Welt; Datenbankadministrator (DBA) (will Stabilität) versus Entwickler (braucht Veränderung).

Auf Konferenzen genieße ich immer das gutmütige Geplänkel zwischen DBAs und Entwicklern. Ein Event an dem ich kürzlich teilnahm ist dafür ein gutes Beispiel. Datenbankadministratoren (DBAs) wurden so dargestellt, als würden sie sich wie Gandalf benehmen und Entwicklern, die versuchten, „die Regeln“ für die Anwendungsbereitstellung zu brechen, weismachen: „Du kannst nicht vorbei!“. Es folgte gerechtfertigte Empörung in den sozialen Medien – von Entwicklern, die DBAs beschuldigten, langweilig zu sein, und von DBAs, die einen Katalog von Kopfschmerzen zitierten, die Entwickler ihnen bereitet hätten.


Us (us, us, us, us) and them (them, them, them, them)
And after all we're only ordinary men – Wright/Waters

Entwicklungsfunktionen haben bestimmte Ziele: Reaktionsfähigkeit auf geschäftliche Veränderungen, Entwicklungsgeschwindigkeit, Code-Qualität und mehr. Entsprechende Tests können jedoch beispielsweise nicht die Performance in einer Produktionsumgebung untersuchen. Bei DBAs wiederum macht sich mitunter Trübsal breit, weil sie alles wieder zum Laufen bringen müssen, um sicherzustellen, dass die Änderungen in jedem Maßstab und in der Produktion funktionieren.

Wechselnde Technologie-Trends

The general sat/And the lines on the map
Moved from side to side – Wright/Waters

Trends in der Entwicklung haben sich im Laufe der Jahre verändert, da die Technologie schnellere und billigere Speicher- und Rechenleistung geliefert hat. In den 60er und frühen 70er Jahren führten die Grenzen der Computertechnologie dazu, dass Geschäftsanwendungen in der Regel als monolithische Codeblöcke erstellt wurden, die voll und ganz darauf ausgelegt waren, eine vorgeschriebene Geschäftsfunktion auszuführen.

Ergänzendes zum Thema
 
Über die EnterpriseDB Corporation

Dann traten Datenbankprodukte wie „IMS“, „DB2“ und „Oracle“ auf den Plan und trennten die wichtigen Funktionen der Speicherung von und des Zugriffs auf wichtige Geschäftsdaten. Die Rolle des DBA war geboren.

In den 90er Jahren ermöglichte die immer besser werdende Technologie die Schaffung einer Middleware-Schicht, die die unangenehme Angelegenheit der Zugriffsvermittlung zwischen Anwendungen und Daten übernahm – damit wurde erstmals ein Keil zwischen Anwendungsentwickler und DBAs getrieben. Unternehmensleitungen (die „Generäle“) beteiligten sich sehr wenig daran – vorausgesetzt, die IT-Abteilung lieferte die richtige Geschäftsfunktion, ohne das Budget zu sehr zu belasten – und beobachteten lediglich, wie sich die Linien im Rahmen dieser wechselnden Technologietrends von Seite zu Seite verschoben.

Größere Freiheit, mehr Fehler

In den vergangenen fünf Jahren hat das Aufkommen der digitalen Transformation dazu geführt, dass Open-Source-Datenbanken, insbesondere NoSQL und „Hadoop“, für Entwickler immer attraktiver werden, da sie Datenbankinstanzen erstellen können, ohne die Regeln strukturierter relationaler Datenbanken einhalten zu müssen. Diese Entwicklung hat zu einer Vielzahl von strukturierten und unstrukturierten Daten innerhalb von Unternehmen geführt, die verwaltet werden müssen.

Da diese Ausbreitung oft eine Ursache für Schwachstellen und Zuverlässigkeitsprobleme ist hat sie dazu beigetragen, die Kluft zwischen Entwicklern und DBAs weiter zu vergrößern. Für Entwickler bietet Open Source mehr Auswahlmöglichkeiten, die ohne den Aufwand komplexer Einkaufsprozesse leicht heruntergeladen werden können. In Kombination mit DevOps erhalten sie so die Möglichkeit, viel schneller zu handeln, um in stetem Wandel begriffene Kunden- und Marktanforderungen zu verstehen und auf diese zu reagieren.

DBAs hingegen müssen diese Daten aus verschiedenen Quellen integrieren, um die Bereitstellung mit Blick auf Performance und Verfügbarkeit zu optimieren. Und doch kann ihr etwas maßvollerer Ansatz gelegentlich zu Frustration bei den Entwicklern führen, die definitiv das Gefühl haben, dass DBAs nicht mit der DevOps-Geschwindigkeit Schritt halten!

Ordnung ist doch ganz gut?

Glücklicherweise haben wir in den letzten zwei Jahren gesehen, wie sich die Beziehung erneut verändert hat. Entwickler erkennen allmählich, dass das relationale Datenmodell doch nicht so schlecht ist, da es Ordnung für eine bessere Abfrage der Daten und erhöhte Datengenauigkeit schafft. Wenn Anwendungen in Echtzeit reagieren müssen, um die Anforderungen der Kunden online zu erfüllen, hat die strukturierte Abfrage von Daten klare Vorteile.

Gleichzeitig beginnen DBAs, die DevOps/Agile-Denkweise zu übernehmen. Sie wissen wie wichtig es für das Unternehmen ist, schnell handeln und Anwendungen bereitstellen zu können. Sie beginnen, zu verstehen, was die Vor- und Nachteile neuer Funktionen und Funktionalitäten sind und ob und wie diese sich skalieren und in eine Produktionsumgebung integrieren lassen.

Das Bedürfnis nach Einigkeit

Me And you (you, you, you)
God only knows
It's not what we would choose (choose, choose) to do (to do, to do) – Wright/Waters

Eine IT-Funktion ist um einiges effektiver, wenn DBAs und Entwickler sich entschließen, zusammenzuarbeiten.

  • Entwickler sollten sich zunehmend Gedanken darüber machen, wie Änderungen in einer Produktionsumgebung funktionieren werden, zum Beispiel mit hunderttausenden von Benutzern oder Transaktionen und nicht nur in einer Testumgebung mit Dutzenden. Es ist an der Zeit, die Datenmodellierung weitaus genauer unter die Lupe zu nehmen.
  • DBAs müssen sich ständig mit neuen Features und Funktionen vertraut machen – und verstehen, wie diese sich in die Infrastruktur einfügen, welche sie pflegen müssen. In diesem Sinne muss die Akzeptanz einer agileren Implementierung und Verwaltung von Datenbanken im DevOps-Stil erfolgen – ein Ziel, das Cloud-Datenbankdienste mit beträchtlichem Aufwand verfolgen.
  • Und hier kommt der CIO ins Spiel, der sicherstellen muss, dass die IT-Plattform, die der Geschäftsfunktion zugrunde liegt, sowohl für Entwickler als auch für DBAs Vorteile bringt.

Postgres ist ein gutes Beispiel für eine solche Plattform. Ihre Erweiterbarkeit ermöglicht einerseits eine Integration in eine Vielzahl von Programmierumgebungen, was einen breiteren Kreis von Entwicklern anspricht. Andererseits ist die Architektur weniger komplex als die großer Datenbanken, was DBAs das Leben erleichtert.

Den Konflikt lösen

Out of the way, It's a busy day
I've got things on my mind – Wright/Waters

Entwickler und DBAs sind gleichermaßen beschäftigte Menschen. Durch eine engere Zusammenarbeit können sie IT-Veränderungen effektiver umsetzen und sich so gegenseitig das Leben leichter machen.

Doch dabei müssen beide Seiten sich einiger wichtiger Aspekte bewusst sein. Beispielsweise müssen Anwendungsentwickler aussagekräftige Datenbestände testen, bevor sie in Produktionsumgebungen übergehen, und sie sollten prüfen, welche Anwendungsfunktion besser in die Datenbank passt, um die Leistung und Zuverlässigkeit des Gesamtsystems zu gewährleisten. Vor allem sollten sie mit dem DBA über die Datenbankstruktur und den Aufbau einer sinnvollen SQL-Strategie sprechen, anstatt einfach nur das nächstgelegene praktische Entwicklungs-Framework zu verwenden.

Es liegt jedoch nicht allein in der Verantwortung von Anwendungsentwicklern, dafür Sorge zu tragen, dass die Beziehung funktioniert. Datenbankadministratoren müssen sich vor Augen führen, dass es die Anwendungsfunktion ist, die das Unternehmen am Laufen hält und bereit sein zu verstehen, wie neue Funktionen in das Unternehmen passen. Sie sollten außerdem offen für die Zusammenarbeit mit Entwicklern sein.

Anstatt sich auf Zeitmangel zu berufen sollten sie sich auf die Aufregung für das Neue, wie DevOps, einlassen und herausfinden, wie die Infrastruktur diese Innovationen unterstützen kann. DBAs können Schritte unternehmen, um Entwicklern bei der Feinabstimmung von Abfragen zu helfen, die in die Produktionsumgebung passen.

Letztendlich ist der Schlüssel die Zusammenarbeit. DBAs und Entwickler müssen sich für eine engere Zusammenarbeit entscheiden. Bei Nutzung von Technologieplattformen, die diese Zusammenarbeit erleichtern, können viele Geschäftsfunktionen sehr viel schneller und effektiver live gehen.

* Jan Karremans ist bei EnterpriseDB Senior Sales Engineer für die DACH-Region und Missionar in Sachen EDB Postgres. In dieser Rolle hilft er Kunden und Partnern bei der Implementierung der Open-Source-basierten Plattform.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46043185 / Data)