Enterprise Architecture Management (EAM) im digitalen Wandel
Wie kommt man vom Wasserfall-basierten Vorgehen zum agilen Enterprise Architecture Management?
Der digitale Wandel macht auch vor Enterprise Architecture Management (EAM) nicht halt. Doch wie bringt man dem bürokratischen Wasserfall-Vorgehen im traditionellen EAM Agilität und DevOps bei? Wie schafft man Win-Win Situationen? Eine Veränderung der Unternehmenskultur ist genauso ein Thema wie das Entstauben der hierarchischen Strukturen! Gegenseitige Vorteile kommen erst mit der Akzeptanz der Sichtweisen aller beteiligten Stakeholder und somit mit Vertrauen.
Index
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.
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.
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…“
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“.
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.
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?
Die Kommentarfunktion ist geschlossen.