Rollenkonzepte im EAM

Welche Art von Rollen gibt es im Enterprise Architecture Management?
Von Yann Vandercoilden (Yann Vandercoilden | LinkedIn) |
Tags:
Categories:

Rollen-Konzepte im EAM

Wozu Rollen im EAM?

Enterprise Architecture Management (EAM) bewegt sich im Spannungsfeld zwischen Strategie, Organisation, IT-Systemen und operativen Prozessen. Ohne klar definierte Rollen besteht die Gefahr, dass Architekturarbeit entweder rein dokumentarisch bleibt oder unkoordiniert von verschiedenen Stellen betrieben wird.

Rollen im EAM erfüllen daher mehrere zentrale Funktionen:

1. Verantwortlichkeiten klären
Architekturentscheidungen betreffen viele Bereiche eines Unternehmens. Rollen sorgen dafür, dass klar ist, wer Entscheidungen vorbereitet, trifft oder verantwortet.

2. Perspektiven strukturieren
EAM betrachtet Organisationen aus unterschiedlichen Blickwinkeln (Business, Daten, Anwendungen, Technologie). Rollen helfen, diese Perspektiven organisatorisch zu verankern.

3. Kommunikation ermöglichen
Architektur ist ein Übersetzungsraum zwischen Business und IT. Rollen definieren, wer welche Sprache spricht und welche Interessen vertritt.

4. Governance sicherstellen
Architekturvorgaben entfalten nur Wirkung, wenn jemand für ihre Durchsetzung zuständig ist – etwa über Architekturboards oder Review-Prozesse.

Kurz gesagt:
Rollen bilden die organisatorische Grundlage, damit Architektur nicht nur modelliert, sondern auch gelebt und gesteuert wird.

Wie gehen bekannte Frameworks damit um?

TOGAF

Das TOGAF-Framework definiert eine Reihe von Rollen rund um die Architekturarbeit, insbesondere im Kontext der Architecture Development Method (ADM).

Architekturrollen und Ihre Verbindungen nach TOGAF Entnommen von TOGAF Architecture Roles and Skills (Benutzerkonto notwendig).

Die Architekturrollen in TOGAF sind:

  • Enterprise Architect – Gesamtverantwortung für die Architektur des Unternehmens

  • Segment Architect – Verantwortung für spezifische Architekturdomänen (Business, Data, Application, Technology)

  • Solution Architect – Architektur eines konkreten Projekts oder Systems

  • Chief Architect – Governance- und Entscheidungsorgan für Architekturfragen

TOGAF betrachtet Rollen primär aus einer Governance- und Prozessperspektive.
Sie sind eng mit den Phasen der ADM und der Architektur-Governance verknüpft.

Die Rollen sind jedoch bewusst generisch formuliert und müssen von jeder Organisation an ihre eigene Struktur angepasst werden.

Zachman Framework

Das Zachman Framework verfolgt einen anderen Ansatz. Es definiert keine expliziten Rollen, sondern strukturiert Architekturartefakte entlang zweier Dimensionen:

Die Struktur von Zachman

Bild entnommen von About the Zachman Framework.

  • Fragen (What, How, Where, Who, When, Why)

  • Perspektiven (Planner, Owner, Designer, Builder, Subcontractor, Functioning System)

Die Zeilen des Frameworks lassen sich jedoch als implizite Rollenperspektiven interpretieren:

Perspektive Typische Rolle
Planner Strategie / Unternehmensleitung
Owner Business-Verantwortliche
Designer Enterprise- oder Solution-Architekt
Builder Entwickler / Implementierung
Subcontractor technische Spezialisten

Der Beitrag des Zachman-Frameworks liegt weniger in konkreten Rollenbezeichnungen, sondern in der Erkenntnis:

Architektur entsteht aus unterschiedlichen Perspektiven und Fragestellungen.

Damit liefert Zachman eine gute Grundlage, um Rollen systematisch aus den grundlegenden Architekturfragen abzuleiten.

Rollen im Bezug zum EVA-Prinzip

Das EVA-Prinzip (Eingabe – Verarbeitung – Ausgabe) kann als einfache Denkstruktur verwendet werden, um Verantwortlichkeiten im Architekturkontext zu strukturieren.

Übertragen auf Architekturfragen lassen sich sechs grundlegende Perspektiven unterscheiden:

  • Was – Gegenstände und Informationen

  • Wie – Prozesse und Funktionen

  • Womit – Werkzeuge und Technologien

  • Weshalb – Ziele und Motivation

  • Wann – zeitliche Struktur und Planung

  • Wer – Organisation und Verantwortlichkeiten

Diese Fragen helfen, Rollen nicht nur nach Hierarchie oder Fachdomäne zu definieren, sondern nach ihrer funktionalen Verantwortung im Architekturraum.

Im Zusammenhang mit den Grundfragen

Rollen/Verantwortlichkeiten für das “WAS”

Die Frage nach dem „Was“ bezieht sich auf die zentralen Informationsobjekte einer Organisation.

Typische Verantwortlichkeiten:

  • Definition zentraler Informationsobjekte

  • Datenmodelle und Informationsstrukturen

  • Datenqualität und Datenverantwortung

Typische Rollen:

  • Data Architect

  • Information Architect

  • Data Owner

  • Data Steward

Diese Rollen stellen sicher, dass Datenstrukturen konsistent und organisationsweit verständlich sind.

Rollen/Verantwortlichkeiten für das “WIE”

Das „Wie“ beschreibt die Prozesse und Funktionen, mit denen eine Organisation ihre Leistungen erbringt.

