Renovation am laufenden Band

Aus alt mach neu: Wie Legacy-Anwendungen wieder fit werden
Kommentare

Viele Unternehmen sehen sich heute in der Situation, dass die Absatzmärkte nach der Nutzung neuer IT-gestützter Möglichkeiten wie z. B. der Social Media verlangen. In der Informationsverarbeitung sind diese Unternehmen meistens mit dem Problem konfrontiert, dass ihre IT in die Jahre gekommen ist. Das betrifft sowohl die Technologie als auch die Anwendungen. Im folgenden Beitrag zeige ich einen Weg, wie durch die Umsetzung der Leitgedanken der Managed Evolution eine sukzessive Erneuerung von solchen Legacy-Anwendungslandschaften zeitgerecht und mit vertretbaren Kosten durchgeführt werden kann.

Es ist eine Binsenwahrheit, dass eine IT-Umgebung nie fertig gebaut ist, sondern immer weiter entwickelt und ergänzt wird. Heute gibt es kein größeres Unternehmen mehr, das ohne IT auskommt. Die IT-Landschaft ist über die Jahre entstanden, gewachsen und wurde laufend an neue Bedürfnisse angepasst. Mit den vielen Erweiterungen wird es zunehmend schwieriger, aufwändiger und auch teurer, die notwendigen Anpassungen vorzunehmen. Es stellt sich dann die Frage: Wie weiter? Im folgenden Artikel beschreibe ich das Vorgehen der Managed Evolution und beantworte diese Frage.

 Dieser Artikel ist erstmals erschienen im Business Technology Magazin 4.13. Tipp: Wenn Sie sich mehr für die Themen Digitale Transformation, IT-Leadership und Lean Innovation interessieren, dann werfen Sie doch einmal einen Blick auf die Business Technology Days 2014. Die Konferenz findet vom 3. bis 6. November in München statt und vermittelt wertvolles Wissen für innovative Business- und IT-Entscheider. Dabei spielen organisatorische Neuausrichtungen eine ebenso wichtige Rolle wie der Einsatz neuester Technologien. Das Ziel: Sie und Ihr Unternehmen fit zu machen für das digitale Zeitalter. Die Themen: – Best Practices erfolgreicher digitaler Unternehmen – Lean Startup & Innovation Management – Digital Transformation Management – Kontinuierliche Optimierung von IT-Strukturen – Innovationen: Cloud, Mobile, Big Data und vieles mehr Bis nächsten Donnerstag, 19. Juni, profitieren Sie übrigens noch von den Frühbucherrabatten. Infos unter http://btdays.de/2014/.  Business Technology Days

Verhaltensmöglichkeiten

In dieser so gewachsenen Situation, die zunehmend schwerfälliger und unübersichtlicher wird, hat eine Unternehmung vier verschiedene Verhaltensmöglichkeiten.

Die erste Möglichkeit ist, einen Neuanfang zu machen. Das wird auch als Greenfield Approach bezeichnet, man beginnt auf der grünen Wiese. Sehr schnell realisiert man, dass dies (zu) lange dauert. Die verfügbaren Ressourcen werden bei diesem Ansatz überstrapaziert, insbesondere weil der bestehende Betrieb aufrechterhalten werden muss. Bedingt durch die lange Dauer, bis die neue Umgebung verfügbar ist, müssen zudem notwendige Ausbauten getätigt werden, sei dies, weil sich gesetzliche Anforderungen ändern oder weil neue Produkte mit anderen Anforderungen auf den Markt gebracht werden.

Die zweite Möglichkeit ist der Einsatz einer Paketlösung. Die heute verfügbaren Pakete haben einen hohen Ausbaustandard und sind in ihren Möglichkeiten sehr vielfältig. Der Aufwand für die Parametrisierung und Anpassung an die individuellen Bedürfnisse darf aber nicht unterschätzt werden. Der Ersatz einer gesamten IT-Landschaft bedingt auch, dass zusätzlich eigene Anwendungen übernommen und integriert werden müssen.

