Fallstudien zur IT-Modernisierung in der Praxis (Teil 1)

Von Rolf Scheuch

Mit einer Fallstudie zum Re-engineering für Produktivsysteme in der Automotive-Branche starten wir eine Reihe an Fallstudien aus der Praxis der IT-Modernisierung. Damit möchten wir Ihnen spannende Impulse für Ihren ganz eigenen Weg mitgeben. Weitere Fallstudien werden wir in den nächsten Wochen in diesem Blog veröffentlichen. Bleiben Sie also gerne dran und folgen Sie uns!

Viel Spaß beim Lesen!

Warum Unternehmen IT-Systeme und Anwendungen gerade jetzt modernisieren müssen

Der zunehmende Wettbewerbsdruck erfordert Anpassungen von Geschäftsmodellen und unterstützenden Geschäftsprozesse in immer kürzer werdenden Zyklen. Gleichzeitig wird durch die Globalisierung und die digitale Vernetzung der Unternehmen die Interaktion mit externen Geschäftspartnern und Kunden immer entscheidender für den Unternehmenserfolg.

Mit Ausnahme einiger Start-ups ist die bestehende Systemarchitektur wie auch die IT-Organisation der meisten Unternehmen in Altlasten gefangen. Zu lange hat man dem Denkmuster Big is beautiful gefrönt und hat komplexe, integrierte Gesamtsysteme erschaffen. Im Ergebnis sanken zwar die IT-Kosten, die Prozesssicherheit war gewährleistet, aber die Nutzung der neuen technologischen Möglichkeiten zur Implementierung digitaler Geschäftsmodelle war nicht in der geforderten Geschwindigkeit möglich. Jeder Release-Wechsel wird zu einem Abenteuer und erfordert einen Kraftakt der gesamten Organisation. Dies darf nicht so bleiben! Wir brauchen ein Vorgehen und eine Methodik, wie eine Transformation hin zu dynamisch robusten Architekturen bzw. evolutionären Architekturen gelingen kann.

Als Folge der umfassenden Vernetzung im Zuge der Digitalisierung wird der verlässliche Informationsaustauch mit qualitativ hochwertigen und geschützten Daten auf einer umfassenden Plattform entscheidend. Diese Herausforderungen setzen die bislang gewachsenen Systemlandschaften unter Druck und erfordern eine grundlegende Veränderung und Transformation der unterliegenden Architekturkonzepte, wie in -> Abb. 1 aufgeführt [1].

Wir benötigen zukünftig evolutionäre Anwendungsarchitekturen [2], die durch das Architekturprinzip Design for Change eine stetige und gezielte Veränderung der Architektur ermöglichen.

Zielbild ist eine evolutionäre Architektur

Abb. 1 -> Zielbild ist eine evolutionäre Architektur

Analog zu einer Plattformstrategie beim Auto besteht die Systemlandschaft aus Modulen, die in sich Innovation, Austausch und Veränderung erfahren, ohne das Gesamtsystem zu kompromittieren. Hierzu benötigen wir, ähnlich dem BUS-System im Auto, eine transparente, beherrschbare Kopplung der Systemkomponenten untereinander. In der Folge wird unsere Systemwelt zu einer Plattform für eigene, aber fremde [3] Systemkomponenten, die definiert und mit der minimal notwendigen Kopplung miteinander kommunizieren. Denn wir wollen eine Applikationslandschaft mit Systemen, die möglichst unabhängige Release-Zyklen besitzen und damit eine unabhängige Innovation und Dynamik möglich machen. So können wir unsere Softwareprodukte als software assets nutzen und neue Produkte auf bereits bestehenden, robusten Produkten und Services aufbauen.

Status quo: Strukturell zukunftsunfähig?

Die Wirklichkeit sieht leider noch etwas anders aus! Eine Vielzahl deutscher Unternehmen ist in der Wartung und Stabilisierung monolithischer Systemwelten gefangen. Es bleibt keine Kraft, um die neuen Herausforderungen anzugehen. Lünendonk spricht in seiner Studie „Software-Modernisierung“ von einer strukturellen Zukunftsunfähigkeit bei vielen Alt-Systemen; genauer schreibt Lünendonk: „Trotz ihres aktuellen Nutzens für die Unternehmen ist Alt-Software strukturell zukunftsunfähig. Das liegt an ihren Charakteristika und den daraus erwachsenden Risiken für das eigentliche Geschäft“[1]. Eine bei deutschen CIOs durchgeführte Studie im Jahr 2014 unterstreicht diese Aussage mit ihren Umfrageergebnissen.

