EA-Governance: Architecture Board, Prinzipien und Review-Prozess richtig aufsetzen

Kurzfassung: EA-Governance ist der Mechanismus, der aus einer Ziel-Architektur eine tatsächlich gelebte Architektur macht. Sie besteht aus vier Bausteinen: Architekturprinzipien (woran wir uns halten), einem Architecture Board (wer entscheidet), Review-Gates (wann geprüft wird) und einem Ausnahmeprozess (wie begründete Abweichungen befristet erlaubt werden). Ohne diese vier bleibt Enterprise Architecture Dokumentation; mit ihnen wird sie zur Steuerungsfähigkeit. Dieser Artikel zeigt, wie wir EA-Governance in Portamus-Kundenprojekten aufsetzen – schlank genug, dass die Organisation sie akzeptiert.

Das Wichtigste in Kürze

• EA-Governance beantwortet vier Fragen: Wer entscheidet? Nach welchen Prinzipien? Wann wird geprüft? Wie werden Ausnahmen behandelt?
• 10–15 Prinzipien genügen. Jedes braucht Aussage, Begründung und Implikationen – sonst bleibt es Wandschmuck.
• Ein Architecture Board wirkt nur mit echten Entscheidungsrechten, kleiner Besetzung und festem Takt.
• Risikobasierte Prüftiefe ist der wichtigste Hebel gegen die Wahrnehmung „Governance bremst“.
• Der Ausnahmeprozess ist kein Eingeständnis der Niederlage, sondern die Voraussetzung dafür, dass Regeln überhaupt eingehalten werden.
• Gemessen wird Wirkung (Durchlaufzeit, Wiederverwendung, technische Schulden), nicht Aufwand (Anzahl Dokumente).

Was ist EA-Governance?

EA-Governance ist die Gesamtheit der Rollen, Entscheidungsrechte, Prinzipien und Prozesse, mit denen eine Organisation sicherstellt, dass Veränderungen an ihrer Architektur zum Zielbild passen. Sie ist der Unterschied zwischen einer Architektur, die auf Folien existiert, und einer, die Projektentscheidungen tatsächlich beeinflusst.

Der Bezugsrahmen ist TOGAF: Die Preliminary Phase etabliert das Governance-Framework, Phase G (Implementation Governance) stellt sicher, dass die Umsetzung der beschlossenen Architektur folgt. Governance ist damit keine Zusatzdisziplin neben der Architekturarbeit, sondern deren Wirkmechanismus – und ein Kernbestandteil von Enterprise Architecture Management.

Abgrenzung: EA-Governance vs. IT-Governance

In der Praxis ist EA-Governance in die IT-Governance eingebettet: Das Architecture Board liefert die fachliche Bewertung, der Investitionsausschuss entscheidet über Geld. Wo diese Kopplung fehlt, wird Architektur regelmäßig überstimmt.

Baustein 1: Architekturprinzipien

Prinzipien sind das kostengünstigste Governance-Instrument – sie entscheiden hunderte Einzelfälle im Voraus. Nach TOGAF hat ein gutes Prinzip vier Bestandteile:

Beispiele aus unseren Projekten (gekürzt):

• „Buy before build.“ Standardsoftware vor Eigenentwicklung, sofern die Fachanforderung zu ≥ 80 % abgedeckt ist. Implikation: Prozesse werden im Zweifel an die Software angepasst, nicht umgekehrt.
• „Ein führender Ort je Datenobjekt.“ Jedes Geschäftsobjekt hat genau ein führendes System. Implikation: Zweitschriften sind lesend, Synchronisation ist einseitig.
• „Integration über die Plattform.“ Keine Punkt-zu-Punkt-Schnittstellen zwischen Kernsystemen. Implikation: Projekte kalkulieren Integrationsaufwand über die Integrationsarchitektur ein.

Faustregel: Wenn ein Prinzip nie zu einer unbequemen Konsequenz führt, ist es kein Prinzip, sondern eine Absichtserklärung.

