Schrittweise, API-basierte Modernisierung von Bestandssystemen

Bimodale Praxis: Agil oder bimodal? Uns egal!
Keine Kommentare

Wir stellen uns der Behauptung unseres letzten Artikels, dass man sich nicht dualistisch für Gartner oder Forrester (bimodal vs. „alles agil“) entscheiden muss. Welche Möglichkeiten gibt es, aus IT-Sicht schnellen Nutzen und Wertschöpfung zu stiften, auch wenn die Systeme schon in die Jahre gekommen sind?

Im ersten Teil unserer Artikelreihe haben wir uns mit den Herausforderungen der beschleunigten Veränderung von Wirtschaft, Technologie, Mitarbeiter-Skills und dazugehörigen Organisationsformen beschäftigt: Wie schaffen Unternehmen den Spagat zwischen kürzeren Produktzyklen, besser informierten Kunden, schnellerem Mitbewerb, Millennial-Mitarbeitern auf der einen und Legacy-Prozessen/Organisationsformen/Systemen auf der anderen Seite? Ein möglicher Ansatz ist das bewusste Koordinieren von unterschiedlichen Geschwindigkeiten, von beständigen Prozessen und sich laufend ändernden Prozessen im Sinne einer bimodalen IT. Wie wir gesehen haben, gibt es zwei Lager: Die einen vertrauen der bimodalen IT und die anderen wollen ganz in Richtung agil gehen. In diesem Artikel geht es darum, wie man Prozesse und IT-Systeme schrittweise agilisiert, ohne sich gleich für eins der Lager entscheiden zu müssen.

Artikelserie

Eine Anekdote: die Geschichte vom ERP als Klotz am Bein

Beim größten CIO-Kongress Österreichs berichtete der CIO eines großen Handelsunternehmens über Herausforderungen und Strategien in einem Business, das durch Plattformen wie Amazon und deren digitale Geschäftsmodelle bedrängt wird. Ein Teil seiner Strategie ist, dass er in Zukunft innovative Themen agil und in Zusammenarbeit mit wohlbekannten Onlineplayern umsetzen wolle. Gleichzeitig brachte er das Bild eines Häftlings, der eine schwere Sträflingskugel am Bein trug. Die pointierte Aussage dazu lautete: „Das klassische ERP-System ist ein Klotz am Bein“. Sie kennen sicher viele ähnliche Anekdoten aus diesem Umfeld: ERP-Systeme sind unerlässlich für eine geordnete Unternehmenssteuerung, aber sie haben ihren Preis. Unternehmen investieren viel in Customizing, um ihre wettbewerbsrelevanten Prozesse anzupassen und schneller am Markt zu sein. Damit verstärkt sich das Vendor Lock In: Upgrades auf neue Systemversionen werden zu Mehrjahresprojekten, die die Key-Ressourcen im Unternehmen binden. Und das alles nur, damit alles so läuft wie gewohnt. Diese Ressourcen fehlen für Innovationsprojekte, die das Unternehmen wirklich weiterbringen. Im weiteren Verlauf des Artikels wird das Thema ERP-Systeme näher thematisiert.

Ein Kapitel für sich: Legacy-Systeme

Legacy-Systeme sind über Jahrzehnte gewachsen und bei vielen KMUs nach wie vor das Rückgrat der Kernprozesse. In ihnen liegt das gesammelte Unternehmenswissen und damit auch der Wettbewerbsvorteil: „Was genau machen wir anders, besser oder schneller als andere Unternehmen?“ Oftmals können Unternehmen diese Frage nicht exakt beantworten, weil das Wissen nicht explizit vorhanden, sondern im Legacy-System versteckt ist.

