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?

Allzu oft finden wir Architekten in Stabsstellen, die sich mehr oder weniger intensiv mit Listen und Bebauungsplänen beschäftigen, die vor allem Dokumentationszwecken dienen und die bei wichtigen Investitions- oder Sourcing-Entscheidungen kaum eine Rolle spielen. Warum ist das so?

Architekturprojekte sind zu oft gescheitert. Mit dem Begriff »Architektur« werden verschiedene Dinge assoziiert, die dann gern vermischt werden. Schnell verbindet man mit Architektur gewagte Formensprache und in der eigenen Wahrnehmung skurrile Entwürfe von Bauwerken. Ein Architekt ist jemand, der plant und gestaltet. Übertragen auf die Unternehmensarchitektur heißt das, hier wird ein Unternehmen geplant und gestaltet und der Unternehmensarchitekt ist der oberste Planer und Gestalter. Damit das alles gut funktioniert, gibt es das Architekturmanagement beziehungsweise das Enterprise Architecture Management (EAM). Und EAM wird gern als die zentrale Managementdisziplin im IT-Management insgesamt dargestellt. Spätestens hier stellt sich allerdings die Frage nach Anspruch und Wirklichkeit, zumal es durchaus erfolgreiche IT-Abteilungen ohne ausgeprägtes EAM gibt.

Und dann gibt es in der mittlerweile langen IT-Geschichte zahlreiche Beispiele für gescheiterte Architekturprojekte, die über Jahre Unsummen an Ressourcen verschlungen und sehr viel Papier produziert haben, deren praktischer Nutzen aber bestenfalls überschaubar geblieben ist. Wo ist der Business Case für EAM?

Es ist nicht so, dass für jede planerische Entscheidung ein Enterprise-Architekt zu Rate gezogen werden muss. Hier drängt sich der Vergleich zum Hausbau auf. Das besondere Gebäude kommt ohne Architekten nicht aus. Für das normale Einfamilienhaus ist oft ein Handwerksmeister oder ein Bautechniker berechtigt, die erforderlichen Planungsdokumente zu unterschreiben, bei allen anderen Planungen kann dies auch der Bauingenieur tun. Die Bauten sind deswegen nicht zwangsläufig schlechter.

Bezogen auf die IT-Architektur heißt das, dass eine IT-Abteilung durchaus eine Software-Auswahl oder eine Plattformentscheidung treffen kann, ohne dass es dazu eines Enterprise-Architekten bedarf. Genau wie der Praktiker am Bau hat der IT-Experte ausreichend Wissen, um für alltägliche Fragestellungen die richtige Entscheidung zu treffen.

EAM ist ein Werkzeugkasten. Heißt das jetzt, dass EAM entbehrlich ist? Nein, auf keinen Fall! Wir plädieren allerdings dafür, einen pragmatischen Blick auf EAM zu werfen. Eine Unternehmensarchitektur ist im Kern die Beschreibung der Strukturelemente eines Unternehmens und ihres Zusammenwirkens. Und EAM stellt die dafür erforderlichen Werkzeuge und Vorgehensmodelle zur Verfügung. So gesehen kann man EAM als einen Werkzeugkasten verstehen, der eine große Vielfalt an Werkzeugen für die unterschiedlichsten Einsatzfälle bereitstellt.

Und aus diesem Werkzeugkasten muss sich jede IT-Abteilung das nehmen, was für die konkrete Situation nötig ist. Analog zum Maschinenbau wird nicht immer die hochmoderne Fabrik benötigt, um etwa ein Gehäuseteil in höchster Präzision und Festigkeit anzufertigen, oft genügt ein Teil aus einem 3D-Drucker den Anforderungen. Allerdings muss in beiden Fällen eine Vorstellung davon bestehen, wie das Teil auszusehen hat und welche Funktion es erfüllen soll.

Das heißt bezogen auf die IT, dass jede IT-Abteilung heute EAM in irgendeiner Form betreibt. Oder drastischer dargestellt: es gibt keine IT ohne EAM, weil jede Entscheidung in Bezug auf Infrastruktur oder auf Software immer auch eine architektonische Entscheidung ist. So wird etwa ein Sourcing-Schnitt entwickelt, der beschreibt, was intern und was extern geleistet wird und wo die Schnittstellen sind. Oder es werden Pläne zur Einführung oder Ablösung von Anwendungen gemacht. Dies alles sind Werkzeuge aus dem EAM-Werkzeugkasten und es ist unerheblich, ob EAM dabei organisatorisch verankert ist oder die Werkzeuge durch das jeweilige Projektteam genutzt wurden. Die entscheidende Frage ist: Sind die derzeit genutzten Werkzeuge angemessen oder besteht Anpassungsbedarf?

Und da kann durchaus Handlungsbedarf bestehen. Die verbreitete Nutzung der Cloud-Dienste hat einen massiven Umbau der IT zur Folge. Neue Anwendungen und Services sind schnell zu integrieren. Die Komplexität steigt. Die Gewährleistung der IT-Sicherheit verlangt ein neues Herangehen – um nur ein paar der aktuellen Themen auszuwählen. All das beinhaltet Architekturentscheidungen, die auf Grundlage einer möglichst vollständigen Datenbasis unter Einbeziehung der Anforderungen aller Beteiligten und Betroffenen zu treffen sind. Stehen hierfür die richtigen Werkzeuge zur Verfügung und ist das Unternehmen in der Lage, diese Werkzeuge auch zu nutzen?

Hier empfiehlt sich eine schonungslose Bestandsaufnahme, aus der ein möglicher Handlungsbedarf klar hervorgeht.

