Architekturmodernisierung

Encapsulate – Kapselung – ist der Grundgedanke hinter der API Ökonomie und der Rettungsanker für viele, häufig monolithische Altanwendungen. Die in den Altanwendungen enthaltene Geschäftslogik wurde in der Regel mit sehr viel Aufwand implementiert. Wir erhalten den Kern der Geschäftslogik und kapseln diese hinter modernen (REST-)APIs. Dies legt die Grundlage für eine schrittweise Modernisierung – Sei es durch einen Umbau der Altanwendung oder durch Ergänzung von neuen Services, die vollkommen transparent für die Konsumenten der APIs im Hintergrund entstehen.

Welche Vorteile können Sie dadurch erreichen?

• Encapsulate ist die Option mit der es möglich ist, eine Anwendung so zu strukturieren, dass die fachlichen und technischen Aspekte klar voneinander getrennt sind. Wartung und Weiterentwicklung werden dadurch wesentlich einfacher, sicherer und auch kostengünstiger. Gleiches gilt auch für die saubere Trennung der Fachlichkeit selbst: das Herausarbeiten und Separieren klar definierter und umrissener Bausteine erleichtert eine spätere Erweiterung und verbessert die Lesbarkeit nachhaltig.
• Encapsulate ermöglicht die Öffnung eines geschlossenen Systems um die Nutzungsmöglichkeiten zu verbreitern. So können beispielsweise mobile Endgeräte an bestehende Anwendungen angedockt werden oder wichtige Funktionen von Altanwendungen können Teil digitalisierter Prozesse werden.

Bei dieser Option der Architekturmodernisierung wird die bereits implementierte Kernanwendung nicht verändert, sondern lediglich auf eine neue Hosting Umgebung bewegt. Sie fragen warum? Manchmal ist dies eine betriebsbedingte Notwendigkeit, wenn beispielsweise Rechenzentren geräumt oder umgebaut werden. Häufiger ist es eine Lebensversicherung für die Altanwendung, die auf einer modernen Cloud-Plattform kostengünstiger, flexibler, leichter skalierbar und sicherer betrieben werden kann als in der Altumgebung.

Wie kann ein Rehosting Ihnen helfen?

• Anstelle teurer Infrastrukturanschaffungen, die Ihre Ressourcen auf Jahre hinweg binden, bringen Sie Ihre Anwendungen in die Cloud.
• Es fallen nun zwar nutzenbezogene, variable Kosten an, allerdings sinken Ihre Fixkosten.
• Anschaffungen im eigenen Datacenter können deutlich reduziert werden oder sogar ganz entfallen.

Leicht mit dem Rehosting zu verwechseln, erlauben wir beim Replatforming geringe Eingriffe in den Code der Altanwendung. Diese Eingriffe verändern die bereits implementierte und getestete Geschäftslogik nicht, sondern dienen dazu, die Anwendung an eine neue Laufzeitumgebung anzupassen.

Beispiele sind etwa

• eine Migration von Oracle Weblogic zu Apache Tomcat oder
• eine Umstellung der Anwendung von einer Oracle DB auf eine deutlich elastischere, flexiblere und in der Regel auch kostengünstigere Open-Source RDBMS-Lösung wie MySQL oder PostgreSQL.

Mit solchen Maßnahmen schaffen wir die Grundlage für den Betrieb Ihrer Altanwendungen in der Cloud, so dass Sie im Rahmen einer Cloud-Strategie von allen Vorteilen profitieren können.

Die Option Refactoring ist Teil unseres Standard-Werkzeugkastens, da diese Technik auch in der Individualsoftwareentwicklung regelmäßig zum Einsatz kommt. Unter Refactoring verstehen wir die manuelle oder teilautomatisierte strukturelle Verbesserung von Softwarecode unter Beibehaltung des Verhaltens der Anwendung. Bei der Entscheidung über eine Modernisierungsstrategie Ihrer Anwendungen ist Refactoring daher eine sehr häufig gewählte Option und damit Bestandteil konkreter Handlungsempfehlungen.

Mittels Refactoring schaffen wir für Sie eine ganze Reihe von Vorteilen:

