Ergebnis

Enterprise Architecture Repository als Basis für siloübergreifende Managementsysteme

Verschiedene, nebeneinanderher arbeitende Managementsysteme erschweren unternehmensweite Architekturarbeit. Ein besserer Datenaustausch zwischen den bisherigen Silos kann aber auch Vorteile für die einzelnen Fach- und IT-Domänen bringen. Zum Beispiel in den Bereichen Security und Software Asset Management. Das Cross-Business-Architecture Lab hat untersucht, wo sich eine Datensynchronisierung am ehesten lohnt und wie man sie siloübergreifend realisiert.

Silos sind der Feind des modernen Business- und IT-Managements. Ihre Abgeschlossenheit stört die Entwicklung neuer digitaler Geschäftsmodelle, erschwert Businessabläufe und blockiert Datenflüsse sowie -analysen. Das ist erkannt und deshalb wird interdisziplinäres, siloübergreifendes Arbeiten überall gepredigt.

Schaut man allerdings tiefer ins Detail, stellt sich schnell heraus, dass viele Management-Systeme ebenfalls in einem Silo-Denken verhaftet sind. Beispielsweise indem sie nur für eine oder nur bestimmte Business-Units konzipiert oder auf ein Aufgabenset optimiert sind und keine Daten mit anderen Management-Systemen austauschen. In der Konsequenz wird das interdisziplinäre Arbeiten erschwert und das Zusammenspiel mehrerer Management-Systeme sehr schwierig.

Mehr miteinander arbeiten und weniger nebeneinander

Luft nach oben also, sagte sich das Cross-Business-Architecture Lab und erarbeitete in einer Arbeitsgruppe Konzepte, wie die verschiedenen Managementsysteme eines Unternehmens besser miteinander anstatt nebeneinander arbeiten können. 

Sie erklären einerseits, wie Software Asset Management, Information Security Management, Business Process Management oder Projekt Portfolio Management von den im EA-Repository gesammelten Daten profitieren können und andererseits wie das Enterprise Architecture Management (EAM) die Daten der anderen im Unternehmen eingesetzten Management-Systeme nutzen kann.

Der Workstreamleiter und Leiter des Enterprise Architecture Managements bei Fresenius Netcare Thomas Schreiner gibt ein Beispiel dafür, wie nützlich ein Datenaustausch zwischen verschiedenen Management-Systemen sein kann. „Das Risikomanagement kann beispielsweise Daten des EA-Repositories nutzen, die das Alter von Applikationen anzeigen. Damit lassen sich Gefahren genauer bestimmen wie fehlende Sicherheits-Updates, auslaufender Hersteller-Support oder ungenügende Einhaltung gesetzlicher Vorgaben.“ Auch im Bereich Cybersecurity und im Portfolio-Management eröffnen sich Vorteile durch den Austausch. „Das Unternehmen muss wissen, welche Capabilities gebraucht werden, um bestimmte Geschäftsideen und -modelle umzusetzen. Wenn dafür die Capability Map des EA-Repositories genutzt werden kann, muss das Rad nicht neu erfunden werden.“

User-Stories verdeutlichen Vorteile

Eigentlich sollten solche Vorgehensweisen selbstverständlich sein, aber IT-, Organisations- und Business-Silos verhindern oftmals eine Integration, auch wenn es nur um das Sichtbarmachen von Listen oder Daten geht: So ist es nicht selbstverständlich, dass ein Datenschutzbeauftragter in seinem Datenschutztool eine aktuelle Liste aller IT-Systeme sieht, damit er zuordnen kann, von welchem System welche Daten verarbeitet werden. Wäre das der Fall, könnte er nicht nur Auskunft über die Zuständigkeiten für die IT-Systeme geben oder sagen, wo welche Daten liegen, sondern auch darstellen, welches System welche Daten für wen (Abteilung, Bereich, Line of Business) verarbeitet.

Ebenfalls nicht selbstverständlich ist, dass ein Applikationsverantwortlicher auf Knopfdruck visualisieren kann, von welchen IT-Komponenten seine Applikation abhängig ist.

Auch die IT-Sicherheit könnte von einer einfacheren Integration zwischen den Management-Systemen profitieren, zum Beispiel, wenn sie sehen könnte, welche Applikationen Server nutzen, auf denen Betriebssystemversionen laufen, die der Anbieter nicht mehr unterstützt. Dann könnten die Applikationsverantwortlichen automatisch über notwendige Anpassungen informiert werden.