Diese strukturelle Zukunftsunfähigkeit hinsichtlich der Weiterentwicklung und Evolution der Applikationslandschaft wird somit zu einem Risiko bei der Optimierung der Business Capabilities oder der Verfolgung neuer digitaler Geschäftsmodelle. Diese Systemlandschaften basieren oft auf umfänglichen, aufwendig zu integrierenden Applikations-Suiten, auch Monolithen genannt, und erweisen sich als veränderungsresistent. Daher muss ein Umdenken hinsichtlich der zukünftigen Systemlandschaften und Applikationsarchitekturen stattfinden: Nicht mehr Big is beautiful, sondern mit dem Denkmuster eines Design for Change[2] mit dem Zielbild einer evolutionären Architektur müssen wir uns zukünftig in der VUCA-Welt[3] behaupten.

Das Ziel ist, mit Applikationsarchitekturen adaptiv und agil auf neue Anforderungen zu reagieren und in der Folge veränderungsfähig zu sein. Warum? Um die Dynamik im Markt zum eigenen Vorteil gestalten und fachlich getriebene Anforderungen umsetzen zu können, die wir heute noch gar nicht kennen. Diese evolutionären Architekturen dienen dann als Blueprint für die Modernisierung von monolithischen Anwendungslandschaften.

Wir empfehlen als Zielbild eine dynamikrobuste, evolutionäre Systemwelt mit einer produktzentrierten Applikationsstrategie!

Die nun folgende Fallstudie zeigt, wie eine erfolgreiche Modernisierung in der Praxis aussehen kann. Sie bezieht sich auf ein Re-engineering der bestehenden Manufacturing-Execution-Systeme (MES) für den Shop-Floor bei der Produktion und Montage im Automotive-Umfeld.

Die zukünftige Lösung soll für die nächsten Jahre eine stabile Basis bilden, aber kontinuierlich Innovationen aus dem Industrie-4.0-Umfeld ermöglichen. Feature Freeze ist keine Option! Letztlich war die Erwartungshaltung, dass auf einer robusten Basis stets spezifische neue Technologien zum Einsatz kommen, dringliche Ü„nderungen vorgenommen werden und kurzfristige Erweiterungen erfolgen können. Zudem musste sich die unterliegende Architektur evolutionär weiterentwickeln können, ohne jeweils kostenintensive und risikoreiche Migrationsprojekte durchführen zu müssen. Evolutionär muss es sein!

Das Vorhaben zum Reengineering und zur Harmonisierung auf dem Shop-Floor wird von der Produktionsleitung einer Sparte getrieben und von den weltweiten Werken unterstützt. Die aktuellen MES-Lösungen sind in Teilen individuelle Applikationen, die umfangreich auf die Spezifika der unterschiedlichen Werke eingehen. Diese Chance soll genutzt werden, um notwendige architektonische Vorbereitungen für Industrie-4.0-Prozesse im Zeitablauf durchzuführen. Darüber hinaus sollen neue Ansätze zu einer Reduktion der Prozesskosten, einem verbesserten Eskalationsmanagement sowie der Nutzung der werksübergreifenden Schwarmintelligenz auf Shop-Floor-Ebene führen und ein generelles mobiles Arbeiten ermöglichen. Durch Big-Data-Ansätze soll eine verbesserte werksübergreifende Mustererkennung von Schwachstellen und ein längerer gesicherter Blick in die Zukunft möglich werden, damit die JIT-Produktion stabiler wird. Die grundlegenden Eckdaten des Mandates haben wir in einem Steckbrief in -> Tabelle 1 zusammengefasst.

Tabelle 1 -> Steckbrief: System of Systems als Treiber von Industrie 4.0

Ausgangspunkt und Zielarchitektur

Ausgangspunkt war eine heterogene Systemwelt, die im Zeitablauf gewachsen war und über unterschiedlichste Integrationsmechanismen Daten austauschte. Glücklicherweise war die ursprüngliche Strukturierung der Systeme nach den unterstützten Prozessen sehr hilfreich, jedoch wurde die domänenspezifische Ausrichtung im Zeitablauf verwässert und es fehlten klare Integrationsprinzipien einer losen Kopplung, sodass sich die Systemwelt als monolithisch ineinander verwoben darstellte, wie auch aus -> Abb. 2 ersichtlich wird. Jede größere Anpassung führte zu einem Release-Abenteuer mit einem hohen Zeitaufwand an Qualitätssicherungsmaßnahmen.

