Einfache Stewardship-Lösungen selbst bauen, wenn kein Tool passt

Niemand will „Steward für alle Mappings“ von sales_otc sein — deshalb bleiben INLINE und CSV. Einfaches Stewardship startet mit wenigen kritischen Control Products, nicht mit einem MDM-Programm.

zuerst und optionale UIs nur, wenn der Pflegeprozess passt. Viele Teams bleiben danach stecken: das Grid-Tool fällt bei Validierung oder AuthZ-Review durch; MDM kaufen ist ein Mehrjahresprogramm; Excel bleibt der inoffizielle Schreibpfad, weil „wir brauchen kurzfristig etwas.“.

Lösung: Wenn kein Tool passt, bauen Sie die kleinste Oberfläche, die Persistenz, validierte Writes, Audit, Consumer-Vertrag und AuthZ liefert.

In einem Satz: Wenn kein Tool passt, bauen Sie die kleinste Oberfläche, die Persistenz, validierte Writes, Audit, Consumer-Vertrag und AuthZ liefert.

Problem

Teil 6 empfahl PostgreSQL zuerst und optionale UIs nur, wenn der Pflegeprozess passt. Viele Teams bleiben danach stecken: das Grid-Tool fällt bei Validierung oder AuthZ-Review durch; MDM kaufen ist ein Mehrjahresprogramm; Excel bleibt der inoffizielle Schreibpfad, weil „wir brauchen kurzfristig etwas.“

Dieser Stillstand reproduziert die Failure Modes aus früheren Teilen. Inline-Tabellen verstecken geteilte Wahrheit. Datei-als-Quelle bricht Pipelines bei Umbenennung und Locale. Schatten-Workbooks driften. Zugangsmatrizen leben in E-Mails. Governance wirkt im Katalog vollständig, während der Schreibpfad noch ein persönlicher SharePoint-Link ist.

Das gegenteilige Versagen ist Scope-Explosion. „Wir bauen unser eigenes MDM“ wächst Golden-Record-Matching, Survivorship, Multi-Domain-Hubs und UI-Frameworks, bevor das erste Status-Mapping einen stabilen Schlüssel und ein Audit-Log hat. Steuertabellen brauchen diese Oberfläche nicht.

Die praktische Lücke ist schmal: Fachbereiche müssen eine kleine Menge Tabellen sicher ändern; Consumer müssen einen stabilen Vertrag lesen; Auditoren müssen sehen, wer was geändert hat. Technologie ist austauschbar. Der Vertrag ist es nicht.

Entscheidung

Wenn kein Tool passt, bauen Sie die kleinste Oberfläche, die Persistenz, validierte Writes, Audit, Consumer-Vertrag und AuthZ liefert. Ergänzen Sie Freigabe nur dort, wo das Risiko des Assets es verlangt. Bleiben Sie bei Steuertabellen — nicht bei Golden-Record-MDM.

Nutzen Sie diesen DIY-Pfad, wenn:

• Domain-Regeln (Gültigkeitsfenster, Cross-Field-Checks, geschlossene Mengen) nicht in ein generisches Grid passen;
• sensible Berechtigungs nicht in einer Low-Code-Black-Box leben dürfen;
• das Team SQL plus eine dünne App betreiben kann, aber kein MDM-Programm;
• der Zeitrahmen Wochen sind, keine Quartale;
• die UI-Fit-Bewertung aus Teil 6 gescheitert ist und Excel die einzige verbleibende Alternative ist.

Die Platzierung bleibt wie in Wohin Steuerdaten gehören entschieden: meist Postgres. Stack-Defaults bleiben wie in Open-Source-Optionen für Steuerdaten. DIY ersetzt den Schreibpfad, nicht die Persistenzentscheidung.

Minimale Oberfläche (sechs Fähigkeiten)

1. Persistenz — Postgres-Tabellen, stabile Schlüssel, valid_from / valid_to, wenn Historie zählt.
2. Write-API oder Formular — Create/Update mit serverseitiger Validierung (Constraints + Anwendungsregeln).
3. Audit — wer / wann / was (append-only Change Log oder temporale Tabelle).
4. Consumer-Vertrag — stabile View oder API; nie rohe Edit-Spalten als Vertrag.
5. AuthZ — Rollen, wer welche Tabelle pflegen darf; nicht „jeder mit dem Link.“
6. Optionale Freigabe — Draft → Approved nur für kritische Assets (Berechtigungs, regulatorische Listen).

Stufen A–D (keine Framework-Religion)

Starten Sie bei der niedrigsten Stufe, die Excel-als-Quelle entfernt. Bevorzugen Sie B gegenüber C, wenn Zeilenzahlen klein und Edits selten sind. Bevorzugen Sie C, wenn Stewards bereits große Mapping-Sheets pflegen und einen Reject-Report brauchen. Bevorzugen Sie D, wenn eine falsche Zeile Zugriff gewährt oder verweigert.

Skizze: Mapping-Tabelle und Audit

Nur illustrativ — kein Produkt-Repository.

-- Editable base (stewards write here via app / approved upload)
CREATE TABLE control_sales.status_map_base (
  status_code      text PRIMARY KEY,
  status_label     text NOT NULL,
  is_revenue       boolean NOT NULL DEFAULT false,
  valid_from       date NOT NULL DEFAULT CURRENT_DATE,
  valid_to         date,
  updated_at       timestamptz NOT NULL DEFAULT now(),
  updated_by       text NOT NULL,
  CHECK (valid_to IS NULL OR valid_to >= valid_from)
);