Zehn Domänen für Integration identifiziert

Eine weitere User-Story wäre die Integration zwischen Projektplanungssoftware und EA-Repository. Für ein Projekt wäre es hilfreich, wenn die Beteiligten genau sehen könnten, welche Auswirkungen das Projekt auf die IT-Systeme hat (Belastung, Performance, zusätzliche Anforderungen). Davon profitieren sowohl die Projektverantwortlichen als auch die Architekten.

Auch für andere Domänen lassen sich die Vorteile einer Integration mit dem EA-Repository aufzeigen. Das CBA Lab hat in seinem Whitepaper insgesamt zehn Domänen ausgewählt und sie hinsichtlich ihrer Relevanz für die Analyse der EA-Integration bewertet. Ergebnis: Risk Management, Data Management, Data Privacy Management und Software Asset Management können am stärksten von der Integration mit dem EA-Repository profitieren. Config/ITIL Management sowie Organisation Management erwiesen sich ebenfalls noch als sehr relevant. 

Bei IT Cost Management, Business Process Management, Information Security Management und Projekt Portfolio Management wäre der Nutzen zwar geringer, aber da sie sehr nah an der Businessseite stehen und Teil der digitalen Wertschöpfungskette sind, wird auch hier eine größere Transparenz bedeutsamer.

Das CBA Lab hat Stakeholder, Daten-Kontexte, die zu erwartenden Wertbeiträge sowie relevante aus EAM-Sicht bereitzustellende Daten und die von EAM zu konsumierenden Daten pro Domäne zusammengestellt. In einem demnächst publizierten Whitepaper werden diese detaillierten Aufstellungen für alle zehn identifizierten Domänen dargestellt.

Integration von SAM und EA-Repository zeigt Vorteile exemplarisch

Anhand der Domäne Software Asset Management (SAM) lassen sich die Vorteile einer Integration mit einem EA-Repository exemplarisch erläutern.

Eine Integration von Software-Asset-Management-Systemen wie Snow, Matrix42 oder andere in ein zentrales EA-Repository ermöglicht viele Anwendungsfälle, die sowohl für EAM als auch für SAM einen Vorteil bieten können. Da SAM-Tools in der Regel über automatisierte Inventory-Lösungen verfügen, welche die Systemlandschaft kontinuierlich inventarisieren, ist für gewöhnlich immer der aktuellste „IST-Stand“ verfügbar. 

Würde dieser automatisch mit dem EA-Repository abgeglichen, stünden die Daten ohne manuelle Pflege tagesaktuell für Auswertungen zur Verfügung. So könnten mithilfe der SAM-Daten z. B. das Technologierisiko für Applikationen ermittelt werden, oder auch die Business-Kritikalität von IT-Komponenten anhand der Applikations-Kritikalität beurteilt werden. „Wenn ich weiß, wie alt meine Infrastruktur für geschäftskritische Applikationen ist, kann ich das Risiko einer Legacy-Falle oder erhöhter Supportkosten viel genauer abschätzen“ erklärt Thomas Schreiner.

Dabei ist es nicht ratsam, alle Daten aus dem SAM-Tool zu übernehmen. Sie sind zum größten Teil nicht relevant für das EA-Repository. Hier sollten die für eine Integration relevanten Daten vorab definiert werden. Relevant könnten hier Daten zu den verwendeten Betriebssystemen, Datenbanken und zu Applikation-Runtimes sein oder auch aggregierte Werte, wie die Anzahl an Installationen. Weniger relevante Daten können z. B. Client-Applikationen wie VLC, Firefox oder installierte Smartphone-Apps sein, welche aus EA-Sicht in der Regel wenig bis keine Relevanz haben.

Einige SAM-Tools sind darauf spezialisiert, Cloud-Umgebungen wie Azure, AWS, GCP auszulesen. Werden diese Daten ebenfalls mit dem EA-Repository kombiniert, ergeben sich weitere Governance- und Steuerungsoptionen für die Verwendung der Cloud-Umgebungen.

Ganz praktisch mit Power-Shell-Script und REST-API

Da durch die automatisierten Scans immer der Ist-Stand erfasst wird und auch teilweise SaaS oder Cloud-Anwendungen erkannt werden, kann eine EA-Integration auch ein mächtiges Werkzeug sein, um Einblicke in die „Schatten-IT“ zu bekommen und auch Maverick-Buyings aufzudecken. 