Grundlage und Herzstück des MES waren Oracle-Forms-Client/Server-Anwendungen mit eigenen Datenbank-Schemata, aber einer Vielzahl an Database-Links, die zu einer engen Kopplung führten. Die Geschäftslogik war überwiegend in PL/SQL Stored Procedures abgebildet. Die Portfoliosteuerung erfolgte über isolierte Projekte und wurde durch die Systemverantwortlichen der Module aus der IT gesteuert.

Das gemeinsam abgestimmte Zielbild sieht das MES als ein ganzheitliches digitales Produkt mit domänenspezifischen, in sich unabhängigen Lösungen, die über eine lose Kopplung miteinander kommunizieren können. Ü„nderungen der internen Datenmodelle sollten ohne externe Abhängigkeiten möglich sein und somit die Robustheit erhöhen und die Cycle-Times senken. Die Gesamtsicht des Zielbilds liegt als Grafik in -> Abb. 2 vor. Weiterhin war eine harte Rahmenbedingung, dass der Produktiveinsatz auf dem Shop-Floor ohne Downtime bei der Produktion selbst erfolgen musste. Hieraus ergibt sich sofort, dass mehrere (abwärtskompatible) Versionen gleichzeitig nutzbar sein müssen und eine Begrenzung der Systemkomplexität durch klare Systemgrenzen erfolgen sollte.

Abb. 2 -> Modernisierung der Systemwelt in Richtung evolutionärer Architekturen durch Separation of Concerns mit einem Anti Corruption Layer, kurz ACL (Ausgangslage und Zielbild bei MES)

Als fachliches Zielbild wurde die „alte“ Idee einer Systemfamilie aufgegriffen und ein System-of-System-Ansatz verfolgt, wobei jedes System eine unabhängige Release-Einheit bilden sollte. Den hohen Aufwänden der Qualitätssicherung beim Release-Wechsel sollte durch ein großes Maß an Testautomatisierung begegnet werden. -> Abb. 2 fasst Ausgangslage und Zielbild zusammen.

Vorgehensweise

Um das Zielbild zu verfolgen, mussten wir an mehreren Fronten „angreifen“. Nachdem das Zielbild abgestimmt war, haben wir uns über organisatorische Hemmnisse unterhalten. Beginnend beim Fachbereich, konnten wir Wunsch wie auch Bereitschaft erzeugen, aus der fachlichen Sicht wieder das Produktmanagement für das MES zu übernehmen und bei agilen Vorgehensweisen den Product Owner zu stellen. Da wir einen Application-Management-Services-Vertrag für das MES hatten, stellten wir selbst das agile Team mit dem technischen Architekten. Damit sind wir in der Rolle des technischen Produktmanagements und somit, aus der architektonischen Sicht, der Hüter der Vision. Der Mandant führte in der Folge die Projekte inhaltlich über den Product Owner und stellte seitens der IT die notwendigen Betriebsressourcen sicher, damit wir DevOps-Themen frühzeitig und in Abstimmung mit OPs angehen konnten. Hier waren Coaching-Maßnahmen als Facilitation nötig, um die agilen Denkweisen im Mindset zu verankern und dem Product Owner wie auch der Betriebsmannschaft die Chance zu geben, entsprechend ihrer Rolle zu agieren. Das gesamte MES wurde als Produkt betrachtet und unterliegt einem Produktportfolio-Management. Entscheidend für die Verfolgung der Vision war, dass ein Teil des Budgets für Refactoring und Restrukturierung vorbehalten war, damit die evolutionäre und gesteuerte Verfolgung des Zielbilds möglich wurde.

Nach nunmehr 10 Jahren Wartung und inkrementeller Restrukturierung erfolgt nun alle drei Wochen ein neues Release einiger Sub-Systeme auf dem Shop-Floor. Dank der Testautomatisierung hatten wir seit Jahren keine produktionsrelevante Störung mehr auf dem Shop Floor „“ dynamisch, aber robust!

Seitens der Applikationsarchitektur wurde der Blueprint eines digitalen, integrierten Arbeitsplatzes verfolgt. -> Abb. 3 zeigt auf, wie sich das System of Systems (SoS) aus einzelnen Self-contained Systems (ScS) zusammensetzt, wobei die Integration über eine Event-Driven Architecture erfolgt. Hierbei kommunizieren die Backend-Prozesse miteinander, und nur im Eskalationsfall werden Incidents „geworfen“ und ein manuelles Einschreiten wird zur Optimierung bzw. Fehlerbehebung notwendig.

