Zum Hauptinhalt springen

Governance im Engineering

Governance ist kein Gremium.

Governance ist die Struktur,
mit der Entscheidungen unter Risiko getroffen werden.

Ohne Governance entstehen:

  • implizite Architektur
  • inkonsistente Standards
  • politische Entscheidungen
  • steigende technische Schulden
  • nicht steuerbare Risiken

Mit zu viel Governance entstehen:

  • Bürokratie
  • langsame Delivery
  • Entscheidungsstau
  • Innovationshemmung

Die Herausforderung ist Balance.


1. Was Governance wirklich bedeutet

Governance beantwortet fünf Fragen:

  1. Wer darf entscheiden?
  2. Wer trägt das Risiko?
  3. Wer darf widersprechen?
  4. Wie werden Entscheidungen dokumentiert?
  5. Wie werden Abweichungen behandelt?

Governance ist Entscheidungsarchitektur.


2. Warum Governance notwendig ist

Je höher:

  • Risiko
  • Teamgröße
  • Systemkomplexität
  • Lebensdauer
  • regulatorische Anforderungen

desto wichtiger wird Governance.

In kleinen Teams funktioniert viel implizit.

In größeren Systemen führt implizite Steuerung zu:

  • Fragmentierung
  • Architektur-Zerfall
  • Sicherheitslücken
  • inkonsistenter Qualität

3. Governance ≠ Bürokratie

Governance bedeutet nicht:

  • endlose Meetings
  • PowerPoint-Boards
  • starre Prozesse
  • Freigaben für jede Kleinigkeit

Governance bedeutet:

  • klare Entscheidungsdomänen
  • dokumentierte Leitplanken
  • transparente Eskalationspfade
  • verbindliche Standards

Gute Governance reduziert Reibung.

Schlechte Governance erzeugt sie.


4. Typische Governance-Mechanismen

Governance kann sehr unterschiedlich aussehen.

Architektur-Governance

  • Architekturprinzipien
  • ADRs
  • Review-Gremien (leichtgewichtig)
  • klare Kontextgrenzen

Qualitäts-Governance

  • definierte Gates
  • Teststrategie
  • Security-Veto
  • Release-Kriterien

Betriebs-Governance

  • SLOs
  • Incident-Prozesse
  • Change-Freigaben
  • Rollback-Strategien

5. Governance je Qualitätsstufe

Stufe 1–2:

  • informelle Abstimmung
  • wenige verbindliche Leitplanken
  • hohe Flexibilität

Stufe 3:

  • dokumentierte Architekturprinzipien
  • klare Qualitätsgates
  • definierte Entscheidungsdomänen

Stufe 4:

  • formalisierte Freigaben
  • Security-Reviews
  • Nachweisbarkeit
  • strukturierte Change-Control

Stufe 5:

  • auditierbare Prozesse
  • dokumentierte Verantwortlichkeiten
  • Traceability
  • externe Prüfungen

Governance wächst mit Risiko.


6. Anti-Pattern

Governance als Machtinstrument

  • Architektur-Board blockiert Teams
  • Security als Verhinderer
  • QA als Gate ohne Dialog

Ergebnis:

  • Schattenarchitektur
  • Umgehungsstrategien
  • sinkende Motivation

Governance als Feigenblatt

  • Prinzipien existieren nur im Wiki
  • ADRs werden ignoriert
  • Standards sind optional
  • Veto wird überstimmt

Ergebnis:

  • Papier-Governance
  • steigende Systeminstabilität

7. Governance und Mandat

Governance funktioniert nur, wenn:

  • Rollen Mandat haben
  • Entscheidungsrechte respektiert werden
  • Eskalationspfade klar sind
  • Verantwortung nicht politisch verschoben wird

Governance ohne Mandat ist Dekoration.

Mandat ohne Governance ist Macht.


8. Leitfragen für Organisationen

  • Sind Architekturprinzipien verbindlich?
  • Wer darf ein Release stoppen?
  • Wer darf Qualität gegen Zeit priorisieren?
  • Sind Sicherheitsrisiken dokumentiert?
  • Gibt es einen klaren Eskalationspfad?
  • Werden Entscheidungen nachvollziehbar dokumentiert?

Wenn diese Fragen nicht klar beantwortet werden können, ist Governance schwach.


9. Minimal-Governance (praktisch)

Eine gesunde Minimal-Governance enthält:

  • klare Architekturprinzipien
  • ADRs für relevante Entscheidungen
  • definierte Quality Gates
  • dokumentierte Veto-Rechte
  • transparente Eskalationswege

Mehr braucht es oft nicht.


Kerngedanke

Governance ist kein Selbstzweck.

Sie ist Risikosteuerung.

Ohne Governance skaliert Chaos.
Mit überzogener Governance skaliert Bürokratie.

Gute Governance schafft:

  • Klarheit
  • Stabilität
  • Geschwindigkeit
  • Verantwortlichkeit
  • langfristige Systemgesundheit