Personal, Prozesse, Plattformen

Die 3 entscheidenden Faktoren bei der Systemmodernisierung

| Autor / Redakteur: Roman Gruhn* / Ulrike Ostler

3 Ps kennzeichnen die wichtigsten Bausteine bei der Systemmodernisierung: Personal, Prozesse, Plattformen.
3 Ps kennzeichnen die wichtigsten Bausteine bei der Systemmodernisierung: Personal, Prozesse, Plattformen. (Bild: gemeinfrei - mwewering/Pixabay / CC0)

Bestehende Systemen versetzen die Firmen häufig nicht länger in der Lage, mit anpassungsfähigeren Konkurrenten mitzuhalten. Das liegt in der Regel an veralteten Infrastrukturen, die die Entwicklungsprozesse verlangsamen, die Qualität der Endprodukte beeinträchtigen und – vielleicht noch wichtiger – spätere Änderungen erschweren oder unmöglich machen.

Da die Digitalisierung inzwischen alle Branchen erreicht hat, ist der Einsatz moderner Technologien zur Bereitstellung neuer Services und benutzerfreundlicher Online-Angebote nicht mehr nur eine lukrative Option, sondern zunehmend unerlässlich. Zum Glück gibt es verschiedene Ansätze, mit denen sich ältere Umgebungen modernisieren lassen. Dieser Artikel beschäftigt sich damit, wie die richtigen Akzente in Bezug auf das Personal, die Prozesse und die Plattformen setzen lassen und dadurch der Umstieg auf neue Entwicklungsmethoden und -systeme ermöglicht werden.

Personal: Lösungen für das Produktivitätsproblem

Beginnen wir mit dem wichtigsten Faktor: den Mitarbeitern. Obwohl inzwischen allgemein bekannt ist, dass Entwickler bei Innovationsprozessen eine tragende Rolle spielen, versäumen es viele Unternehmen weiterhin, ihr Know-how und Wissen profitabel zu nutzen. Deshalb sollte es bei jeder Modernisierungsinitiative vorrangig darum gehen, die richtigen Rahmenbedingungen zu schaffen, damit Entwickler effizient und produktiv arbeiten können.

Eine kürzlich von Stripe und Harris Poll durchgeführte Umfrage verdeutlicht das Problem: Software-Entwickler gaben an, dass sie im Durchschnitt 42 Prozent ihrer Zeit mit Wartungsarbeiten und der Pflege schlecht entwickelter, veralteter Software verbringen.

Etwa die Hälfte der Umfrageteilnehmer führte die Produktivitätsdefizite der Entwickler auf veraltete Anwendungen zurück. Eine detailliertere Aufschlüsselung ergab, dass 9 Prozent der Arbeitszeit für die Korrektur fehlerhaften Codes und 33 Prozent für Wartungsaufgaben wie Debugging und Refactoring aufgewendet werden müssen.

Defizite in der Entwicklung

Und das ist erst die halbe Wahrheit, wie eine zweite aktuelle Umfrage zu diesem Thema zeigt, die MongoDB zusammen mit Stack Overflow durchgeführt hat. Dabei haben wir zahlreiche weitere Probleme aufgedeckt, die die Produktivität der Entwickler beeinträchtigen. Beispielsweise entfallen 41 Prozent des Arbeitstages eines Entwicklers auf die Pflege der Infrastruktur und stehen somit nicht für Innovationsprojekte oder die Entwicklung neuer Produkte zur Verfügung.

Veraltete Infrastrukturen und monotone Backend-Programmierung kosten Entwickler also viel Zeit, die dann für wertschöpfende Tätigkeiten fehlt. Daher ist es wichtig, bessere Rahmenbedingungen für Entwicklungsprozesse zu schaffen und ältere Anwendungen auf moderne Daten- und Softwareplattformen zu migrieren. Andernfalls vergeudet man das Talent einer der wichtigsten Ressourcen im Unternehmen und kann das Potenzial der neuen Datenquellen nicht vollends ausnutzen.

Begleitend bietet sich die Einführung verschiedener Ansätze zur Optimierung und Beschleunigung der Entwicklungsprozesse an, insbesondere der Umstieg auf agile Softwareentwicklung, DevOps und Microservices. Diese Maßnahmen verbessern auch die Qualität der Software, erleichtern die Pflege der Anwendungen und vereinfachen die Skalierung in der Cloud. Sehen wir uns nun genauer an, was hinter diesen Begriffen steckt und welche Vorteile diese Konzepte dem Unternehmen bieten.

