04Interne Anwendung · Governance

IT-Reife- und Governance-Cockpit

Eine Webanwendung überführt IT-Reife, Governance und Integrationsbereitschaft aus einer tabellenbasierten Arbeitsweise in versionierte Assessments, Maßnahmen, Risikoakzeptanzen und belastbares Reporting.

Zeitraum
2026
Status
Anonymisierte Fallstudie
Meine Rolle
End-to-End-Entwicklung und Domain Design

01 — Ausgangslage

Problem & Kontext

Bewertungen zu IT-Reife und Governance wurden ursprünglich in Tabellen erfasst. Mit wachsender fachlicher Tiefe wurden Versionierung, Zuständigkeiten und die konsistente Berechnung von Ergebnissen zunehmend schwer nachvollziehbar.

Die Anwendung bildet Assessments, Maßnahmen und zeitlich begrenzte Risikoakzeptanzen in einem gemeinsamen Domänenmodell ab. Historische Bewertungsstände bleiben erhalten und können für Reporting und Audit-Trails ausgewertet werden.

Professionelle Rahmenbedingungen

  • Bewertung, Maßnahmenstatus und Risikoakzeptanz folgen unterschiedlichen Regeln und dürfen nicht zu einem irreführenden Gesamtergebnis vermischt werden.
  • Historische Assessment-Stände müssen auch dann belastbar bleiben, wenn sich Kontrollrahmen oder Organisationen später verändern.
  • Parallele Bearbeitung braucht kontrollierte Konflikterkennung statt stiller Überschreibung.
  • Jeder fachliche API-Zugriff muss standardmäßig geschützt sein und bei unklarer Berechtigung geschlossen ablehnen.

02 — Verantwortung

Meine Rolle

Ich habe die Anwendung end-to-end konzipiert und umgesetzt: Domänenmodell, Benutzeroberfläche, Backend und API-Verträge, Datenbankregeln, Sicherheitsgrenzen, Tests sowie Azure-Infrastruktur und Delivery.

  1. 01Modellierung von Assessments, Kontrollen, Maßnahmen und Risikoakzeptanzen
  2. 02Entwurf von Architektur, API-Verträgen und Datenbankinvarianten
  3. 03Umsetzung von Benutzeroberfläche, Backend und technischen Sicherheitsregeln
  4. 04Teststrategie für Bewertung, Autorisierung und historische Daten
  5. 05Azure-Infrastruktur und freigabegesteuerter Delivery-Prozess

03 — Umsetzung

Ansatz & Entscheidungen

Die fachlichen Regeln wurden aus der Oberfläche und einzelnen Tabellenformeln in explizite, testbare Domänenlogik verschoben. Frontend und Backend teilen einen versionierten OpenAPI-Vertrag, während Datenbankregeln und Nebenläufigkeitskontrollen kritische Zustände zusätzlich absichern.

D01

Bewertung und Risiko getrennt halten

Eine akzeptierte Abweichung dokumentiert eine bewusste Entscheidung, verändert aber nicht rückwirkend den tatsächlichen Reifegrad. Beide Perspektiven bleiben im Modell und im Reporting getrennt sichtbar.

D02

Historische Zustände erhalten

Abgeschlossene Bewertungszyklen werden als belastbare historische Stände behandelt. Änderungen am aktuellen Kontrollrahmen überschreiben deshalb keine früheren Ergebnisse.

D03

Geschützte API als Standard

Autorisierung wird serverseitig durchgesetzt. Automatisierte Prüfungen erkennen ungeschützte HTTP-Endpunkte, damit neue Funktionen nicht versehentlich außerhalb des Rollenmodells verfügbar werden.

D04

Verträge gegen Schnittstellendrift

Ein generierter TypeScript-Vertrag aus OpenAPI verbindet Frontend und Backend. Änderungen an Requests, Antworten oder Fehlerfällen werden so früh im Build statt erst während der Nutzung sichtbar.

04 — Technologie

Technischer Rahmen

  • Vue 3
  • TypeScript
  • OpenAPI
  • C#
  • .NET
  • Azure Functions
  • PostgreSQL
  • Microsoft Entra ID
  • Bicep
  • Azure DevOps

05 — Rückblick

Ergebnis & Erkenntnisse

Aus einer tabellenbasierten Bewertung entstand eine nachvollziehbare Anwendung mit expliziten Geschäftsregeln, rollenbasierten Arbeitsbereichen und historisch belastbarem Reporting.

Bewertungen, offene Maßnahmen und akzeptierte Risiken können getrennt betrachtet werden, ohne den Zusammenhang innerhalb eines Assessment-Zyklus zu verlieren.

  • L01Komplexe Bewertungssysteme brauchen ein explizites Domänenmodell statt verteilter Berechnungslogik in Oberfläche und Tabellen.
  • L02Risikoakzeptanz ist eine Governance-Entscheidung und kein Ersatz für den gemessenen Ist-Zustand.
  • L03Historisierung muss fachlich definiert sein, bevor technische Snapshot- oder Audit-Mechanismen belastbar werden.
  • L04Sicherheitsreviews wirken am besten, wenn ihre Erkenntnisse als automatisierte Guardrails im Projekt bleiben.