• Fachliche Anforderungen können wieder effizient in das System eingebracht werden. Ihre Time-to-market für neue Funktionen verkürzt sich deutlich. Wieso das so ist? Das Verständnis über die inneren Strukturen Ihrer Anwendung ist viel leichter herstellbar und damit Änderungen viel einfacher und sicherer zu realisieren.
• Anwendungen, die auf einer grundsätzlich tragfähigen Basis aufgebaut sind, können mittels Refactoring auf die neuesten Sicherheitsstandards gebracht werden. Sie schaffen dadurch ein sicheres und zukunftsfähiges System.
• Ihre Anwendungen werden für Ihre Entwickler:innen wieder nachvollziehbar. Die Umsetzung von professionellen Entwicklungsrichtlinien im Rahmen des Refactorings schaffen die Grundlage dafür, dass alle Beteiligten die Anwendung besser verstehen, erweitern und warten können.

Beim Rearchitect denken wir die Architektur Ihrer Anwendung neu – Dabei ist Rearchitecting in gewisser Weise die Voraussetzung für viele der übrigen hier beleuchteten Optionen.

Wir wollen bei der Architekturmodernisierung zum einen die grundsätzlichen funktionalen Eigenschaften der Anwendung bewahren, zum anderen ist ein „Alles genauso wie vorher”-Ansatz nicht immer empfehlenswert, da Sie sonst Optionen zur Prozessverbesserung und Digitalisierung Ihrer Geschäftsprozesse verpassen werden. Mittels Rearchitecting ändern wir Ihre Anwendung in der Weise, dass wir sie auf eine neue Anwendungsarchitektur übertragen können. Diese neuen Architekturpotentiale ermöglichen die Steigerung der Resilienz Ihrer Anwendung und die Senkung der Betriebs- und Wartungskosten.

Es ergeben sich folgende Vorteile für Sie beim Rearchitect:

• Bislang geschlossene Systems werden geöffnet und können damit für die Digitalisierung Ihrer Geschäftsprozesse verwendet werden. Außerdem werden die Nutzungsmöglichkeiten solchermaßen zugänglich gemachter Systeme insgesamt verbreitert.
• Wie beim Refactor ist die Umsetzung von fachlichen Anforderungen nach einem Rearchitect deutlich einfacher und Sie erreichen eine wesentlich kürzere Time-to-market neuer Funktionen.
• Rearchitect erlaubt die Vereinheitlichung der technologischen Basis Ihrer Anwendungslandschaft. Dies hat viele Vereinfachungen zur Folge, beispielsweise eine einheitliche Aus- und Weiterbildung Ihrer Mitarbeiter:innen oder ein flexiblerer Einsatz Ihres Personals über verschiedene Projekte hinweg.

Sollten die anderen Optionen zu kurz greifen oder in ihren Möglichkeiten bereits ausgeschöpft sein, bleibt in sehr vielen Fällen der Weg einer Modernisierung mittels des Neubaus – dem Rebuild – einer Anwendungskomponente. Im Unterschied zu einer kompletten Individualsoftwareentwicklung orientieren wir uns in diesem Fall aber immer noch an den funktionalen Anforderungen, die den Altkomponenten zugrunde lagen. Damit wird sich die neue Komponente nahtlos in ein bestehendes Netzwerk an Schnittstellen einfügen.

Wie profitieren Sie von einem Rebuild einer Anwendungskomponente?

• Ihre Anwendungslandschaft wird einfacher und basiert auf einer einheitlichen technologischen Basis. Dabei können beispielsweise Funktionen unterschiedlicher Anwendungen sinnvoll zusammengefasst werden und so mehrere unterschiedliche Altanwendungen in einer neuen Anwendung aufgehen.
• Der Ersatz bestehender Komponenten durch ein Rebuild ermöglicht zusätzlich die Integration moderner Schnittstellen, so dass bisher manuelle Abläufe automatisiert werden können und sich damit Durchlaufzeiten insgesamt reduzieren.

Anders als beim Rebuild werden beim Replace nicht einzelne Komponenten einer Altanwendung ersetzt, sondern die gesamte Anwendung wird erneuert. Wir gehen beim Replacement davon aus, die nach wie vor gültigen funktionalen Anforderungen der Altanwendung am sinnvollsten durch eine vollständig neue Lösung bedienen zu können. Für diese neue Lösung stellt sich die Frage nach dem „Make or Buy?“. Sollte Ihre Antwort „Make“ lauten, stehen wir Ihnen gerne mit Beratung und Individualsoftwareentwicklung zur Seite.

Diese Vorteile ergeben sich für Sie bei der Option Replace:

