Illustration: Absmeier Geralt

Eigentlich sind Managementsysteme ein Segen. Aber wenn sie rein siloorientiert sind und keine Daten miteinander austauschen, können sie durchaus übergreifende Prozess- und Geschäftsmodelle bremsen. Das Cross-Business-Architecture Lab (CBA Lab) hatte nun die Idee, die verschiedenen Managementsysteme auf Basis des Enterprise Architecture Repository zu integrieren. Der erste Schritt dazu war, zu untersuchen, wo sich Datensynchronisierung lohnt und wie man sie siloübergreifend realisiert.

Siloübergreifendes Arbeiten gilt als effektiv und schnell – vorausgesetzt Unternehmen verfügen über eine entsprechende Organisation, Kultur und nicht zuletzt Technologie, die diese Art des Arbeitens unterstützt. Leider ist letztere in puncto Managementsysteme häufig nicht vorhanden. Viele bleiben dem Silo-Denken verhaftet und können im Extremfall die Entwicklung neuer digitaler Geschäftsmodelle stören oder übergreifende Datenflüsse und -analysen blockieren. Sie sind zum Beispiel nur für eine oder nur für bestimmte Business-Units konzipiert oder auf ein Aufgabenset optimiert. Außerdem können sie keine Daten mit anderen Managementsystemen austauschen. In der Konsequenz wird das interdisziplinäre Arbeiten erschwert und das Zusammenspiel mehrerer Management-Systeme sehr schwierig.

Statt nebeneinander mehr miteinander

Dieser Kooperationsschwäche wollte das Cross-Business-Architecture Lab zu Leibe rücken. In einer Arbeitsgruppe entwickelt es daher Konzepte, wie die verschiedenen Managementsysteme eines Unternehmens besser miteinander anstatt nebeneinander arbeiten können. Die Arbeitsgruppe erläutert, wie einerseits Software Asset Management, Information Security Management, Business Process Management oder Projekt Portfolio Management von den im EA-Repository gesammelten Daten profitieren können und wie andererseits das Enterprise Architecture Management (EAM) die Daten der anderen im Unternehmen eingesetzten Managementsysteme nutzen kann.

User-Stories beweisen den Nutzen

Auch wenn solche Vorgehensweisen selbstverständlich sein sollten, verhindern IT-, Organisations- und Business-Silos oftmals die Integration, auch wenn es nur um das Sichtbarmachen von Listen oder Daten geht: So ist es bisher leider nicht normal, dass ein Datenschutzbeauftragter in seinem Datenschutztool eine aktuelle Liste aller IT-Systeme sieht, damit sich schnell klären lässt, welches System welche Daten verarbeitet. Wäre das der Normalfall, könnte der Datenschützer 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 sieht, in welchem Verhältnis »seine« Applikation zu bestimmten Infrastrukturkomponenten steht – sprich von welchem Server und welchem Speicher sie abhängig ist.

Die einfachere Integration zwischen Managementsystemen brächte auch die IT-Sicherheit voran. Zum Beispiel, wenn die Security-Admins erkennen könnten, welche Geschäftsapplikationen eine Betriebssystemversion verwenden, die der Anbieter nicht mehr unterstützt. Dann könnten die Applikationsverantwortlichen automatisch über notwendige Anpassungen informiert werden.

Zehn Domänen würden profitieren

Auch die Integration zwischen Projektplanungssoftware und EA-Repository zeigt den Nutzen. Für ein Projekt wäre es hilfreich, wenn die Beteiligten genau sehen könnten, welche Auswirkungen das Projekt auf die IT-Systeme hat (Schnittstellen, Serverlandschaft, Rollout auf weitere Organisationen). 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 könnte bis in Recruiting-Systeme hineinreichen. Der Ausbau bestimmter IT-Systeme oder IT-Architekturen könnte den Personalbedarf in diesem Bereich erhöhen. In einem Unternehmen mittlerer Größe ist eine bessere Integration der verschiedenen Management-Systeme nützlich, aber vielleicht nicht notwendig. In großen, weitverzweigten Unternehmen sieht das anders aus. Dort muss Transparenz hergestellt werden, sie ist anders als in überschaubaren Strukturen nicht mehr per se gegeben.

Das CBA Lab hat in seinem Whitepaper insgesamt zehn Domänen ausgewählt und geprüft, ob sie in Bezug auf eine EA-Integration relevant sind. 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. Configuration und IT Service 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, Datenkontexte, 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.

Exemplarische Vorteile

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 anderen 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. SAM-Tools mit entsprechenden Routinen verfügen in der Regel immer über einen aktuellen IST-Stand der Systemlandschaft. Wenn man dem EA-Repository diese Daten automatisiert zur Verfügung stellt, können sie tagesaktuell ausgewertet werden. So können mithilfe der SAM-Daten z. B. das Technologierisiko für Applikationen ermittelt oder auch die Business-Kritikalität von IT-Komponenten anhand der Applikations-Kritikalität beurteilt werden.

Allerdings ist es ratsam, nicht alle Daten aus dem SAM-Tool zu ziehen, sondern hier sollten die relevanten Daten vor einer Integration definiert werden. Relevant könnten hier Daten zu den verwendeten Betriebssystemen, Datenbanken und zu Application-Runtimes sein oder auch aggregierte Werte, wie die Anzahl an Installationen. Weniger relevante Daten können etwa 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.

Einblicke in die Schatten-IT

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.

Für die Auswahl der passenden technischen Integrationswerkzeuge und -methoden gibt das CBA Lab Unternehmen verschiedene Kriterien an die Hand. Dabei lautet die Faustregel: 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. Das heißt aber auch, Implementierungsaufwände und Skill-Voraussetzungen sind deutlich höher als bei einer manuellen Integration oder wenn RPA-Bots den Datenaustausch bewerkstelligen.

Ein System sollte führen

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

Eine Enterprise-Architecture-Management-Funktion schafft eine verbindliche, unternehmensweite Sprache. Diese vermeidet Missverständnisse durch ein gemeinsames Verständnis. 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 (beispielsweise »Applikation« = »Installiertes Programm« vs. »Geschäftsapplikation«). Auch sind Granularität oder der Scope der Daten oftmals unklar. Der Begriff »Prozess« könnte 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, etwa »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 den jeweils beteiligten fachlichen Domänen auszuarbeiten, innerhalb welcher Prozesse die betroffenen Datensätze verarbeitet 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.

»Unsere Arbeit hat deutlich gezeigt, dass EAM noch besser funktioniert, wenn es siloübergreifend implementiert wird. Die von uns vorgeschlagene und für verschiedene 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.

https://cba-lab.de/so-arbeiten-wir.html

NEWS | BUSINESS | STRATEGIEN | AUSGABE 7-8-2020

Enterprise Architecture Management – Übertriebener Formalismus oder nützliches Werkzeug?

17. August 2020

Gibt es in Ihrem Unternehmen einen IT-Architekten oder gar ein Architektur-Team? Wenn Ihre Antwort »nein« heißt, steht Ihr Unternehmen damit nicht allein da. Und falls Sie einen Architekten haben: Wie wichtig ist er oder sie für den Erfolg der IT und des Unternehmens a) in seiner eigenen Wahrnehmung und b) in der Wahrnehmung des Unternehmens?