Als Beispiel für die praktische Umsetzung hier das Vorgehen bei einem Datenimport aus dem SAM-Tool Snow in das EAM-Werkzeug LeanIX. Bei den Daten handelt es sich um erkannte Server, deren jeweiliges Betriebssystem, Lifecycle, Virtualisierungsplattform und andere automatisch erfasste Daten. Die Integration wird über ein PowerShell-Script realisiert, welches die Daten aus Snow per REST-API abruft. 

Diese Informationen werden dann mit Daten aus dem Active-Directory angereichert, um den Lifecycle des Servers abbilden zu können. Die gesammelten Informationen werden daraufhin in ein LDIF-Format (LeanIX Data Interchange Format) transformiert und an die Integration-API übergeben. Anhand der dort hinterlegten Prozessoren werden die Daten dann eingelesen und auf Fact-Sheets abgebildet. „Das Verfahren ist nicht sehr aufwändig. 

Doch durch die Brücke zwischen SAM-Tool und EA-Repository ergeben sich diverse Vorteile. Im Procurement erhöht sich die Reaktionsfähigkeit bei Ende des Lebenszyklus. Außerdem erhöht sich durch die automatische Ergänzung der Applikationen um die zugrunde liegenden Softwareprodukte der Automatisierungsgrad“, erklärt Schreiner.

Für die Auswahl der passenden technischen Integrationswerkzeuge und -methoden gibt die Arbeitsgruppe des CBA Lab Unternehmen verschiedene Kriterien an die Hand. Als Faustregel kann gelten: Je häufiger und je mehr Daten ausgetauscht werden sollen, desto höher ist die Notwendigkeit einer technischen Integration durch Scripts, ESB, Middleware oder APIs. Allerdings sind dafür auch die Implementierungsaufwände und die Skillvoraussetzungen deutlich höher als bei einer manuellen Integration oder wenn RPA-Bots den Datenaustausch bewerkstelligen.

Datenqualität und andere Voraussetzungen

Um Schiefstände und Asynchronitäten zu vermeiden, wenn mehrere Systeme miteinander synchronisiert werden, ist es vorteilhaft, das jeweils führende System zu definieren.

Ein großer Vorteil einer Enterprise Architecture Management-Funktion ist das Schaffen einer verbindlichen, unternehmensweiten Sprache, die ein gemeinsames Verständnis schafft und Missverständnisse vermeidet. Dennoch kann es bei der Integration mit Drittsystemen zu Konflikten kommen, da ein Begriff in der fachlichen Domäne des Zielsystems anders verwendet wird als im Quellsystem (z. B. „Applikation“ = „Installiertes Programm“ vs. „Geschäftsapplikation“). Auch ist die Granularität oder der Scope der Daten oftmals unklar.

Der Begriff „Prozess“ könnte z. B. sowohl für alle Geschäftsprozesse des Unternehmens stehen als auch für die Menge aller Verarbeitungstätigkeiten, die im Verfahrensverzeichnis des Datenschutzes dokumentiert sind. Oft gibt es auch abweichende Begriffe von Attributen, z. B. „Kritikalität“, „Risiko“, sowie abweichende Rollen und Verantwortlichkeiten. Diese potenziellen Konflikte müssen zwingend vor der Synchronisation geklärt werden, um zu garantieren, dass die Erwartungen beider Parteien an den Datenaustausch erfüllt werden.

Unabhängig von der technischen Einrichtung der Synchronisation empfiehlt es sich, im Dialog zwischen beiden beteiligten fachlichen Domänen auszuarbeiten, innerhalb welcher Prozesse die betroffenen Datensätze angelegt, verwendet, verändert, gelöscht und möglicherweise auch mit Dritt-Elementen verknüpft werden können. Eine End-to-End-Sicht auf den gesamten Lebenszyklus eines Elements ermöglicht die Identifikation von Konsistenzproblemen und bisher unerkannten Abhängigkeiten.

„Es ist klar geworden, dass EAM noch besser funktioniert, wenn es siloübergreifend implementiert wird. Die von uns vorgeschlagene und für zehn Domänen durchdeklinierte Repository-Integration zeigt, wie das praktisch funktionieren kann. Wir belegen, dass IT- und Fachdomänen, die sich der Integration öffnen, selbst klare Vorteile daraus ziehen“, resümiert Dr. Karsten Schweichhart, Vorstandsmitglied des CBA Lab.