Typische Verantwortlichkeiten:

  • Modellierung von Geschäftsprozessen

  • Definition von Fähigkeiten (Capabilities)

  • Abstimmung zwischen Business und IT

Typische Rollen:

  • Business Architect

  • Process Owner

  • Capability Manager

Diese Rollen sorgen dafür, dass Geschäftsprozesse und IT-Systeme aufeinander abgestimmt sind.

Rollen/Verantwortlichkeiten für das “WOMIT”

Die Frage „Womit“ betrifft die technologischen Mittel zur Umsetzung der Prozesse.

Typische Verantwortlichkeiten:

  • Technologie-Standards

  • Plattformarchitekturen

  • Infrastruktur-Strategien

Typische Rollen:

  • Technology Architect

  • Infrastructure Architect

  • Platform Architect

Sie definieren die technischen Rahmenbedingungen, innerhalb derer Lösungen entstehen.

Im Zusammenhang mit den Grundfragen

Rollen/Verantwortlichkeiten für das “WESHALB”

Das „Weshalb“ verbindet Architektur mit der strategischen Ausrichtung des Unternehmens.

Typische Verantwortlichkeiten:

  • Ableitung von Architekturprinzipien

  • strategische Zielbilder

  • Transformations-Roadmaps

Typische Rollen:

  • Enterprise Architect

  • Strategy Architect

  • Transformation Lead

Diese Rollen sorgen dafür, dass Architekturentscheidungen strategisch begründet sind.

Rollen/Verantwortlichkeiten für das “WANN”

Das „Wann“ betrifft die zeitliche Koordination von Architekturveränderungen.

Typische Verantwortlichkeiten:

  • Transformationsplanung

  • Roadmaps

  • Release- und Programmplanung

Typische Rollen:

  • Portfolio Manager

  • Program Manager

  • Transformation Manager

Sie sorgen dafür, dass Architektur nicht nur entworfen, sondern auch zeitlich umgesetzt wird.

Rollen/Verantwortlichkeiten für das “WER”

Die Frage „Wer“ betrifft die organisatorische Verankerung der Architekturarbeit.

Typische Verantwortlichkeiten:

  • Governance-Strukturen

  • Rollen und Verantwortlichkeiten

  • Entscheidungsprozesse

Typische Rollen:

  • Architecture Board

  • Domain Leads

  • Architecture Governance Lead

Diese Rollen stellen sicher, dass Architekturentscheidungen institutionell verankert sind.

Skalierung des Rollen-Konzeptes

Nicht jede Organisation benötigt dieselben Rollen.
Die Anzahl und Spezialisierung von Rollen hängt stark von der Größe und Komplexität der Organisation ab.

Das DPBoK (Digital Practitioner Body of Knowledge) beschreibt vier Kontextstufen, anhand derer sich Rollen sinnvoll skalieren lassen.

Context I: Einzelperson / Gründer

In sehr kleinen Organisationen übernimmt eine einzelne Person oft mehrere Rollen gleichzeitig.

Typische Situation:

  • Gründer = Strategie, Architektur und Umsetzung

  • geringe formale Trennung von Rollen

Charakteristika:

  • implizite Architektur

  • schnelle Entscheidungen

  • minimale Governance

Architekturarbeit erfolgt hier eher intuitiv.

Context II: Team

Mit zunehmender Größe entstehen erste funktionale Rollen.

Typische Rollen:

  • Product Owner

  • Lead Developer

  • Solution Architect

Architektur entsteht häufig innerhalb eines Teams und wird stark durch konkrete Produkte geprägt.

Context III: Team von Teams

Ab dieser Stufe entstehen koordinierende Architekturrollen.

Typische Rollen:

  • Enterprise Architect

  • Domain Architect

  • Architecture Board

Zentrale Aufgaben:

  • Abstimmung zwischen Teams

  • gemeinsame Architekturprinzipien

  • Plattform- und Datenstandards

Architektur wird hier erstmals unternehmensweit koordiniert.

Context IV: Dauerhaftes Unternehmen

In etablierten Organisationen wird Architektur zu einer eigenen organisatorischen Funktion.

Typische Strukturen:

  • Architecture Office

  • Enterprise Architecture Practice

  • Architecture Governance

Charakteristisch sind:

  • klar definierte Rollen

  • formale Governance

  • langfristige Transformationsplanung

Hier wird Architektur zu einem zentralen Instrument der Unternehmenssteuerung.

Fazit

Rollen im Enterprise Architecture Management lassen sich auf unterschiedliche Weise definieren. Während Frameworks wie TOGAF konkrete Rollen vorschlagen, zeigt das Zachman Framework vor allem unterschiedliche Perspektiven auf Architektur.

Eine systematische Herleitung von Rollen gelingt, wenn man Architektur entlang grundlegender Fragen strukturiert – etwa über die sechs Perspektiven:

  • Was

  • Wie

  • Womit

  • Weshalb

  • Wann

  • Wer

Diese Fragen machen sichtbar, welche Verantwortlichkeiten im Architekturraum überhaupt existieren.

Welche Rollen tatsächlich etabliert werden, hängt jedoch stark vom organisatorischen Kontext ab. Mithilfe der Skalierungsstufen des DPBoK lässt sich nachvollziehen, wie Architekturrollen von einer einzelnen Person bis hin zu einer institutionalisierten Architekturorganisation wachsen können.

Damit wird deutlich:
EAM-Rollen sind kein starres Set von Titeln, sondern ein skalierbares Organisationskonzept für Architekturverantwortung.