Prozesse: der Umstieg auf Microservices

Der umfangreiche und oft monolithische Quellcode herkömmlicher Unternehmensanwendungen ist keine geeignete Basis für schnelle Innovationen und Agilität, da er sich nur schwer an neue geschäftliche Anforderungen anpassen lässt. Zudem nimmt die Komplexität des Codes im Zuge der Weiterentwicklung der Produkte unter Umständen drastisch zu, was die Pflege erschwert und den Koordinationsaufwand für sämtliche Änderungen erhöht. Dadurch werden Entwicklungsprozesse ausgebremst.

Um hier Abhilfe zu schaffen und die Entwicklung neuer Anwendungen zu beschleunigen, setzen moderne Teams auf neue Methoden. Bei DevOps und der agilen Software-Entwicklung werden bereichsübergreifende Teams aus Entwicklern, IT-Technikern, Sicherheitsexperten und den Geschäftsbereichen gebildet, die eigenständig arbeiten und über alle erforderlichen Fachkenntnisse verfügen, um neue Services zu entwickeln und zu verbessern. Diese Teams sind für die Erstellung, den Betrieb und die fortlaufende Verbesserung der Anwendungen verantwortlich.

Sie teilen die starren monolithischen Anwendungen in kleinere Komponenten auf, die Microservices genannt werden. Diese funktionieren autonom und sind in der Regel einem bestimmten Geschäftsbereich oder Unternehmensziel zugeordnet. Mithilfe von Microservices können große Unternehmen schneller neue Produkte und Services einführen und die Entwicklerteams zur Realisierung bestimmter Unternehmensziele einsetzen.

Das Beispiel Breuninger

Da jeder neue Service in der Regel auf eine spezifische Zielsetzung oder Funktion ausgerichtet sowie einem bestimmten Geschäftsprozess zugeordnet ist, trägt dieser Ansatz dazu bei, dass sich die einzelnen Teams auf die richtigen Ziele konzentrieren und alle entwickelten Services autonom sind. Das bedeutet, dass jeder Service unabhängig von den anderen entwickelt, getestet und bereitgestellt wird und kommuniziert über ein Netzwerk und standardisierte APIs mit anderen Services.

Wir haben bereits viele Start-ups und etablierte Unternehmen bei der Einführung von Microservices unterstützt. Ein Beispiel ist das deutsche Einzelhandelsunternehmen Breuninger, das eine benutzerfreundlichere E-Commerce-Plattform für seine Kunden entwickelte.

Breuningers vorheriger Onlineshop basierte auf einer branchenüblichen PCM-Plattform (Product Content Management), die laut Einschätzung des Unternehmens jedoch „monolithisch und schwer zu programmieren“ war. Häufige Code-Freezes und die zugrunde liegende starre Infrastruktur hinderten den Einzelhändler wiederholt daran, flexiblere Prozesse zu implementieren, um neue Kundenanforderungen besser erfüllen zu können.

Monate statt Jahre

Aus diesem Grund entschied sich Breuninger, seine Anwendung in einzelne Microservices aufzuteilen, die gezielt am Kundenverhalten in den Ladengeschäften ausgerichtet waren. Außerdem wurden kleinere Entwicklerteams gebildet, denen bestimmte Phasen der Customer Journey zugewiesen wurden. Infolgedessen dauerte die Entwicklung einer kanalübergreifenden Plattform nur wenige Monate statt mehrerer Jahre.

Da bei Microservices jeder autonome Service über einen eigenen Datenspeicher verfügt und nicht alle Daten in einer gemeinsamen Datenbank gespeichert werden, war es wichtig, eine flexible Plattform zu finden, die diese Architektur unterstützt. Um diesen Prozess zu illustrieren, möchte ich im Folgenden erläutern, wie die Migration von einer relationalen, tabellenbasierten Datenbank zu einer modernen Datenplattform vor sich geht und warum sich dieser Schritt lohnt.

Plattformen: die Vorteile eines dokumentorientierten Datenmodells

