Im Blog-Post zu unseren Objectives & Key Results (OKR) haben wir die geplanten Maßnahmen an unserer Anwendungslandschaft bereits näher erläutert. Wir arbeiten an neuen Web- und Cloud-Applikationen und wollen mittels Standards und Automatisierung für eine höhere Effektivität sorgen. Dabei ist es wichtig, den Überblick über die IT-Landschaft zu behalten und auch zukünftige Entwicklungen mit ihren jeweiligen Konsequenzen darstellen und bewerten zu können.

Zu diesem Zweck haben wir uns entschieden, die Lösung “LeanIX Enterprise Architecture Management” übergreifend und einheitlich einzusetzen. Unsere Erfahrungen mit der Lösung möchten wir in diesem Beitrag mit Euch teilen.

Die Problemstellung im Alltag

In der täglichen Arbeit benötigen wir in der Anwendungsentwicklung wie auch jede andere IT-nahe Einheit regelmäßig einen Überblick über relevante Informationen zu unseren Applikationen für unterschiedliche Zwecke, wie zum Beispiel:

• ein Projekt bewertet die Optionen zur Migration von Applikationen in die Cloud,
• ein Sicherheitsvorfall erfordert eine Bewertung aller Applikationen hinsichtlich deren Betroffenheit oder
• die Architektur der IT-Landschaft soll weiter ausgestaltet werden.

In diesen Fällen stellen sich gewöhnlich die immer selben Fragen:

• Wer ist verantwortlich für eine bestimmte Applikation?
• Wer kann fachlich bzw. technische Auskünfte geben?
• Wie kritisch ist eine Anwendung für das Unternehmen?
• Wie hängt eine Anwendung mit anderen Komponenten zusammen?

Eine dezentrale, Anwendungs-bezogene Dokumentation reicht für die fundierte Beantwortung solcher Fragen oft nicht aus. Vielmehr werden sogar zu viele redundante Informationen gepflegt, ohne dass ein aktueller Gesamtüberblick existiert.

Wir haben uns daher entschlossen, mit LeanIX ein unternehmensweites Applikations-Repository zu etablieren, das kontinuierlich aktuell gehalten wird und für unterschiedliche Zwecke auswertbar ist.

Das zentrale Applikations-Repository

Vor diesem Hintergrund haben wir uns auf die Suche nach einer Best-in-Class Lösung am Markt begeben und uns für die Software “LeanIX Enterprise Architecture Management” entschieden.

In LeanIX werden Applikationen in Form von Datenblättern beschrieben. Neben einem eindeutigen Namen für Applikationen und einer kurzen, prägnanten Beschreibung werden auch weitere Informationen vorgehalten, die immer wieder benötigt werden. Ein prominentes Beispiel ist die Geschäftskritikalität, die uns in der Planungsphase einer neuen Anwendung unter anderem als Indikator für die erforderliche Verfügbarkeit dient und auch in weiteren Betriebsabläufen, wie dem Incident-Managment, bei der Behebung von Störungen von großem Nutzen ist.

Auch beim Lifecycle-Management der Anwendungen ist LeanIX als Übersicht sinnvoll einsetzbar. Einige Applikationen befinden sich in der Planung oder werden zurzeit implementiert, andere werden aktiv von den Anwendern genutzt, wieder andere befinden sich in der Ausgliederungsphase (End of Life) und haben bereits eine Nachfolgeapplikation. An solche Informationen lassen sich beispielsweise Deprovisionierungsprozesse anschließen.

Diese und weitere wertvolle Informationen erzeugen einen echten Mehrwehrt nicht nur für die Anwendungsentwicklung, sondern auch für viele unserer Unternehmensbereiche. Uns in der Anwendungsentwicklung helfen Angaben zur fachlichen Zuständigkeit sowie zum Lebenszyklus beispielsweise dabei, angeforderte Features gemeinsam mit dem IT-Produktmanagement den “richtigen” Anwendungen zuzuordnen und somit Investitionen in Alt-Anwendungen weitestgehend zu vermeiden.

Der Weg zum unternehmensweiten Applikationsmanagement

Wir sind bei der Etablierung eines übergreifenden Applikationsmanagements nicht auf der “grünen Wiese” gestartet. In verschiedenen Organisationseinheiten waren aufgrund der dort gegebenen Herausforderungen bereits eigene Lösungen entstanden, die eine für ihren jeweiligen Anwendungsfall passende Teil-Beschreibung der Landschaft darstellten. So wurden beispielsweise durch das Incident-Management eigene Datenbanken erstellt und gepflegt, aus denen u.a. die Kritikalität der Anwendungen hervorgeht. Dabei ergeben sich verschiedene Herausforderungen.