Diese Bestandssysteme sind bei den Mitarbeitern gut etabliert. Sie können damit umgehen und es wird wenig Schulungs- und Supportaufwand benötigt. Die Systeme laufen in der Regel sehr stabil, sind gut integriert und ihre Fehler wurden weitgehend behoben oder zumindest umschifft. Gleichzeitig können sich in Bestandssystemen aber auch Verbindlichkeiten verstecken, die sich in keiner Bilanz finden lassen. Wir haben sie im letzten Artikel als technische Schulden bezeichnet und meinen bei Legacy-Systemen Folgendes:

  • Zu geringe Flexibilität und Agilität: Neue Geschäfts- oder Marketinganforderungen können nicht schnell genug unterstützt werden, da ihre Umsetzung unvorhersehbare Nebeneffekte im System verursacht.
  • Ausfallgefahr durch endende Systemwartung und fehlende Experten: Für die Systeme selbst oder benötigte Basiskomponenten (Betriebssystem, Datenbank usw.) gibt es keine Updates mehr. Es wird daher immer schwieriger, die Systeme am Leben zu halten. Die Experten, die genau wissen, was sie im Problemfall tun müssen, sind meist nicht innerhalb kurzer Zeit greifbar.
  • Fehlendes Wissen und Dokumentation: Das Unternehmenswissen liegt nicht explizit vor, sondern großtenteils in der Software des Bestandssystems. Eine ausreichende Dokumentation aus fachlicher Sicht fehlt und die Experten, die das Wissen noch im Kopf haben, werden immer weniger.
  • Schlechtes Employer-Branding: Junge Benutzer sind ansprechende Lösungen gewöhnt: Zeitgemäße Benutzeroberflächen, schnelle und einfache Bedienung, einfache Integration, mobiles Arbeiten von überall. Mit veralteten Bestandssystemen ist dieses Thema kaum zu lösen.
  • Bestehende Integrationshindernisse: Es handelt sich meist um in sich geschlossene Systeme, die über zu wenige moderne Schnittstellen verfügen und die Integration in andere Lösungen erschweren.

Ein Fallbeispiel aus der Automobilbranche

Ein Generalimporteur entschloss sich aufgrund einer Prozessanalyse, den speziellen Schritt „Lieferauskunft“ des Verkaufsprozesses zu optimieren. Dem Kunden soll dabei das möglichst frühzeitige und korrekte Lieferdatum genannt werden. Das scheint einfach und nicht wirklich relevant für einen Verkaufsabschluss, aber dennoch hat die Prozessanalyse etwas anderes ergeben: Die Lieferauskunft dauert bis zu zehn Minuten und der Verkäufer, der den Kunden im Schauraum betreuen sollte, muss in einen anderen Raum mit einem entsprechenden PC-Zugang zum Legacy-System gehen. Dort loggt er sich über VPN ein und sucht das Lieferdatum. Es kommt schon vor, dass ungeduldige Kunden den Schauraum aufgrund dieser Unterbrechung wieder verlassen, was aus der Verkaufsprozesssicht fatal ist: Kurz vor dem Abschluss springt der Kunde ab. Warum wurde dieser Prozess nicht einfach im IT-System des Generalimporteurs verbessert, damit die Verkäufer direkt am Kunden bleiben können? Weil das Bestandssystem das nicht erlaubte: Es war nicht möglich, die entsprechenden Funktionen benutzerfreundlich in den Verkaufsraum zu bekommen, beispielsweise auf Tablets oder Smartphones. Das Bestandssystem wurde so zu einem Hemmschuh für den Verkaufserfolg.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Ein einfacher Plan: Ablöse durch ein neueres Standardsystem

Der Generalimporteur stand vor der Qual der Wahl: Das Altsystem zu aktualisieren und aufzubohren oder gleich ein neueres Standardsystem (ERP) einzuführen. Vor allem aus der manchmal nicht so IT-affinen Management- beziehungsweise Eigentümersicht findet sich oft die Grundhaltung, die im letzten Artikel als Gefahr der bimodalen IT erwähnt wurde: „Die IT führt ein ERP-System ein und damit löst man das Problem“. Leider steckt aber viel mehr als eine Systemeinführung dahinter: Es geht beispielsweise um aufwändiges Reengineering des Unternehmenswissens aus den Bestandssystemen. Darüber hinaus sind die Auswirkungen der Systemeinführung auf die Organisation sehr groß, sodass diese Projekte auch Jahre dauern können. In dieser Zeit beschäftigen sich Key-Mitarbeiter des Unternehmens zudem mit der Migration von IT-Systemen statt mit Innovationen (Innovationsbremse). Das Ablösen eines alten Systems ist oft mit einem Big Bang verbunden. Zur Risikominderung sind intensive Tests und ein Plan B notwendig, um beispielsweise auf das Altsystem zurücksteigen zu können. Denn dass ein neues System die Probleme besser löst, muss es erst beweisen. Was man auch immer bedenken muss: Die meisten Unternehmen bewegen sich im Korsett ihres Systems. Auch wenn in diesem System verschiedenste Prozesse abbildbar sind, sind die grundlegenden Arbeitsabläufe und die User-Experience festgelegt, und zwar für alle Benutzergruppen. Dieses One-size-fits-all-Prinzip passt heutzutage jedoch nicht mehr. Hinzu kommt, dass die Customizingkosten fast immer unterschätzt werden. Es geht darum, agil, flexibel und kundenorientiert aufzutreten und nicht systemgetrieben. Wenn alles am Standard bleibt, gibt es wenige Unterscheidungsmerkmale zum Mitbewerb. Daher wird immer noch sehr viel individuell im Korsett des Standardsystems entwickelt.

