Enterprise Architecture Management (EAM) im digitalen Wandel

Wie kommt man vom Wasserfall-basierten Vorgehen zum agilen Enterprise Architecture Management?

Was ist Enterprise Architecture Management?

Heutzutage ist ja schon fast jeder in einem IT-Konzern ein Architekt. Eine der Aufgaben von Enterprise Architecture Management (kurz EAM) ist die Schaffung einer einheitlichen Konzernsprache, wenn es um … ja wie heißen sie denn, diese „Dinger“ … Anwendungen, Systeme, Softwareprodukte, … geht.

Warum? Es geht darum, diese „Dinger“ über ihren gesamten Lebenszyklus auf Basis einer schlüssigen Technologievision zu begleiten, Innovationspotentiale zu erkennen, Technologierisiken aufzuzeigen, eine Technologiestrategie abzuleiten.
Und oft scheitert EAM bereits an dieser Konzernsprache, weil die meist abstrakten Aufträge samt abstrakter oder wirtschaftlicher Business-Sprache direkt aus dem Vorstand kommen und „umzusetzen sind“. Budgetierung gibt es dabei meist keine, denn „da müssen halt alle mitmachen“. So sieht die Realität aus, und EAM wird zwischen Vorstand und der Entwicklung und dem Betrieb zerrieben.

Fragt einmal euren Vorstand, wieviele Anwendungs-„Dinger“ im Konzern so existieren! Und dann fragt einen zweiten Entscheidungsträger. Das Delta gibt oft den inoffiziellen Grad der Verwirrung wieder!

Schade eigentlich, denn in die Jahre gekommenen IT-Konzerne brauchen Überblick für Innovationen wie einen Bissen Brot, um nicht am Abstellgleis zu landen. Dass man von einem der wesentlich wendigeren Fintechs überholt wird ist keine Seltenheit.

Wie also kann man Enterprise Architecturemanagement die Kurve kratzen, um der versprochene Hebel für den digitalen Wandel zu sein?

Lose-Lose: wie sieht Enterprise Architecture Management (EAM) derzeit aus?

Um die Unvereinbarkeit zwischen den Welten des Vorstands und der „echten“ operativen Welt der Produktteams zu veranschaulichen, möchte ich ein paar typische plakative Gespräche zwischen Enterprise Architekten und anderen IT-Rollen „modellieren“. John ist der Enterprise Architekt, Larry kommt aus einem Produktteam (z.B. ein Scrum Master, ein Produkt Manager, ein Test Manager).

John: Hey Larry, der Vorstand hat mir gestern um 23:34 Uhr den Auftrag gegeben, eine Erhebung aller Java Anwendungen zu machen. Ziel: 5 Folien bis heute Mittag 12:00 Uhr. Ich schick Dir gleich das Formular, OK?

Larry: John, ich habe Ende der Woche Produktivsetzung der neuen Release, das wird sich nicht ….
John: Danke, Larry, es muss leider sein!

Kommt euch das bekannt vor? Keiner von beiden wird nachhaltig von dieser Aufgabe einen Vorteil haben. Schade eigentlich. Lose-Lose.

Gleichzeitig machen sich die beiden natürlich Gedanken.

Larry’s Gedanken: Mann, schon wieder. Das ist der dritte derartige Auftrag dieses Monat, der mir meine Zeit stiehlt. Können die das nicht sinnvoller machen und gleich ein Repository mit allen Infos anlegen? Dann hätte ich auch was davon, einen Überblick über die Java Anwendungen hätte ich auch gern, dann müsste ich diese Information wie jeder andere nicht selbst erheben!

John’s Gedanken: Schnell weg. Ich weiß eh, dass das schon der dritte derartige Auftrag dieses Monat war. Die haben echt viel zu tun, und eigentlich würde ich ihnen gerne helfen. Aber wie? Wir haben keine einheitliche Vorgehensweise, Budget für ein sinnvolles EA Tool und keine Ressourcen. Und eigentlich verstehe ich die Java Frage vom Vorstand auch nicht ganz? Muss wieder dem Aufsichtsrat irgendwas berichten, wahrscheinlich. Wäre echt cool, wenn wir echtes agiles EAM etablieren könnten! So hat irgendwie keiner was davon…“

Warum kommt EAM sooft in die Lose-Lose Einbahnstraße?

Win-Win: wo könnten EAM Hebel ansetzen?

Nachhaltigkeit, Nutzen für die Stakeholder und Gemeinsamkeiten finden: der Enterprise Architekt ist eigentlich Support für die Produktteams. Wenn er gescheit ist, versucht er daher Win-Win Situationen zu erreichen. Dazu muss er die Wünsche aller Stakeholder gut kennen, und manchmal mit Fingerspitzengefühl hartnäckig bleiben. Proaktiv in die Zukunft schauen statt reaktiv die Vergangenheit aufarbeiten.

Wie könnte das Gespräch denn aussehen, damit alle etwas davon haben? Ein Versuch …

Larry: Hey John, gut dass ich Dich sehe. Letztes Mal haben wir uns ja darauf geeinigt, dass wir die Technologieinformationen besser und transparenter verwalten. Sehr cool, dass Du allen Produktteams da eine Möglichkeit gegeben hast. Es hat jetzt schon zwei Situationen gegeben, wo wir die Informationen der anderen Produktteams nutzen konnten und in der Startphase des Projekts schneller die richtigen Informationen hatten!

John: Das freut mich! Bringen unsere gemeinsamen Gespräche ja doch was! Glücklicherweise sind eure Wünsche beim Vorstand gut angekommen. Seitdem kann ich dem Vorstand auch einen monatlichen Bericht geben, den er im Aufsichtsrat verwenden kann. Und der Clou: die Infos habe ich mir nicht aus dem Finger gesaugt, die sind echt, danke euch!