Die Aktualität und Einheitlichkeit von Informationen in den verteilten Systemen über die jeweiligen Organisationseinheiten hinweg zu wahren, gestaltete sich schwer und ineffizient. Alle Informationen auf demselben Stand zu halten, war praktisch nicht möglich.

Ein weiteres Problem ist die Definition einer Applikation. Viele Organisationseinheiten arbeiten mit einem unterschiedlichen Applikationsbegriff. Ein Anwender versteht unter “Applikation” etwas anderes als ein Entwickler oder der Infrastrukturbetrieb. Stellenweise nutzen verschiedene Einheiten sogar unterschiedliche Benamungen für dieselbe Applikation. So wird beispielsweise der Projektname als Synonym für die im Projekt entstandenen eigentlichen Anwendungen verwendet, während andere Einheiten die Anwendungen mit Blick auf Kunden und das entsprechende Marketing umbenennen. In Einzelfällen werden diese Benamungen aber nicht mehr von allen betroffenen Einheiten übernommen und nachgepflegt. Durch solche Effekte gibt es überschneidende Informationen in den unterschiedlichen Systemen zu neuralgischen Punkten, ohne dass diese übergreifend bemerkt werden.

Mehrwerte durch Integration des Applikations Repositorys zu anderen Systemen

Um diese Hürden bereits im Keim zu vermeiden, haben wir gemeinsam mit den involvierten Einheiten einen unternehmensweit einheitlichen Applikationsbegriff mit entsprechender Name-Policy definiert. Wir haben uns dazu entschieden, die Applikation unter dem Namen zu pflegen, unter dem der Endanwender sie kennt. Im Sinne einer effektiven Suche im zentralen Applikations-Repository, haben wir daneben die Hinterlegung von Aliasen ermöglicht. Hier können weitere Synonyme hinterlegt werden, unter denen eine Anwendung im Unternehmen bekannt ist.

Wir haben die Erfahrung gemacht, dass oftmals die Informationen, die zur Applikation in den verschiedenen Systemen hinterlegt waren, für unsere Belange nicht ausreichten. Zahlreiche Fragestellungen erfordern die Zusammenführung der Informationen aus verschiedenen Quellen.

Über LeanIX können diese separat bestehenden Informationen miteinander verknüpft werden. Anhand einer eindeutigen Applikations-ID aus dem unternehmensweiten Applikations-Repository kann ein Mapping stattfinden.

So wird aus LeanIX der aktuelle Applikationsverantwortlich automatisch ausgelesen und als Tag an die Azure Resource Gruppe gehängt. Damit ist es dann möglich, dass der Cloud Betrieb im Incident-Fall sehr schnell die Zuständigkeiten zuordnen kann.

Des Weiteren ist es anhand des Azure Tags für Kostencontrolling möglich die Kosten den richtigen Personen zuordnen. Es werden einmal im Monat die Kosten aggregiert und eine Kostenaufstellung den verantwortlich zugeschickt.

Durch die Integration weiterer Systeme wie GitHub lassen sich die Quellcode-Repositories zu Applikationen zuordnen. Durch das automatisierte Auslesen aller Software-Repositories und Import nach LeanIX lässt sich eine Relation von Softwarekomponenten zur fachlichen Anwendung herstellen. Die zentralisierte Pflege von Verantwortlichkeiten in LeanIX hilft im Incidentfall wie beispielsweise Log4J die richtigen Personen zum Schließen der Sicherheitslücken zu aktivieren.

Die Pflege der Informationen

Die Pflege der Informationen gelingt als Gemeinschaftsleistung der gesamten IT - ähnlich der Collaboration in einem Wiki . Dazu haben wir jedem Mitarbeiter der IT auf das zentrale Repository berechtigt, um für alle die Möglichkeit zu schaffen, die hier hinterlegten Informationen zu lesen und bei Bedarf zu ergänzen bzw. zu aktualisieren. Neben diesem Community-Ansatz schaffen wir über Pflichtfelder im Repository die nötige Verantwortlichkeit und Verbindlichkeit. So muss jede Applikation eine/n Verantwortliche/n und technische sowie fachliche Ansprechpartner besitzen. Die zugewiesenen Ansprechpartner sind primär für die Pflege ihrer Datenblätter verantwortlich. Um die Aktualität der Daten zu gewährleisten, besitzen die Datenblätter ein Qualitätssiegel, das in einem regelmäßigen Turnus planmäßig gebrochen wird und von den Verantwortlichen nach Prüfung der Aktualität erneut zu setzen ist.

