Ihre Herausforderungen bei Wartung und Weiterentwicklung Ihrer Altanwendungen

Der Begriff „Legacy-Anwendung” wird oft mit einem alten, schlechten und kaum noch wartbaren System assoziiert. Auch „Altanwendung” oder gar „Altlast” sind gerne gebrauchte Bezeichnungen für solche Systeme. Dabei handelt es sich bei diesen Systemen oft um zentrale Anwendungen, mit denen wesentliche Teile des Geschäfts abgewickelt werden. Daher adelt der Begriff „Legacy” auch ein System, weil eine unwichtige Anwendung gar nie diesen Zustand erreichen wird.

Nichtsdestotrotz bereiten diese Altanwendungen gewisse Probleme. Insbesondere wenn es darum geht, aktuelle Anforderungen umzusetzen.

Allgemeine Herausforderungen

  • Neue Typen von Schnittstellen, beispielsweise zu mobilen Endgeräten oder öffentlichen APIs, sollen durch Ihre Altanwendungen bedient werden.
  • In Ihrer Altanwendung fällt es schwer, zwischen technischen und fachlichen Aspekten zu unterscheiden. Weiterentwicklung und Wartung wird dadurch behindert.
  • Unterschiedliche Fachlichkeiten sind in Ihren Altanwendungen miteinander vermischt, sodass Änderungen in einem Baustein Seiteneffekte auf andere Bausteine haben. Oft geht das damit einher, dass die Bereitstellung von neuer fachlicher Funktionalität aufgrund von Anwendungsschwächen lange dauert und sehr fehleranfällig ist – bestehende Funktionalität bricht.
  • Die Kosten für die Wartung Ihrer bestehenden Systeme explodieren, da Technologien – End of Life – oder Personal – Rente – nicht mehr verfügbar sind.
  • Ihre in die Jahre gekommenen Anwendungslandschaften entsprechen nicht mehr heutigen Sicherheitsstandards und müssen dringend ertüchtigt werden.
  • Sie haben über die Jahre so viele technische Schulden in Ihren Anwendungen angehäuft, dass der Betrieb derselben immer fragiler wird.

Herausforderungen bei der Digitalisierung

Im Zusammenhang mit der zunehmenden Digitalisierung und dem Einsatz von Drittanwendungen ergeben sich weitere Aufgaben:

  • Ihre Digitalisierung von existierenden Abläufen machen eine Erweiterung bzw. Neuentwicklung notwendig.
  • Sie müssen eine Eigenentwicklung durch eine Drittanwendung ersetzen und in die bestehende Architekturlandschaft einbetten.
  • Eine Drittanwendung entspricht nicht Ihren Anforderungen und muss mit einer Eigenentwicklung ersetzt werden.

Herausforderungen im gesamten Unternehmen

Wenn wir den Blick auf das ganze Unternehmen richten, werden weitere Herausforderungen sichtbar:

  • Sie betreiben eine veraltete Anwendungslandschaft, welche über mehrere Jahrzehnte gewachsen ist. Ihnen fehlt eine Strategie, wie die Anwendungslandschaft modernisiert werden kann.
  • Ihr „Zoo” an Anwendungen wird immer größer und deren Betrieb immer schwieriger und teurer.
  • Aus Firmenfusionen und -übernahmen haben Sie verschiedene Anwendungen, die ähnliche Funktionalität besitzen. Eine gezielte Konsolidierung ist erforderlich.

Und nicht zuletzt sollten wir die Betriebsumgebung betrachten, auf der Ihre Altanwendungen laufen. Und natürlich Ihre gesamte Strategie bezüglich einer Migration in die Cloud.

  • Es stehen teure Infrastrukturanschaffungen an, die Ihre Ressourcen auf Jahre hinaus binden. Können diese mithilfe einer Cloud-Strategie nicht deutlich kleiner oder anders ausfallen?
  • Insgesamt sind Sie mit Qualitätsanforderungen wie Verfügbarkeit und Ausfallsicherheit Ihrer Altanwendungen unzufrieden und erwägen daher die Migration bestehender Anwendungen in die Cloud.