Ein pragmatischer Plan: Service-/API-basiert, schrittweise und bedarfsorientiert

Wie im ersten Artikel angedeutet, müssen Unternehmen mit der Realität leben, dass sie längerfristige und reliable Bestandssysteme einsetzen. Sie können weder darauf warten, dass alle Prozesse und Systeme agilisiert sind, noch darauf, dass ein modernes Standardsystem eingeführt wird. Sie müssen mit den aktuellen Anforderungen starten. Unserer Erfahrung nach hilft in vielen Situationen das in Abbildung 1 gezeigte Vorgehensmodell. Es ermöglicht uns, dass wir uns nicht gleich zwischen bimodal und agil entscheiden müssen, sondern dass wir entlang des Weges lernen, was Sinn macht.

Abb. 1: Vorgehensmodell: schrittweise und in der selbst gewählten Geschwindigkeit

Renovierung: Die einfachste Ausbaustufe ist die Renovierung. Dabei geht es um optische Modernisierung, Usability und moderneres Design. Erreicht wird das beispielsweise durch eine HTML-5-Applikation, die im Responsive-Design läuft. Das Bestandssystem bleibt unverändert und stellt lediglich vorhandene Schnittstellen – zum Beispiel Dateien, Programme, Tabellen, SQL – zur Verfügung. Renovierte Programmteile können relativ einfach für Kunden, Partner und Lieferanten freigeschaltet werden und erzeugen hohen Nutzen: Die renovierten Applikationen kommen bei den Endbenutzern sofort an, obwohl das Altsystem nicht verändert wurde.

Service-orientiert integrieren und öffnen: Die Öffnung der Systeme ist ein wichtiger Schritt in Richtung Digitalisierung. Doch wie schafft man das auf moderne Art und Weise? Dazu werden zunächst geschäftskritische, zentrale Funktionen über eine schlanke Service-Schicht allgemein verfügbar gemacht (Abb.2).

Abb. 2: Service-Schicht über dem Bestandssytem aufbauen

Die Applikationen greifen nicht mehr direkt auf das Altsystem zu, sondern über die Service-Schicht. Funktionalitäten, die teilweise in verschiedenen Systemen redundant vorhanden waren, werden zu einem Single Point of Knowledge kanalisiert und müssen nur mehr an einer Stelle gewartet werden. Dabei werden die Funktionen des Bestandssystems durch die Service-Schicht um zusätzliche Informationen und Funktionen angereichert, kombiniert und orchestriert. Die Service-Schicht erleichtert infolge auch das Monitoring geschäftskritischer Prozesse.

Schrittweise zu den Services kommen: Das Projektteam identifiziert zuerst den Prozess, der den höchsten Geschäftsnutzen aufweist (Abb. 3). Für diesen erstellen wir Design-Mock-ups und Prototypen, die von den Fachabteilungen und Key-Usern unmittelbar begutachtet und freigegeben werden. Es folgen die Implementierung der Services sowie der zugehörigen Applikationen und schlussendlich wird der Prozess internen und externen Benutzern zur Verfügung gestellt. Mit jeder Umsetzung eines weiteren Prozesses entstehen zusätzliche, wiederverwendbare Services. Das ist einer der wesentlichen Unterschiede zu anderen Ansätzen: Es handelt sich um echte Schnellboote, die den Geschäfts- und Kundennutzen ganz in den Fokus rücken. Es geht im ersten Schritt nicht darum, die schönste Service-Architektur der Welt aufzubauen, sondern darum, dass wir schneller am Markt und die (End-)Kunden zufriedener sind. Wir nehmen an dieser Stelle in Kauf, dass wir später unter Umständen refaktorisieren müssen, aber das ist bei agilen SW-Projekten ohnehin üblich.