Bei IT-Landschaften mit sehr großen Frequenzen in einzelnen Bereichen, z. B. bei einer Bank im Zahlungsverkehr, kommt eine doppelte Problematik hinzu. Die Performance von Paketlösungen ist nicht auf solche Häufigkeiten ausgerichtet und zusätzlich nehmen die Spezialfälle ein großes Ausmaß an. Wenn z. B. pro Tag 1 000 Fälle zu verarbeiten sind und 1 Prozent davon als Spezialfälle zur manuellen Bearbeitung ausgesteuert werden, so sind das 10 Fälle. Das ist mit vernünftigem Aufwand zu meistern und wird oft als Bereicherung der Arbeit empfunden. Wenn jedoch 1 000 000 Fälle anfallen, so sind das 10 000 Spezialfälle. Das wird einen zusätzlichen Ausbau der Paketlösung nach sich ziehen, um einen großen Teil dieser Spezialfälle zu automatisieren. Zum Schluss ist dann der Unterschied zum Eigenbau in Bezug auf Zeitbedarf, Aufwand und Risiken in der Realisierungsphase nicht mehr so groß, wie ursprünglich angenommen (oder verschwindet sogar ganz).

Die dritte Möglichkeit ist, die Lösung einer gleichgelagerten Unternehmung zu übernehmen. Auch diesem Unterfangen stehen einige Hindernisse im Weg. Welche Unternehmung wird ihre IT-Lösung verkaufen, wenn sie viel darin investiert und dadurch einen Vorsprung im Markt erreicht hat? Wenn dies nicht der Fall ist, so wird die betrachtete Lösung vermutlich auch ihre Mängel haben und ein Vorteil gegenüber der heutigen Lösung ist fraglich. Realistisch ist eine solche Übernahme nur im Zusammenhang mit Merger and Aquisition, dann sind im Gesamten nennenswerte Kostenvorteile zu erwarten.

Bleibt noch eine vierte Möglichkeit, die darin besteht, dass in opportunistischer Weise immer die aktuellen Anforderungen angegangen werden, so lange die Ressourcen dazu ausreichen. Diese Vorgehensweise bringt kurzfristig Erfolge, birgt aber immense Risiken, da in der Regel an den bestehenden Strukturen Raubbau betrieben wird und innerhalb kurzer Zeit ein unübersehbares Geflecht von Beziehungen quer durch die ganze IT-Landschaft entsteht. So wird jede neue Anpassung aufwändiger und mit immer größeren Risiken behaftet.

All diese Möglichkeiten zeigen ein eher düsteres Bild. Die Situation gleicht der des Barons von Münchhausen, der sich am eigenen Schopf aus dem Sumpf zieht. Wenn wir hier einen Ausweg finden wollen, müssen wir die Sache grundsätzlich angehen.

Beurteilung

Das klassische Vorgehen mit der Abfolge „Feststellen der Bedürfnisse des Business“ und anschließender „Realisierung“ ist sicher richtig, weist jedoch bei unbesehener Anwendung im Einzelnen einen großen Geburtsfehler auf. Die Zeitvorstellungen des Business decken sich nicht mit dem Zeitbedarf, den die IT für die Umsetzung der Anforderungen braucht. Verheerend wirkt sich dies aus, wenn jedes einzelne Bedürfnis auf diese Weise angegangen wird. Das würde dann der oben beschriebenen opportunistischen Vorgehensweise entsprechen. Daraus können wir zwei wichtige Schlüsse ziehen: Eine Planung im Sinne der Zusammenfassung von verschiedenen Anforderungen aus dem gleichen Anwendungsgebiet mit Priorisierung und Ressourcenzuteilung ist unumgänglich. So werden die Projekte für die Weiterentwicklung formiert.

Der zweite Ansatzpunkt ist die Zeit, die für die Umsetzung der Projekte benötigt wird. In den letzten Jahren wurden hier große Anstrengungen unternommen, um eine effizientere Abwicklung zu realisieren. Das Hauptaugenmerk lag dabei auf den Modellen des Projektvorgehens, z. B. Scrum [1]. Die bestehende Umgebung, in welche die neuen Funktionen eingebaut werden sollen, und wo die Anpassungen vorgenommen werden müssen, wird dabei meist als gegeben hingenommen. Der Einfluss von Struktur und Aufbau der bestehenden IT-Landschaft auf den Aufwand für ein einzelnes Projekt ist aber wesentlich. Dieser Sachverhalt zeigt sich im Widerstand gegen Veränderung (Resistance to Change (RtC)), der dem Projekt aus der bestehenden IT-Landschaft entgegengehalten wird. Diese Resistance to Change ist ein prägendes Merkmal für die Beurteilung der Qualität einer Anwendungslandschaft.