Überall dort, wo eine Automatisierung möglich ist, wollen wir die Ansprechpartner bei der Pflege entlasten. So sollen die einzelnen Komponenten einer Applikation möglichst automatisch aus den verschiedenen Quellsystemen ausgelesen und im zentralen Repository bereitgestellt werden. Hier haben wir beispielsweise Kubernetes und GitHub an das zentrale Repository angeschlossen, sodass Informationen über die dort hinterlegte Software nicht mehr mit hohem Aufwand händisch im zentralen Repository eingepflegt werden müssen. Stattdessen werden relevante Detail-Informationen zu den Applikationen automatisiert von GitHub und Kubernetes ausgelesen und im LeanIX-Repository hinterlegt. So ist sichergestellt, dass die Informationen im Repository stets eine hohe Datenqualität aufweisen.

Wir möchten zukünftig weitere qualitätssichernde Maßnahmen etablieren. Hierzu haben wir geplant, ein Reporting mittels Key Performance Indicators (KPI) aufsetzen, das einen Überblick über die Datenqualität im Applikations-Repository gibt. Mit einem Dashboard wollen wir verschiedene KPIs, wie bspw. Datenblätter ohne Verantwortliche, genauso wie fehlende Geschäftskritikalität oder Angabe des Lebenszyklus der Applikationen darstellen. Solche Dashboards können in der Organisation genutzt werden, um den Handlungsbedarf zur Verbesserung der Datenqualität übergreifend zu identifizieren und zu veranschaulichen.

Die Darstellung des Repositorys als Applikationslandkarte

Ein weiterer Nutzen des zentralen Applikations-Repositorys ist die Erzeugung einer grafisch aufbereiteten IT-Landkarte von aktueller Anwendungslandschaft und geplanter Ziel-Landschaft. Eine solche Landkarte - oder im Einzelfall auch Teile davon - sind erfahrungsgemäß eine sehr effektive Diskussionsgrundlage für IT nahe als auch ferne Mitarbeiter, in welchem Umfeld sie sich bewegen, wie sich das Umfeld verändern wird und in welche Richtung sich die IT-Landschaft insgesamt bewegt. Dies sorgt für Alignment weit über die IT-Organisation hinaus.

Für stärker technische Aspekte ist ein Drill Down in die IT-Landkarte möglich, um eine detaillierte Sicht auf die Applikationen zu erhalten. Die IT-Architektur nutzt den Zoom-In für detailliertere Informationen über den technischen Aufbau einzelner Anwendungen und deren Abhängigkeiten zu anderen Systemen. Auf Grundlage dieser Informationen können die Steigerung der Softwareresilienz und weitere technische Verbesserung abgeleitet werden.

Beim Einführen neuer fachlicher Funktionen gibt die IT-Landkarte mit der Zuordnung von Anwendungen zu Geschäftsfertigkeiten einen Überblick welche Anwendungen geeignet für die Implementierung der neuen fachlichen Funktion sind oder wo es bereits Überschneidungen mit ähnlichen Funktionalitäten gibt. Dies hilft die fachliche Architektur der IT-Landkarte zu ordnen und den Nutzen für die Anwender zu verbessern.

Fazit

Ein einheitliches, zentrales und stets aktuelles Repository als Golden Source für unsere Anwendungslandschaft hat sich in der Praxis bisher für uns als effektives Mittel zur Erreichung unserer Ziele bestätigt. Nicht von der Hand zu weisen ist allerdings, dass ein solches Tool nur so gut ist, wie die eingepflegten Informationen. Zur vollen Wirksamkeit eines solchen Tools bedarf es daher - vor allem initial - des gemeinschaftlichen Committments aller Applikations-Verantwortlichen, Informationen zentral anzuliefern und zu pflegen und keine dezentralen Listen zu unterhalten. Dieses Committment nachzuhalten, in die entsprechenden Prozesse einzupflegen und auch letzte Widerständler einzufangen, ist ein essenzieller Faktor für den effektiven und effizienten Einsatz. Dieser Aufwand wird mit fortschreitender Optimierung von Informationsqualität und -quantität erfahrungsgemäß geringer, da der Nutzen ab einem gewissen Level alle Beteiligten überzeugt.

In Zukunft möchten wir die Integration und Automatisierung mit weiteren Systemen ausbauen, um die dargestellten Mehrwerte für die gesamte Organisation weiter zu steigern und Aufwände zu reduzieren.

Wie ist Eure Erfahrung mit der Einführung eines Repositorys für das Enterprise Architecture Management? Wir freuen uns auf den Erfahrungsaustausch!