Einige ältere Anwendungen lassen sich nicht so einfach auf moderne Daten- und Softwareplattformen migrieren, da sie im Tagesgeschäft nahezu unentbehrlich sind. Das betrifft beispielsweise unternehmenskritische Anwendungen von Banken oder Fluggesellschaften, die auf Mainframes laufen. Bei solchen Systemen sind Modifikationen oder die Einbindung neuer Funktionen mitunter fast so schwierig wie eine Operation am offenen Herzen. Beim kleinsten Fehler fällt die Anwendung aus und der gesamte Geschäftsbetrieb wird lahmgelegt.

Es gibt jedoch praktische Lösungen für dieses Problem, mit denen auch ältere Anwendungen überarbeitet und an die neuen, effizienteren Entwicklungs- und Betriebsprozesse angepasst werden können. Zuerst müssen sämtliche vorhandenen Anwendungen im Hinblick auf ihre technische Eignung, ihren Stellenwert im Geschäftsbetrieb und ihr Innovationspotenzial eingeschätzt werden.

Anwendungen, die bei dieser Evaluation gut abschneiden, werden dann eingehender analysiert. Anschließend wird eine übergeordnete Struktur entworfen und der Aufwand für den Aufbau einer neuen Plattform geschätzt. Die Ergebnisse werden den jeweiligen Anwendungseigentümern mitgeteilt, die die endgültige Entscheidung über die Umstellung treffen.

Wer Altanwendungen überarbeiten will, muss sie zunächst ihre technische Eignung, ihren Stellenwert im Geschäftsbetrieb und ihr Innovationspotenzial einschätzen. Schließlich muss sich der Aufwand rechtfertigen.
Wer Altanwendungen überarbeiten will, muss sie zunächst ihre technische Eignung, ihren Stellenwert im Geschäftsbetrieb und ihr Innovationspotenzial einschätzen. Schließlich muss sich der Aufwand rechtfertigen. (Bild: MongoDB)

Vorhandene tabellenbasierte Datenbanken, die vor zehn oder 20 Jahren noch zu den führenden Lösungen gehörten, können die Anforderungen an modernes Daten-Management im digitalen Zeitalter nicht mehr erfüllen. Diese Datenbanken haben jahrelang gute Arbeit geleistet, weisen aber mittlerweile einen entscheidenden Makel auf: Sie sind nicht flexibel genug, wenn neue Funktionen hinzugefügt werden müssen. Denn neue Datentypen lassen sich nur schwer in ein starres Schema aus verknüpften zweidimensionalen Tabellen einfügen.

Im Vergleich dazu ist die Nutzung von Dokumentdatenbanken viel intuitiver und einfacher, da Dokumente auf einer einzelnen Datenstruktur basieren, in der miteinander verknüpfte Daten als Unterdokumente und Arrays abgebildet werden. Dokumente können daher genau auf die Struktur der Objekte in der Programmiersprache abgestimmt werden.

So lassen sich die Daten in der Anwendung bei der Entwicklung am einfachsten und schnellsten in der Datenbank abbilden. Außerdem können neue Entwickler viel schneller in Projekte eingearbeitet werden – beispielsweise, um einer vorhandenen App neue Microservices hinzuzufügen.

Herausforderungen bei der Migration

Die größte Veränderung bei der Migration von einer tabellenbasierten zu einer dokumentorientierten Datenbank wie „MongoDB“ betrifft jedoch die Art und Weise der Datenmodellierung und die Erstellung des Schemas, das diese Modelle darstellt. Obwohl die Datenmodellierung selbstverständlich von Anwendungsfall zu Anwendungsfall variiert, gibt es ein paar allgemeine Überlegungen, die auf die meisten Projekte zur Schemamigration zutreffen.

Die Umstellung erfordert es, dass Datenarchitekten, Entwickler und Datenbankadministratoren beim Schemadesign einen anderen Blickwinkel einnehmen. Statt eines herkömmlichen relationalen Datenmodells, bei dem Daten in starre zweidimensionale Tabellen mit Zeilen und Spalten gezwängt wurden, kommen jetzt ebenso intuitive wie flexible dokumentbasierte Datenmodelle mit eingebetteten Unterdokumenten und Arrays zum Einsatz, deren Strukturen die Objekte im Anwendungscode genau abbilden. Zudem unterstützen die neuen Modelle Online-Anwendungen und mobile Apps, die neue Datentypen verwenden und Daten in großer Zahl generieren.

