Saltar al contenido principal

Comprensión del metamodelo basado en datos

La mayoría de las herramientas de AE codifican su modelo de objetos directamente en el código fuente de la aplicación. Canopy adopta un enfoque diferente: cada concepto estructural — tipos de tarjeta, campos, subtipos, relaciones, roles de partes interesadas y campos calculados — se almacena como dato en la base de datos, no como código. Esta página explica por qué se tomó esa decisión y qué implica en la práctica.

Qué es el metamodelo​

El metamodelo es el esquema de su modelo de AE. Define:

  • Tipos de tarjeta — los tipos de entidades que usted registra (Application, BusinessCapability, Initiative, etc.)
  • Campos — las propiedades que esas entidades pueden tener (estado del ciclo de vida, coste, propietario, pila tecnológica, etc.)
  • Subtipos — variantes más específicas de un tipo que comparten el mismo conjunto de campos (por ejemplo, Application → Microservice, SaaS, AI Agent)
  • Tipos de relación — los vínculos permitidos entre tipos (Application «corre sobre» ITComponent, Initiative «realiza» BusinessCapability, etc.)
  • Roles de partes interesadas — los roles que los usuarios pueden ejercer sobre una tarjeta concreta (Propietario técnico, Propietario de negocio, Custodio de datos, etc.)
  • Campos calculados — fórmulas que derivan valores de campo a partir de otros datos en el momento de guardar

Todo esto son filas en card_types, relation_types y columnas JSONB asociadas. Nada de ello requiere un cambio de código ni un reinicio de la aplicación para modificarse.

¿Por qué datos y no código?​

Personalización sin bifurcaciones​

Las organizaciones tienen metamodelos de AE muy distintos entre sí. Algunos equipos registran «Proveedor», «Licencia» y «SLA». Otros registran «Dominio de datos», «Capacidad ESG» y «Flujo de valor». Si el metamodelo fuera código, cada personalización requeriría una bifurcación del producto o un sistema de plugins — ambas opciones son costosas de mantener.

Con un metamodelo basado en datos, un administrador puede añadir un nuevo campo, renombrar un tipo de tarjeta o definir un tipo de relación personalizado en minutos a través de la interfaz de usuario o la API. El frontend se adapta automáticamente: la cuadrícula del Inventario gana una nueva columna, la página de detalle de la tarjeta muestra la nueva sección y los informes pueden filtrar por el nuevo campo. No se requiere ningún despliegue.

Evolución del esquema sin migraciones por cliente​

Cuando Canopy incorpora un nuevo tipo de tarjeta o campo integrado, lo hace a través de seed.py — una rutina de inicio que comprueba si la fila integrada existe y la crea solo si falta. Las personalizaciones existentes nunca se tocan. Esto significa:

  • Actualizar Canopy no sobreescribe sus campos personalizados
  • Los tipos integrados siguen siendo editables (puede cambiar el icono, el color o la etiqueta de «Application» sin hacer una bifurcación)
  • Si un valor predeterminado integrado se desvía de su valor original, una migración de Alembic protegida corrige únicamente las filas no modificadas

Multi-tenencia en un único código base​

Dado que el metamodelo es un dato, un único despliegue de Canopy puede dar servicio a equipos con modelos de objeto completamente distintos — o el mismo despliegue puede reconfigurarse por completo sin tocar el código base.

La estructura de fields_schema​

Cada tipo de tarjeta almacena sus definiciones de campo como un array JSONB de secciones:

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

El valor weight de cada campo alimenta la puntuación de calidad de datos — las tarjetas se puntúan del 0 al 100 % en función de cuántos campos ponderados están completados. Esto convierte el metamodelo en un mecanismo de control de calidad: usted define qué significa tener datos «buenos» asignando pesos más altos a los campos que más importan.

Qué no puede cambiar mediante el metamodelo​

El metamodelo gobierna la estructura, no el comportamiento. Algunas cosas permanecen en código:

  • El motor de cálculo — el entorno seguro que evalúa fórmulas es una biblioteca de Python (simpleeval). Las fórmulas en sí son datos, pero el evaluador es código.
  • El sistema de permisos — el conjunto de claves de permiso válidas es una lista de permitidos en backend/app/core/permissions.py. Añadir una nueva clave de permiso (no solo concederla) requiere un cambio de código.
  • El esquema de la base de datos — añadir una nueva tabla de nivel superior (por ejemplo, un nuevo módulo como PPM o GRC) requiere una migración de Alembic. El esquema de atributos de tarjeta se amplía sin migraciones porque los atributos son JSONB.

Véase también​