Aufmacherbild: innovation concept von Shutterstock / Urheberrecht: Carlos Amarillo

[ header = Seite 2: Resistance to Change ]

Resistance to Change

Die Resistance to Change (RtC) kann einfach beschrieben werden. Intuitiv bedeutet eine geringe RtC, dass neue Anforderungen einfach und mit angemessenen Kosten realisiert werden können, während eine hohe RtC bedeutet, dass neue Anforderungen kompliziert zu realisieren sind, viel kosten und dementsprechend lange dauern.

Die RtC kann quantitativ definiert und operationell umgesetzt werden. Die Messwerte sind die Kosten, die jedes Projekt verursacht (DevC) und die Dauer vom Zeitpunkt des Projektstarts bis zur Einführung (TtM). Dabei ist zu beachten, dass das Projektende nicht zwingend mit der Einführung zusammenfällt. So ist insbesondere die Einführungsphase immer noch kostenrelevant für das laufende Projekt. Man kann den Zeitraum zwischen Einführung und Abschluss der Kostenzurechnung als Garantiezeitraum betrachten, dies insbesondere, damit nicht unfertige Projekte wegen der Budgetzahlen oder weil der Termin fällig ist schon abgeschlossen werden und die restlichen Entwicklungskosten dann unter Wartung verbucht werden müssen.

Damit wir die Projekte miteinander vergleichen können, ist es nötig, ein Maß für die Größe (Size) jedes Projekts festzulegen. Es gibt große und kleine Projekte, solche, die komplex sind, und solche, die weniger komplex sind. Wirklich einfache Projekte gibt es kaum und bei denen, die so aussehen, steckt der Teufel im Detail. Ein gutes Maß sind Function Points (FP) oder Use Case Points (UCP) [2], die für die ex ante Aufwandschätzung benutzt werden. Dabei sind UCP näher beim applikatorischen Anwendungsfall gegenüber den FP, die auf der softwaretechnischen Aufgliederung der Anforderung basieren. Eine reine Kostenangabe ist ungeeignet für die Bestimmung der Mächtigkeit eines Projekts in diesem Zusammenhang. Die Kosten werden, wie oben ausgeführt, als eigene Messgröße erfasst. Wenn hier nochmals die Kosten verwendet würden, so wäre dies tautologisch. Auch ist zu berücksichtigen, dass Projekte verschiedene Charakteristiken aufweisen. So ist ein FP oder UCP in einem Entwicklungsprojekt in einem neuen Gebiet nicht gleich schwer zu gewichten wie bei einem Projekt, in dem es darum geht, eine bestehende Applikation zu entfernen. Sinnvollerweise werden die FPs oder UCPs zuerst bestimmt und nachher mit der entsprechenden Gewichtung versehen.

Wir können nun für jedes Projekt bestimmen, wie viel eine Einheit von Size (z. B. UCP) kostet (DevC/Size) und wie viele Arbeitstage (TtM/Size) dafür aufgewendet wurden. Die Resistance to Change (RtC) ergibt sich nun aus den drei Paramentern DevC, TtM und Size, indem wir die zwei Größen miteinander multiplizieren (DevC / Size * TtM / Size = DevC * TtM / Size2). In der Praxis hat es sich gezeigt, dass die Datenbereitstellung eine Herausforderung ist. Nach einem Einführungszeitraum von über einem Jahr waren die Resultate dann brauchbar und der Erfolg der dazu eingeleiteten Maßnahmen zeigte sich (Abb. 1) [3, S. 223].

Abb. 1: Bestimmung der Resistance to Change und der IT-Effizienz [3, S. 541]

Die nächste Frage ist jetzt: Wie kann die RtC beeinflusst werden? Die erste Antwort dazu ist einfach: Veränderungen an der IT-Landschaft werden durch die Projekte vorgenommen. Also müssen wir die Projekte entsprechend gestalten, instruieren und die notwendigen Voraussetzungen für eine erfolgreiche Umsetzung schaffen.

[ header = Seite 3: Wertschätzung der Legacy-Systeme ]

Wertschätzung der Legacy-Systeme

Die Rahmenbedingungen für die Projekte sind durch das Management gestaltbar. Dazu müssen wir uns im generellen Zieldreieck zwischen geforderter Funktionalität, effizienter Bereitstellung der Applikationen und kostengünstiger Bertreibbarkeit positionieren (Abb. 2). Dabei kann die geforderte Funktionalität als Nebenbedingung fixiert werden. Die Betreibbarkeit ihrerseits wird durch die Auslegung in der Bereitstellung vorbestimmt. Somit gilt unser Hauptaugenmerk der effektiven und effizienten Bereitstellung von Applikationen. Es geht darum, das Richtige richtig zu tun.

Abb. 2: Zielkonflikte bei den Erwartungen an die IT

Der Zielkonflikt besteht darin, dass die Kosten für die Bereitstellung der geforderten Funktionalität in der Regel die verfügbaren Mittel (bei Weitem) übersteigen. Hier muss ein Ausgleich gefunden werden, in dem entweder die Leistungserstellung vereinfacht und/oder die Ansprüche reduziert werden.

Zur Bewältigung dieser Konflikte und zur Bereitstellung optimaler Voraussetzungen für die Realisierung der Applikationen und deren anschließenden Betrieb verfügt die IT über ein umfangreiches Instrumentarium. Neben den klassischen Managementinstrumenten, wie Planung, Verhandlungsführung, Budgetierung etc. kann die IT mit dem spezifischen Mittel der IT-Architektur den Überblick schaffen und diesen auch bewahren. Architektur wird dabei zum einen als Struktur und Aufbau eines Systems und zum anderen auch als die Tätigkeit der Systemgestaltung verstanden. Das ist das Kerngebiet von Enterprise Architecture Management. Damit wird eine Brücke zwischen den Businessanforderungen und deren Darstellung im IT-Bereich geschlagen. [5, S. 185 ff]

Im Folgenden konzentrieren wir unsere Betrachtung auf die Struktur der IT-Architektur, wozu auch die zugehörige Dokumentation gehört. Architektur als Tätigkeit umfasst die Prozesse, die Zuteilung der finanziellen und personellen Ressourcen und die Governance [6, S. 70 ff].

Die bestehende Applikationslandschaft repräsentiert ein großes finanzielles Investment, das schnell in die Millionen gehen kann. Dies legt nahe, dass dieses Asset auch als solches geschätzt und dass ihm Sorge getragen wird. Bestehende Systeme, vor allem, wenn sie über Jahre oder gar Jahrzehnte gewachsen sind, haben oft einen schlechten Ruf und werden als Legacy-Systeme mit einem negativen Unterton bezeichnet. Dabei müssen wir uns bewusst sein, dass letztlich jede Umgebung nur aus Legacy-Applikationen besteht, denn auch, wenn heute eine neue Applikation eingeführt wird, so ist sie morgen schon Legacy und wir haben bei Anpassungen und Erweiterungen festgefügte Vorgaben, die den Bewegungsspielraum einschränken.

Wenn wir die vorhandenen Anwendungen genauer analysieren, so werden wir oft feststellen, dass diese in die Jahre gekommenen Applikationen oft auf einem sehr klaren Konzept beruhen. Dieses wurde im Laufe der Zeit durch die dauernden Ergänzungen und Umbauten bis zur Unkenntlichkeit überdeckt. Das zugrunde liegende Know-how, insbesondere bei den Anwendern und den IT-Mitarbeitern sollten wir uns zunutze machen. Die Konsequenz daraus bedeutet: Die bestehenden Systeme stellen ein Vermögen dar und nicht (nur) eine Altlast.

Unnötige Komplexität vermeiden

Bisher haben wir zwei wesentliche Erkenntnisse gewonnen:

  • Der Widerstand der Applikationslandschaft gegen Anpassungen muss optimiert werden.
  • Die bestehende Applikationslandschaft stellt einen großen Wert dar, den es zu pflegen gilt.