Sie sehen, die Herausforderungen sind vielfältig. Und damit auch die Gründe für eine Architekturmodernisierung. Aber sehr häufig lohnt sich das Investment in Ihre bestehenden Anwendungen. Und das bei einem oft signifikant kleineren Risiko im Vergleich zu einer Neuentwicklung. Lassen Sie uns die Vorteile daher im nächsten Abschnitt genauer beleuchten.

Ihre Vorteile durch Architekturmodernisierung

Um die Vorteile der Architekturmodernisierung deutlich zu machen, müssen wir etwas ausholen. Architekturmodernisierung kann auf ganz unterschiedliche Arten durchgeführt werden. Grundlage einer Entscheidung, wie Ihre Anwendungen modernisiert werden können, sind die Antworten auf folgende Fragen:

  1. Wie lange soll das Leben einer Anwendung verlängert werden?
  2. Wie hoch ist der geschäftliche Nutzen der Anwendung?
  3. Mit welcher Technologie wurde die betroffene Anwendung realisiert?

Diese zentralen Fragestellungen geben, gemeinsam mit einigen weiteren Randbedingungen, die möglichen Migrationswege vor. In diesem Zusammenhang gefällt uns die Kategorisierung der Migrationswege von Gartner Research sehr gut: Die 2010 ursprünglich beschriebenen fünf Optionen, die fünf strategischen R’s für Anwendungsmigration, haben sich im Lauf der Jahre verändert. So sieht Gartner Research seit 2018 sieben Optionen um Altanwendungen zu modernisieren.

Vorteile der Modernisierung im Überblick

Auf Grundlage dieser sieben Optionen ergeben sich unterschiedliche Vorteile bei der Modernisierung Ihrer Altanwendungen:

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.

Allerdings sind wir überzeugt davon, dass Architekturmodernisierung mit modernen Methoden sich nicht auf genau eine der sieben genannten Möglichkeiten beschränken muss. Es gilt vielmehr auch hier der Grundsatz, durch iteratives Vorgehen den für die jeweilige Komponente der Anwendung besten Ansatz zum passenden Zeitpunkt zu finden.

So ist es denkbar, in einem ersten Schritt mit einem Replatforming zu beginnen, um dann durch schrittweises Refactoring und teilweises Rebuilding der Anwendungskomponenten das Zielbild zu erreichen.

Die Vorgehensweise bei der Architekturmodernisierung

Wie sieht nun eine solche Architekturmodernisierung im Detail aus? Wie bereits beschrieben, hängt die Vorgehensweise stark von der gewählten Option ab. Weiterhin haben die möglichen Optionen Überschneidungen und Gemeinsamkeiten. Nachfolgende Abbildung zeigt die Optionen als U-Bahn-Linien. Wichtige Aufgaben und Tätigkeiten werden als Stationen dargestellt. Üblicherweise fahren Sie von links nach rechts, also von der Beurteilung der Geschäftskritikalität einer Anwendung bis zum Go-Live der modernisierten Architektur.

Optionen der Architekturmodernisierung.Quelle: eigene Darstellung

Wieso nun ein Netzplan mit neun U-Bahn-Linien bei nur sieben vorgestellten Optionen? Zwei Linien verfolgen wir an dieser Stelle nicht weiter: Retain und Retire sind, abhängig von den Gegebenheiten, durchaus valide Optionen. Allerdings enden Sie nicht in einer Architekturmodernisierung, weshalb sie hier keine weitere Rolle spielen.

Interessant sind die Wege und Stationen der sieben Linien Rebuild, Replace, Refactor, Replatform, Rearchitect, Encapsulate sowie Rehost – genau diejenigen, die wir bereits bei den Vorteilen der Architekturmodernisierung beschrieben haben. Zu Beginn und am Ende durchlaufen diese gemeinsame Stationen, bis zum Ziel befahren die Linien aber zum Teil sehr unterschiedliche Strecken.

