Architekt-Methodologe: TOGAF und Change Management

Architekt-Methodolog: Die Lücke zwischen Strategie und Code mit TOGAF, Change Management und Prozessautomatisierung schließen

Unternehmensarchitektur bleibt oft nur eine Ansammlung von PowerPoint-Folien – nicht weil sie schlecht konzipiert ist, sondern weil es keine gesteuerte, messbare, rollenbasierte und automatisierte Brücke zwischen ihrer Konzeption und Umsetzung gibt. Diese Lücke führt dazu, dass ArchiMate-Zieldiagramme keinen Einfluss auf die Entscheidungen der Entwicklungsteams haben, Prinzipien standardmäßig verletzt werden und technische Schulden mit jeder Release linear anwachsen. Die Lösung ist keine neue Methodik, sondern die Synthese aus drei Komponenten: ingenieurtechnischem Objektmanagement (TOGAF ADM Phase H), der Verhaltensausrichtung der Bedeutungen (Organizational Change Management) und deren operativer Fixierung durch Automatisierung in CI/CD, Jira und Repositories. Ein Architekt-Methodolog ist keine Position im Organigramm – es ist eine Funktion, die diese Ebenen vereint.

Warum Architektur ‚schwebt‘: Diagnose der Lücke zwischen Discovery und Delivery

In einem typischen IT-Prozess definiert der Enterprise Architect (EA) die Zielarchitektur, die Prinzipien und den Fahrplan – nimmt jedoch nicht an der Entscheidungsfindung auf Aufgabenebene teil. Der Solution Architect (SolA) entwirft eine Lösung für eine spezifische Aufgabe, konzentriert sich dabei auf Deadlines und die aktuellen Kompetenzen des Teams, ohne direktes Feedback aus strategischen Artefakten zu erhalten. Das Ergebnis: Das implementierte System entspricht weder dem strategischen noch dem taktischen Modell.

Dies ist kein Menschenproblem – es ist ein systemischer Governance-Defekt. Er zeigt sich in fehlenden klaren Antworten auf zentrale Fragen:

• Wie wird das architektonische Backlog in Aufgaben in Jira überführt und im Pipeline validiert?
• Wer entscheidet, und nach welchen Kriterien, ob von architektonischen Prinzipien abgewichen wird?
• Wie misst man, wie nahe die tatsächliche Architektur dem Ziel entspricht – nicht einmal jährlich, sondern bei jedem PR?
• Wo sind die Verantwortlichkeiten für jedes architektonische Artefakt dokumentiert (z. B. ADR, Integrationsbeschreibung, Verschlüsselungswahl)?
• Wie stellt man sicher, dass eine Änderung in einem Service keine Sicherheits- oder Datenprinzipien in einem anderen verletzt?

Ohne formalisierte Interaktionsprozesse zwischen EA, SolA und DevOps-Teams wird Architektur eher zur Metapher als zum Werkzeug.

TOGAF Phase H als Grundlage für objektbasiertes Architekturmanagement

Die letzte Phase des TOGAF ADM – Phase H (Architecture Change Management) – ist nicht nur „Dokumentationsunterstützung“, sondern ein vollwertiger Engineering-Zyklus für das Management architektonischer Objekte. Sie definiert genau, wie sich Artefakte ändern, wer beteiligt ist, welche Änderungen genehmigungspflichtig sind und welche automatisch im Repository reflektiert werden können.

Wichtige Elemente von Phase H in der praktischen Anwendung:

• Managementobjekte: architektonische Prinzipien, Technologieauswahlstandards (z. B. „Nur PostgreSQL 15+ für OLTP“), Integrationsschemata (OpenAPI, AsyncAPI), ADR-Dokumente, Datenbereichsbeschreibungen (im DAMA-DMBOK-Jargon).
• Klassifizierungsprozesse: Unterscheidung zwischen Simplifizierung (Verschlankung der bestehenden Architektur), inkrementeller (schrittweise Einführung einer neuen Komponente) und Re-Architektur (kompletter Schichtersatz). Jeder Typ hat seinen eigenen Genehmigungsweg – von automatischen CI-Checks bis hin zu Architecture-Board-Sitzungen.
• Messmetriken: Prozentsatz der Aufgaben mit fertigem ADR, Anteil der PRs, die automatisch auf OpenAPI-Spezifikationen geprüft werden, Anzahl der abgelehnten Anfragen zur Nutzung nicht zugelassener Technologien, Niveau der architektonischen Schulden gemäß SonarQube + kundenspezifischen Regeln.

Phase H liefert Sprache, Struktur und Koordinaten. Doch sie löst nicht die Frage: Warum sollte ein Entwickler einen ADR ausfüllen, wenn er nicht in seinen Workflow integriert ist?

Change Management als Arbeit mit dem menschlichen Faktor

Organizational Change Management (OCM) ist hier keine HR-Schulung; es ist eine technische Disziplin, um die Wahrnehmung, Motivation und das Verhalten der Beteiligten zu steuern. Ihr Ziel ist es, die Einhaltung architektonischer Regeln zu einer natürlichen Folge der Arbeit zu machen – statt zu einer zusätzlichen Belastung.

Dies gelingt über drei Ebenen:

• Kommunikation in der Sprache des Wertes: Statt „Sie müssen einen ADR ausfüllen“ – „Ein ADR ermöglicht es Ihnen, Integrationskonflikte frühzeitig zu erkennen und drei Tage Debugging in der Produktion zu vermeiden.“
• Schulung im Kontext der Aufgabe: eingebettete Checklisten in Jira-Templates, interaktive Tutorials in GitLab Wiki beim Erstellen eines neuen Services, Beispiele für ADRs im Repository mit Kommentaren wie „Warum wurde diese Wahl getroffen?“
• Engagement durch Verantwortung: explizite Zuweisung der Rolle „Architect“ im Review-Workflow, automatische Hinzufügung zur Assignee-Liste, wenn eine Aufgabe in den „Design Review“ wechselt, sowie Berichte über die Aktivität jeder Rolle bei architektonischen Entscheidungen.

OCM ersetzt TOGAF nicht – es macht ihn anwendbar. Ohne OCM bleiben architektonische Regeln Empfehlungen. Mit ihm werden sie Teil der operativen Realität.

Automatisierung als Bindeglied zwischen Objekten und Bedeutungen

Automatisierung ist nicht nur Bequemlichkeit; sie ist der einzige Weg, architektonische Einschränkungen irreversibel und messbar zu machen. Das Hauptprinzip: Wenn eine Regel nicht automatisch in CI/CD oder Jira überprüft werden kann, funktioniert sie nicht.

Beispiele für die Umsetzung:

# Überprüfung des ADR vor Beginn der Pipeline
if [ ! -f "docs/architecture/adr-$(echo $CI_COMMIT_TAG | cut -d'-' -f2).md" ]; then
  echo "FEHLER: Fehlender ADR für Tag $CI_COMMIT_TAG"
  exit 1
fi

# Jira-Workflow: Eine Aufgabe kommt erst in den ‚Ready for Dev‘-Status, wenn folgende Felder ausgefüllt sind:
# - ‚Architecture Decision Record ID‘
# - ‚Data Domain Owner‘
# - ‚Security Review Status‘ = ‚Approved‘

# Automatische OpenAPI v3.1-Validierung: Einhaltung interner Versionierungsstandards
# und obligatorische securitySchemes
import openapi_spec_validator
from openapi_spec_validator import validate_spec
spec = load_spec('openapi.yaml')
assert spec['info']['version'].startswith('v2.'), "API-Version muss v2.x sein"
assert 'securitySchemes' in spec.get('components', {}), "Fehlende securitySchemes"

Solche Automatisierungen nehmen kognitive Last ab, schaffen eine Single Source of Truth und fördern eine Kultur der Verantwortlichkeit. Entwickler brechen die Regel nicht – sie können sie einfach nicht brechen, ohne die Prüfung explizit zu deaktivieren und zu erklären, warum.

Was wirklich zählt

• Die Lücke zwischen Discovery und Delivery ist ein systemisches Problem, nicht mangelnde Kompetenz: Sie entsteht durch das Fehlen formalisierter Interaktionsprozesse zwischen EA, SolA und DevOps.
• TOGAF Phase H bietet einen ingenieurtechnischen Rahmen für das Management architektonischer Objekte: Prinzipien, Standards, Artefakte und Metriken.
• Organizational Change Management sorgt dafür, dass Menschen diese Objekte durch wertebasierte Kommunikation, kontextspezifische Schulungen und rollenbasiertes Engagement annehmen.
• Automatisierung in CI/CD, Jira und Repositories ist kein optionaler Luxus – sie ist ein Muss in der IT-Governance: Nur so können wir die Einhaltung von Regeln im täglichen Betrieb garantieren.
• Der Architekt-Methodolog ist eine Funktion, nicht eine Position: Er beherrscht sowohl das Objektmodell (TOGAF, ArchiMate) als auch die Verhaltenspraktiken (OCM) und weiß, wie man sie durch technische Implementierung miteinander verbindet.

IT-Governance beginnt nicht damit, ein Gremium einzurichten, sondern mit der Implementierung einer einzigen automatisierten Regel – zum Beispiel der Überprüfung von ADRs in CI. Der Rest ist Skalierung dieser Praxis: weitere Checks hinzufügen, Rollen erweitern, Qualitäts- und Sicherheitsmetriken integrieren. Der Schlüssel liegt darin, Architektur nicht als Präsentation stehen zu lassen – sie muss in Code, Pipelines und Workflows eingewoben werden. Nur dann hört sie auf, Folien zu sein, und beginnt, zu regieren.

— Editorial Team