Zehn bis fünfzehn Prinzipien sind die praktikable Obergrenze. Der begrenzende Faktor ist nicht die Formulierung, sondern die Erinnerungsfähigkeit der Organisation.

Baustein 2: Das Architecture Board

Das Architecture Board ist das Gremium, das Prinzipien verabschiedet, Zielbilder freigibt, über Abweichungen entscheidet und technische Schulden priorisiert.

Was in der Praxis funktioniert:

• Fünf bis sieben stimmberechtigte Mitglieder – Lead-Architektur, IT-Betrieb, Informationssicherheit, ein Fachbereichsvertreter, Anwendungsentwicklung. Größere Runden entscheiden nicht, sie diskutieren.
• Fester Takt, typischerweise alle zwei Wochen, mit Vorlagenschluss 48 Stunden vorher.
• Verbindliche Entscheidungsrechte – dokumentiert in einer RACI-Übersicht, gegengezeichnet von der IT-Leitung. Ein Board, dessen Entscheidungen umgangen werden können, kostet nur Zeit.
• Schriftliche Entscheidungen in Form von Architecture Decision Records: Kontext, Entscheidung, Konsequenzen, Datum. Sie sind später die wertvollste Quelle für die Frage „Warum eigentlich?“.

Was nicht funktioniert: ein Board ohne Vorbereitung, ohne Quorum, mit wechselnder Besetzung – oder eines, das Lösungsdesigns im Detail nachbaut, statt zu entscheiden.

Baustein 3: Review-Gates

Governance braucht definierte Prüfpunkte im Vorhabensverlauf. Bewährt haben sich drei:

Entscheidend ist die risikobasierte Prüftiefe. Wir arbeiten mit einer kurzen Einstufung (Architekturwirkung hoch / mittel / gering) anhand weniger Kriterien: neues System, neue Schnittstelle zu einem Kernsystem, personenbezogene Daten, Cloud-Verlagerung, Abweichung von einem Prinzip. Nur die Kategorie „hoch“ durchläuft alle drei Gates; „mittel“ wird schriftlich geprüft; „gering“ läuft über Selbstauskunft. In unseren Projekten fallen so typischerweise 15 bis 25 % der Vorhaben in die volle Prüfung – und genau diese Konzentration macht die Governance akzeptabel.

Baustein 4: Der Ausnahmeprozess

Jede Architekturregel wird irgendwann berechtigterweise verletzt – wegen einer Übernahme, einer Frist, einer Altlast. Die relevante Frage ist nicht ob, sondern wie sichtbar.

Ein tragfähiger Ausnahmeprozess hat vier Merkmale:

1. Antragsweg mit Begründung und benannter verantwortlicher Person.
2. Befristung – jede Ausnahme läuft ab, typischerweise nach 6 bis 18 Monaten.
3. Rückbauplan oder ausdrückliche Übernahme in die technische Schuld.
4. Sichtbarkeit – ein Ausnahmeregister, das im Board regelmäßig aufgerufen wird.

Ohne diesen Prozess entstehen stille Abweichungen: Sie werden nicht beantragt, nicht dokumentiert und tauchen erst Jahre später in einer IT-Landschaftsanalyse wieder auf – dann als teure Überraschung.

Wirksamkeit messen

Governance, die sich nicht messen lässt, wird beim ersten Sparzwang gestrichen. Sinnvolle Kennzahlen:

• Durchlaufzeit einer Architekturentscheidung (Ziel: ≤ 10 Arbeitstage).
• Abdeckungsgrad: Anteil der Vorhaben mit hoher Architekturwirkung, die tatsächlich geprüft wurden.
• Offene und abgelaufene Ausnahmen – ein wachsender Bestand abgelaufener Ausnahmen ist das früheste Warnsignal.
• Wiederverwendungsquote bestehender Services statt Neubau.
• Entwicklung der technischen Schulden, idealerweise gekoppelt an das Applikationsportfolio-Management.

Nicht messen sollten Sie die Anzahl erstellter Dokumente oder abgehaltener Sitzungen: Das misst Aufwand, nicht Wirkung.