-- Published contract (consumers read only this)
CREATE VIEW control_sales.v_status_map AS
SELECT status_code, status_label, is_revenue, valid_from, valid_to
FROM control_sales.status_map_base
WHERE valid_to IS NULL OR valid_to >= CURRENT_DATE;

-- Append-only audit
CREATE TABLE control_sales.status_map_audit (
  audit_id     bigserial PRIMARY KEY,
  changed_at   timestamptz NOT NULL DEFAULT now(),
  changed_by   text NOT NULL,
  change_type  text NOT NULL CHECK (change_type IN ('insert','update','delete')),
  status_code  text NOT NULL,
  old_row      jsonb,
  new_row      jsonb
);

Skizze: Upload → validieren → commit (Stufe C)

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

1. Steward uploads template (stable columns: status_code, status_label, is_revenue, valid_from, valid_to)
2. Server parses rows; does not touch production yet
3. Validate:
   - required keys present
   - no duplicate status_code in file
   - boolean / date parse OK
   - FK / closed-set rules pass
   - AuthZ: steward may maintain this asset
4. If any row fails → reject report (row number, field, rule); zero commits
5. If all pass → transaction:
   - upsert base
   - write audit rows
   - optional: write draft until approver promotes (tier D)
6. Consumers keep reading v_status_map; reload after publish

Pseudocode für das Gate:

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

result = validate(rows, rules)
if result.errors:
  return RejectReport(result.errors)   # no partial commit
with transaction:
  upsert(base, rows)
  append_audit(actor, rows)
  if requires_approval:
    mark_draft(rows)
  else:
    publish_or_already_live()

Anti-Patterns

• Eine Web-UI, die unbeschränkten Text speichert — zweites Excel hinter einem Login.
• Low-Code ohne Schema-Migrationen und ohne getestetes Backup/Restore.
• „Wir bauen MDM“ — Matching, Survivorship und Multi-Hub-UI, bevor ein Mapping einen Vertrag hat.
• Nutzer lesen die Edit-Tabelle inklusive Draft- und Reject-Zeilen.
• DIY-Frameworks über jede Domain streuen, bevor der erste Pilot Dual-Run-Evidenz hat.
• AuthZ überspringen, weil „nur drei Leute die URL kennen.“

Entscheidungsregel

Bauen Sie die kleinste Oberfläche, die Validierung, Audit und Vertrag erfüllt. Das Framework können Sie später tauschen; den Vertrag nicht.

Teil 8 wendet dasselbe Produkt-Betriebsmodell auf DIY und gekaufte UIs an.

Checkliste

• UI-Fit aus Teil 6 gescheitert oder kein geeignetes Produkt vorhanden; DIY ist eine explizite Entscheidung, kein Drift.
• Umfang sind Steuertabellen, nicht Enterprise-Golden-Record-MDM.
• Alle sechs Minimalfähigkeiten sind benannt; Freigabe ist begründet oder explizit out of scope.
• Stufe A–D für das Pilot-Asset gewählt und dokumentiert.
• Stabile Schlüssel und veröffentlichte Nutzer-View existieren vor UI-Politur.
• Serverseitige Validierung lehnt schlechte Uploads/Edits mit klarem Report ab.
• Audit erfasst Actor, Zeit und Before/After für Produktionsänderungen.
• AuthZ ist rollenbasiert pro Asset-Familie.
• Excel/CSV nur als gestagter Input unter Stufe C, nie als führende Quelle.
• Do-not-build-Liste ist geschrieben und mit Sponsoren reviewed.
• Ein-Wochen-MVP-Cut ist vereinbart (Tabellen, Regeln, ein Nutzer).
• Dual-Run-Plan existiert, bevor Inline- oder Dateiquellen retired werden.

Artefakt

Erstellen Sie einen DIY Stewardship Blueprint für den Pilot.

Beispiel (Lehrfall, keine Kundendaten): Typisches Muster aus Governance-Projekten — im eigenen Umfeld durch Catalog-/BI-/Ticket-/Prozessquellen ersetzen.

# DIY Stewardship Blueprint — <asset_family>

## Why DIY
- tools evaluated / rejected:
- Excel risk if we wait:

## Capabilities
- [ ] persistence
- [ ] validated write path (API | form | upload)
- [ ] audit
- [ ] consumer contract (view/API name)
- [ ] AuthZ roles
- [ ] approval (yes/no + trigger)

## Tier
A | B | C | D — rationale:

## One-week MVP cut
- tables:
- validation rules (top 5):
- first consumer:
- success metric:

## Nicht bauen
- Matching / Survivorship / Multi-Domain-Hub
- generische Workflow-Engine für alle Daten
- Katalog ersetzen
- …

## Betrieb
- Repo- / Migrationspfad:
- Backup-verantwortliche Person:
- On-Call für Schreibpfad:
- Promote-to-Produktion-Prüfpunkt:

Tools

• PostgreSQL + Migrationen — Persistenz geteilt mit Teil 6.
• Dünner interner Stack, den Sie bereits betreiben (z. B. Laravel, FastAPI, Streamlit) — eine Seite statt einer neuen Plattform bevorzugen.
• Architecture Fit — DIY innerhalb der Platzierungsentscheidung halten.
• Reject-Report-Templates (CSV out) für Stufe-C-Stewards.

Ressourcen

• Serie: Steuer- und Referenzdaten Deep Dive
• Vorher: Open-Source-Optionen für Steuerdaten
• Platzierung: Wohin Steuerdaten gehören
• Weiter: Steuerdaten als Datenprodukte betreiben
• Excel-Schatten-BI und Kennzahlen-Drift
• Excel und CSV als führende Quelle zerstören Pipelines
• Fachlogik außerhalb der BI-Apps halten