Abb. 3: Schrittweiser Durchstich pro Prozess oder Use Case

Schritt-/modulweise Ablöse: Falls gewünscht, werden die Services in dieser Stufe des Vorgehensmodells dazu verwendet, die Funktionen des Altsystems schrittweise zu ersetzen. Die Services rufen dann nicht mehr die Funktionen des Altsystems auf, sondern modernere Implementierungen. Es ist auch eine Mischung von Technologien möglich, beispielsweise im Fall einer Umsetzung durch verschiedene Entwicklerteams. Erfahrungen zum Thema Microservices lassen sich hier nutzenbringend einsetzen.

Laufende Modernisierung, API- und Application-Portfolio-Management: Den krönenden Abschluss der Modernisierung bildet schließlich das API-Management bzw. das Application-Portfolio-Management. Mit jedem Prozess, jedem Durchstich und jeder Schleife, mit der wir die Services erweitern, entscheiden wir, ob wir sie sauber refaktorisieren und dem API-Management zuführen oder vielleicht doch in das Bestandssystem übernehmen.

Ab diesem Zeitpunkt werden die Services im Rahmen des IT-Strategieprozesses regelmäßig bewertet und bei Bedarf wieder modernisiert oder abgelöst. In Summe ergibt sich dadurch ein laufender Prozess, in dem sich technische Softwareschulden nicht wieder jahrelang auftürmen.

Die Service-Orientierung ermöglicht uns aus der organisatorischen und auch aus der IT-Sicht viele Vorteile:

  • Nutzung moderner Softwarearchitekturen und Betriebsmodelle: Microservices, Serverless usw. Die verschiedenen Services können bei Bedarf leicht skaliert werden.
  • Beschleunigung von Application Lifecycle und DevOps, „in Minuten statt Tagen“: Continuous Integration, Continuous Deployment
  • Bessere Dokumentation des Unternehmenswissens: Services, die klare Verantwortlichkeiten übernehmen und für sich dokumentiert sind, geben einen guten Überblick über die Unternehmensprozesse.
  • Bessere Skalierbarkeit der Entwicklung: Die Entwicklung der Services kann einfacher auf verschiedene Mitarbeiter oder Teams aufgeteilt werden, da die Seiteneffekte stark reduziert werden.

API-Management – alter Wein in neuen Schläuchen?

Uns wird diese Frage oft gestellt: Ist API-Management nicht alter Wein in neuen Schläuchen? Aus der Historie kennen wir eine Vielzahl von Methoden, um wartbare und Service-orientierte Komponenten zu entwickeln: RPC, CORBA, EJB, SOAP und UDDI Registries, SOA, Enterprise Service Bus, REST, Microservices, API-Management. Letztendlich ist uns die Namensgebung aus pragmatischer Sicht egal. Es geht uns nicht darum, in Unternehmen die nächste Buzzword-/Tool-/Vendor-Welle einzuläuten, sondern darum, agil wertschöpfende Services von der Anforderungserhebung bis zu DevOps umzusetzen, ohne dabei schlampig und unreliabel zu werden. In Abbildung 4 sieht man den API-Management-Kreislauf im Kontext eines Vorgehensmodells.

Abb. 4: API-Management im Kontext unseres Vorgehensmodells

Fazit: Agil oder bimodal? Uns egal!

Mit dem schrittweisen und Service-orientierten Vorgehen bleiben einem stets beide Wege offen. Wenn sich herausstellt, dass Schnellboote nicht den erhofften Erfolg bringen, können diese ohne großen Aufwand versenkt werden. Wenn sie erfolgreich sind, hat man die freie Wahl, ob man sie in das API-Management integriert und als eigenständige Lösung betreibt oder ob man sie in das Bestandssystem überführen möchte.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -