Noch nicht bemerkt? Sie haben technische Schulden!

Die Wichtigkeit von IT als kritischem Faktor wird noch immer allzu oft vom Management ignoriert. Doch wollen Unternehmen langfristig überleben, müssen sie das Management ihrer IT-Architektur zum Pflichtprogramm erheben. [...]

Die heutige IT ist mit großen Herausforderungen konfrontiert, verursacht durch drei einzelne Phänomene, die erst in ihrer Kombination die „kritische“ Masse erreichen: Die unbemerkt angesammelte Komplexität der IT-Architektur, der Druck durch unternehmenskritische Veränderungstreiber sowie oftmals schwache IT-Architektur-Kompetenzen im Unternehmen.

Man kennt es von der heimischen Garage: Hin und wieder ein bisschen hier und dort aufzuräumen, hilft nicht wirklich. Allzu schnell sammelt sich neuer Kram an, man findet nichts wieder und verliert irgendwann den Überblick. Doch die Mühen des großen Entrümpelns scheut man, solange es auch ohne geht. Dabei ist der Aufwand dafür ein ähnlicher wie für kontinuierliches „House-Keeping“ – mit dem Unterschied, dass er meistens in wesentlich kürzerer Zeit erbracht werden muss, weil ein Ereignis oder Anlass plötzlich dazu zwingt.

Nicht viel anders verhält es sich mit der IT in Unternehmen: Werden dort nicht kontinuierlich Applikationen, Infrastruktur und Services auf Aktualität und belastbare Ausbaufähigkeit untersucht und Legacy Applikationen entrümpelt, wird unmerklich immer größere „technische Schuld“ aufgebaut. Egal, ob dies aus Unverständnis, Ahnungslosigkeit, Bequemlichkeit oder purer Angst vor (Ver)Änderungen geschieht – dem Unternehmen erweist man damit auf Dauer einen Bärendienst.

Komplexität und Veränderungstreiber als „Falle“ für die IT
In der frühen Phase, wenn ein Unternehmen gerade durchstartet und erfolgreich ist, funktioniert alles (noch) bestens: Was der Fachbereich von der IT verlangt, bekommt er auch gerne und individuell geliefert – die Prozesse laufen wunschgemäß ab: Das Arbeiten mit zehn bis zwanzig verschiedenen Applikationen funktioniert gut und auch das Outsourcing in die Cloud erfolgt in kleinerem Ausmaß noch zufriedenstellend. Doch mit wachsendem Unternehmenserfolg, –größe und Diversifikation entstehen eine wachsende Anzahl von Applikationen und Schnittstellen – in der Regel sind schnell mehrere hundert erreicht – dadurch steigt in einem langsamen, aber stetigen Prozess auch die Unübersichtlichkeit und mangelnde Wartbarkeit.

Eines Tages aber schlägt der konstante Druck des Marktes durch, sei es in Form von Mergers & Acquisitions, Kostendruck oder dringend notwendiger Produkt- bzw. Technologie-Innovationen. Das Unternehmen reagiert. Es will sich verändern – und zwar schnell (Sie wollen motiviert ein neues Projekt starten – die Garage muss frei werden und zwar schnell). Dies geht zwangsläufig mit substantiellen Auswirkungen auf die IT einher. Und plötzlich läuft es nicht mehr rund, weil niemand dafür gesorgt hat, sowohl die Komplexitäten unter Kontrolle zu halten, als auch die Veränderungsfähigkeit der IT zu gewährleisten. Mit steigender Applikationsanzahl ändert sich die gesamte Charakteristik der IT, diese kann nicht mehr folgen, die Fachbereiche sind nun öfter unzufrieden. Auch Versäumnisse können sich nun rächen: Unternehmen, die stets nach dem Motto „das funktioniert schon noch so“ agieren, haben in der Vergangenheit keinen Evolutionsdruck auf ihre IT Architektur erzeugt. Daher wurden die Probleme in der IT nie präsent und die IT ist auf die neue Situation nicht oder nur schwerlich vorbereitet.

Doch das besonders Tückische ist hier die schleichende Anhäufung von Komplexität, der nicht entgegengewirkt wird. Denn im Standardbetrieb ohne größere Veränderungen kann dies über viele Jahre unbemerkt bleiben. Symptome dieser hinsichtlich Wandelbarkeit defizitären Entwicklung zeigen sich dann langfristig: die IT-Kosten steigen, die IT-Unternehmensarchitektur ist nicht mehr in der Lage, sich rasch zu verändern, Ausfälle und bisher nicht bekannte Problemstellungen häufen sich, die IT kann dem Fachbereich nicht mehr folgen. Und nun erkennt man im Unternehmen, dass etwas unrund läuft, irgendetwas passt nicht mehr. Aber was? Wo soll man ansetzen? Da Manches schlecht, aber Vieles auch weiterhin gut läuft, gestalten sich Problemlagen komplex oder gar diffus und Ursachen sind nicht eindeutig auszumachen.

Unternehmen scheuen Investitionen in IT-Architektur-Management
Bei einer solchen Symptomlage, deren Ursachen unklar scheinen, sollten Unternehmen prüfen, welchen Stellenwert die IT-Architektur im Unternehmen hat. Eine der Ursachen könnte zunächst ein fehlendes oder nicht ausreichend stringentes IT-Architektur-Management in der Vergangenheit sein. Da alle Branchen Veränderungsprozessen unterworfen sind, kann diese Symptomlage überall auftreten, wo Unternehmen große IT-Abteilungen betreiben, die diesen Wandel mitgehen müssen: erhöhte regulatorische Anforderungen (bspw. Banken), der Betrieb kritischer Infrastruktur (bspw. Lebensmittelkonzerne) oder Digitalisierung der Fertigung (bspw. produzierende Unternehmen aber auch Dienstleistungsunternehmen wie die Touristik- oder Wellnessbranche).

Meistens versäumen Unternehmen aus Unkenntnis der Folgen, hier gut vorzusorgen. Denn dies bedeutet eben in ein funktionierendes Management der IT-Architektur zu investieren – eine unangenehme Kostenfrage, der Unternehmen allzu gerne ausweichen. Daher zögern Unternehmen diesen Schritt häufig hinaus – zumal sie erst dann Benefits in Investitionen erkennen, wenn schließlich die Probleme auftauchen, die mit einer rechtzeitigen Investition hätten vermieden werden können. Ein Grund dafür ist sicherlich die Zurückhaltung, in vermeintlich funktionierenden Systemen Veränderungen durchzuführen und konstant substantielle Investitionen zu tätigen. Vor allem in der späten Phase, wenn sich bereits hohe Komplexität angehäuft hat, wird man sehr zögerlich, Eingriffe vorzunehmen. Viele Unternehmen halten sich hier – trügerischerweise – weiterhin an den Grundsatz Never change a running system.

Erst wenn es wirklich „wehtut“, wird Geld für Werkzeuge und Mitarbeiter ausgegeben. Je nach Unternehmensgröße benötigt ein funktionierendes IT-Architektur-Management einen IT-Architekten oder ein Architektur-Board, in dem Mitarbeiter abgestellt sind, um die IT-Architektur konsequent fortzuentwickeln. Diesen Bedarf zu erkennen, setzt allerdings substantielle Erfahrungen voraus, denn Benefits zeigen sich nicht sofort und unmittelbar. Es werden ggf. keine neuen Funktionalitäten geschaffen, es läuft u. U. nichts schneller als zuvor – aber, und das ist der springende Punkt: Die getätigten Investitionen zahlen sich in der Zukunft durch eine Wandelbarkeit der IT aus, um nötige Transformationen für das Unternehmen effizient umsetzen zu können.

IT-Architekten benötigen Rückhalt im Unternehmen
Eine wesentliche positive Eigenschaft funktionierender IT-Architekturen ist somit ihre Fähigkeit zur Veränderung. Daher ist die Planung von IT-Architekturen eine äußerst komplexe Aufgabe, die langjährige Erfahrung im Entwicklungsumfeld wie auch im gelebten Projektgeschäft erfordert. Oftmals ist die Position des IT-Architekten unbekannt oder erfährt ein geringes Ansehen durch das Unternehmensmanagement, da seiner Funktion eine geringe Bedeutung für den Geschäftserfolg beigemessen wird. Doch eine stärkere Berücksichtigung und eine intensivere Einbindung von IT-Architekten sind wünschenswert, denn positive wie negative Resultate aus (un-)bewußten Entscheidungen die IT-Architektur betreffend zeigen sich in der Regel langfristig. Zudem können andere Symptome diese Resultate überlagern, was eine Diagnose zugrundeliegender Probleme auf IT-Seite erschwert. Deshalb ist es oftmals alles andere als trivial, sich ein klares Bild der aktuellen Situation zu verschaffen und auf dieser Basis vorausschauende Entscheidungen zu treffen.

Das Motto des IT-Architekten sollte lauten: Komplexitätskontrolle und Standardisierung versus Weiterentwicklung und Individualisierung. Mit einer allumfassenden Standardisierung kann er aufgrund zu starrer Strukturen durchaus Nachteile und Unzufriedenheit für seine Fachbereiche verursachen. Manchmal ist es für einen Fachbereich sogar unumgänglich, mit einer Applikation zu arbeiten, die gegen die Richtlinien der IT-Architektur des Unternehmens verstößt – zum Beispiel, um sich im Wettbewerb abzugrenzen. In solchen Fällen gilt es, mit Augenmaß zu entscheiden. Die Richtlinienkompetenz des IT-Architekten muss sich darin zeigen, dass er Rückhalt durch das Top-Management in der Unternehmensführung genießt. Da Entscheidungen über einzusetzende Technologien Konsequenzen für die Nutzung durch Anwender, die IT-Architektur, deren Betrieb, Wartbarkeit und Erweiterbarkeit haben, sollten sie nicht leichtfertig getroffen werden. Zu den Aufgaben des IT-Architekten gehört es also, klar Grenzen aufzuzeigen und an diesen Grenzen bewusst über Abweichungen im Einzelfall zu entscheiden.

In einer klaren Plattformstrategie legt er auf Basis unternehmerischer Priorisierungen fest, wo spezialisierte Applikationen unterstützen werden sollen und wo Standards gesetzt werden müssen. Außerdem behält er die Ausbaufähigkeit der IT-Architektur des Unternehmens stets im Blick. Dadurch ist er in der Lage, schnell auf gewünschte Veränderungen zu reagieren. Um jederzeit aus seiner aktuellen IT Architektur eine neue Plattformstrategie und Planung ableiten zu können, benötigt der IT-Architekt unter anderem ein klares Verständnis aller Komponenten und deren Integrationsfähigkeit: Wie interagieren die Komponenten miteinander? Hier entscheidet sich oftmals, ob eine IT-Architektur tragfähig ist. Betrachtet man die Innovationskraft jüngerer Unternehmen, wird schnell klar, wie wesentlich es für etablierte Unternehmen ist, dass man Applikationien und Komponenten effizient austauschen kann. Diese Integrations- und Austauschfähigkeit sind u.a. Merkmale einer guten IT-Architektur.

Enterprise Architecture Management: vom Status Quo zum Redesign
Unternehmen, die nicht aktiv und mit Weitblick für eine gute IT-Architektur gesorgt haben, stehen vor der Herausforderung, in kürzester Zeit ihre IT-Architektur einer raschen, aber verlässlichen Bestandsaufnahme und einem anschließenden Redesign hin zu einer tragfähigen Zielarchitektur zu unterwerfen. Ein wesentliches Werkzeug ist dabei Enterprise Architecture Management (EAM): Ein methodisches Vorgehen gepaart mit leistungsfähigen Tools, die in die neuen IT-Prozesse integriert werden. EAM fokussiert sich auf wesentliche Assets in der IT, also Applikationen und Komponenten, Services und Schnittstellen sowie Client und Server-Infrastrukturen.

Unternehmen die das IT Architekturmanagement in der Vergangenheit vernachlässigten haben als Resultat üblicherweise keinen aktuellen Überblick über o.g. Assets. Deshalb besteht die erste „Pflichtübung“ darin, genau diese relevanten Assets der IT für Betrieb und Projekte in ihrem Unternehmen zu erfassen – auch deren Abhängigkeiten zueinander. Dafür sollte ein eigenes Tool zur Verfügung stehen, welches für jedes Asset auch diverse Charakteristiken wie Kritikalität oder Lebenszyklus von Applikationen erfasst. Die Erfahrung zeigt, dass in den wenigsten Unternehmen Überblick darüber herrscht, wie viele Applikationen bereits das Ende ihres Lebenszyklus’ oder einen Punkt darüber hinaus erreicht haben. Da in Unternehmen sensible Daten behandelt werden, muss zudem der jeweilige Schutzbedarf ermittelt werden, ebenso der Grad der notwendigen Stabilität und Verfügbarkeit (üblichweise abgeleitet aus der definierten Kritikalität), mit dem die Applikation laufen muss.

Verfügbar sind spezialisierte EAM-Tools mit drei unterschiedlichen Perspektiven auf das Thema IT-Asset: aus der betrieblichen Perspektive, aus einer eher fachlich orientierten Perspektive und aus der Perspektive der IT-Sicherheit. Ihre Einsatz unterscheidet sich üblicherweise je nach Größe und Komplexität des Unternehmens: Für kleinere Betriebe ist es oftmals sinnvoll, ein Werkzeug zu wählen, das alle drei Perspektiven beinhaltet und den Nachteil einer geringeren Detailtiefe in den jeweiligen Aspekten aufgrund der geringen Unternehmensgröße guten Gewissens in Kauf nehmen kann. Für größere – und daher auch komplexere – Unternehmen kann es sinnvoll sein, auf spezialisierte Tools zu setzen und mehr Aufwand für die konsistente Integration zwischen diesen Tools in Anspruch zu nehmen. Eine isolierte Verwendung einzelner Tools birgt allerdings das Risiko, dass das Unternehmen seine Prozesse nicht aufeinander abstimmt und diese ineffizient gestaltet.

Redesign oder Neukonzeption der IT-Architektur in vier Phasen
Während dieser Bestandsaufnahme wird parallel ein Verfahren etabliert, das es erlaubt, die IT Architektur nachhaltig in drei wesentliche Problemfelder zu integrieren: Change Management, Incident Management und Problem Management. Veränderungsprozesse werden hier jeweils durch die IT-Architektur – je nach Unternehmensgröße – in Form einzelner, kompetenter IT-Architekten oder eines IT-Architektur-Boards begleitet. Unternehmensspezifische ist somit zu klären, wann ein IT-Architekt in beratender Funktion in welchen Prozess involviert ist. Neben dem Anforderungsmanagement gibt es weitere Aspekte, wenn aus IT-betrieblichen Gründen Restrukturierungen vorgenommen werden, wie die Verlagerung in die Cloud oder Ausschreibungen mit neuen IT-Dienstleistern. Dort ist immer auch die IT-Architektur gefragt, in beratender Funktion oder auch mit harten Vorgaben.

Der Prozess, eine neue IT-Unternehmensarchitektur oder IT-Architektur-Management aufzusetzen, wird z. B. von spezialisierten Beratungsunternehmen durchgeführt, die dazu ein eigenes methodisches Vorgehensmodell nutzen. Dieses sichert solche Transformationen in vier Phasen ab:

1. Der Status Quo der IT Unternehmens Architektur wird schnell und effizient erfasst. Hier erfolgt die Identifikation und Dokumentation aller wesentlichen Assets
2. Direktes Abstimmen mit den Fachbereichen im Sinne eines Business IT Alignments: (Es ist entscheidend zu wissen, wohin das Unternehmen steuert, um die IT-Architektur entsprechend zu entwerfen oder zu verändern. Will ein Unternehmen bspw. international expandieren, neue Länderorganisationen gründen, hat dies substantiell andere Auswirkungen auf die IT als das bspw. das Ziel, neue Produkte möglichst effizient einzuführen oder gar den IT Betrieb grundsätzlich zu stablisieren. Deswegen gilt es immer auch, die unternehmerische Perspektive der Fachbereiche und ihrer Anforderungen einzunehmen.)
3. Mit Hilfe des etablierten EAM und den nun bekannten unternehmerischen Rahmenbedingungen wird nun eine zukünftige Zielarchitektur antizipiert.
4. Je nach Unternehmenspräferenz werden einer oder mehrere mögliche Migrationspfade erarbeitet, um vom jetzigen Zustand in den Zielzustand zu gelangen. Mit Festlegung eines Migrationspfads beginnt dann die eigentliche Aufgabe der IT Architektur auf das Zielbild zuzuarbeiten und Änderungen immer wieder konsistent und zielführend einzuplanen und zu integrieren (die Garage bleibt endlich mal längere Zeit aufgeräumt).

*Frank Schröder ist Leiter „IT Enterprise Architecture Excellence“ bei der DARCBLUE AG.