• Die neu erstellten Anwendungen basieren auf einer aktuellen Technologie, für die auch Personal für eine dauerhafte Weiterentwicklung und Pflege verfügbar ist. Außerdem verhindern Sie „Strafgebühren” von Herstellern für den Betrieb von Anwendung auf bereits abgekündigten Systemen und Umgebungen.
• Sie ersetzen eine schwerfällige und nicht mehr Ihren Anforderungen genügende Drittanwendung durch eine effektive und effiziente Eigenentwicklung.
• Die reibungs- und rückstandslose Dekommissionierung hinterlässt keine Altlasten, die Sie dauerhaft behindern.
• Wechseln Sie von einer eigenentwickelten Altanwendung auf eine Standardlösung ergibt sich dadurch eine Kostenersparnis sowie die Reduktion der Wartungsaufwände.

So starten die beiden Optionen Rebuild und Replace beide mit einer Anforderungsanalyse, bei der die funktionalen Anforderungen Ihrer Anwendung erhoben werden. Diese sind Grundlage der nachfolgenden Evaluierung, bei der sich die Strecke gabelt. „Make or Buy?” ist die zentrale Frage bei der Evaluation: fällt die Entscheidung auf „Make”, folgt die Architekturmodernisierung der Rebuild-Strecke. Ist die Entscheidung „Buy”, verläuft der weitere Weg entlang der Option Replace.

Für Rebuild, also eine Neuentwicklung, sind die nächsten Stationen die Definition einer Produktvision, also die Erarbeitung und Darstellung eines Zielbildes der nachfolgenden Neuentwicklung. Mit dieser Produktvision kann die Architektur Ihres Systems skizziert und auf Basis der Anforderungen Schritt für Schritt aufgebaut werden. Nun folgt die Neuentwicklung der Software, üblicherweise als Individualsoftwareentwicklung. Auf der Parallelstrecke Replace unterstützen wir Sie beim Buy-Prozess, also bei der Auswahl des richtigen Produktes für die erhobenen Anforderungen. Dazu gehört die Erstellung von Kriterienkatalogen, das Aufstellen von Long- und Shortlists, ggf. die Durchführung von Proof-of-Concepts sowie der Bewertung der Produkte.

Bei beiden Linien geht es gemeinsam weiter mit der Station Datenmigration, bei der die Daten Ihrer vorhandenen Altsysteme verifiziert, sofern notwendig vervollständigt und abschließend überführt werden. Ein Verfahren für einen ggf. notwendigen Parallelbetrieb von Alt- und Neusystem folgt in der Form, dass für Ihre Anwender geringstmögliche Zusatzaufwände entstehen. Anschließend münden beide Linien in den unten beschriebenen gemeinsamen Streckenabschnitt.

Die beiden Linien Refactor und Replatform laufen zunächst durch die gemeinsame Station Technologietausch – bestimmte Teile der Architektur Ihrer Anwendung werden durch neue Elemente und moderne Technologien ersetzt. Für die Linie Replatform ist diese Station Voraussetzung für die nachfolgende Aktualisierung der Plattform – der zentralen Idee hinter dieser Strecke.

Beim Refactoring dagegen ist der Technologietausch Ausgangspunkt für die nächste Station Statische Codeanalyse, also der Überprüfung, ob der Code und die Struktur Ihrer Anwendung zuvor festgelegten Regeln entspricht. Dabei setzen wir Werkzeuge wie SonarQube oder Sonargraph ein. Auf diese Weise legen wir eine Baseline fest und können nachfolgend dafür sorgen, dass der Code und die Anwendungsstruktur nicht weiter degenerieren.

Dies ist insbesondere für die nachfolgende Station, die Beseitigung Technischer Schulden, essenziell. Darunter verstehen wir die Kategorisierung der technischen Schulden sowie deren Priorisierung und Eliminierung. Flankiert wird dies dadurch, dass Code Reviews zur Routineaufgabe gemacht werden, der Integration von Strukturanalysen in Ihre CI/CD-Pipeline, der automatisierten Überprüfung von Architekturregeln, z. B. mittels ArchUnit oder Sonargraph, und einer hohen Testautomatisierung – der ersten Station des weiteren gemeinsamen Streckenverlaufs.