Besonders wichtig sind die Stationen am Anfang der Fahrt:

  1. Die Beurteilung der Geschäftskritikalität ist die erste Station. Für weitere Entscheidungen ist es unumgänglich zu wissen, welche Rolle eine Anwendung im Geschäftsmodell des Unternehmens spielt – genau dies wird an dieser Station untersucht. Das Ergebnis ist wichtige Grundlage aller weiteren Prioritäten und Entscheidungen.
  2. Die Station Architekturreview und Cloud Readiness Assessment ist die zweite Station. Hier betrachten wir Ihre Anwendung im Detail und machen uns ein Bild der Architektur, der eingesetzten Technologien und der verwendeten Frameworks. Auch prüfen wir, ob eine Anwendung grundsätzlich das Potenzial einer Überführung in die Cloud hat. An dieser Station wird entschieden, ob eine Architekturmodernisierung grundsätzlich sinnvoll ist – zwei Linien, Retain und Retire, enden hier.
  3. Die dritte gemeinsame Station ist die Security Analyse. Gerade bei der Überführung einer Anwendung in die Cloud ist die Betrachtung der Sicherheit essenziell. Aber auch bei einer Architekturmodernisierung, bei der die Anwendung On-Premise bleibt, hat diese Analyse zentrale Bedeutung für die nachfolgenden Tätigkeiten.

Nun teilt sich der Netzplan auf und je nach gewählter Option werden unterschiedliche Stationen angefahren. Jede davon beschreibt eine wichtige Tätigkeit, die Teil der gewählten Option ist. Dabei laufen einige der Linien zeitweise parallel, da dieselben Aufgaben und Tätigkeiten durchgeführt werden.

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.

Unabhängig davon, mit welcher der Linien sie eine Architekturmodernisierung durchgeführt haben – am Ende landen Sie wieder auf einem gemeinsam Gleis:

  • Mit der Testautomatisierung schaffen Sie einen wichtigen Schritt zur höheren Auslieferungsgeschwindigkeit und somit zu besserer Qualität und Time-to-Market.
  • Die Integration mit der Zielplattform stellt sicher, dass Ihre Daten und Services in der IT-Landschaft verfügbar sind und einheitlich genutzt werden können. Je nach Komplexität der intern und extern genutzten Services kann der Einsatz eines API Gateways und die Etablierung eines API Managements einen wertvollen Beitrag zur Performanz und Sicherheit Ihrer Anwendungslandschaft leisten.
  • Nach dem Go-Live der Anwendung ist der Optimierungsprozess noch nicht abgeschlossen. Hier wird üblicherweise noch das Monitoring weiter ausgebaut und an die Bedarfe der Stakeholder angepasst. Zudem empfiehlt es sich, den Automatisierungsgrad Ihrer Anwendung und deren Auslieferungsprozesse zu erhöhen, um Ihre Geschwindigkeit und Flexibilität kontinuierlich zu steigern.

Selbstverständlich sind die Schwerpunkte der Architekturmodernisierung so individuell wie die betrachtete Anwendung und die vorliegenden Rahmenbedingungen selbst. Daher werden in der Praxis nicht alle Stationen in gleichem Maße und gleicher Intensität durchlaufen.

Wer möchte schon eine Lösung von der Stange? Wir helfen Ihnen gern bei der Auswahl der für Sie geeigneten Strategie zur Architekturmodernisierung.

Unsere Dienstleistungen im Bereich der Architekturmodernisierung

