Enterprise Architecture Management (EAM): Regel 3 – Integriert und Hand in Hand

Publish date:

Enterprise Architecture Management, kurz EAM, ist weder Zuckerschlecken noch Hexenwerk. Es kann ausufern oder leichtfüßig von statten gehen. Es liegt an Ihnen und Ihrem Vorgehensmodell.

RSS-Feed abonnieren

Heute habe ich für Sie Regel Nummer drei von sieben: Der Schulterschluss von Unternehmens- und Lösungsarchitekten. Regel eins und zwei für das leichtgewichtige EAM habe ich ihnen bereits in vergangenen Beiträgen beschrieben. Lesen Sie sie gerne nochmal nach!

Nun direkt zu Regel drei: Ja, es gibt viel mehr Rollen als nur den Unternehmens- und Lösungsarchitekten. Das ist gerade sicher ihr Veto. Was ist denn mit den System-, Software-, Business-, Daten-, Integrations-, Domänen-, Technologie-, Cloud-, Mobile-, Social-, Analytics-, Big-Data- und natürlich [hier beliebiges IT-Schlagwort einsetzen]-Architekten? Sie alle haben ihre Rolle im Unternehmen. Folgt man  dem KISS-Prinzip stellt sich jedoch die Frage, ob eine solch feingranulare Unterscheidung wirklich notwendig ist.

Fakt ist, Sie brauchen jemanden, der den Blick auf das große Ganze behält: den Unternehmensarchitekten – von ihm  aber gern auch mehrere. Außerdem brauchen Sie Leute, die sich mit den Details auseinandersetzen, wobei es mal mehr und mal weniger detaillierte Details sind. Legen Sie am besten einfach fest, dass sich Unternehmensarchitekten um viele Anwendungen in unterschiedlichen Domänen kümmern und Lösungsarchitekten um nur ganz wenige, oder sogar nur eine Anwendung. Und von dieser vielleicht auch nur um einen Teil.

Enger Schulterschluss ist gefragt

Obwohl diese organisatorische Aufgabenverteilung grundlegend ist, klärt sie noch nicht die zentrale Frage, wie Unternehmens- und Lösungsarchitekten Hand in Hand zusammenarbeiten.

Des Pudels Kern liegt für mich viel mehr in der tagtäglichen Zusammenarbeit von Unternehmens- und Lösungsarchitekten. Hier ist der enge Schulterschluss gefragt. Die Unternehmensarchitekten müssen ihr Wissen über die Gesamtzusammenhänge der Organisation an die Lösungsarchitekten weitergeben. Sie müssen aufzeigen, wenn an zwei Stellen etwas Ähnliches oder Gleiches gemacht wird und dann den Austausch anstoßen. Sie müssen die groben Leitlinien des Zielbilds an die Lösungsarchitekten weitergeben und über alle Lösungsarchitekturen hinweg für Standardisierung sorgen.

Im Umkehrschluss sind sie auf gute Ergebnisse der Lösungsarchitekten angewiesen. Sie tragen die grobgranularen Vorgaben in die Projekte und erproben sie auf diese Weise. Das Feedback fließt schließlich wieder zurück an die Unternehmensarchitekten. Im Idealfall auch ein paar Best Practices. Spannungen und Meinungsverschiedenheiten sind da vorprogrammiert – aber auch gewünscht.

Wissen weiterreichen und recyceln

Best Practices wiederverwenden: TOGAF nennt diesen Workflow das Generalisieren von Building Blocks im Rahmen des Enterprise Continuum. Das bedeutet: Unternehmensarchitekten sollen Lösungsarchitekturen finden und im sogenannten Continuum weiter nach links verschieben (d. h. generalisieren), um sie anderswo wiederzuverwenden. Ich denke dafür braucht es keinen Unternehmensarchitekten. Die jeweiligen Nutznießer der Best Practices können diese Transferleistung des Generalisierens und des erneuten Spezialisierens für einen anderen Anwendungsfall selbst erbringen. Im einfachen Fall bedeutet das, dass sie  eine kurze Problembeschreibung einschließlich des Lösungswegs und den gelernten Lektionen liefern. Die Schwierigkeit dieses Wissensrecyclings liegt ja nicht darin, dass niemand etwas mit den Infos anfangen kann, weil es auf einen bestimmten Anwendungsfall zugeschnitten ist. Es sind eher die bekannten Probleme des Wissensmanagements, wie das strukturierte Ablegen, Wiederfinden und zur Verfügung stellen für alle potentiellen Nutzer. Hier muss der Unternehmensarchitekt einen geeigneten zentralen Ablage- und Fundort sicherstellen.

Für den operativen Austausch von Unternehmens- und Lösungsarchitekten hat sich meiner Erfahrung nach eine wöchentliche Runde à zwei Stunden mit allen Architekten bewährt. Hier sollte jeder kurz von seinen aktuellen Aktivitäten berichten und ausgewählte Themen können in einer gemeinsamen Diskussion vertieft werden. Die Themen können dabei sowohl die Lösungs- als auch die Unternehmensarchitektur betreffen.

 

Was halten Sie von meinen Vorschlägen für eine leichtgewichtige Zusammenarbeit zwischen den Unternehmens- und Lösungs-Architekten?

In meinem nächsten Beitrag erkläre ich, wie Sie genau die Themen identifizieren, mit denen sich die Lösungsarchitekten eigentlich beschäftigen sollten. Und wahrscheinlich ahnen Sie es schon: Ich schlage keine vollumfängliche Ist-Erfassung plus Schwachstellenanalyse vor.

 

Weitere Posts

IT-Trends

IT Trends 2020: Sind intelligente Technologien ein Erfolg?

Sven L. Roth
Date icon Mai 15, 2020

Die Auswirkungen der Corona-Pandemie zwingen viele Unternehmen dazu, ihre Kosten zu senken....

DevOps

OOP: IT-Architektur zwischen Software und Business

Daniel Hardt
Date icon Januar 22, 2020

Unter dem Motto “Software meets Business” bringt die OOP IT-Experten, Projektleiter und...

IT-Architektur

Vier Praxisbeispiele für agiles Enterprise Architecture Management

Tim Lüecke
Date icon November 29, 2019

Agilität und Enterprise Architecture Management (EAM) sind nur auf den ersten Blick ein...