Hop til hovedindhold

Forståelse af den datadrevne metamodel

De fleste EA-værktøjer hardkoder deres objektmodel i applikationens kildekode. Canopy tager en anden tilgang: ethvert strukturelt begreb — korttyper, felter, undertyper, relationer, interessentroller og beregnede felter — gemmes som data i databasen, ikke som kode. Denne side forklarer, hvorfor den beslutning blev truffet, og hvad det betyder i praksis.

Hvad metamodellen er​

Metamodellen er skemaet for din EA-model. Den definerer:

  • Korttyper — de typer entiteter, du sporer (Application, BusinessCapability, Initiative osv.)
  • Felter — de egenskaber, disse entiteter kan have (livscyklusstatus, omkostninger, ejer, teknologistak osv.)
  • Undertyper — detaljerede varianter af en type, der deler det samme feltsæt (f.eks. Application → Microservice, SaaS, AI Agent)
  • Relationstyper — de tilladte forbindelser mellem typer (Application "kører på" ITComponent, Initiative "realiserer" BusinessCapability osv.)
  • Interessentroller — de roller, brugere kan have på et bestemt kort (Technical Owner, Business Owner, Data Steward osv.)
  • Beregnede felter — formler, der udleder feltværdier fra andre data ved gemning

Alle disse er rækker i card_types, relation_types og tilhørende JSONB-kolonner. Ingen af dem kræver en kodeændring eller genstart af applikationen for at blive ændret.

Hvorfor data frem for kode?​

Tilpasning uden forks​

Forskellige organisationer har vidt forskellige EA-metamodeller. Nogle teams sporer "Vendor", "License" og "SLA". Andre sporer "Data Domain", "ESG Capability" og "Value Stream". Hvis metamodellen var kode, ville enhver tilpasning kræve enten en fork af produktet eller et plugin-system — begge dyre at vedligeholde.

Med en datadreven metamodel kan en administrator tilføje et nyt felt, omdøbe en korttype eller definere en brugerdefineret relationstype på få minutter via brugergrænsefladen eller API'et. Frontend tilpasser sig automatisk: inventartabellen får en ny kolonne, kortsiden viser det nye afsnit, og rapporterne kan filtrere på det nye felt. Ingen installation kræves.

Skemaevolution uden migrationer pr. kunde​

Når Canopy leverer en ny indbygget korttype eller et nyt felt, sker det via seed.py — en opstartsrutine, der kontrollerer, om den indbyggede række eksisterer, og kun opretter den, hvis den mangler. Eksisterende tilpasninger berøres aldrig. Det betyder:

  • Opdatering af Canopy overskriver ikke dine brugerdefinerede felter
  • Indbyggede typer forbliver redigerbare (du kan ændre ikonet, farven eller etiketten på "Application" uden at lave en fork)
  • Hvis en indbygget standardværdi afviger fra sin oprindelige værdi, korrigerer en beskyttet Alembic-migrering kun de upåvirkede rækker

Multi-tenancy i en enkelt kodebase​

Fordi metamodellen er data, kan en enkelt Canopy-installation betjene teams med helt forskellige objektmodeller — eller den samme installation kan rekonfigureres fuldstændigt uden at røre kodebasen.

Strukturen fields_schema​

Hver korttype gemmer sine feltdefinitioner som et JSONB-array af afsnit:

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

weight på hvert felt påvirker datakvalitetsscoren — kort scores fra 0 til 100 % baseret på, hvor mange vægtede felter der er udfyldt. Dette gør metamodellen til en mekanisme til kvalitetssikring: du definerer, hvad "gode" data ser ud ved at tildele højere vægte til de felter, der betyder mest.

Hvad du ikke kan ændre via metamodellen​

Metamodellen styrer form, ikke adfærd. Nogle ting forbliver i kode:

  • Beregnings­motoren — den sikre sandkasse, der evaluerer formler, er et Python-bibliotek (simpleeval). Formlerne selv er data, men evaluatoren er kode.
  • Tilladelsessystemet — sættet af gyldige tilladelsesnøgler er en tilladelsesliste i backend/app/core/permissions.py. Tilføjelse af en ny tilladelsesnøgle (ikke blot tildeling af den) kræver en kodeændring.
  • Databaseskemaet — tilføjelse af en ny øverste tabel (f.eks. et nyt modul som PPM eller GRC) kræver en Alembic-migrering. Kortattributskemaet udvides uden migreringer, fordi attributter er JSONB.

Se også​