Ganz selten habe ich solche positiven Effekte selbst erleben können. Effekte, die sich aus Ruhe und Achtsamkeit heraus ergeben, dem einander Zuhören und aufeinander Eingehen. Was bedeutet hier Agilität bzw. Selbstverantwortung – eine Kombination, die ich gerne in den Mindset des sogenannten „New Work“ einordne? Die Menschen, die es am besten wissen sollten können am kreativen gemeinsam Prozess mitwirken. Die sogenannte Managementfunktion ist eigentlich „nur“ ein „positives Abfallprodukt“.

Wie schafft man es, EAM im Win-Win Mindset zu leben?

Nutzen von EAM

Bevor wir auf New Work mit positivem Mindset und radikale Transparenz kommen, einige pragmatische Gedanken. Was könnte denn ein Nutzen von EAM sein?

Diese Frage muss man sich immer im Kontext des eigenen Unternehmens überlegen! Eine TOGAF Abschrift der EAM Ziele oder Prinzipien ist da nicht hilfreich, z.B. „Oberstes Ziel von EAM ist die Kostenreduktion“. Hat noch nie funktioniert. Ja, es kann sein, dass Kosten gesenkt werden können. Aber EAM bringt immer mehr Qualität, und die Kostenersparnisse sind nicht buchhalterisch, sie gehen immer gleich in neue Methoden oder Vorgehensweisen auf: eine bessere Übersicht über die Anwendungen ermöglicht es Projekten, schneller zu starten, die gewonnene Zeit und der Wenigeraufwand wird sofort in sinnvolle andere Aufwände gesteckt.

Was will das Unternehmen mit EAM also erreichen?

Vor etwa einem Jahr habe ich dazu ein Ziel formuliert: „Menschen glücklich machen“. Ja, vielleicht zu allgemein formuliert! Aber im Kern könnte es darum gehen.

Folgende „generische Ziel-Kandidaten“ fallen mir spontan ein:

  • Förderung der Zusammenarbeit im Zuge von Projekten: wer einen guten Überblick auf Basis gemeinsamer Begrifflichkeiten über alle Anwendungen im Unternehmen hat, dem fällt eine Diskussion mit unterschiedlichen Stakeholdern leicht. Wenn jedem klar ist, was mit „Anwendung X“ gemeint ist, dann kann man gleich über Lösungen sprechen. Macht auch mehr Spass!
  • Bereitstellung von „DevOps Bauchläden“: DevOps Bauchläden sind für mich Toolstacks mit vielen Freiheitsgraden, z.B. für die EntwicklerInnen von Anwendungen. Freiheit, dort wo Kreativität von EntwicklerInnen gefordert ist (jeder Entwickler arbeitet am besten mit seinen bekannten Frameworks), und „Bachladen“ dort, wo die EntwicklerInnen gerne Hilfe annehmen würden (Bereitstellung von durchdachten Testtools, die an Requirementstools angeschlossen sind, Autotest-Frameworks; eigentlich alle Tools, die „am Rande“ für die Qualität von Anwendungen notwendig sind).
  • Leben von radikaler Transparenz: Spieltheorie und Verhaltensökonomie … hier denke ich immer an James Bond und Doppelagenten. In der Agentenwelt geht es um Geheimnisse, Verschleierungen von Informationen und Irreführungen. Ist aber nicht so ganz untypisch für Unternehmenskommunikation. Aber wer hat da den Überblick über Wahrheit und trügerische Information? Bei echter „radikaler Transparenz“ kommt man gleich zum Wesentlichen!
  • Mutige innovative Produkte erschaffen: wahrscheinlich eine Folge der ersten drei Kandidaten (oder doch umgekehrt) ist das Erschaffen von mutigen Anwendungen, die gleichzeitig den KundInnen von Vorteil sind, z.B. Blockchains in der Bankenwelt.
Welche Kandidaten für EAM Ziele gibt es im Unternehmen?

Die Krise als Chance! Brücken bauen! – New Enterprise Architecture Management (EAM)

Radikale Transparenz, Änderung des Mindsets der Unternehmenskultur, Achtsamkeit im Umgang mit KollegInnen, mehrere Meinungen zulassen, Diversität bewusst nutzen, Hierarchien abbauen, Brücken statt Mauern bauen! Konzepte, die in traditionellen hierarchisch strukturierten Unternehmen problematisch gesehen werden.

All diese Konzepte brauchen Zeit und sind für jedes Unternehmen unterschiedlich. Sich damit beschäftigen, es zulassen, neue Wege gehen! New Work und EAM. New EAM

Jedenfalls eine Kombination, die es in sich hat. Und die Krise zeigt, dass es technisch ohne weiteres möglich ist. Homeoffice ist zum de facto Standard geworden. Aber wird es überall wirklich sinnvoll gelebt? Und was passiert, wenn die Krise vorbei ist? Bleiben wir bei den neu gewonnenen Errungenschaften?

Ich freue mich auf die New-Zukunft!
Aufgewachsen in Wien genoss Hannes Lischka eine akademische Ausbildung in Wirtschaftsinformatik. Seine mittlerweile 20 jährige Laufbahn führte ihn beinahe durchs gesamte IT-Management, der Fokus lag seit 2007 auf Enterprise Architektur Management (EAM). In den letzten Jahren erkannte er, dass nachhaltiger Erfolg weniger durch technokratische Prozesse als vielmehr durch die beteiligten Menschen entsteht. Seine Brücken baut er seitdem zwischen EAM und New Work.

Die Kommentarfunktion ist geschlossen.

MoreThanDigital Newsletter
Subscribe
Join the #bethechange community
close-image