Pular para o conteúdo principal

Compreender o Metamodelo Orientado a Dados

A maioria das ferramentas de EA codifica o seu modelo de objetos diretamente no código-fonte da aplicação. O Canopy adota uma abordagem diferente: todos os conceitos estruturais — tipos de cartão, campos, subtipos, relações, funções de partes interessadas e campos calculados — são armazenados como dados na base de dados, não como código. Esta página explica porque foi tomada essa decisão e o que significa na prática.

O que é o metamodelo​

O metamodelo é o esquema do seu modelo de EA. Define:

  • Tipos de cartão — os tipos de entidades que acompanha (Application, BusinessCapability, Initiative, etc.)
  • Campos — as propriedades que essas entidades podem conter (estado do ciclo de vida, custo, responsável, pilha tecnológica, etc.)
  • Subtipos — variantes mais detalhadas de um tipo que partilham o mesmo conjunto de campos (por exemplo, Application → Microservice, SaaS, AI Agent)
  • Tipos de relação — as ligações permitidas entre tipos (Application "executa em" ITComponent, Initiative "concretiza" BusinessCapability, etc.)
  • Funções de partes interessadas — as funções que os utilizadores podem desempenhar num cartão específico (Responsável Técnico, Responsável de Negócio, Gestor de Dados, etc.)
  • Campos calculados — fórmulas que derivam valores de campo a partir de outros dados no momento de guardar

Todos estes elementos são linhas em card_types, relation_types e colunas JSONB associadas. Nenhum deles requer uma alteração de código ou o reinício da aplicação para ser modificado.

Porquê dados e não código?​

Personalização sem ramificações​

As diferentes organizações têm metamodelos de EA muito distintos. Algumas equipas acompanham "Fornecedor", "Licença" e "SLA". Outras acompanham "Domínio de Dados", "Capacidade ESG" e "Cadeia de Valor". Se o metamodelo fosse código, cada personalização exigiria uma ramificação do produto ou um sistema de extensões — ambos com custos elevados de manutenção.

Com um metamodelo orientado a dados, um administrador pode adicionar um novo campo, renomear um tipo de cartão ou definir um tipo de relação personalizado em minutos, através da interface ou da API. O frontend adapta-se automaticamente: a grelha de Inventário ganha uma nova coluna, a página de Detalhe do Cartão exibe a nova secção, e os relatórios podem filtrar pelo novo campo. Sem necessidade de nova implementação.

Evolução do esquema sem migrações por cliente​

Quando o Canopy lança um novo tipo de cartão ou campo integrado, fá-lo através de seed.py — uma rotina de arranque que verifica se a linha integrada existe e só a cria se estiver em falta. As personalizações existentes nunca são alteradas. Isto significa que:

  • Atualizar o Canopy não substitui os seus campos personalizados
  • Os tipos integrados continuam a ser editáveis (pode alterar o ícone, a cor ou o nome de "Application" sem criar uma ramificação)
  • Se um valor predefinido integrado se desviar do valor original, uma migração Alembic condicionada corrige apenas as linhas não modificadas

Multi-arrendamento num único código-fonte​

Como o metamodelo é dados, uma única implementação do Canopy pode servir equipas com modelos de objetos completamente diferentes — ou a mesma implementação pode ser reconfigurada inteiramente sem tocar no código-fonte.

A estrutura fields_schema​

Cada tipo de cartão armazena as suas definições de campo como uma matriz JSONB de secções:

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

O weight em cada campo alimenta a pontuação de qualidade de dados — os cartões são pontuados entre 0 e 100% com base na quantidade de campos ponderados que estão preenchidos. Isto transforma o metamodelo num mecanismo de controlo de qualidade: define o que são "bons" dados atribuindo pesos mais elevados aos campos mais importantes.

O que não pode ser alterado através do metamodelo​

O metamodelo governa a forma, não o comportamento. Alguns aspetos permanecem no código:

  • O motor de cálculo — a sandbox segura que avalia fórmulas é uma biblioteca Python (simpleeval). As fórmulas em si são dados, mas o avaliador é código.
  • O sistema de permissões — o conjunto de chaves de permissão válidas é uma lista de permissões em backend/app/core/permissions.py. Adicionar uma nova chave de permissão (não apenas concedê-la) requer uma alteração de código.
  • O esquema de base de dados — adicionar uma nova tabela de nível superior (por exemplo, um novo módulo como PPM ou GRC) requer uma migração Alembic. O esquema de atributos de cartão expande-se sem migrações porque os atributos são JSONB.

Consulte também​