Tooling-Blueprint on-prem (als Prinzip, nicht als Produktliste)

  • SCM und CI: Selbstverwaltete Plattform, Runner in kontrollierter Zone, Pipeline-Definitionen versioniert, Policy-as-Code für Sicherheitsregeln.

  • Artefakte: Interne Container-/Binary-Repos, signierte Artefakte, SBOM-Generierung, provenance-Metadaten.

  • Datasets/Modelle: Versionsverwaltung mit dedizierten Registern, Zugriffssteuerung, Prüfprotokolle je Version.

  • Doku als Code: Einheitlicher Build, überprüfbar, versioniert, mit statischen Prüfungen (Link-Checker, Linting).

  • Observability: Metriken, Logs, Traces on-prem, keine Abhängigkeit von externen SaaS-Diensten.

  • Reproduzierbarkeit: Toolchain-Versionen als Container, Build-Umgebungen deterministisch, Infra-as-Code für Deployments.

Souveränität als Ermöglicher von Intelligenz

Viele Unternehmen sehen Souveränität als Einschränkung. In sicherheitskritischen Umgebungen ist sie ein Beschleuniger: Wer Toolchain, Artefakte und Deployments selbst kontrolliert, kann Iterationen sicher und schnell fahren, ohne auf externe Freigaben oder Cloud-Verfügbarkeiten zu warten. On-premise, DSGVO-konform, ohne US-Cloud-Dependencies ist keine ideologische Entscheidung, sondern eine technische: Nur so lässt sich ein lückenloser Herkunfts- und Nachweispfad bauen, der im Ernstfall standhält.

Antipatterns, die Sie vermeiden sollten

  • Agile Theater: Dailys und Boards, aber keine technische DoD, keine Evidenz. Ergebnis: „falsche“ Geschwindigkeit.

  • Dokumentation im Big-Bang: Monate später Artefakte aus Commits herausdestillieren. Ergebnis: Lücken, Inkonsistenzen, Schmerz.

  • Über-Fragmentierung: 30 Microservices, 30 Auditpfade, 30 Deployments – niemand kann das betreiben oder prüfen.

  • MVP als Labordemo: Schön anzusehen, nicht deploybar, keine Evidenz. Ergebnis: Vertrauensverlust beim Betreiber.

  • Product-only Ownership: Features priorisieren, NFRs ignorieren. Ergebnis: Performance/Sicherheitsprobleme erst im Integrationssystem sichtbar.

Wie man startet: ein praktikabler Fahrplan für 90 Tage

  • Woche 1–2: Technical Owner benennen, Rollen klären. Definition of Done++ entwerfen. Compliance-Backlog anlegen.

  • Woche 3–4: Pipeline-Minimum aufbauen: Build, Tests, Doku-Build, Traceability-Generator, Artefakt-Signaturen. Alles on-prem.

  • Woche 5–6: Architektur-Schnittstellen als Verträge definieren, Contract-Tests hinzufügen. Erste Change Envelope skizzieren.

  • Woche 7–10: Erster Safety Slice bis Shadow Mode, inklusive Evidenzpaket. Audit-Dry-Run organisieren.

  • Woche 11–12: Release-Train-Takt festlegen, Baseline-Prozess testen, Metriken einführen.

FAQ

Frage: „Agil in regulierten Branchen – geht das nicht zwangsläufig gegen Stage-Gates?“
Antwort: Nein. Stage-Gates verschwinden nicht, aber sie werden planbar, wenn Sie die Gate-Artefakte inkrementell erzeugen. Ein Release-Train, der pro Zyklus ein vollständiges, wenn auch kleines Evidenzpaket liefert, ist agiler als eine Phase, in der drei Monate Code geschrieben und am Ende Doku improvisiert wird.

Frage: „Wie erkläre ich Prüfern Sprints, ohne Misstrauen zu ernten?“
Antwort: Sprints sind ein internes Taktmittel. Prüfer wollen Konsistenz und Nachvollziehbarkeit. Zeigen Sie die Pipeline, die zu jedem Sprint-Inkrement ein prüfbares Paket generiert (Code, Tests, Traceability, Reports, Signaturen). Bieten Sie Self-Service-Zugang zu Artefakten und planen Sie regelmäßige, kurze Review-Slots statt eines Big-Bang-Reviews.

Frage: „Worin unterscheidet sich Technical Ownership vom klassischen Software-Architekten?“
Antwort: Ein Architekt entwirft Strukturen. Ein Technical Owner besitzt Systemqualitäten und den Flow dahin: Definition of Done++, Test- und Evidenzarchitektur, Change Control, Toolchain-Policy, Audit-Schnittstelle. Er hat Mandat für Go/No-Go bei Änderungen, die NFRs oder Safety betreffen. Beides kann in einer Person liegen, aber die Ownership-Komponente ist operativer und verantwortet Lieferfähigkeit, nicht nur Design.

Frage: „Wie sieht ein MVP aus, wenn ich noch keine Sicherheitsfreigabe habe?“
Antwort: Ein MVP läuft in einer Umgebung mit begrenztem Risiko (Shadow/Advisory), hat kontrollierten Dateneingang (Read-Only), produziert vollständige Evidenz für seinen Scope und kann jederzeit abgeschaltet werden. Er enthält keine autonomen sicherheitskritischen Aktionen, aber er bildet End-to-End den späteren Weg ab – inklusive Deployment, Monitoring und Rückfallebenen.

Frage: „Wir haben bereits ein starres Wasserfall-Vorgehen. Wie migrieren wir, ohne Chaos zu erzeugen?“
Antwort: Beginnen Sie nicht mit einer Prozessrevolution. Führen Sie stattdessen drei technische Anker ein: Definition of Done++ (inkl. Evidenz), eine minimale on-prem Pipeline, die Artefakte generiert, und einen Release-Train mit Baselines. Danach ergänzen Sie den Compliance-Backlog und definieren die erste Change Envelope. So wird das bestehende Stage-Gate planbarer und später ersetzbar.

Schluss

Agilität in regulierten Branchen ist kein Widerspruch – sie ist eine Notwendigkeit. Wer Sicherheit, Auditierbarkeit und Souveränität von Anfang an konstruiert, kann in kurzen Takten liefern, Risiken kontrollieren und Prüfungen bestehen. Der Unterschied zwischen Agilität als Theater und Agilität als Lieferdisziplin liegt in der Technik: Definition of Done++, Architektur mit Änderungszonen, on-prem Toolchain, Traceability als Code und eine starke Technical Ownership. Souveränität ermöglicht Intelligenz – und vor allem ermöglicht sie, dass Ihre Software nicht nur entsteht, sondern auch verantwortbar betrieben wird.