Unsere Dienstleistungen umfassen Angebote für alle sieben beschriebenen Optionen bei der Architekturmodernisierung. Gemeinsam mit Ihnen erarbeiten wir ein Gesamtkonzept sowie einen Fahrplan, um Sie bestmöglich bei Ihrem Modernisierungsvorhaben zu unterstützen. Lassen Sie uns einige konkrete Bausteine betrachten, die sinnvoll zusammengestellt ein solches Gesamtkonzept darstellen:

  • Unter die Option Encapsulate fallen Maßnahmen wie die Ermittlung der Grenzen zwischen technischen und fachlichen Aspekten, die Identifikation fachlicher Schnitte und deren korrekte Abbildung in Bausteinen oder die Unterstützung bei der Integration von Mustersprachen wie zum Beispiel DDD (Domain-Driven Design). Ebenso fällt in diesen Bereich die Spezifikation und die Bereitstellung von Schnittstellen.
  • Beim Rehost stellen wir Entscheidungen zu teuren anstehenden Infrastrukturanschaffungen, die Ressourcen auf Jahre hinaus binden, auf den Prüfstand. Wir helfen Ihnen bei der Beantwortung der Frage, ob durch Cloudifizierung diese Anschaffungen nicht entfallen oder zumindest deutlich kleiner ausfallen können. Und natürlich umfasst unser Angebot auch die Umsetzung eines solchen Rehostings.
  • Im Rahmen der Option Replatform unterstützen wir Sie beim Erstellen einer Cloud-Strategie, beim Aufbau einer Cloud-Infrastruktur sowie bei der Migration der bestehenden Anwendungen in die Cloud.
  • Für die Option Refactor umfasst unser Angebot unter anderem die Unterstützung mit Good Practices, die Architekturanalyse sowie die Schwerpunktpriorisierung um kontraproduktives Verhalten und Anwendungsschwächen abzustellen. Ebenfalls hier angesiedelt ist unser Angebot des Refactorings von Anwendungen für die Einhaltung aktueller Sicherheitsstandards.
  • Gemeinsam mit Ihnen erarbeiten wir bei der Option Rearchitect eine einheitliche – oder zumindest einheitlichere – Architektur und Technlogienutzung für die betroffenen Anwendungen.
  • Bei unserem Angebot im Rahmen der Option Rebuild werfen wir gemeinsam mit Ihnen einen Blick auf die Fachlichkeit von Anwendungen. Ziel ist das Zusammenfassen von Funktionen, das Eliminieren doppelter Funktionen sowie das Schaffen von Schnittstellen in bestehenden Anwendungen zur Integration bestehender Funktionen in digitalisierte Prozesse. Je nachdem was wir hier vorfinden werden bestehende Komponenten in Teilen durch Neuentwicklungen ersetzt.
  • Unter der Option Replace können wir Ihnen ebenfalls eine Reihe von Dienstleistungen anbieten. Gemeinsam mit Ihnen identifizieren wir Anwendungen, deren Funktionen nicht oder kaum mehr verwendet werden. Wir unterstützen Sie bei der Identifikation und Neugestaltung der Entwicklung bestehender Komponenten in modernen Technologien. Sowohl für Eigenentwicklung aber auch bei der Einführung neuer Drittanwendungen unterstützen wir Sie bei der Erhebung und der Umsetzung von Anforderungen. Und in allen genannten Fällen begleiten wir Sie gerne bei der Dekommissionierung Ihrer nicht mehr notwendigen Altanwendungen. Soll der Blick über den Tellerrand gehen und beispielsweise alle Systeme Ihres Unternehmens beinhalten, unterstützt Sie gerne unser Enterprise Architecture Team.

Die oben genannten Optionen gehen sehr oft Hand-in-Hand und die Übergänge sind meist fließend. Bei einer Architekturmodernisierung holen wir Sie daher genau da ab, wo Sie stehen und überlegen gemeinsam, wie ein optimaler Weg in Ihrem Fall aussieht. Sehr oft starten wir mit einem Architecture Review, geben darauf aufbauend Handlungsempfehlungen und erarbeiten in der Folge gemeinsam mit Ihnen eine Architektur-Roadmap. Diese enthält üblicherweise verschiedene Bausteine der dargestellten Optionen.

Mit unserem großen Erfahrungsschatz und einer Vielzahl erfolgreich modernisierter Anwendungen finden wir die richtige Vorgehensweise auch für Ihr Vorhaben!

Aktuelle Blogbeiträge

Ihr Ansprechpartner

bildhübsche fotografie | Andreas Körner | www.a-koerner.de | info@a-koerner.de | +49 711 22 11 20

Steve Walter

Senior Consultant
Inhaltsverzeichnis
Ihr Ansprechpartner Steve Walter Senior Consultant