Wir haben auch gesehen, dass die Applikationslandschaft durch dauernde Erweiterungen und Anpassungen immer komplexer und schwerfälliger wird. Sie ist in ständiger Veränderung und hat die Tendenz, an Ordnung zu verlieren. Unsere Aufgabe ist es, die notwendigen Vorkehrungen gegen diese Tendenz zu treffen. Darauf wollen wir im nächsten Abschnitt eingehen.

Jedes System hat seine natürliche Komplexität. Diese kann ohne Informationsverlust nicht reduziert werden. So enthält z. B. eine topographische Karte als Abbild der Realität nur die für den Zweck relevanten Angaben und das entsprechend dem gewählten Maßstab. Ein System kann jedoch auch unnötig komplex sein.

Im IT-Bereich führen oft verlockende Quick Wins zu einer unerwünschten Erhöhung der Komplexität. Wenn zum Beispiel durch ein solches Vorhaben eine neue Technologie zum einmaligen Gebrauch eingeführt wird. Die Koexistenz verschiedener Technologien mit ähnlichem Leistungsprofil bedingt im Nachgang immer auch deren Pflege und das ist zusätzlicher Aufwand. Ausführliche Analysen bei einem großen Finanzdienstleister haben gezeigt, dass eine nachträgliche Bereinigung dieser Situationen keinen positiven Business-Case erbringt, da die einzusparenden Kosten in keinem Verhältnis zum notwendigen Aufwand stehen. Die Paybackperiode würde die restliche Lebenszeit der Anwendung bei Weitem übersteigen. Eine Bereinigung dieser Situation ist dann gegeben, wenn eine größere Anpassung oder gar ein Ersatz dieser Anwendung nötig ist. Ein positiver Business-Case ergibt sich fast immer, wenn vor dem Entscheid für die Quick-Win-Lösung die Kosten voll aufgerechnet werden. Auch der Zeitverlust für zusätzliche Abklärungen und eventuelle Ausbildung von Mitarbeitern ist meist vertretbar.

Daraus können wir lernen: Jedes Projekt hat neben dem Businessnutzen, der den eigentlichen Zweck des Projekts darstellt, auch einen Beitrag zur Erhaltung der IT-Effizienz zu leisten, um die Wartbarkeit aufrecht zu erhalten und die Unterhaltskosten zu minimieren.

[ header = Seite 4: Komplexität beherrschen ]

Komplexität beherrschen

Jedes System hat seine Komplexität und die kann ohne Verlust an Information nicht reduziert werden. Wir sind also gezwungen, diese Komplexität zu akzeptieren. Was wir machen können, ist das System strukturieren, um so eine übersichtliche Ordnung zu erhalten. Damit wird die Komplexität bis zu einem gewissen Grad beherrschbar. Dabei stehen drei Begriffe im Zentrum:

  • Kohäsion, die sich auf den inneren Zusammenhang zwischen zwei Elementen aus Applikationssicht bezieht.
  • Kapselung, welche dafür sorgt, dass die zusammengefassten Elemente gegenüber dem Rest der IT-Landschaft abgegrenzt werden.
  • Schnittstellen (Interfaces), welche die Kommunikation zwischen den Kapselungseinheiten sicherstellen.

Ein einfaches Beispiel dazu ist die Zusammenfassung der CRUD-Funktionalitäten für die Bearbeitung einer Relation in einer Datenbank (CRUD bedeutet Create, Read, Update und Delete). Der innere Zusammenhang dieser vier Funktionen ist offensichtlich, denn sie bearbeiten alle das gleiche Objekt und die Ausgestaltung ihrer Funktionen ist nicht unabhängig. Wir bilden also hier eine Kapselungseinheit, auf die von außen nur über wohldefinierte Schnittstellen zugegriffen werden kann. Insbesondere die Lesefunktion wird an vielen Orten in der IT-Landschaft immer wieder verwendet, so zum Beispiel bei Kundendaten. Die verändernden Funktionen werden nur an wenigen Orten benötigt, aber oft in größerem Zusammenhang, d. h. Updates werden an mehreren Objekten gleichzeitig durchgeführt. Das führt dann dazu, dass diese Schnittstellen zu höheren Konstruktionen aggregiert werden.