Das höchste architektonische (und somit auch implizite kaufmännische) Ziel liegt in der Unabhängigkeit (Autonomie) der einzelnen Self-contained-Systeme, den Sub-Systemen. Martin Fowler führt aus: „Gather together those things that change for the same reason, and separate those things that change for different reasons.“ Die notwendige Kommunikation mit anderen Sub-Systemen und zentralen prozess- und auftragsübergreifenden Services erfolgt über den Anti Corruption Layer (ACL), dessen Versionierung der Interfaces auch die notwendige lose Kopplung und Robustheit ermöglicht. 

Abb. 3 -> Evolutionärer Ansatz durch Seperation of Concerns mit einem ACL als Vorgehensweise beim Re-engineering

Durch die nun (endlich wieder) saubere Trennung der Daten-Schemata pro Sub-System und Delegation der Prozessfunktionalitäten an die zugehörigen Sub-Systeme haben die realisierten ScS nur noch systeminterne Abhängigkeiten und Ü„nderungen an der Datenhaltung sind deutlich weniger komplex. In der Folge wird bei einem Release-Wechsel das Risiko übersichtlicher und die Cycle-Time für Innovationen und Erweiterungen sinkt.

-> Abb. 4 beschreibt das MES als SoS aus einer fachlichen Sicht. Bei der Analyse wurde offensichtlich, dass auftrags- und prozessübergreifende Sichten zur Steuerung notwendig sind und das Qualitätsmanagement-System trotz der Qualitätssicherung an den Maschinen ein eigenes Sub-System darstellt.

Abb. 4 -> System-of-Systems: Design an der Wertschöpfung ausgerichtet (Das SoS-Design für das digitale Produkt MES)

Lessons Learned

  1. Man braucht einen langen Atem! Rückblickend hat es fast ein Jahrzehnt gedauert, bis die Vision des SoS mit eigenständigen ScS Wirklichkeit wurde und die Dynamik plötzlich auch umsetzbar wurde. Ein wunderbarer Seiteneffekt ist die Ruhe in den Portfolio-Meetings. Wurde früher gekämpft, damit eine benötigte Funktionalität ins neue Release kam, so herrscht nun viel Gelassenheit, da durch die vielen Releases der eigene Punkt bestimmt in den nächsten 3″“4 Monaten produktiv wird!
  2. Agilität braucht Coaching und am Anfang eine permanente Energiezufuhr: Die Fachbereiche müssen als Product Owner wieder lernen, Verantwortung zu übernehmen, und wir als Service Provider mussten lernen, proaktiv mitzuarbeiten und nicht „stumpf“ Features umzusetzen.
  3. Parallelläufe und Schattenprozesse: Natürlich ist die Testautomatisierung der Hebel für Qualität, aber wo kommen die Testdaten her? Neben der Nutzung von mittlerweile Tausenden von Testfällen lassen wir neu implementierte Systeme teilweise wochenlang als Schattenprozess nebenherlaufen und vergleichen automatisiert die Ergebnisse aus dem laufenden Produktivsystem mit den Ergebnissen der Schattenprozesse. Erst wenn wir eine verschwindend geringe Fehlerquote haben, schalten wir auf das neue System um.
  4. Nicht zu viel auf einmal! Dies ist natürlich eine Binsenwahrheit, aber in der Praxis sind alle Seiten durch kaufmännische Eckdaten getrieben. Die Gefahr ist uns allen bekannt: Zu viel führt zu verlängerten Laufzeiten und einer sinkenden Qualität. Tatsächlich ist dies durch die kurzen Cycle-Times deutlich entspannter, da nun der Product Owner situativ weitere Features aus dem Backlog realisieren kann.

[1] Wir haben Abb. 1 auf Englisch gehalten, da die englischen Begriffe aussagekräftiger sind

[2] Neal Ford et al., Building Evolutionary Architectures, O“™Reilly Media, Inc., USA 2017

[3] Lünendonk® White Paper, Software-Modernisierung, Lünendonk, 2015

[4] https://www.opitz-consulting.com/portfolio/digitalisierung/e-book-dynamikrobuste-architekturen-der-digitalisierung.html

[5] https://www.vuca-welt.de/

Spannendes Live-Webinar zum Thema

Live-Webinar mit Rolf Scheuch und Torsten Winterberg am 14. Mai 2020, 11 – 12 Uhr
Jetzt anmelden!

Lesetipp: Whitepaper „Wohin mit dem Monolithen?

Das Thema IT-Modernisierung ist gerade aktuell für Unternehmen sehr wichtig. Deshalb haben wir ein Whitepaper zum kostenlosen Download bereitgestellt und weitere Informationen dazu im Web aufbereitet: www.opitz-consulting.com/it-modernisierung

Alle Beiträge von thecattlecrew

OPITZ CONSULTING Technology Blog

Schreibe einen Kommentar