PROYECTOS PÚBLICOS

Proyectos

Selección de proyectos públicos en los que desarrollo soluciones de Data Governance, automatización y arquitectura de datos. Cada caso resume el problema que aborda, el enfoque seguido y las decisiones principales, con el repositorio disponible para revisar la implementación en detalle.

En desarrollo

collibra-governance-automation

Collibra Governance Automation

v2.0.0

Motor open source de Governance-as-Code en Python con Provider SDK público (API 1), configuración neutral respecto al proveedor, provenance y authority de metadatos, conflicts, lineage, impact y drift, planificación determinista y reconciliación segura con Collibra — dry-run por defecto, preflight y autorización explícita. Proveedor externo de referencia: governance-provider-example.

Qué problema resuelve

PostgreSQL, ODCS, dbt y OpenLineage describen partes distintas del mismo ecosistema. El problema no es simplemente reunir esos metadatos, sino darles una identidad común, conservar de dónde proceden, analizar authority y conflictos, y entender impacto y drift antes de llevar cambios a una plataforma de gobierno.

Cómo lo he planteado

El proyecto combina Governance-as-Code, change intelligence y un Provider SDK extensible (API 1). Construye un núcleo de gobierno neutral, analiza provenance, authority, conflicts, lineage, impact y drift, prepara planes deterministas y solo entonces reconcilia con Collibra — dry-run por defecto, preflight y autorización explícita para mutaciones. Un proveedor externo de ejemplo (governance-provider-example) demuestra el mismo modelo de registro público.

En desarrollo

purview-governance-automation

Microsoft Purview Governance Automation

v1.2.0

Governance-as-Code en Python para Microsoft Purview v1.2.0: desired state, remote state con alcance por permisos, comparación y planificación deterministas, Scanning & Classification, Unified Catalog (Public Preview, contrato v3), dry-run por defecto, protección stale-state, fail-closed y controlled apply con autorización explícita. Contratos offline ≠ validación contra tenant real.

Qué problema resuelve

Cuando la configuración de Purview se mantiene mediante operaciones manuales o scripts directos, resulta difícil saber qué debería existir, qué ha cambiado realmente y qué se va a modificar en cada ejecución.

Cómo lo he planteado

El proyecto parte de una configuración deseada, observa el estado real de Purview, clasifica las diferencias y genera un plan determinista. Antes de escribir vuelve a consultar el entorno y bloquea la ejecución si el estado ya no coincide con el contexto para el que se creó el plan.