Pragmatisches Vorgehen ist gefragt. Ist der neue Handlungsdruck die Rechtfertigung für das nächste EAM-Projekt? Schaut man sich TOGAF als ein weit verbreitetes Rahmenwerk für den Aufbau und die Nutzung von EAM an, dann findet man dort 10 Schritte mit über 50 Ergebnistypen, die für die Entwicklung einer Unternehmensarchitektur erforderlich sind. Hier ist sehr viel Architekturerfahrung eingeflossen, die in großen und komplexen Organisationen gesammelt wurde. Es gibt viele Beispiele und Referenzarchitekturen. Aus all diesen Vorlagen lässt sich ein großangelegtes EAM-Projekt herleiten. Erfahrungsgemäß wird es allerdings schwierig, hier einen handfesten Business Case darzustellen. Oft hilft man sich dann mit mittelbarem Nutzen wie etwa der schnelleren Einführung neuer Softwarekomponenten oder der höheren Transparenz bei der Beantwortung von Compliance-Anfragen. Viele Unternehmen halten – mit Recht – solche Projekte für nicht mehr zeitgemäß.

Unsere Erfahrung zeigt, dass es gerade für mittelständische Unternehmen sinnvoller ist, Architekturkompetenz schrittweise dort aufzubauen, wo sie benötigt wird. Mit den Ergebnissen der Bestandsaufnahme kann schnell der Handlungsbedarf priorisiert werden. Es werden die Themen identifiziert, die den größten messbaren Nutzen liefern. Diese Themen bilden den Product Backlog. Eine agile Vorgehensweise stellt sicher, dass schnell nutzbare Ergebnisse vorliegen. Das gesamte Vorgehen orientiert sich daran, bestehende Konzepte und schon vorhandene Arbeitsergebnisse, die beispielsweise im Zusammenhang mit einer Sourcing-Entscheidung bereits erarbeitet wurden, zu nutzen.

So werden bedarfsgerecht geeignete Werkzeuge aus dem großen EAM-Werkzeugkasten ausgewählt und eingeführt. Die Aufwände für EAM bleiben überschaubar und der Nutzen wird schnell greifbar.

Das Ziel ist eine angemessene Architekturkompetenz. Welches Niveau der Architekturkompetenz ist aber für mein Unternehmen das richtige? Je nach Umfeld des Unternehmens sind unterschiedliche Aspekte wichtig. Während beispielsweise in einem Unternehmen dringender Handlungsbedarf in der Anwendungskonsolidierung und im Application Lifecycle Management besteht, muss sich ein anderes Unternehmen vielleicht auf die Herausforderungen im Integrationsmanagement konzentrieren. Auf die jeweiligen Schwerpunkte gilt es sich zu konzentrieren. Dabei geht es, wie oben beschrieben, nicht nur um Vorlagen und Prozesse, sondern auch um die organisatorische Verankerung beziehungsweise Governance. Diese Frage stellt sich nicht nur zwischen zentraler und dezentraler IT oder zwischen IT und Business, sondern auch zwischen Unternehmen und Dienstleister. Mit jeder Sourcing-Entscheidung wird auch die Frage beantwortet, welche architektonischen Fragen der Dienstleister und welche Fragen die IT des Auftraggebers entscheiden kann. Die sich hier ergebende Linie ist nicht dauerhaft konstant, sondern wird sich mit zunehmender Zahl von Dienstleistern verschieben. In der Regel wächst damit auch der Anspruch an Architekturkompetenz im eigenen Haus, der nicht ohne Weiteres zu befriedigen ist. Somit stellt sich auch hier die Frage des Sourcing von Architekturdienstleistungen (siehe dazu auch: manage it 1-2 2020: Architecture as a Service [1]).

Fazit: EAM ist ein nützliches und unverzichtbares Werkzeug. Fragestellungen der Integration und des Zusammenwirkens von Prozessen, Anwendungen und Daten werden im Rahmen des Siegeszugs von Plattformen aller Art für jedes Unternehmen häufiger zu entscheiden sein. Die ökonomische Relevanz von Fehlentscheidungen lässt sich nur im Nachgang feststellen. Umso wichtiger ist eine ausreichende Architekturkompetenz. EAM bietet die dafür notwendigen Werkzeuge. Die sichere Auswahl und souveräne Handhabung dieser Werkzeuge in Verbindung mit der passgerechten Nutzung externer Kompetenz wird auch in Zukunft entscheidend zum Unternehmenserfolg beitragen.

Dr. Ulf Prengemann,
LEXTA CONSULTANTS GROUP,
Berlin,

www.lexta.com

[1] https://ap-verlag.de/architecture-as-a-service-ein-plaedoyer/58740/

Illustration: © cepera /shutterstock.com

1308 Artikel zu „Architektur IT“

NEWS | IT-SECURITY | AUSGABE 5-6-2020 | SECURITY SPEZIAL 5-6-2020

IT-Sicherheit im Home Office – Macht Zero-Trust-Architektur die Cloud sicher?

19. Juni 2020

Cyberkriminelle nutzen die aktuelle Unsicherheit rund um die weltweite Corona-Pandemie. Die Folge sind umfangreiche Angriffe auf Industrieunternehmen. Bevorzugte Opfer: Mitarbeiter im Home Office. Können hochsichere Cloud-Dienste für den Unternehmenseinsatz Abhilfe schaffen?

Dr. Ulf Prengemann, LEXTA CONSULTANTS GROUP, Berlin,

[1] https://ap-verlag.de/architecture-as-a-service-ein-plaedoyer/58740/

1308 Artikel zu „Architektur IT“

Dr. Ulf Prengemann,
LEXTA CONSULTANTS GROUP,
Berlin,