Die beiden Linien Rearchitect und Encapsulate haben ebenfalls eine Reihe gemeinsamer Station. Beim Rearchitect steht allerdings zu Beginn der Einsatz von Domain Driven Design (DDD). Domain Driven Design ist ein ganzheitlicher Architektur- und Entwicklungsansatz für Softwaresysteme in fachlich komplexen Domänen. Insbesondere in der oft technisch orientierten Welt der Softwareentwicklung stellt DDD die Fachlichkeit in den Vordergrund. Die Fachlichkeit, sprich die Domäne, ist ausschlaggebend für strukturprägende Architekturentscheidungen eines Softwaresystems und steht somit bei Entwicklern, Architekten und Fachexperten an erster Stelle.

In der Linie Encapsulate steht die Station Anti-Corruption Layer am Anfang. Ein Anti-Corruption Layer ist eine Isolationsschicht, die mittels Schnittstellen ein System vor äußeren Einflüssen schützt. Solange diese Schnittstelle unangetastet bleibt, können Entwickler:innen Änderungen implementieren oder sogar eigene oder fremde Software ersetzen, ohne die Nutzer dieser Schnittstelle zu beeinträchtigen. Die Einführung eines Anti-Corruption Layer schafft damit die Voraussetzungen für die nachfolgenden Schritte.

Gemeinsam weiter auf der Reise geht es mit dem Service-Schnitt. Im Fall von Rearchitect können beispielsweise Bound Contexts oder Aggregates potenziell passende Größen für den Schnitt von Microservices sein. Bei Encapsulate können Verfahren wie Service Taxonomy – aus der SOA-Welt kommend – Basis des Zuschnitts der Services sein. Nachfolgende Station behandelt den Einsatz von Architekturprinzipien. Dabei geht es um die Anwendung bewährter und erprobter Grundsätze (Best-Practices) auf Fragen des Architekturentwurfs. Architekturprinzipien sind allgemeine Leitlinien, die in vielen Entwurfssituationen angewendet werden können und zwei Hauptprobleme adressieren: Reduzierung der Komplexität und Erhöhung der Flexibilität.

Auf der Linie Rearchitect folgt nach der Anwendung grundlegender Architekturprinzipien die Auswahl und Anwendung eines Architekturstils, also die Festlegung der fundamentalen Struktur und Eigenschaften eines Softwaresystems. Fällt hierbei die Wahl auf beispielsweise REST, erfolgt an dieser Stelle die Festlegung der HTTP-Verben und deren CRUD-Semantik, der Resource (Primärresource/Sekundärresource) als zentrale Größe, der Bedeutung der HTTP Status Codes, usw.

Letzte gemeinsame Station von Rearchitect und Encapsulate ist der Einsatz von Entwurfsmustern. Dies bedeutet die Nutzung bewährter bzw. erprobter und damit wiederverwendbarer Lösungsansätze für bestimmte, konkrete Arten von Problemstellungen. Solche Entwurfsmuster sind eine dreiteilige Regel, die die Beziehung zwischen einem bestimmten Kontext, einem Problem und einer Lösung ausdrücken. Am Ende dieser Station haben wir bei beiden Linien eine Anwendung, die aufgrund der eingesetzten Verfahren wesentlich wartbarer als die Ausgangsanwendung ist.

Die Linie Rehost führt nach der Security Analyse zur Infrastrukturmodernisierung. An dieser Station kümmern wir uns darum, weg vom „Blech” – also dedizierten Servern – zu kommen und gehen den Weg in Richtung Virtualisierung. Hier gibt es verschiedene Spielarten, unsere bevorzugte Lösung dabei ist die Containervirtualisierung. Diese liefert die Grundlage für die nächste Station, die Containerisierung. Hierbei handelt es sich um eine Virtualisierung auf Anwendungsebene, bei der Instanzen eines Betriebssystems isoliert voneinander auf einem einzelnen Kernel ausgeführt werden.

Diese Instanzen werden Container genannt. Die Bereitstellung und Organisation von Containern zur Unterstützung von Anwendungen wird als Container-Orchestrierung bezeichnet, die über ein Container-Orchestrierungs-Tool realisiert wird. Zu den beliebtesten Open-Source-Orchestrierungs-Tools gehören Kubernetes und Docker Swarm. Letzte Station beim Rehost, bevor wir wieder in den gemeinsamen Strang einschwenken, ist der Aufbau bzw. die Erweiterung der CI/CD-Pipeline. Gerade mit der Containerisierung und den zugehörigen Orchestrierungs-Tools ergeben sich ganz neue Möglichkeiten, neue Funktionen auf Knopfdruck in Produktion zu bringen.