Zum Hauptinhalt springen

Das datengesteuerte Metamodell verstehen

Die meisten EA-Werkzeuge kodieren ihr Objektmodell fest im Anwendungsquellcode. Canopy verfolgt einen anderen Ansatz: Jedes strukturelle Konzept – Kartentypen, Felder, Subtypen, Relationen, Stakeholder-Rollen und berechnete Felder – wird als Daten in der Datenbank gespeichert, nicht als Code. Diese Seite erklärt, warum diese Entscheidung getroffen wurde und was sie in der Praxis bedeutet.

Was das Metamodell ist​

Das Metamodell ist das Schema Ihres EA-Modells. Es definiert:

  • Kartentypen – die Arten von Entitäten, die Sie verwalten (Application, BusinessCapability, Initiative usw.)
  • Felder – die Eigenschaften, die diese Entitäten besitzen können (Lebenszyklusstatus, Kosten, Eigentümer, Technologie-Stack usw.)
  • Subtypen – feinkörnige Varianten eines Typs, die dasselbe Feldset teilen (z. B. Application → Microservice, SaaS, AI Agent)
  • Relationstypen – die erlaubten Kanten zwischen Typen (Application „läuft auf" ITComponent, Initiative „realisiert" BusinessCapability usw.)
  • Stakeholder-Rollen – die Rollen, die Benutzer auf einer bestimmten Karte einnehmen können (Technical Owner, Business Owner, Data Steward usw.)
  • Berechnete Felder – Formeln, die Feldwerte beim Speichern aus anderen Daten ableiten

All diese Elemente sind Datensätze in card_types, relation_types und zugehörigen JSONB-Spalten. Keine davon erfordert eine Codeänderung oder einen Neustart der Anwendung, um sie zu ändern.

Warum Daten statt Code?​

Anpassung ohne Forks​

Verschiedene Organisationen haben sehr unterschiedliche EA-Metamodelle. Manche Teams verwalten „Vendor", „License" und „SLA". Andere verwalten „Data Domain", „ESG Capability" und „Value Stream". Wenn das Metamodell Code wäre, würde jede Anpassung entweder einen Fork des Produkts oder ein Plugin-System erfordern – beides ist aufwändig zu warten.

Mit einem datengesteuerten Metamodell kann ein Administrator innerhalb von Minuten über die Benutzeroberfläche oder die API ein neues Feld hinzufügen, einen Kartentyp umbenennen oder einen benutzerdefinierten Relationstyp definieren. Das Frontend passt sich automatisch an: Das Inventarraster erhält eine neue Spalte, die Kartendetailseite zeigt den neuen Abschnitt, und die Berichte können nach dem neuen Feld filtern. Kein Deployment erforderlich.

Schema-Evolution ohne kundenspezifische Migrationen​

Wenn Canopy einen neuen integrierten Kartentyp oder ein neues Feld ausliefert, geschieht dies über seed.py – eine Startroutine, die prüft, ob die integrierte Zeile vorhanden ist, und sie nur dann erstellt, wenn sie fehlt. Bestehende Anpassungen werden nie verändert. Das bedeutet:

  • Ein Upgrade von Canopy überschreibt Ihre benutzerdefinierten Felder nicht
  • Integrierte Typen bleiben bearbeitbar (Sie können Symbol, Farbe oder Bezeichnung von „Application" ändern, ohne einen Fork zu erstellen)
  • Wenn ein integrierter Standardwert von seinem ursprünglichen Wert abweicht, korrigiert eine überwachte Alembic-Migration nur die unveränderten Zeilen

Mehrmandantenfähigkeit in einer einzelnen Codebasis​

Da das Metamodell Daten sind, kann eine einzige Canopy-Bereitstellung Teams mit völlig unterschiedlichen Objektmodellen bedienen – oder dieselbe Bereitstellung kann vollständig neu konfiguriert werden, ohne die Codebasis zu berühren.

Die fields_schema-Struktur​

Jeder Kartentyp speichert seine Felddefinitionen als JSONB-Array von Abschnitten:

[
  {
    "section": "Technology",
    "columns": 2,
    "fields": [
      {
        "key": "techStack",
        "label": "Technology Stack",
        "type": "multiple_select",
        "options": [{"key": "java", "label": "Java"}, {"key": "python", "label": "Python"}],
        "weight": 2
      }
    ]
  }
]

Das weight auf jedem Feld fließt in den Datenqualitätsscore ein – Karten werden mit 0–100 % bewertet, basierend darauf, wie viele gewichtete Felder ausgefüllt sind. Damit wird das Metamodell zu einem Qualitätssicherungsmechanismus: Sie definieren, wie „gute" Daten aussehen, indem Sie den wichtigsten Feldern höhere Gewichtungen zuweisen.

Was Sie über das Metamodell nicht ändern können​

Das Metamodell regelt die Form, nicht das Verhalten. Einige Dinge verbleiben im Code:

  • Die Berechnungsmaschine – die sichere Sandbox, die Formeln auswertet, ist eine Python-Bibliothek (simpleeval). Die Formeln selbst sind Daten, aber der Auswertungsmodul ist Code.
  • Das Berechtigungssystem – die Menge gültiger Berechtigungsschlüssel ist eine Allowlist in backend/app/core/permissions.py. Das Hinzufügen eines neuen Berechtigungsschlüssels (nicht nur dessen Vergabe) erfordert eine Codeänderung.
  • Das Datenbankschema – das Hinzufügen einer neuen Tabelle auf oberster Ebene (z. B. ein neues Modul wie PPM oder GRC) erfordert eine Alembic-Migration. Das Kartenattributschema erweitert sich ohne Migrationen, da Attribute JSONB sind.

Siehe auch​