Typische Fehler

• Governance vor Zielbild. Ohne beschlossene Ziel-Architektur prüft das Board gegen Geschmack statt gegen Inhalt.
• Zu viele Prinzipien. 40 Prinzipien sind faktisch keine.
• Board ohne Mandat. Empfehlungen ohne Entscheidungsrecht werden im Projektalltag ignoriert.
• Einheitliche Prüftiefe für alles. Erzeugt Warteschlangen und damit Umgehung.
• Keine Ausnahmen erlauben. Führt nicht zu mehr Konformität, sondern zu unsichtbarer Nichtkonformität.
• Governance ohne Architektin oder Architekt. Ein Gremium kann Entscheidungen treffen, aber keine Architektur erarbeiten.

Häufige Fragen zur EA-Governance

Was ist EA-Governance? Die Gesamtheit der Rollen, Entscheidungsrechte, Prinzipien und Prozesse, mit denen sichergestellt wird, dass Veränderungen an IT- und Geschäftsarchitektur zur Ziel-Architektur passen.

Was macht ein Architecture Board? Es verabschiedet Prinzipien und Zielbilder, entscheidet über Abweichungen, gibt Vorhaben an Review-Gates frei und priorisiert technische Schulden – wirksam bei kleiner Besetzung, festem Takt und echten Entscheidungsrechten.

Was sind Architekturprinzipien? Verbindliche, begründete Leitsätze für Architekturentscheidungen. Nach TOGAF bestehen sie aus Name, Aussage, Begründung und Implikationen; zehn bis fünfzehn genügen.

Wie unterscheidet sich EA-Governance von IT-Governance? IT-Governance (COBIT) steuert die IT-Organisation als Ganzes; EA-Governance steuert die inhaltliche Konsistenz der Architektur und ist in die IT-Governance eingebettet.

Ab welcher Größe ist ein Architecture Board sinnvoll? Erfahrungsgemäß ab ca. 150–200 Mitarbeitenden in der IT-nahen Organisation oder ab fünf bis sieben parallelen Vorhaben. Darunter genügt ein benannter Lead-Architekt mit Entscheidungsrecht.

Wie verhindert man, dass EA-Governance zum Bremsklotz wird? Risikobasierte Prüftiefe, feste Antwortzeiten und ein sauberer Ausnahmeprozess.

Welche Rolle spielt TOGAF? TOGAF etabliert Governance in der Preliminary Phase und sichert sie in Phase G (Implementation Governance) ab; Architecture Contracts und Compliance Reviews liefern die Grundlage für Review-Gates.

Wie misst man, ob EA-Governance wirkt? Durchlaufzeit von Entscheidungen, Abdeckungsgrad geprüfter Vorhaben, offene und abgelaufene Ausnahmen, Wiederverwendungsquote und Entwicklung der technischen Schulden.

Fazit

EA-Governance ist kein Kontrollapparat, sondern ein Entscheidungssystem. Vier Bausteine genügen: wenige belastbare Prinzipien, ein kleines Gremium mit echtem Mandat, risikobasierte Review-Gates und ein transparenter Ausnahmeprozess. Unsere Erfahrung aus Portamus-Projekten: Der Widerstand gegen Governance richtet sich fast nie gegen die Regeln selbst, sondern gegen Wartezeit und Willkür. Wer schnelle, nachvollziehbare und dokumentierte Entscheidungen liefert, bekommt Akzeptanz – und damit eine Architektur, die tatsächlich steuert.

Sie möchten EA-Governance aufsetzen oder ein bestehendes Architecture Board wirksam machen? Wir bringen Prinzipien, Gremien und Review-Prozesse in eine Form, die Ihre Organisation trägt. → Portamus EA-Programmentwicklung entdecken

Quellen

• The Open Group: TOGAF Standard, 10th Edition – Architecture Governance, Phase G (2022)
• ISACA: COBIT 2019 Framework: Governance and Management Objectives (2018)
• ISO/IEC/IEEE 42010:2022 – Software, systems and enterprise — Architecture description