Dieses Vorgehen entspricht dem Prinzip der SOA (Service-oriented Architecture). Dabei kann jetzt die Entwicklung in zwei Richtungen weiterverfolgt werden [5, S. 344]. Zum einen der Pfad, der die SOA bekannt gemacht hat. Es geht um die semantische und syntaktische Ausgestaltung vor allem der Schnittstellen in der Software und deren technische Umsetzung (Web Services, Enterprise Service Bus und zu Beginn CORBA). Die andere Richtung weist in die EA (Enterprise Architecture) und befasst sich vor allem mit der pragmatischen Dimension der Semiotik, wobei gleichartige, zusammenhängende Funktionalitäten gesucht und gebündelt werden, um die Landschaft der Informationsverarbeitung in einem Unternehmen zu strukturieren. Diese Richtung wollen wir nun weiter verfolgen, denn durch diese Art der Strukturierung ist es möglich, die Komplexität beherrschbar zu machen. Beide Richtungen sind für eine erfolgreiche Realisierung notwendig, aber alleine nicht hinreichend.

Ein weiterer Begriff in diesem Zusammenhang ist die Koppelung [3, S. 46]. Eine enge Koppelung zwischen zwei Elementen bedeutet, dass Aufbau und Verhalten des einen Elements direkten Einfluss hat auf das andere Element. Bei den oben erwähnten CRUD-Funktionen ist dies gegeben und auch gewollt. Insofern besteht eine gewisse Affinität zwischen Kohäsion und Koppelung.

Die notwendige Koppelung zwischen zwei Kapselungseinheiten kann auf allen drei Ebenen des Schichtenmodells (Präsentationsschicht, Prozessschicht, Datenschicht) erfolgen. Um eine möglichst große Unabhängigkeit zwischen den einzelnen Kapselungseinheiten zu gewährleisten, ist die Koppelung über die Prozessschicht, d. h. mittels Funktionen vorzuziehen. Eine Koppelung über die Datenschicht führt dazu, dass keine Anpassungen am Datenmodell möglich sind, ohne dass alle betroffenen Einheiten gleichzeitig umgestellt werden. Wird die Koppelung über die Präsentationsschicht vorgenommen, so führt auch dies zu unerwünschten Kaskaden bei den Anpassungen. Manchmal lassen sich diese unerwünschten Koppelungen aus applikatorischer oder technischer Sicht nicht vermeiden, z. B. bei Joint-Views auf eine Datenbank macht es keinen Sinn, zuerst die ganzen Daten auszulesen, um sie in einem separaten Bereich nochmals aufzubauen.

Ziel muss es sein, dass eine möglichst große Unabhängigkeit zwischen den einzelnen Koppelungseinheiten besteht. Man spricht dann von lose gekoppelten (loosely coupled) Systemen, im Gegensatz zu eng gekoppelten (tightly coupled). Diese Unabhängigkeit ermöglicht es, eine Veränderung in einer Kapselungseinheit vorzunehmen, ohne dass die angekoppelte Einheit synchron nachziehen muss. Wird z. B. ein Leseservice angeboten, so kann die Datenbank dahinter beliebig optimiert werden, ohne die nachfragenden Elemente zu beeinträchtigen. Würde die Koppelung auf der Datenebene erfolgen, so müsste jede Lesefunktion unmittelbar angepasst werden.

Koppelungen können explizit definiert werden. Häufig entstehen jedoch auch implizite Koppelungen durch stillschweigende Annahmen. Diese können sehr unangenehme Folgen haben, wenn sie sich dann als irrig erweisen. Beispiele dazu sind:

  • In einer Buchhaltung gibt es nur positive Beträge. Ein Vorzeichen ist nicht notwendig. Das stimmt wohl, es sei denn, Stornos werden mit negativem Vorzeichen gebucht, um keine Verfälschung des Umsatzes zu erzeugen.
  • Die Buchhaltung wird nur in einer Währung geführt und die Währungsbezeichnung wird bei Beträgen nicht mitgegeben. Stimmt bis zum Moment, wo der Währungskreis verlassen wird und im internationalen Geschäft mehrere Währungen benötigt werden.
  • Die Anwendungen benötigen nur eine Benutzersprache.
  • 7/24 h Verfügbarkeit wird nicht benötigt. Ob diese direkt realisiert wird, ist eine andere Frage, aber bestimmte Arten der Verarbeitungen verunmöglichen eine spätere Anpassung.
  • Etc.