Die nachfolgende Tabelle bietet einen nützlichen Überblick über wichtige Konzepte tabellenbasierter Datenbanken und ihre Äquivalent in dokumentorientierten Systemen.

Tabellenbasierte Datenbank Dokumentorientierte Datenbank
Tabelle Collection
Zeile Dokument
Spalte Feld
Index Index
ACID-Transaktionen ACID-Transaktionen
JOIN Eingebettetes Dokument, Dokumentverweis oder Dokumenten-Lookup zum Verknüpfen von Daten aus verschiedenen Collections

In der Vergangenheit wurden Anwendungen in der Regel meist für eine Abteilung in der Unternehmenszentrale oder eine andere eng umrissene Zielgruppe entwickelt. Doch heutzutage erwarten die Benutzer Apps, die jederzeit und auf jedem Gerät verfügbar sind, ohne Störungen skaliert werden können, an jedem Standort kurze Reaktionszeiten bieten und die Vorschriften der neuen Datenschutzverordnungen in Bezug auf die Datenhoheit erfüllen.

Mit modernen Datenbanken können Anwendungsentwickler diese Anforderungen erfüllen und dabei effizienter arbeiten sowie eine bessere Leistung erzielen als mit konventionellen relationalen Datenbanken. Zusätzlich werden Kosteneinsparungen möglich, da sich das System bei steigendem Zugriffsvolumen ohne Neuanschaffung teurer Server erweitern lässt.

Die verteilten Datenbanken können auf kostengünstiger Standard-Hardware oder in einer Cloud-Infrastruktur horizontal skaliert werden und dadurch auch Apps mit großen Datensätzen und einem hohen Durchsatz unterstützen. Diese Technik wird Sharding genannt.

Automatisierte Anpassung per Sharding

Beim Sharding werden Datenbanken automatisch partitioniert und die Daten auf mehrere physische Instanzen (die so genannten Shards) verteilt. Dadurch können die Entwickler die Datenbank nahtlos skalieren, wenn die Apps die Hardwarebeschränkungen eines Servers überschreiten, ohne dass die Struktur der Anwendung komplexer wird.

Dagegen lassen sich tabellenbasierte Datenbanken, die für einen einzigen Server entwickelt wurden, nicht so einfach in die Architektur moderner Cloud-Plattformen einbinden, die auf kostengünstiger Standard-Hardware basieren und je nach Bedarf skaliert werden können. Deshalb sollten die Entwicklerteams unbedingt verteilte Datenbanken für ihre Anwendungen nutzen. Auf diese Weise vermeiden sie die Bindung an einen Cloud-Anbieter und ermöglichen eine konsistente Nutzererfahrung in allen Umgebungen.

Der Autor des Artikels ist Roman Gruhn, Senior Director Strategic Field Programmes bei MongoDB.
Der Autor des Artikels ist Roman Gruhn, Senior Director Strategic Field Programmes bei MongoDB. (Bild: MongoDB)

Die wichtigsten Punkte

Zusammenfassend lässt sich also festhalten:

  • Über 30 Jahre alte Technologien wie tabellenbasierte Datenbanken und das Wasserfallmodell haben sich zwar in der Vergangenheit bewährt, bieten Unternehmen mittlerweile aber längst nicht mehr das nötige Maß an Flexibilität, um schnell auf neue Anforderungen reagieren zu können.
  • Wer Geschäftsprozesse flexibler gestalten und die Produktivität der Entwickler verbessern möchte, sollte neue Microservices-Architekturen einführen und die Migration auf moderne Datenplattformen vorantreiben.
  • Entwickler müssen die Möglichkeit haben, ihr Innovationspotenzial voll zu entfalten. Dazu benötigen sie moderne, intuitive Plattformen und reibungslose Prozesse.
  • Die Modernisierung einer ineffizienten, monolithischen Architektur scheint zunächst abschreckend, in der Regel muss dafür aber nicht zwangsläufig alles grundlegend verändert und vollständig umstrukturiert werden. Konzentriert sich ein Unternehmen auf die drei entscheidenden Faktoren Personal, Prozesse und Plattformen, so bleibt nicht nur die Wettbewerbsfähigkeit erhalten, das Unternehmen kann zudem schneller, besser, günstiger und sicherer agieren.

* Roman Gruhn ist Senior Director Strategic Field Programmes bei MongoDB.

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: 45694664 / Data)