Um solchen Überraschungen vorzubeugen, sind die nicht funktionalen Eigenschaften eines Systems explizit festzuhalten, ohne dass schon ein Dringlichkeitsfall vorliegt.

Was wir hier festhalten: Die Bildung von möglichst lose gekoppelten Kapselungseinheiten ist für die Beherrschung der Komplexität der IT-Landschaft eine Voraussetzung.

Ansätze zur Strukturbildung

Grundsätzlich erfolgt eine Strukturierung entweder von oben nach unten oder von unten nach oben, bekannt als „top down“ oder „bottom up“. Rasch wird man dann bei top down feststellen, dass nur triviale Erkenntnisse resultieren oder bei bottom up die Verdichtung nicht vorankommt und man vor lauter Bäumen den Wald nicht mehr sieht.

Ziel der Strukturierung ist eine hierarchische Gliederung bestehend aus Domänen (Domains), Subdomänen (Subdomains) und Anwendungen (Applications), wobei Konflikte bei der Zuteilung auch schon auf Schwachstellen in der Applikationslandschaft hinweisen. Den einzelnen Applikationen werden die elementaren Kapselungseinheiten zugewiesen.

Eine Gliederung nach IT-technischen Gesichtspunkten, wie z. B. Datenbanksystem, Programmiersprache oder Entwicklungsmethode ist dagegen nicht zielführend, weil so die Wahrscheinlichkeit groß ist, dass die gleiche Funktion mehrmals redundant realisiert wird und im Anschluss daran gewartet werden muss.

Als Ansatz für die Strukturbildung hat sich auf der obersten Ebene ein einfaches Modell aus fünf Kategorien als praktikabel gezeigt. Die einzelnen Kapselungseinheiten werden diesen Kategorien zugewiesen. Ob das Applikationen, Datenbanken, Dialogsequenzen oder Ähnliches sind, spielt vorläufig keine Rolle. Man beginnt mit den Elementen, die man kennt und die gut fassbar sind, dann arbeitet man sich durch die ganze Plattform durch. Dieses Vorgehen ist pragmatisch und kann als „middle out“ verstanden werden. Die fünf Kategorien am Anfang sind (Abb. 3):

  • Externe Partner
  • Kommunikation und Koordination
  • Marktleistung
  • Finanzen, Risiko, Reporting
  • Administrative Belange

Abb. 3: Kategorien als oberste Konsolidierungsebene

Für die Fortsetzung werden dann die Kategorien in Domänen unterteilt und die in den Kategorien enthaltenen Kapselungseinheiten den Domänen zugeteilt.

Eine weitere Gliederungsmöglichkeit, die sich auf Stufe der Applikationen als sinnvoll erwiesen hat, ist die Unterteilung nach der Dauer des Lebenszyklus. So kann davon ausgegangen werden, dass:

  • kanalspezifische Dialoge eine Lebenserwartung von ca. zwei Jahren haben, bis sie überarbeitet werden müssen.
  • Prozessabläufe zehn Jahren haben.
  • generische Funktionen bis zu dreißig Jahren haben.

Diese Aussage gibt auch einen Hinweis darauf, warum viele sehr alte Anwendungen immer noch im Gebrauch sind. Meistens wurde jedoch verpasst, die Teile mit den kürzeren Laufzeiten sauber abzukapseln und daraus resultiert dann das Malaise bei der Wartung.

Daraus sehen wir: Kapselung ist eine notwendige, aber nicht hinreichende Voraussetzung um eine IT-Landschaft strukturieren zu können.

Erst im Zusammenspiel von mehreren Kriterien, wie applikationsbezogene Domainbildung und Lebenserwartung kann eine tragfähige Struktur erreicht werden.

[ header = Seite 5: Entschärfung der Zielkonflikte & Zusammenfassung ]

Entschärfung der Zielkonflikte

Wir haben die vier wesentlichen Gesichtspunkte herausgearbeitet. Diese sind:

  • der Widerstand gegen Anpassungen (Resistance to Change (RtC))
  • die Wertschätzung der bestehenden IT-Landschaft
  • das Berücksichtigen von Businessnutzen und IT-Effizienz in den einzelnen Projekten
  • die Strukturierung der bestehenden Applikationslandschaft

Jetzt fehlt noch eine Lösung für den Umgang mit den Zielkonflikten. Durch unsere Vorarbeiten, insbesondere durch die Strukturierung der Landschaft, sind wir in der Lage, gut abzuschätzen, welche Teile der IT-Landschaft angepasst werden müssen. Für jedes Projekt können wir bestimmen, welche Bedingungen für eine ordnungsgemäße Realisierung einzuhalten sind. So unterbinden wir Piratenzugriffe in fremde Datenbanken und verweisen dafür auf die angebotenen Services. Dadurch werden die Risiken bezüglich unliebsamer Überraschungen kleiner und die IT-Effizienz wird verbessert.

Die bessere Kenntnis der eigenen IT-Landschaft ermöglicht eine Vision für den Sollzustand und die Erarbeitung einer strategischen Planung, die in realisierbare Schritte umgesetzt werden kann. Wesentlicher ist aber, dass es damit gelingt, große Businessprojekte aufzuteilen, die einfacher zu realisieren sind, die kürzere Laufzeiten haben und letztlich auch im Gesamten zu günstigeren Kosten abgewickelt werden. Ziel muss es sein, Teilprojekte zu bilden, die innerhalb 9–12 Monaten einen Businessnutzen erbringen und die zur Verbesserung der Resistance to Change beitragen.

Wird in einem Projekt aus Gründen der Time to Market (Quick Wins) gegen die saubere Struktur verstoßen, so sind die Maßnahmen zur Wiederherstellung der Ordnung von Anfang zu planen und die Aufwände dem Projekt zuzurechnen.

Es findet keine einmalige, großflächige Umgestaltung der IT-Landschaft statt, sondern das Vorgehen erfolgt etappenweise. Dies kann vor allem zu Beginn die unliebsame Konsequenz haben, dass Brücken gebaut werden müssen, die später wieder hinfällig werden. Dabei ist darauf zu achten, dass die alten Systeme den neuen Services angepasst werden und somit eine allfällige Umsetzung in der Brücke stattfindet und nicht, dass die neuen Systeme von Anfang an mit Altlasten verunstaltet werden.

All dies führt dazu, dass nicht mehr Mammutprojekte mit einem Big Bang eingeführt werden, sondern dass ein steter Strom von kleineren Ergänzungen, Erweiterungen oder Ersatz von Applikationen verfügbar wird. Trotzdem ist Guderians Grundsatz vom „Klotzen, nicht kleckern“ [7, S. 286] Rechnung getragen, da für die IT-Landschaft eine langfristige Vision und die zugehörige strategische Planung als Grundlage bestehen.

Zusammenfassung

Managed Evolution ist die iterative, gezielte und messbare Weiterentwicklung der IT-Landschaft unter Berücksichtigung der Balance zwischen Geschäftsnutzen und IT-Effizienz und unter Einhaltung von Vorgaben zu Qualität und Gesamtkosten. Und dies sind die Merksätze zur Managed Evolution:

  • Zentraler Begriff ist die Resistance to Change (RtC).
  • Zusätzlich zum Geschäftsnutzen (Business Value) wird in jedem Projekt auch für die Aufrechterhaltung und Verbesserung der IT-Effizienz (RtC) gesorgt.
  • Die Anpassungen und Erweiterungen erfolgen kontinuierlich und nicht mit einem Big Bang.
  • Die existierenden IT-Landschaften sind als Vermögen (Assets) zu sehen und nicht primär als Altlasten. Dies gilt speziell auch für das Know-how der Mitarbeiter.
  • Beherrschung der Komplexität der IT-Landschaft durch Strukturierung nach Applikationsgesichtspunkten, um Teile unabhängig weiterentwickeln zu können.
  • Alt passt sich neu an und nicht umgekehrt.
  • Es gibt kein endgültiges Zielsystem, da die Umgebung sich immer weiterentwickelt und somit auch Vision und IT-Strategie immer wieder angepasst werden müssen.

Dabei ist darauf zu achten, dass die fünf Bausteine der IT-Architektur, Struktur, Dokumentation, Ressourcen, Prozesse und Governance, in einem ausgewogenen Verhältnis zueinander stehen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -