Secretaría de Hacienda / Alcaldía de Armenia, Quindío

Arquitectura de Datos Institucional

Derivada del documento "ARQUITECTURA DE DATOS SECRETARÍA DE HACIENDA - ACTIVIDAD: HACIENDA INTELIGENTE" (Vigencia 2026). Metodología Capacity WORKS (GIZ) + Modelo EFQM.

2026 4 Capas Gobernanza Capacity WORKS
Versión: 1.0 (Baseline)
Estado: Aprobación Directiva
Clasificación: Pública / Interna
Owner: Jefatura Inteligencia Tributaria

1. Contexto Estratégico y Drivers

La presente arquitectura nace como requisito habilitante para la iniciativa "Hacienda Inteligente", alineada con el modelo de excelencia EFQM (gestión de calidad) y la metodología Capacity WORKS de la GIZ (gestión para el desarrollo sostenible). El objetivo es transformar la Secretaría de Hacienda (SH) en una entidad orientada a datos, con servicios proactivos, trazables y de alta calidad para el ciudadano.

DimensiónDefinición en la Arquitectura
Objetivo CentralSH Inteligente: Decisiones basadas en datos, servicios digitales proactivos, recaudo eficiente, control interno robusto.
Alcance FuncionalTributario (ICA, Predial), Catastro, Contratación, Talento Humano, Proyectos/Programas, Atención Ciudadana.
Principios RectoresUnicidad (SSOT) Trazabilidad Privacidad (Ley 1581) Interoperabilidad (ENI) Gobernanza Activa
Metodología BaseCapacity WORKS (GIZ): Mapa de Actores → Grupos de Valor/Interés → Necesidades → Arquitectura de Datos.

2. Panorama de Actores (Stakeholder Landscape)

El mapa de actores (diagrama "Cebolla" Capacity WORKS) define la frontera de la arquitectura, los flujos de datos y los requisitos de seguridad/acceso.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#1e3a5f', 'secondaryColor': '#2c5f8a', 'tertiaryColor': '#0096d6', 'background': '#ffffff', 'mainBkg': '#f8fafc', 'clusterBkg': '#eef4fa', 'fontFamily': 'Inter' }}}%% graph TB subgraph VETO["🛑 Jugadores Veto (Poder Bloqueo)"] CTRL[Organismos Control
Contraloría, Procuraduría] CONCEJO[Concejo Municipal] end subgraph KEY["🎯 Actores Clave (Centro)"] CIUD[Ciudadanos / Contribuyentes PN & PJ] PRED[Propietarios Predios] JEF[Jefatura Inteligencia Tributaria] end subgraph PRIMARY["🔵 Actores Primarios"] DEP[Dependencias Alcaldía] EMP[Empleados / Jubilados] FIN[Entidades Financieras] EPA[EPA / CRQ] URB[Urbanizadores / Constructores] ARR[Arrendatarios] end subgraph SECONDARY["🟣 Actores Secundarios"] DIAN[DIAN] BANREP[Banco República] MINHAC[MinHacienda / DNP] JUZ[Juzgados Civiles] INTL[Financiadores Internacionales] ASCAP[Asocapitales] end style VETO fill:#fee2e2,stroke:#ef4444,stroke-width:2px style KEY fill:#dbeafe,stroke:#3b82f6,stroke-width:3px style PRIMARY fill:#d1fae5,stroke:#10b981,stroke-width:2px style SECONDARY fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray: 5 5
Categoría Capacity WORKSActores RepresentativosRol en Arquitectura de Datos
Clave (Centro)Ciudadanos/Contribuyentes (PN/PJ), Propietarios Predios, Jefatura Inteligencia TributariaFuentes y Consumidores principales de Master Data (Ciudadano, Predio, Empresa) y Transaccional (Pagos, Trámites). Definen requisitos de calidad.
PrimariosDependencias Alcaldía, Empleados/Jubilados, Entidades Financieras, EPA, CRQ, Urbanizadores, ArrendatariosProductores/Consumidores operacionales. Alimentan Transacciones (Contratos, Nóminas, Recaudos) y consumen Reportes/BI.
SecundariosDIAN, Banco República, MinHacienda, Contralorías, Procuraduría, Juzgados, Financiadores InternacionalesConsumidores de Reportes Regulatorios y Fuentes de Reference Data (Listas restrictivas, CIIU, Normativa, Tasas).
Veto (Bloqueo)Organismos de Control (Contraloría, Procuraduría), Concejo MunicipalValidadores de Cumplimiento. Exigen Auditoría total, Linaje, Retención documental (AGN), Seguridad y Privacidad.

3. Arquitectura de Datos: Modelo de 4 Capas (Layered Architecture)

Separación de responsabilidades estilo Data Mesh / Layered Architecture para garantizar escalabilidad, gobernanza y evolución independiente de cada capa.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#1e3a5f', 'secondaryColor': '#2c5f8a', 'tertiaryColor': '#0096d6', 'background': '#ffffff', 'mainBkg': '#f8fafc', 'clusterBkg': '#eef4fa', 'fontFamily': 'Inter' }}}%% graph TB subgraph CONSUMO["📊 CAPA 4: CONSUMO Y SERVICIOS (Data Products)"] BI[Business Intelligence
Dashboards Ejecutivos / Operativos] API[APIs / Servicios Abiertos
Interoperabilidad ENI] PORTAL[Portal Ciudadano
Ventanilla Única / Chatbot] end subgraph GOBERNANZA["🛡️ CAPA 3: METADATOS Y GOBERNANZA (Transversal)"] CAT[Data Catalog / Diccionario
OpenMetadata / DataHub] LINEAGE[Linaje de Datos End-to-End
OpenLineage] QUALITY[Catálogo Calidad / Data Contracts
Great Expectations / Soda] GOV[Data Governance Board
Políticas / Stewards / DPIA] end subgraph ALMACENAMIENTO["🏪 CAPA 2: ALMACENAMIENTO Y PROCESAMIENTO (Plataforma)"] DW[(Data Lakehouse / DW
Delta Lake / Iceberg / Snowflake)] MDM[MDM Hub
Golden Records / Match-Merge] REF[Reference Data Hub
Catálogos Versionados / APIs] ODS[ODS / Staging Area
Raw / Bronze Layer] end subgraph FUENTES["🔌 CAPA 1: FUENTES Y CAPTURA (Sistemas Transaccionales)"] SRC1[Sistemas Tributarios
ICA / Predial] SRC2[Sistema Catastro / GIS
PostGIS / IGAC] SRC3[Sistema Contratación
SECOP / Local] SRC4[Sistema Talento Humano] SRC5[Sistemas Proyectos
Planeación / Seguimiento] SRC6[Canales Pago / Bancos
Pasarelas / Recibo] SRC7[Fuentes Externas
DIAN, IGAC, Registraduría] end SRC1 & SRC2 & SRC3 & SRC4 & SRC5 & SRC6 & SRC7 -->|Extracción Batch / CDC| ODS ODS -->|Limpieza / Match-Merge| MDM ODS -->|Validación / Carga| REF ODS -->|Carga Incremental| DW MDM -->|Dimensiones Conformadas| DW REF -->|Dimensiones Referencia| DW DW -->|Modelos Estrella / Data Marts| BI & API & PORTAL CAT -.->|Gobierna / Documenta| MDM & REF & DW & ODS LINEAGE -.->|Rastrea| MDM & REF & DW & ODS QUALITY -.->|Valida / Alerta| MDM & REF & DW & ODS GOV -.->|Define Políticas| MDM & REF & DW & ODS classDef layer4 fill:#dbeafe,stroke:#3b82f6,stroke-width:2px; classDef layer3 fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,stroke-dasharray: 5 5; classDef layer2 fill:#d1fae5,stroke:#10b981,stroke-width:2px; classDef layer1 fill:#f3f4f6,stroke:#6b7280,stroke-width:1px; class BI,API,PORTAL layer4; class CAT,LINEAGE,QUALITY,GOV layer3; class DW,MDM,REF,ODS layer2; class SRC1,SRC2,SRC3,SRC4,SRC5,SRC6,SRC7 layer1;
Patrón Arquitectónico

Se adopta un enfoque Lakehouse Moderno (Bronze → Silver → Gold) sobre almacenamiento objeto (S3/MinIO) con formatos abiertos (Delta Lake / Apache Iceberg). La Capa 3 (Metadatos) es transversal y gobierna todo el ciclo de vida. La Capa 2 incluye un MDM Hub activo para Master Data y un Reference Data Hub con APIs versionadas.

4.1 Capa Master Data (Datos Maestros) — "Única Fuente de Verdad (SSOT)"

Establece la golden record para las entidades nucleares. Garantiza unicidad, calidad, seguridad, auditoría y versionamiento histórico (SCD Tipo 2).

Entidad MaestraClave PKAtributos Críticos / Reglas de NegocioReglas de Oro (Best Practices del Documento)
Ciudadano
Eje Central
id_ciudadano Tipo/Nro Doc (Validado Registraduría), Nombre, Fechas, Dirección, Contacto, Email Unicidad: Match & Merge probabilístico (Nombre+Dir).
Privacidad: Encriptación PII, RBAC estricto (Solo Gestión Humana/Secretaría General).
Auditoría: SCD Tipo 2 (created_by, modified_by, vigencia).
Predio
Núcleo Catastral
id_predio Código Catastral (Único vs IGAC), Geometría (PostGIS), Área m², Uso Suelo, FK Ciudadano Integridad Espacial: Validación topológica PostGIS.
Código Único: Validación contra base IGAC.
FK Obligatoria: A Ciudadano vigente y activo.
Metadatos Uso Suelo: Clasificación oficial + fuente.
Empleado id_empleado ID Interno (≠ Doc Personal), Cargo/Dep Histórico, Contacto Corporativo (@alcaldia.gov.co) IAM Integration: Active Directory / Azure AD.
Versionado: Histórico cargos/dependencias (cargo_actual vs cargos_previos).
Seguridad: Permisos por rol.
Proveedor id_proveedor Razón Social, NIT (Validado DIAN), Categoría CIIU 4.0, Score Desempeño Validación NIT: Vigencia/Estado DIAN (activo, inhabilitado).
Scorecards: KPIs cumplimiento (Tiempo, Calidad).
Histórico: Contratos y cotizaciones (Auditoría relaciones).
Empresa
Agente Económico
id_empresa NIT, Tipo (Comercial/Industrial/ONG), Rep. Legal (Versionado), Certificaciones CamComercio Deduplicación vs Proveedor: Mapear NIT/RUT único.
Compliance: RUT actualizado obligatorio.
Rep. Legal: Versionar cambios y periodos vigencia.
Programa
Plan Gobierno
id_programa Objetivos SMART, KPIs, Dependencia Responsable (FK), Cronograma Versionado KPIs Documentados: En diccionario de datos.
Versionado: Alcance y presupuesto con ajustes.
Riesgos: Alertas desviación (Plazo/Costo) embebidas.
Proyecto id_proyecto Fases (Iniciación-Cierre), Presupuesto (Original vs Ejecutado), Estado Estandarizado Governance: Comité Seguimiento, Roles Aprobación (RACI).
Earned Value: % Avance Físico vs Financiero.
Estados: Planeado, En Curso, En Riesgo, Cerrado.
Implementación Técnica Recomendada

Desplegar MDM Hub en modo "Coexistence" o "Centralized" (ej. Semarchy, Reltio, Informatica, o Open Source: Apache Atlas + Reglas Custom). Sincronización bidireccional con sistemas transaccionales vía CDC (Change Data Capture). APIs de consulta unificada (GET /api/v1/ciudadanos/{id}) para consumidores internos/externos.

4.2 Capa Reference Data (Datos de Referencia) — "Estructura Semántica Común"

Catálogos estandarizados, versionados y gobernados que sirven como dominios de valor (Value Domains) y claves foráneas en toda la arquitectura. Aseguran consistencia semántica y operacional.

Dominio / CatálogoTabla EjemploAtributos ClaveFuente / Gobernanza
Ubicación GeográficaDepartamento, Municipio, Barrio, Comuna, Veredaid_ubicación, código_DANE, nivel, geometríaOficial: IGAC / DANE. Actualización Anual. Comité Geo.
Tipos de TrámiteTipo_Tramiteid_tipo_tramite, nombre, descripción, vigenciaComité Trámites (Ley 1755/2015). Versionado por decreto.
Clasificación PresupuestalClase_Gasto, Rubro_Presupuestalid_clase, id_rubro, nombre, fuente_normativaAlineado Ley 358/1997, DNP, CHIP. Gobernanza: Secretaría Hacienda.
Métodos de PagoMetodo_Pagoid_metodo_pago, nombre, detalle, activoSincronizado con Entidades Financieras / Pasarelas Pago.
Dependencias InternasDependenciaid_dependencia, nombre, nivel (Sec/Unidad)Maestría: Secretaría General / Talento Humano. Jerarquía orgánica.
Actividad EconómicaCodigo_CIIUid_ciiu, código, descripción, nivel (1-4 dígitos)Estándar Obligatorio: CIIU 4.0 (DANE).
Estados Proy/ProgramaEstado_Entidadid_estado, dominio (Proyecto/Programa), nombreValores fijos controlados: Planeado, En Curso, En Riesgo, Cerrado, Suspendido.
KPIs / MétricasKPI_Definicionid_kpi, nombre, unidad, fórmula, frecuencia, ownerDefinición técnica + Negocio (Data Dictionary). Aprobación Data Council.
Categorías ServicioCategoria_Servicioid_categoria, nombre, descripciónClasificación servicios municipales (Recolección, Infraestructura, etc.).

Lineamientos Técnicos de Implementación

4.3 Capa Transactional Data (Datos Transaccionales) — "Registro Operacional Inmutable"

Captura de eventos de negocio (OLTP) que alimentan tanto la operación diaria como los sistemas analíticos (Data Warehouse, BI). Modelo normalizado (3FN) en origen; dimensional (Kimball) en analítica.

Área FuncionalEntidades / Tablas CoreGranularidad / Clave NaturalReglas Críticas / SLAs
Pagos y Recaudos Pago_Impuesto, Pago_Servicio, Recaudo_Patrimonio id_pago (PK Surrogate) + recibo_número (Natural) Latencia BI: < 15 min (Near Real Time). CDC Obligatorio. Particionado por fecha_pago.
Trámites y Solicitudes Trámite, Solicitud, Registro_Ciudadano id_trámite + radicado SLA Estados: Radicado → En Trámite → Resuelto. Trazabilidad completa (Ley 1755).
Contratación Contrato, Adición_Presupuestal, Acta_Vinculación id_contrato + numero_proceso (SECOP) Integridad: FK Proveedor/Empleado vigentes. Audit Trail completo (Ley 80/93).
Servicios Ciudadanos Solicitud_Servicio, Atención_Servicio, Cierre_Servicio id_solicitud Canales: Web, Presencial, Móvil. Métricas: TAT, NPS, FCR (First Contact Resolution).
Gestión Proyectos Avance_Proyecto, Hito_Proyecto, Desembolso_Proyecto id_avance (FK Proyecto + Fecha) Earned Value: % Avance Físico vs Financiero. Alertas automáticas desviación > 10%.
Ejecución Programas Desembolso_Programa, Informe_KPI_Programa, Registro_Actividad id_desembolso, id_kpi (FK RefData) Resultados: Indicadores de Producto / Efecto / Impacto (Marco Lógico).
Auditoría Transaccional Log_Transacción (Tabla Unificada) id_log (BigSerial) Captura: Tabla Origen, Operación (I/U/D), Usuario, Timestamp, Before/After Image (JSONB). Inmutable.

Patrones Técnicos Obligatorios

Modelado y CDC
  • 3FN en OLTP; Estrella/Copo Nieve en DW.
  • CDC Log-based (Debezium) → Kafka/Redpanda → Lakehouse.
  • Particionamiento: Fecha + id_dependencia/id_comuna.
Seguridad y Validación
  • Column-level Encryption (PII). TLS 1.3.
  • Row-Level Security (RLS) por Dependencia/Rol.
  • Validaciones en origen (Front-end/API) + FK a Master/Ref Data.
Monitoreo y SLA
  • Dashboards operativos: Volumen por canal, Estado trámites, Desviaciones proyectos.
  • Alertas automáticas: Caída ETL, Alta tasa errores, Incumplimiento SLA (>15 min).
  • Retención Logs CDC: Equilibrio Trazabilidad vs Almacenamiento (Política 90 días hot, 7 años cold).
Legado y Migración
  • Patrón Strangler Fig: APIs Anti-Corruption Layer sobre sistemas legacy (FoxPro, VB6, Access).
  • Ingesta controlada por archivos planos/CSV validados si no hay API.
  • Priorizar migración fuentes críticas: Tributario, Catastro, Contratación.

4.4 Capa Metadatos (Metadata) — "Datos sobre los Datos (Gobernanza Transversal)"

Habilita auto-servicio, confianza, cumplimiento normativo (Ley 1712 Transparencia, Ley 1581 Protección Datos) y gestión del conocimiento organizacional.

Categoría MetadatoHerramienta / ArtefactoAlcance en Armenia
Diccionario Datos Físico/LógicoData Catalog (OpenMetadata / DataHub / Amundsen / Comercial)Definición técnica: Tipo, Longitud, Nulabilidad, Dominio (FK a RefData), Descripción Negocio.
Linaje de Datos (End-to-End)Lineage Viewer (Automatizado via parsers ETL/DBT/Airflow)Origen (Formulario Web / API Banco) → ETL → Staging → MDM/Ref → DW → Dashboard. Impact Analysis.
Políticas de RetenciónTabla Retention_Policy + Jobs Purge/Archive (Airflow)Ej: Expedientes Civiles 20 años, Logs Transaccionales 5 años, Datos Analíticos Indefinido. Cumple AGN (Res 090/2018).
Catálogo Calidad (DQ Rules)Great Expectations / Soda Core / Deequ / ElementaryReglas: Completitud (Email válido > 95%), Unicidad (NIT Proveedor), Validez (Código Catastral formato IGAC), Consistencia (Saldos).
Configuración ETL/ELT (Data Contracts)Orquestador (Airflow / Prefect / Dagster) + Repo Git (DBT)Jobs versionados: ETL_PREDIOS_DIARIO, CDC_PAGOS_STREAM. Parámetros, Alertas, Owners, Tests.
Modelos Físicos (DDL) / MigracionesRepo Git (Flyway / Liquibase / DBT) + Data CatalogEsquemas: raw, stg, mdm, ref, dw, audit. Migraciones controladas, revisionables.
Versionamiento Catálogos RefDataHistorial en Reference_Data_History + Data CatalogAuditoría: ¿Quién cambió el estrato del barrio X? ¿Cuándo? ¿Por qué decreto/acto administrativo?
Glosario de NegocioBusiness Glossary (Catálogo)Definiciones acordadas: "Programa", "Predio Mejorado", "Contribuyente Activo", "Recaudo Efectivo". Alineación Semántica.

Gobernanza de Metadatos (Operación)

Roles
  • Data Council / Board: Aprueba Glosario, Políticas, Calidad, Retención.
  • Data Stewards por Dominio: (Tributario, Catastro, Contratación, Talento Humano, Proyectos). Dueños de calidad.
  • Data Engineers: Implementan pipelines, linaje automatizado, tests calidad.
Privacidad y Seguridad
  • Etiquetado PII/Sensible: Auto-descubrimiento + Revisión Manual.
  • Políticas Acceso/Encriptación vinculadas a etiquetas en Catálogo.
  • DPIA Obligatorio para nuevos proyectos/procesos con datos personales.

5. Modelo Conceptual Entidad-Relación (Mermaid)

Modelo unificado derivado de las 4 capas. Muestra entidades núcleo (Master Data), sus relaciones transaccionales y vinculación a Reference Data. Notación Crow's Foot.

Modelo Conceptual Entidad-Relación

Secretaría de Hacienda - Alcaldía de Armenia, Quindío | Derivado de "Hacienda Inteligente 2026"

Capa: Master Data Capa: Reference Data Capa: Transactional
erDiagram %% ==================== ENTIDADES MAESTRAS (NÚCLEO) ==================== CIUDADANO { int id_ciudadano PK string tipo_documento string numero_documento UK string nombre date fecha_nacimiento string direccion string email string telefono string estado_vigencia string created_by datetime created_at string modified_by datetime modified_at } PREDIO { int id_predio PK string codigo_catastral UK int id_ciudadano FK string ubicacion_geom float area_m2 string uso_suelo int estrato int id_ubicacion FK string created_by datetime created_at string modified_by datetime modified_at } EMPLEADO { int id_empleado PK string nombre string cargo_actual date fecha_ingreso int id_dependencia FK string email_corp UK string created_by datetime created_at string modified_by datetime modified_at } PROVEEDOR { int id_proveedor PK string razon_social string nit UK string direccion string telefono string categoria_ciiu FK float score_desempeno string created_by datetime created_at string modified_by datetime modified_at } EMPRESA { int id_empresa PK string nombre string nit UK string tipo_empresa string direccion string representante_legal date fec_vigencia_rep_legal string created_by datetime created_at string modified_by datetime modified_at } PROGRAMA { int id_programa PK string nombre string descripcion string objetivo date fecha_inicio date fecha_fin string dependencia_responsable int id_empresa FK string created_by datetime created_at string modified_by datetime modified_at } PROYECTO { int id_proyecto PK string nombre string descripcion string objeto float presupuesto date fecha_inicio date fecha_fin string estado int id_programa FK int id_empresa FK string created_by datetime created_at string modified_by datetime modified_at } %% ==================== REFERENCE DATA (CATÁLOGOS) ==================== TIPO_TRAMITE { int id_tipo_tramite PK string nombre string descripcion boolean vigente } METODO_PAGO { int id_metodo_pago PK string nombre string detalle boolean activo } DEPENDENCIA { int id_dependencia PK string nombre string nivel int id_dependencia_padre FK } CODIGO_CIIU { int id_ciiu PK string codigo string descripcion int nivel } ESTADO_ENTIDAD { int id_estado PK string dominio string nombre } UBICACION_GEO { int id_ubicacion PK string codigo_dane string nombre int nivel string geom } KPI_DEFINICION { int id_kpi PK string nombre string unidad string formula string frecuencia } IMPUESTO { int id_impuesto PK string nombre string descripcion string tipo } CATEGORIA_SERVICIO { int id_categoria_servicio PK string nombre string descripcion } %% ==================== TRANSACCIONALES ==================== TRAMITE { int id_tramite PK int id_ciudadano FK int id_tipo_tramite FK date fecha_solicitud string estado string observaciones string created_by datetime created_at string modified_by datetime modified_at } PAGO_IMPUESTO { int id_pago PK int id_ciudadano FK int id_predio FK int id_impuesto FK float valor date fecha_pago int id_metodo_pago FK string recibo_numero UK string created_by datetime created_at string modified_by datetime modified_at } CONTRATO { int id_contrato PK int id_empleado FK int id_proveedor FK date fecha_inicio date fecha_final float valor_contrato string objeto string created_by datetime created_at string modified_by datetime modified_at } SOLICITUD { int id_solicitud PK int id_servicio FK int id_ciudadano FK date fecha_solicitud string estado string observaciones string created_by datetime created_at string modified_by datetime modified_at } SERVICIO { int id_servicio PK string nombre string descripcion int id_categoria_servicio FK } AVANCE_PROYECTO { int id_avance PK int id_proyecto FK date fecha_registro float porcentaje_avance string comentario string created_by datetime created_at } HITO_PROYECTO { int id_hito PK int id_proyecto FK string nombre date fecha_hito_planeada date fecha_hito_real string estado } DESEMBOLSO_PROYECTO { int id_desembolso PK int id_proyecto FK date fecha float monto string concepto } DESEMBOLSO_PROGRAMA { int id_desembolso PK int id_programa FK date fecha float monto } INFORME_KPI_PROGRAMA { int id_informe PK int id_programa FK int id_kpi FK date fecha_medicion float valor string observaciones } LOG_TRANSACCION { int id_log PK string tabla_origen string operacion string usuario datetime timestamp string datos_previos_json string datos_posteriores_json } %% ==================== RELACIONES ==================== %% Núcleo Ciudadano/Territorio CIUDADANO ||--o{ PREDIO : "posee" CIUDADANO ||--o{ TRAMITE : "solicita" CIUDADANO ||--o{ PAGO_IMPUESTO : "efectua" CIUDADANO ||--o{ SOLICITUD : "inicia" PREDIO }o--o{ IMPUESTO : "genera" TRAMITE }o--|| TIPO_TRAMITE : "clasifica" PAGO_IMPUESTO }o--|| METODO_PAGO : "usa" PAGO_IMPUESTO }o--|| PREDIO : "aplica_a" PAGO_IMPUESTO }o--|| IMPUESTO : "paga" %% Núcleo Talento Humano / Contratación EMPLEADO ||--o{ CONTRATO : "firma" CONTRATO }o--|| PROVEEDOR : "relaciona" EMPLEADO }o--|| DEPENDENCIA : "pertenece" %% Núcleo Servicios SERVICIO ||--o{ SOLICITUD : "atiende" SERVICIO }o--|| CATEGORIA_SERVICIO : "clasifica" %% Núcleo Planificación / Inversión EMPRESA ||--o{ PROGRAMA : "ejecuta" EMPRESA ||--o{ PROYECTO : "patrocina" PROGRAMA ||--o{ PROYECTO : "contiene" PROYECTO }o--|| ESTADO_ENTIDAD : "estado" PROGRAMA }o--|| ESTADO_ENTIDAD : "estado" %% Referencias Geográficas y Sectoriales PREDIO }o--|| UBICACION_GEO : "ubicado_en" PROVEEDOR }o--|| CODIGO_CIIU : "actividad_economica" EMPRESA }o--|| CODIGO_CIIU : "sector" %% KPIs y Avances AVANCE_PROYECTO }o--|| PROYECTO : "registra" HITO_PROYECTO }o--|| PROYECTO : "hito_de" DESEMBOLSO_PROYECTO }o--|| PROYECTO : "financia" DESEMBOLSO_PROGRAMA }o--|| PROGRAMA : "financia" INFORME_KPI_PROGRAMA }o--|| PROGRAMA : "mide" INFORME_KPI_PROGRAMA }o--|| KPI_DEFINICION : "indica"

Notación: Crow's Foot (Mermaid v10) | PK: Primary Key | FK: Foreign Key | UK: Unique Key

Entidades coloreadas por capa: Azul=Master Data · Ámbar=Reference Data · Verde=Transactional

6. Roadmap de Implementación (4 Fases)

Enfoque iterativo e incremental: Fundación → Quick Wins → Plataforma → Valor Analítico.

0

Fase 0: Fundación y Gobernanza (Meses 1-3)

Objetivo: Establecer mandato, roles y catálogos base.

  • Gobernanza: Data Governance Charter, Data Council formado, Data Stewards asignados por dominio.
  • Políticas: Seguridad/Privacidad (Ley 1581), Retención (AGN), Clasificación Datos, Acceso.
  • Reference Data Inicial: CIIU 4.0, DANE Geo, Tipos Trámite, Clasif. Presupuestal, Métodos Pago, Estados Proy. Versionados y con API.
  • Inventario: Catálogo de sistemas fuentes (Legado, Actuales, Externos), dueños, frecuencia, calidad percibida.
Wiki/Confluence Jira/GitLab DBT Docs
1

Fase 1: Quick Wins - Master Data Crítico (Meses 3-8)

Objetivo: Resolver duplicidad Ciudadano/Predio (Core Tributario). Habilitar "Ventanilla Única".

  • MDM Hub Operativo: Golden Record Ciudadano (Merge Registraduría + Catastro + Tributario + Talento Humano).
  • Golden Record Predio: Unificación IGAC + Catastro Local + Tributario. Validación geoespacial (PostGIS).
  • APIs Unificadas: GET /ciudadanos/{id}, GET /predios/{codigo_catastral} para consumidores.
  • Limpieza Masiva: Reglas Match & Merge, deduplicación NIT (Proveedor/Empresa), estandarización direcciones.
MDM: Semarchy / Reltio / Open Source DB: Postgres + PostGIS API Gateway: Kong / Apigee
2

Fase 2: Plataforma Analítica y Transaccionales (Meses 6-12)

Objetivo: Lakehouse moderno. Ingesta unificada (Batch + CDC). Modelos dimensionales certificados.

  • Arquitectura Medalión: Bronze (Raw/Staging) → Silver (Clean/Conformed/MDM) → Gold (Business/Dimensional).
  • Modelos Estrella (Kimball) Prioritarios: Recaudo, Trámites, Contratación, Proyectos, Predial.
  • CDC Streaming: Debezium (Fuentes Transaccionales) → Kafka/Redpanda → Lakehouse (Merge/Update Near Real Time).
  • Self-Service BI: Power BI / Superset / Metabase sobre capa Gold. Roles y RLS.
Storage: S3/MinIO (Delta/Iceberg) Compute: Spark/Flink/DuckDB/Snowflake Orquestación: Airflow/Prefect CDC: Debezium + Kafka
3

Fase 3: Metadata, Calidad Automatizada y Contratos (Meses 9-14)

Objetivo: Observabilidad total, confianza en datos, contratos entre productores/consumidores.

  • Data Catalog Poblado: Linaje automático (OpenLineage desde Airflow/DBT/Spark), Diccionario técnico/negocio.
  • Data Contracts: Esquemas versionados, SLAs de frescura/calidad, notificaciones de breaking changes.
  • Quality Gates en Pipeline: Great Expectations / Soda Core. Bloqueo promoción Silver→Gold si falla.
  • Dashboards Data Health: % tablas documentadas, frescura, volumen, tasas error, cumplimiento SLA.
Catalog: OpenMetadata / DataHub Quality: Great Expectations / Soda Contracts: DBT / OpenLineage
4

Fase 4: Servicios Inteligentes e IA (Meses 12+)

Objetivo: Valor analítico avanzado: Predictivo, Prescriptivo, Generativo.

  • Modelos Predictivos: Evasión ICA/Predial (Scoring contribuyentes), Riesgo Proveedores, Demanda Trámites, Sobrecostos Proyectos.
  • Asistente Ciudadano (RAG): Chatbot sobre Glosario, Normativa, Trámites, Estado solicitudes. Human-in-the-loop.
  • Next Best Action: Recomendaciones inspectores (Rutas, Priorización fiscalización), Gestores cobro.
  • Simulador Presupuestal/Escenarios: What-if análisis impacto tasas, inversión, coyuntura macro.
MLOps: MLflow / Kubeflow / Vertex AI LLM: RAG (LangChain/LlamaIndex) + Vector DB Feature Store: Feast / Hopsworks

7. Matriz de Riesgos y Mitigaciones Arquitectónicas

RiesgoImpactoProb.Mitigación Arquitectónica
Duplicidad Ciudadano/Predio (Fuentes dispares sin clave única confiable) Crítico Alta MDM Hub con Match/Merge probabilístico + Reglas determinísticas (Nro Doc, Cod Catastral). Validación Registraduría/IGAC en tiempo real (API). Steward dueño de "Golden Record".
Calidad Referencia desactualizada (CIIU, DANE, Tarifas, Estructuras orgánicas) Alto Media Automatización ingesta RefData (Web Services DANE/DIAN/IGAC/Secretaría General). Data Contracts con owners. Alertas automáticas caducidad versión. Comité Datos aprueba cambios.
Latencia Recaudo → BI > 24h (Cierres contables tardíos, decisiones reactivas) Crítico Media Arquitectura CDC (Debezium) + Streaming (Kafka) → Lakehouse (Merge/Update). SLA 15 min medido y alertado. Particionamiento óptimo. Índices en claves de consulta frecuente.
Fuga datos sensibles (PII Ciudadano/Empleado/Proveedor) Crítico Media-Baja Privacy by Design: Pseudonimización en Capa Analítica (Silver/Gold). Tokenización reversible solo para roles autorizados. RLS estricto por Dependencia/Rol. Auditoría acceso completa (Log_Transacción). DPIA obligatorio nuevos proyectos.
Deuda técnica sistemas legado (FoxPro, VB6, Access, BD sin API, esquemas cerrados) Crítico Alta Patrón Strangler Fig: APIs Anti-Corruption Layer sobre legado. Ingesta por archivos planos/CSV validados (con checksum y metadatos) si no hay API. Priorizar migración fuentes críticas (Tributario, Catastro, Contratación). Documentación ingeniería inversa.
Falta adopción cultura de datos (Catálogo vacío, Calidad baja, "Excel culture", Resistencia cambio) Alto Alta Data Literacy Program obligatorio. Data Champions por dependencia. Métricas uso Catálogo/Calidad en Evaluación Desempeño. Quick Wins visibles (ej. Dashboard Recaudo Diario automático). Comunicación constante logros.
Cambio normativo frecuente (Reformas tributarias, Leyes transparencia, Estándares DANE/MinTIC) Medio Media Capa Reference Data versionada con vigencias. Data Contracts versionados (SemVer). Arquitectura modular: cambios en RefData no rompen Transaccional/Analítica. Monitoreo fuentes oficiales (Diario Oficial, DANE, MinTIC).

8. Alineación Normativa y Estándares (Contexto Colombia)

La arquitectura cumple y habilita el cumplimiento del marco legal colombiano vigente.

Norma / EstándarAplicación Concreta en la Arquitectura
Ley 1712/2014 (Transparencia y Acceso Información Pública)Metadatos abiertos (DCAT-AP.co), API Datos Abiertos, Catálogo Publicable, Retención documental automatizada, Log_Transacción inmutable.
Ley 1581/2012 + Dec. 1377/2013 (Protección Datos Personales - Habeas Data)Privacy by Design, Consentimiento gestionado en Master Data, Derechos ARCO (APIs Acceso/Rectificación/Supresión/Oposición), DPIA obligatorio, Pseudonimización en capa analítica, Roles de Custodio/Encargado.
Decreto 1081/2015 (Art 2.2.3.5.1) - MECI (Modelo Estándar Control Interno)Trazabilidad completa (Linaje), Auditoría técnica (Log_Transacción), Segregación funciones (RLS/RBAC), Plan Continuidad (Backups/DR documentados en Metadatos), Gestión Riesgos (Matriz integrada).
Resolución 0090/2018 (AGN) - Tablas Retención Documental (TRD)Tablas Retention_Policy mapeadas a TRD. Disposición final documentada y auditable. Jobs de purga/archivo automáticos con certificación.
Estándares DANE (CIIU 4.0, División Político-Administrativa, Clasificaciones estadísticas)Reference Data Obligatorio. Sincronización automática programada. Mapeo local → Estándar Nacional. Validación en origen (FK a catálogos DANE).
Esquema Nacional Interoperabilidad (ENI - MinTIC)APIs REST/JSON, OAuth2/OpenID Connect, Metadatos DCAT-AP.co para Portal Datos Abiertos, Formatos abiertos (CSV, JSON, XML, Parquet), Servicios web documentados (OpenAPI/Swagger).
CONPES 3918/2018 (Política Gobierno Digital)Ciudadano en el centro (Master Data Ciudadano único), Interoperabilidad por defecto, Datos Abiertos proactivos, Analítica para decisiones basadas en evidencia, Arquitectura empresarial alineada.
Ley 1755/2015 (Código de Trámites)Catálogo Tipo_Tramite versionado, SLA por trámite en metadatos, Trazabilidad completa ciclo de vida (Radicado → Respuesta), Canales digitales habilitados.
Ley 80/1993 & Ley 1150/2007 (Régimen Contractual Estatal)Modelo Contratación alineado SECOP II, Trazabilidad Adiciones/Prórrogas/Suspensiones, Publicación obligatoria (SECOP), Control presupuestal (RP/CP) en transaccional.

9. Resumen Ejecutivo para Toma de Decisiones

Esta arquitectura representa la Especificación Base (Baseline) validada técnicamente. Requiere aprobación directiva y asignación de recursos para ejecución.

DimensiónEstado Actual (Implícito en Doc Fuente)Estado Objetivo (Arquitectura Propuesta)Gap Principal / Acción Requerida
Gobernanza Incipiente (Liderada solo por Jefatura Inteligencia Tributaria) Data Governance Board transversal (Alcaldía) + Stewards por dominio (Tributario, Catastro, Contratación, Talento Humano, Proyectos) Formalizar Decreto/Resolución creando Consejo de Datos. Asignar presupuesto y tiempo (20% Stewards).
Master Data Silos funcionales (Catastro, Tributario, Talento Humano, Contratación, Planeación separados, datos inconsistentes) MDM Hub Unificado (Ciudadano, Predio, Proveedor, Empresa, Empleado, Programa, Proyecto). Golden Records certificados. Proyecto de Integración/Migración datos históricos. Definición reglas Match/Merge. Limpieza masiva inicial.
Reference Data Hojas de cálculo / Tablas sueltas en cada BD / Versiones obsoletas / Sin APIs Reference Data Hub centralizado, versionado (SemVer + Fechas), API-first (REST/OData), FK enforcadas en toda la plataforma. Limpieza catálogos actuales + Automatización ingesta fuentes oficiales (DANE, DIAN, IGAC, MinHacienda).
Transactional / Analítica Sistemas operacionales desconectados. Volcado manual a Excel para reportes. Sin histórico confiable. Cierres lentos. Lakehouse/DW Moderno con CDC Near Real Time. Modelo Dimensional Certificado (Kimball). Self-Service BI gobernado. Implementar CDC en motores legacy / Middleware de extracción. Definir modelos dimensionales (Workshops negocio).
Metadatos Documentación dispersa (Word/Excel) o inexistente. Desconocimiento linaje. Sin métricas calidad. Data Catalog Activo con Linaje automático, Calidad (Data Contracts), Glosario Negocio, Políticas Retención, Diccionario Técnico. Selección herramienta (OpenMetadata/DataHub/Comercial) + Población inicial (Ingeniería Metadatos 2-3 meses).
Analítica Avanzada / IA Reportes estáticos, reactivos, baja confianza, sin capacidad predictiva. Self-Service BI + Data Science/ML (Predictivo: Evasión, Riesgo, Demanda; Prescriptivo: Next Best Action; Generativo: Chatbot Ciudadano). Cultura de datos + Plataforma MLOps + Casos de uso priorizados con ROI claro (Ej: Modelo Evasión Predial = $$ Recaudo).
Próximos Pasos Inmediatos (Decision Points)
  1. Aprobación de este Baseline por Comité Directivo SH y Comité Gobierno Digital Alcaldía.
  2. Designación formal de Data Stewards (5 dominios) y Data Architect líder.
  3. Presupuesto Fase 0-1 (Gobernanza + MDM Hub + Limpieza Ciudadano/Predio). Estimado: COP $XXX MM (Requiere estimación detallada).
  4. Contratación Plataforma: Decisión Build vs Buy (MDM, Lakehouse, Catalog, BI). Proceso licitatorio / convenio marco.
  5. Kick-off Fase 0: Talleres de Governance Charter, Inventario Sistemas, Políticas Privacidad/Seguridad.
Instrucciones de Uso Guardar: Copie el código anterior y guárdelo como un archivo .html (ej: arquitectura-datos-armenia.html). Abrir: Haga doble clic en el archivo para abrirlo en cualquier navegador moderno (Chrome, Edge, Firefox, Safari). Visualizar: Los diagramas Mermaid (Arquitectura 4 Capas y Modelo ER) se renderizarán automáticamente. Imprimir/PDF: Use Ctrl+P (o Cmd+P) → "Guardar como PDF" / "Microsoft Print to PDF". Los estilos @media print ocultan la tabla de contenidos flotante y optimizan saltos de página. Navegación: La tabla de contenidos (izquierda/arriba) permite saltar a secciones. Al hacer scroll, la sección activa se resalta en el TOC. Características Técnicas del HTML Autónomo (Zero Dependencies locales): Usa CDN para Tailwind CSS, Mermaid.js y FontAwesome. Funciona offline solo si tiene caché de esos CDNs; para uso 100% offline, descargue las librerías y cambie las URLs. Responsivo: Tablas con scroll horizontal en móvil, TOC en una columna en pantallas pequeñas. Accesible: Semántica HTML5 correcta, contraste de colores AA, navegación por teclado. Profesional: Paleta de colores institucional (Azul Oscuro, Azul Medio, Dorado Armenia), tipografía Inter + JetBrains Mono para código. Listo para Decisión: Estructura ejecutiva (Resumen, Roadmap, Riesgos, Normativa) al final para directivos; detalle técnico (Capas, ER, Tablas) en el cuerpo para equipo de datos/IT. Las secciones 3 y 5 que son los mermaid, quedaron con errores y salen en el HTLM como error "Syntax error in text". Por favor corregirlos edit Thought for 26.5 seconds Los errores en Mermaid suelen deberse a: Directivas %%{init}%% complejas con JSON mal formado o claves no soportadas. Estilos style aplicados a subgrafos (no siempre soportados bien). Sintaxis ER inválida: Atributos sin tipo (ej. audit created_by...), entidades referenciadas pero no definidas (IMPUESTO, CATEGORIA_SERVICIO), y restricciones (PK, FK) en lugares incorrectos. Aquí tienes los dos bloques Mermaid corregidos y listos para copiar/pegar en tu HTML (reemplaza exactamente los bloques
...
de las secciones 3 y 5). 1. Sección 3: Arquitectura de 4 Capas (Corregido) Cambios: Eliminada directiva init problemática. Usado classDef para todo (incluyendo subgrafos). Simplificados labels.
graph TB subgraph CAPA4["📊 CAPA 4: CONSUMO Y SERVICIOS"] BI[Business Intelligence
Dashboards Ejecutivos / Operativos] API[APIs / Servicios Abiertos
Interoperabilidad ENI] PORTAL[Portal Ciudadano
Ventanilla Unica / Chatbot] end subgraph CAPA3["🛡️ CAPA 3: METADATOS Y GOBERNANZA (Transversal)"] CAT[Data Catalog / Diccionario
OpenMetadata / DataHub] LINEAGE[Linaje End-to-End
OpenLineage] QUALITY[Calidad / Data Contracts
Great Expectations / Soda] GOV[Data Governance Board
Politicas / Stewards / DPIA] end subgraph CAPA2["🏪 CAPA 2: ALMACENAMIENTO Y PROCESAMIENTO"] DW[(Data Lakehouse / DW
Delta Lake / Iceberg)] MDM[MDM Hub
Golden Records / Match-Merge] REF[Reference Data Hub
Catalogos Versionados / APIs] ODS[ODS / Staging Area
Raw / Bronze Layer] end subgraph CAPA1["🔌 CAPA 1: FUENTES Y CAPTURA"] SRC1[Sistemas Tributarios
ICA / Predial] SRC2[Sistema Catastro / GIS
PostGIS / IGAC] SRC3[Sistema Contratacion
SECOP / Local] SRC4[Sistema Talento Humano] SRC5[Sistemas Proyectos
Planeacion / Seguimiento] SRC6[Canales Pago / Bancos
Pasarelas / Recibo] SRC7[Fuentes Externas
DIAN, IGAC, Registraduria] end %% Flujo de datos SRC1 & SRC2 & SRC3 & SRC4 & SRC5 & SRC6 & SRC7 -->|Extraccion Batch / CDC| ODS ODS -->|Limpieza / Match-Merge| MDM ODS -->|Validacion / Carga| REF ODS -->|Carga Incremental| DW MDM -->|Dimensiones Conformadas| DW REF -->|Dimensiones Referencia| DW DW -->|Modelos Estrella / Data Marts| BI & API & PORTAL %% Gobernanza transversal (punteado) CAT -.->|Gobierna / Documenta| MDM & REF & DW & ODS LINEAGE -.->|Rastrea| MDM & REF & DW & ODS QUALITY -.->|Valida / Alerta| MDM & REF & DW & ODS GOV -.->|Define Politicas| MDM & REF & DW & ODS %% Estilos via ClassDef classDef layer4 fill:#dbeafe,stroke:#3b82f6,stroke-width:2px,color:#1e3a5f; classDef layer3 fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,stroke-dasharray: 5 5,color:#92400e; classDef layer2 fill:#d1fae5,stroke:#10b981,stroke-width:2px,color:#065f46; classDef layer1 fill:#f3f4f6,stroke:#6b7280,stroke-width:1px,color:#374151; classDef transversal fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,stroke-dasharray: 5 5,color:#92400e; class BI,API,PORTAL layer4; class CAT,LINEAGE,QUALITY,GOV layer3; class DW,MDM,REF,ODS layer2; class SRC1,SRC2,SRC3,SRC4,SRC5,SRC6,SRC7 layer1;
2. Sección 5: Modelo Entidad-Relación (Corregido) Cambios mayores: Atributos: Todos tienen tipo nombre (ej. string created_by). Eliminado audit ... suelto. Entidades faltantes: Agregadas IMPUESTO y CATEGORIA_SERVICIO. Restricciones: PK, FK, UK al final de la línea del atributo. Comentarios: Eliminados comentarios inline %% ... %% dentro del bloque ER (Mermaid ER no los soporta bien en todas las versiones). Nombres: Eliminados acentos y caracteres especiales en labels de relaciones para evitar errores de parsing.
erDiagram %% ==================== ENTIDADES MAESTRAS ==================== CIUDADANO { int id_ciudadano PK string tipo_documento string numero_documento UK string nombre date fecha_nacimiento string direccion string email string telefono string estado_vigencia string created_by datetime created_at string modified_by datetime modified_at } PREDIO { int id_predio PK string codigo_catastral UK int id_ciudadano FK string ubicacion_geom float area_m2 string uso_suelo int estrato int id_ubicacion FK string created_by datetime created_at string modified_by datetime modified_at } EMPLEADO { int id_empleado PK string nombre string cargo_actual date fecha_ingreso int id_dependencia FK string email_corp UK string created_by datetime created_at string modified_by datetime modified_at } PROVEEDOR { int id_proveedor PK string razon_social string nit UK string direccion string telefono string categoria_ciiu FK float score_desempeno string created_by datetime created_at string modified_by datetime modified_at } EMPRESA { int id_empresa PK string nombre string nit UK string tipo_empresa string direccion string representante_legal date fec_vigencia_rep_legal string created_by datetime created_at string modified_by datetime modified_at } PROGRAMA { int id_programa PK string nombre string descripcion string objetivo date fecha_inicio date fecha_fin string dependencia_responsable int id_empresa FK string created_by datetime created_at string modified_by datetime modified_at } PROYECTO { int id_proyecto PK string nombre string descripcion string objeto float presupuesto date fecha_inicio date fecha_fin string estado int id_programa FK int id_empresa FK string created_by datetime created_at string modified_by datetime modified_at } %% ==================== REFERENCE DATA ==================== TIPO_TRAMITE { int id_tipo_tramite PK string nombre string descripcion boolean vigente } METODO_PAGO { int id_metodo_pago PK string nombre string detalle boolean activo } DEPENDENCIA { int id_dependencia PK string nombre string nivel int id_dependencia_padre FK } CODIGO_CIIU { int id_ciiu PK string codigo string descripcion int nivel } ESTADO_ENTIDAD { int id_estado PK string dominio string nombre } UBICACION_GEO { int id_ubicacion PK string codigo_dane string nombre int nivel string geom } KPI_DEFINICION { int id_kpi PK string nombre string unidad string formula string frecuencia } IMPUESTO { int id_impuesto PK string nombre string descripcion string tipo } CATEGORIA_SERVICIO { int id_categoria_servicio PK string nombre string descripcion } %% ==================== TRANSACCIONALES ==================== TRAMITE { int id_tramite PK int id_ciudadano FK int id_tipo_tramite FK date fecha_solicitud string estado string observaciones string created_by datetime created_at string modified_by datetime modified_at } PAGO_IMPUESTO { int id_pago PK int id_ciudadano FK int id_predio FK int id_impuesto FK float valor date fecha_pago int id_metodo_pago FK string recibo_numero UK string created_by datetime created_at string modified_by datetime modified_at } CONTRATO { int id_contrato PK int id_empleado FK int id_proveedor FK date fecha_inicio date fecha_final float valor_contrato string objeto string created_by datetime created_at string modified_by datetime modified_at } SOLICITUD { int id_solicitud PK int id_servicio FK int id_ciudadano FK date fecha_solicitud string estado string observaciones string created_by datetime created_at string modified_by datetime modified_at } SERVICIO { int id_servicio PK string nombre string descripcion int id_categoria_servicio FK } AVANCE_PROYECTO { int id_avance PK int id_proyecto FK date fecha_registro float porcentaje_avance string comentario string created_by datetime created_at } HITO_PROYECTO { int id_hito PK int id_proyecto FK string nombre date fecha_hito_planeada date fecha_hito_real string estado } DESEMBOLSO_PROYECTO { int id_desembolso PK int id_proyecto FK date fecha float monto string concepto } DESEMBOLSO_PROGRAMA { int id_desembolso PK int id_programa FK date fecha float monto } INFORME_KPI_PROGRAMA { int id_informe PK int id_programa FK int id_kpi FK date fecha_medicion float valor string observaciones } LOG_TRANSACCION { bigint id_log PK string tabla_origen string operacion string usuario datetime timestamp string datos_previos string datos_posteriores } %% ==================== RELACIONES ==================== %% Nucleo Ciudadano/Territorio CIUDADANO ||--o{ PREDIO : "posee" CIUDADANO ||--o{ TRAMITE : "solicita" CIUDADANO ||--o{ PAGO_IMPUESTO : "efectua" CIUDADANO ||--o{ SOLICITUD : "inicia" PREDIO }o--o{ IMPUESTO : "genera" TRAMITE }o--|| TIPO_TRAMITE : "clasifica" PAGO_IMPUESTO }o--|| METODO_PAGO : "usa" PAGO_IMPUESTO }o--|| PREDIO : "aplica_a" PAGO_IMPUESTO }o--|| IMPUESTO : "paga" %% Nucleo Talento Humano / Contratacion EMPLEADO ||--o{ CONTRATO : "firma" CONTRATO }o--|| PROVEEDOR : "relaciona" EMPLEADO }o--|| DEPENDENCIA : "pertenece" %% Nucleo Servicios SERVICIO ||--o{ SOLICITUD : "atiende" SERVICIO }o--|| CATEGORIA_SERVICIO : "clasifica" %% Nucleo Planificacion / Inversion EMPRESA ||--o{ PROGRAMA : "ejecuta" EMPRESA ||--o{ PROYECTO : "patrocina" PROGRAMA ||--o{ PROYECTO : "contiene" PROYECTO }o--|| ESTADO_ENTIDAD : "estado" PROGRAMA }o--|| ESTADO_ENTIDAD : "estado" %% Referencias PREDIO }o--|| UBICACION_GEO : "ubicado_en" PROVEEDOR }o--|| CODIGO_CIIU : "actividad_economica" EMPRESA }o--|| CODIGO_CIIU : "sector" %% KPIs y Avances AVANCE_PROYECTO }o--|| PROYECTO : "registra" HITO_PROYECTO }o--|| PROYECTO : "hito_de" DESEMBOLSO_PROYECTO }o--|| PROYECTO : "financia" DESEMBOLSO_PROGRAMA }o--|| PROGRAMA : "financia" INFORME_KPI_PROGRAMA }o--|| PROGRAMA : "mide" INFORME_KPI_PROGRAMA }o--|| KPI_DEFINICION : "indica"
Instrucciones para aplicarlos: Abre tu archivo arquitectura-datos-armenia.html en tu editor de código (VS Code, Sublime, Notepad++). Busca la Sección 3 (id="arquitectura-4-capas"). Localiza el
inmediatamente después del párrafo "Separación de responsabilidades estilo...". Borra todo el contenido de ese
...
(incluyendo el %%{init...}%% y el graph TB anterior) y pega el Bloque 1 de arriba. Busca la Sección 5 (id="modelo-er"). Localiza su
. Borra todo el contenido de ese
...
y pega el Bloque 2 de arriba. Guarda y recarga el navegador (Ctrl+R / Cmd+R). Ambos diagramas deberían renderizarse sin errores "Syntax error in text". la sección 2 tambien presenta fallas edit ARQUITECTURA DE DATOS.pdf Deriva un archivo HTLM a partir del análisis de este documento edit Thought for a moment Aquí tienes el archivo HTML completo, corregido y listo para usar. He solucionado los errores de sintaxis de Mermaid en las Secciones 2, 3 y 5 (diagrama de actores "cebolla", arquitectura 4 capas y modelo ER), validando la sintaxis contra la especificación actual de Mermaid. Arquitectura de Datos - Secretaría de Hacienda, Alcaldía de Armenia, Quindío

Secretaría de Hacienda / Alcaldía de Armenia, Quindío

Arquitectura de Datos Institucional

Derivada del documento "ARQUITECTURA DE DATOS SECRETARÍA DE HACIENDA - ACTIVIDAD: HACIENDA INTELIGENTE" (Vigencia 2026). Metodología Capacity WORKS (GIZ) + Modelo EFQM.

2026 4 Capas Gobernanza Capacity WORKS
Versión: 1.0 (Baseline)
Estado: Aprobación Directiva
Clasificación: Pública / Interna
Owner: Jefatura Inteligencia Tributaria

1. Contexto Estratégico y Drivers

La presente arquitectura nace como requisito habilitante para la iniciativa "Hacienda Inteligente", alineada con el modelo de excelencia EFQM (gestión de calidad) y la metodología Capacity WORKS de la GIZ (gestión para el desarrollo sostenible). El objetivo es transformar la Secretaría de Hacienda (SH) en una entidad orientada a datos, con servicios proactivos, trazables y de alta calidad para el ciudadano.

DimensiónDefinición en la Arquitectura
Objetivo CentralSH Inteligente: Decisiones basadas en datos, servicios digitales proactivos, recaudo eficiente, control interno robusto.
Alcance FuncionalTributario (ICA, Predial), Catastro, Contratación, Talento Humano, Proyectos/Programas, Atención Ciudadana.
Principios RectoresUnicidad (SSOT) Trazabilidad Privacidad (Ley 1581) Interoperabilidad (ENI) Gobernanza Activa
Metodología BaseCapacity WORKS (GIZ): Mapa de Actores → Grupos de Valor/Interés → Necesidades → Arquitectura de Datos.

2. Panorama de Actores (Stakeholder Landscape)

El mapa de actores (diagrama "Cebolla" Capacity WORKS) define la frontera de la arquitectura, los flujos de datos y los requisitos de seguridad/acceso. Se identifican tres cuadrantes sectoriales (Público, Privado, Sociedad Civil) y tres anillos de influencia (Clave, Primario, Secundario) con jugadores Veto transversales.

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#1e3a5f', 'secondaryColor': '#2c5f8a', 'tertiaryColor': '#0096d6', 'background': '#ffffff', 'mainBkg': '#f8fafc', 'clusterBkg': '#eef4fa', 'fontFamily': 'Inter', 'fontSize': '13px' }}}%% graph TB %% Definición de Estilos (Classes) classDef ringKey fill:#dbeafe,stroke:#3b82f6,stroke-width:3px,color:#1e3a5f; classDef ringPrimary fill:#d1fae5,stroke:#10b981,stroke-width:2px,color:#065f46; classDef ringSecondary fill:#f3f4f6,stroke:#9ca3af,stroke-width:1px,stroke-dasharray: 5 5,color:#374151; classDef ringVeto fill:#fee2e2,stroke:#ef4444,stroke-width:2px,color:#991b1b; classDef sectorPublic fill:#e0e7ff,stroke:#3730a3,stroke-width:1px; classDef sectorPrivate fill:#fef3c7,stroke:#f59e0b,stroke-width:1px; classDef sectorCivil fill:#fce7f3,stroke:#ec4899,stroke-width:1px; %% ANILLOS CONCÉNTRICOS (Subgraphs invisibles para layout, usamos direction TB) %% Núcleo: Actores Clave subgraph CORE[" "] direction TB CIUD[Ciudadanos / Contribuyentes
(PN & PJ)] PRED[Propietarios de Predios] JEF[Jefatura Inteligencia Tributaria
(SH)] end class CIUD,PRED,JEF ringKey; %% Anillo 1: Actores Primarios subgraph PRIM[" "] direction TB DEP[Dependencias Alcaldía] EMP[Empleados / Jubilados] FIN[Entidades Financieras] EPA[EPA / CRQ] URB[Urbanizadores / Constructores] ARR[Arrendatarios] VETO1[Organismos Control
(Contraloría, Procuraduría)::VETO] VETO2[Concejo Municipal::VETO] end class DEP,EMP,FIN,EPA,URB,ARR ringPrimary; class VETO1,VETO2 ringVeto; %% Anillo 2: Actores Secundarios (Cuadrantes) subgraph SEC_PUB["Sector Público"] direction TB DIAN[DIAN] BANREP[Banco República] MINHAC[MinHacienda / DNP] JUZ[Juzgados Civiles] end class DIAN,BANREP,MINHAC,JUZ ringSecondary,sectorPublic; subgraph SEC_PRIV["Sector Privado"] direction TB ASCAP[Asocapitales] INTL[Financiadores Internacionales] CAMCOM[Cámara Comercio] end class ASCAP,INTL,CAMCOM ringSecondary,sectorPrivate; subgraph SEC_CIV["Sociedad Civil"] direction TB ACADEMIA[Academia / ESAP] CIUDANA[Veédurías / ONGs] end class ACADEMIA,CIUDANA ringSecondary,sectorCivil; %% Relaciones (Lógicas, no visuales en cebolla pero necesarias para Mermaid) JEF --> CIUD JEF --> PRED JEF --> DEP JEF --> FIN JEF --> DIAN JEF --> VETO1 %% Leyenda visual usando nodos invisibles y clickable false classDef invisible fill:transparent,stroke:transparent,color:transparent; LEG1[🟦 Actores Clave (Núcleo)]:::invisible LEG2[🟩 Actores Primarios]:::invisible LEG3[⬜ Actores Secundarios]:::invisible LEG4[🟥 Jugadores Veto]:::invisible
Categoría Capacity WORKSActores Representativos (según PDF)Rol en Arquitectura de Datos
Clave (Núcleo)Ciudadanos/Contribuyentes (PN/PJ), Propietarios Predios, Jefatura Inteligencia TributariaFuentes y Consumidores principales de Master Data (Ciudadano, Predio, Empresa) y Transaccional (Pagos, Trámites). Definen requisitos de calidad.
PrimariosDependencias Alcaldía, Empleados/Jubilados, Entidades Financieras, EPA, CRQ, Urbanizadores, Arrendatarios, Organismos Control (Veto), Concejo Municipal (Veto)Productores/Consumidores operacionales. Alimentan Transacciones (Contratos, Nóminas, Recaudos) y consumen Reportes/BI. Veto exigen Auditoría/Linaje.
SecundariosDIAN, Banco República, MinHacienda, Juzgados, Financiadores Internacionales, Asocapitales, Cámara Comercio, AcademiaConsumidores de Reportes Regulatorios y Fuentes de Reference Data (Listas restrictivas, CIIU, Normativa, Tasas, Estándares).

3. Arquitectura de Datos: Modelo de 4 Capas (Layered Architecture)

Separación de responsabilidades estilo Data Mesh / Layered Architecture para garantizar escalabilidad, gobernanza y evolución independiente de cada capa.

graph TB subgraph CAPA4["📊 CAPA 4: CONSUMO Y SERVICIOS"] BI[Business Intelligence
Dashboards Ejecutivos / Operativos] API[APIs / Servicios Abiertos
Interoperabilidad ENI] PORTAL[Portal Ciudadano
Ventanilla Unica / Chatbot] end subgraph CAPA3["🛡️ CAPA 3: METADATOS Y GOBERNANZA (Transversal)"] CAT[Data Catalog / Diccionario
OpenMetadata / DataHub] LINEAGE[Linaje End-to-End
OpenLineage] QUALITY[Calidad / Data Contracts
Great Expectations / Soda] GOV[Data Governance Board
Politicas / Stewards / DPIA] end subgraph CAPA2["🏪 CAPA 2: ALMACENAMIENTO Y PROCESAMIENTO"] DW[(Data Lakehouse / DW
Delta Lake / Iceberg)] MDM[MDM Hub
Golden Records / Match-Merge] REF[Reference Data Hub
Catalogos Versionados / APIs] ODS[ODS / Staging Area
Raw / Bronze Layer] end subgraph CAPA1["🔌 CAPA 1: FUENTES Y CAPTURA"] SRC1[Sistemas Tributarios
ICA / Predial] SRC2[Sistema Catastro / GIS
PostGIS / IGAC] SRC3[Sistema Contratacion
SECOP / Local] SRC4[Sistema Talento Humano] SRC5[Sistemas Proyectos
Planeacion / Seguimiento] SRC6[Canales Pago / Bancos
Pasarelas / Recibo] SRC7[Fuentes Externas
DIAN, IGAC, Registraduria] end %% Flujo de datos principal SRC1 & SRC2 & SRC3 & SRC4 & SRC5 & SRC6 & SRC7 -->|Extraccion Batch / CDC| ODS ODS -->|Limpieza / Match-Merge| MDM ODS -->|Validacion / Carga| REF ODS -->|Carga Incremental| DW MDM -->|Dimensiones Conformadas| DW REF -->|Dimensiones Referencia| DW DW -->|Modelos Estrella / Data Marts| BI & API & PORTAL %% Gobernanza transversal (punteado) CAT -.->|Gobierna / Documenta| MDM & REF & DW & ODS LINEAGE -.->|Rastrea| MDM & REF & DW & ODS QUALITY -.->|Valida / Alerta| MDM & REF & DW & ODS GOV -.->|Define Politicas| MDM & REF & DW & ODS %% Estilos via ClassDef classDef layer4 fill:#dbeafe,stroke:#3b82f6,stroke-width:2px,color:#1e3a5f; classDef layer3 fill:#fef3c7,stroke:#f59e0b,stroke-width:2px,stroke-dasharray: 5 5,color:#92400e; classDef layer2 fill:#d1fae5,stroke:#10b981,stroke-width:2px,color:#065f46; classDef layer1 fill:#f3f4f6,stroke:#6b7280,stroke-width:1px,color:#374151; class BI,API,PORTAL layer4; class CAT,LINEAGE,QUALITY,GOV layer3; class DW,MDM,REF,ODS layer2; class SRC1,SRC2,SRC3,SRC4,SRC5,SRC6,SRC7 layer1;
Patrón Arquitectónico

Se adopta un enfoque Lakehouse Moderno (Bronze → Silver → Gold) sobre almacenamiento objeto (S3/MinIO) con formatos abiertos (Delta Lake / Apache Iceberg). La Capa 3 (Metadatos) es transversal y gobierna todo el ciclo de vida. La Capa 2 incluye un MDM Hub activo para Master Data y un Reference Data Hub con APIs versionadas.

4.1 Capa Master Data (Datos Maestros) — "Única Fuente de Verdad (SSOT)"

Establece la golden record para las entidades nucleares. Garantiza unicidad, calidad, seguridad, auditoría y versionamiento histórico (SCD Tipo 2).

Entidad MaestraClave PKAtributos Críticos / Reglas de NegocioReglas de Oro (Best Practices del Documento)
Ciudadano
Eje Central
id_ciudadano Tipo/Nro Doc (Validado Registraduría), Nombre, Fechas, Dirección, Contacto, Email Unicidad: Match & Merge probabilístico (Nombre+Dir).
Privacidad: Encriptación PII, RBAC estricto (Solo Gestión Humana/Secretaría General).
Auditoría: SCD Tipo 2 (created_by, modified_by, vigencia).
Predio
Núcleo Catastral
id_predio Código Catastral (Único vs IGAC), Geometría (PostGIS), Área m², Uso Suelo, FK Ciudadano Integridad Espacial: Validación topológica PostGIS.
Código Único: Validación contra base IGAC.
FK Obligatoria: A Ciudadano vigente y activo.
Metadatos Uso Suelo: Clasificación oficial + fuente.
Empleado id_empleado ID Interno (≠ Doc Personal), Cargo/Dep Histórico, Contacto Corporativo (@alcaldia.gov.co) IAM Integration: Active Directory / Azure AD.
Versionado: Histórico cargos/dependencias (cargo_actual vs cargos_previos).
Seguridad: Permisos por rol.
Proveedor id_proveedor Razón Social, NIT (Validado DIAN), Categoría CIIU 4.0, Score Desempeño Validación NIT: Vigencia/Estado DIAN (activo, inhabilitado).
Scorecards: KPIs cumplimiento (Tiempo, Calidad).
Histórico: Contratos y cotizaciones (Auditoría relaciones).
Empresa
Agente Económico
id_empresa NIT, Tipo (Comercial/Industrial/ONG), Rep. Legal (Versionado), Certificaciones CamComercio Deduplicación vs Proveedor: Mapear NIT/RUT único.
Compliance: RUT actualizado obligatorio.
Rep. Legal: Versionar cambios y periodos vigencia.
Programa
Plan Gobierno
id_programa Objetivos SMART, KPIs, Dependencia Responsable (FK), Cronograma Versionado KPIs Documentados: En diccionario de datos.
Versionado: Alcance y presupuesto con ajustes.
Riesgos: Alertas desviación (Plazo/Costo) embebidas.
Proyecto id_proyecto Fases (Iniciación-Cierre), Presupuesto (Original vs Ejecutado), Estado Estandarizado Governance: Comité Seguimiento, Roles Aprobación (RACI).
Earned Value: % Avance Físico vs Financiero.
Estados: Planeado, En Curso, En Riesgo, Cerrado.
Implementación Técnica Recomendada

Desplegar MDM Hub en modo "Coexistence" o "Centralized" (ej. Semarchy, Reltio, Informatica, o Open Source: Apache Atlas + Reglas Custom). Sincronización bidireccional con sistemas transaccionales vía CDC (Change Data Capture). APIs de consulta unificada (GET /api/v1/ciudadanos/{id}) para consumidores internos/externos.

4.2 Capa Reference Data (Datos de Referencia) — "Estructura Semántica Común"

Catálogos estandarizados, versionados y gobernados que sirven como dominios de valor (Value Domains) y claves foráneas en toda la arquitectura. Aseguran consistencia semántica y operacional.

Dominio / CatálogoTabla EjemploAtributos ClaveFuente / Gobernanza
Ubicación GeográficaDepartamento, Municipio, Barrio, Comuna, Veredaid_ubicación, código_DANE, nivel, geometríaOficial: IGAC / DANE. Actualización Anual. Comité Geo.
Tipos de TrámiteTipo_Tramiteid_tipo_tramite, nombre, descripción, vigenciaComité Trámites (Ley 1755/2015). Versionado por decreto.
Clasificación PresupuestalClase_Gasto, Rubro_Presupuestalid_clase, id_rubro, nombre, fuente_normativaAlineado Ley 358/1997, DNP, CHIP. Gobernanza: Secretaría Hacienda.
Métodos de PagoMetodo_Pagoid_metodo_pago, nombre, detalle, activoSincronizado con Entidades Financieras / Pasarelas Pago.
Dependencias InternasDependenciaid_dependencia, nombre, nivel (Sec/Unidad)Maestría: Secretaría General / Talento Humano. Jerarquía orgánica.
Actividad EconómicaCodigo_CIIUid_ciiu, código, descripción, nivel (1-4 dígitos)Estándar Obligatorio: CIIU 4.0 (DANE).
Estados Proy/ProgramaEstado_Entidadid_estado, dominio (Proyecto/Programa), nombreValores fijos controlados: Planeado, En Curso, En Riesgo, Cerrado, Suspendido.
KPIs / MétricasKPI_Definicionid_kpi, nombre, unidad, fórmula, frecuencia, ownerDefinición técnica + Negocio (Data Dictionary). Aprobación Data Council.
Categorías ServicioCategoria_Servicioid_categoria, nombre, descripciónClasificación servicios municipales (Recolección, Infraestructura, etc.).

Lineamientos Técnicos de Implementación

  • APIs RESTful / OData para consumo pull por aplicaciones cliente (Cache TTL 24h).
  • Versionado Semántico (v1.0, v1.1) + Fechas Vigencia (valid_from, valid_to) para historial.
  • FK Enforcadas en Capa Transaccional y Analítica (Integridad Referencial Activa).
  • Gobernanza de Catálogos: Comité de Datos (Data Council) aprueba cambios/nuevas versiones. Logs de modificación (Quién, Cuándo, Por qué decreto).
  • Distribución: Publicación automática via CI/CD al catálogo central y repositorio Git (formato CSV/JSON/Parquet).

4.3 Capa Transactional Data (Datos Transaccionales) — "Registro Operacional Inmutable"

Captura de eventos de negocio (OLTP) que alimentan tanto la operación diaria como los sistemas analíticos (Data Warehouse, BI). Modelo normalizado (3FN) en origen; dimensional (Kimball) en analítica.

Área FuncionalEntidades / Tablas CoreGranularidad / Clave NaturalReglas Críticas / SLAs
Pagos y Recaudos Pago_Impuesto, Pago_Servicio, Recaudo_Patrimonio id_pago (PK Surrogate) + recibo_número (Natural) Latencia BI: < 15 min (Near Real Time). CDC Obligatorio. Particionado por fecha_pago.
Trámites y Solicitudes Trámite, Solicitud, Registro_Ciudadano id_trámite + radicado SLA Estados: Radicado → En Trámite → Resuelto. Trazabilidad completa (Ley 1755).
Contratación Contrato, Adición_Presupuestal, Acta_Vinculación id_contrato + numero_proceso (SECOP) Integridad: FK Proveedor/Empleado vigentes. Audit Trail completo (Ley 80/93).
Servicios Ciudadanos Solicitud_Servicio, Atención_Servicio, Cierre_Servicio id_solicitud Canales: Web, Presencial, Móvil. Métricas: TAT, NPS, FCR (First Contact Resolution).
Gestión Proyectos Avance_Proyecto, Hito_Proyecto, Desembolso_Proyecto id_avance (FK Proyecto + Fecha) Earned Value: % Avance Físico vs Financiero. Alertas automáticas desviación > 10%.
Ejecución Programas Desembolso_Programa, Informe_KPI_Programa, Registro_Actividad id_desembolso, id_kpi (FK RefData) Resultados: Indicadores de Producto / Efecto / Impacto (Marco Lógico).
Auditoría Transaccional Log_Transacción (Tabla Unificada) id_log (BigSerial) Captura: Tabla Origen, Operación (I/U/D), Usuario, Timestamp, Before/After Image (JSONB). Inmutable.

Patrones Técnicos Obligatorios

Modelado y CDC
  • 3FN en OLTP; Estrella/Copo Nieve en DW.
  • CDC Log-based (Debezium) → Kafka/Redpanda → Lakehouse.
  • Particionamiento: Fecha + id_dependencia/id_comuna.
Seguridad y Validación
  • Column-level Encryption (PII). TLS 1.3.
  • Row-Level Security (RLS) por Dependencia/Rol.
  • Validaciones en origen (Front-end/API) + FK a Master/Ref Data.
Monitoreo y SLA
  • Dashboards operativos: Volumen por canal, Estado trámites, Desviaciones proyectos.
  • Alertas automáticas: Caída ETL, Alta tasa errores, Incumplimiento SLA (>15 min).
  • Retención Logs CDC: Equilibrio Trazabilidad vs Almacenamiento (Política 90 días hot, 7 años cold).
Legado y Migración
  • Patrón Strangler Fig: APIs Anti-Corruption Layer sobre sistemas legacy (FoxPro, VB6, Access).
  • Ingesta controlada por archivos planos/CSV validados si no hay API.
  • Priorizar migración fuentes críticas: Tributario, Catastro, Contratación.

4.4 Capa Metadatos (Metadata) — "Datos sobre los Datos (Gobernanza Transversal)"

Habilita auto-servicio, confianza, cumplimiento normativo (Ley 1712 Transparencia, Ley 1581 Protección Datos) y gestión del conocimiento organizacional.

Categoría MetadatoHerramienta / ArtefactoAlcance en Armenia
Diccionario Datos Físico/LógicoData Catalog (OpenMetadata / DataHub / Amundsen / Comercial)Definición técnica: Tipo, Longitud, Nulabilidad, Dominio (FK a RefData), Descripción Negocio.
Linaje de Datos (End-to-End)Lineage Viewer (Automatizado via parsers ETL/DBT/Airflow)Origen (Formulario Web / API Banco) → ETL → Staging → MDM/Ref → DW → Dashboard. Impact Analysis.
Políticas de RetenciónTabla Retention_Policy + Jobs Purge/Archive (Airflow)Ej: Expedientes Civiles 20 años, Logs Transaccionales 5 años, Datos Analíticos Indefinido. Cumple AGN (Res 090/2018).
Catálogo Calidad (DQ Rules)Great Expectations / Soda Core / Deequ / ElementaryReglas: Completitud (Email válido > 95%), Unicidad (NIT Proveedor), Validez (Código Catastral formato IGAC), Consistencia (Saldos).
Configuración ETL/ELT (Data Contracts)Orquestador (Airflow / Prefect / Dagster) + Repo Git (DBT)Jobs versionados: ETL_PREDIOS_DIARIO, CDC_PAGOS_STREAM. Parámetros, Alertas, Owners, Tests.
Modelos Físicos (DDL) / MigracionesRepo Git (Flyway / Liquibase / DBT) + Data CatalogEsquemas: raw, stg, mdm, ref, dw, audit. Migraciones controladas, revisionables.
Versionamiento Catálogos RefDataHistorial en Reference_Data_History + Data CatalogAuditoría: ¿Quién cambió el estrato del barrio X? ¿Cuándo? ¿Por qué decreto/acto administrativo?
Glosario de NegocioBusiness Glossary (Catálogo)Definiciones acordadas: "Programa", "Predio Mejorado", "Contribuyente Activo", "Recaudo Efectivo". Alineación Semántica.

Gobernanza de Metadatos (Operación)

Roles
  • Data Council / Board: Aprueba Glosario, Políticas, Calidad, Retención.
  • Data Stewards por Dominio: (Tributario, Catastro, Contratación, Talento Humano, Proyectos). Dueños de calidad.
  • Data Engineers: Implementan pipelines, linaje automatizado, tests calidad.
Privacidad y Seguridad
  • Etiquetado PII/Sensible: Auto-descubrimiento + Revisión Manual.
  • Políticas Acceso/Encriptación vinculadas a etiquetas en Catálogo.
  • DPIA Obligatorio para nuevos proyectos/procesos con datos personales.

5. Modelo Conceptual Entidad-Relación (Mermaid)

Modelo unificado derivado de las 4 capas. Muestra entidades núcleo (Master Data), sus relaciones transaccionales y vinculación a Reference Data. Notación Crow's Foot. Sintaxis validada para Mermaid v10+.

erDiagram %% ==================== ENTIDADES MAESTRAS ==================== CIUDADANO { int id_ciudadano PK string tipo_documento string numero_documento UK string nombre date fecha_nacimiento string direccion string email string telefono string estado_vigencia string created_by datetime created_at string modified_by datetime modified_at } PREDIO { int id_predio PK string codigo_catastral UK int id_ciudadano FK string ubicacion_geom float area_m2 string uso_suelo int estrato int id_ubicacion FK string created_by datetime created_at string modified_by datetime modified_at } EMPLEADO { int id_empleado PK string nombre string cargo_actual date fecha_ingreso int id_dependencia FK string email_corp UK string created_by datetime created_at string modified_by datetime modified_at } PROVEEDOR { int id_proveedor PK string razon_social string nit UK string direccion string telefono string categoria_ciiu FK float score_desempeno string created_by datetime created_at string modified_by datetime modified_at } EMPRESA { int id_empresa PK string nombre string nit UK string tipo_empresa string direccion string representante_legal date fec_vigencia_rep_legal string created_by datetime created_at string modified_by datetime modified_at } PROGRAMA { int id_programa PK string nombre string descripcion string objetivo date fecha_inicio date fecha_fin string dependencia_responsable int id_empresa FK string created_by datetime created_at string modified_by datetime modified_at } PROYECTO { int id_proyecto PK string nombre string descripcion string objeto float presupuesto date fecha_inicio date fecha_fin string estado int id_programa FK int id_empresa FK string created_by datetime created_at string modified_by datetime modified_at } %% ==================== REFERENCE DATA ==================== TIPO_TRAMITE { int id_tipo_tramite PK string nombre string descripcion boolean vigente } METODO_PAGO { int id_metodo_pago PK string nombre string detalle boolean activo } DEPENDENCIA { int id_dependencia PK string nombre string nivel int id_dependencia_padre FK } CODIGO_CIIU { int id_ciiu PK string codigo string descripcion int nivel } ESTADO_ENTIDAD { int id_estado PK string dominio string nombre } UBICACION_GEO { int id_ubicacion PK string codigo_dane string nombre int nivel string geom } KPI_DEFINICION { int id_kpi PK string nombre string unidad string formula string frecuencia } IMPUESTO { int id_impuesto PK string nombre string descripcion string tipo } CATEGORIA_SERVICIO { int id_categoria_servicio PK string nombre string descripcion } %% ==================== TRANSACCIONALES ==================== TRAMITE { int id_tramite PK int id_ciudadano FK int id_tipo_tramite FK date fecha_solicitud string estado string observaciones string created_by datetime created_at string modified_by datetime modified_at } PAGO_IMPUESTO { int id_pago PK int id_ciudadano FK int id_predio FK int id_impuesto FK float valor date fecha_pago int id_metodo_pago FK string recibo_numero UK string created_by datetime created_at string modified_by datetime modified_at } CONTRATO { int id_contrato PK int id_empleado FK int id_proveedor FK date fecha_inicio date fecha_final float valor_contrato string objeto string created_by datetime created_at string modified_by datetime modified_at } SOLICITUD { int id_solicitud PK int id_servicio FK int id_ciudadano FK date fecha_solicitud string estado string observaciones string created_by datetime created_at string modified_by datetime modified_at } SERVICIO { int id_servicio PK string nombre string descripcion int id_categoria_servicio FK } AVANCE_PROYECTO { int id_avance PK int id_proyecto FK date fecha_registro float porcentaje_avance string comentario string created_by datetime created_at } HITO_PROYECTO { int id_hito PK int id_proyecto FK string nombre date fecha_hito_planeada date fecha_hito_real string estado } DESEMBOLSO_PROYECTO { int id_desembolso PK int id_proyecto FK date fecha float monto string concepto } DESEMBOLSO_PROGRAMA { int id_desembolso PK int id_programa FK date fecha float monto } INFORME_KPI_PROGRAMA { int id_informe PK int id_programa FK int id_kpi FK date fecha_medicion float valor string observaciones } LOG_TRANSACCION { bigint id_log PK string tabla_origen string operacion string usuario datetime timestamp string datos_previos string datos_posteriores } %% ==================== RELACIONES ==================== %% Nucleo Ciudadano/Territorio CIUDADANO ||--o{ PREDIO : "posee" CIUDADANO ||--o{ TRAMITE : "solicita" CIUDADANO ||--o{ PAGO_IMPUESTO : "efectua" CIUDADANO ||--o{ SOLICITUD : "inicia" PREDIO }o--o{ IMPUESTO : "genera" TRAMITE }o--|| TIPO_TRAMITE : "clasifica" PAGO_IMPUESTO }o--|| METODO_PAGO : "usa" PAGO_IMPUESTO }o--|| PREDIO : "aplica_a" PAGO_IMPUESTO }o--|| IMPUESTO : "paga" %% Nucleo Talento Humano / Contratacion EMPLEADO ||--o{ CONTRATO : "firma" CONTRATO }o--|| PROVEEDOR : "relaciona" EMPLEADO }o--|| DEPENDENCIA : "pertenece" %% Nucleo Servicios SERVICIO ||--o{ SOLICITUD : "atiende" SERVICIO }o--|| CATEGORIA_SERVICIO : "clasifica" %% Nucleo Planificacion / Inversion EMPRESA ||--o{ PROGRAMA : "ejecuta" EMPRESA ||--o{ PROYECTO : "patrocina" PROGRAMA ||--o{ PROYECTO : "contiene" PROYECTO }o--|| ESTADO_ENTIDAD : "estado" PROGRAMA }o--|| ESTADO_ENTIDAD : "estado" %% Referencias PREDIO }o--|| UBICACION_GEO : "ubicado_en" PROVEEDOR }o--|| CODIGO_CIIU : "actividad_economica" EMPRESA }o--|| CODIGO_CIIU : "sector" %% KPIs y Avances AVANCE_PROYECTO }o--|| PROYECTO : "registra" HITO_PROYECTO }o--|| PROYECTO : "hito_de" DESEMBOLSO_PROYECTO }o--|| PROYECTO : "financia" DESEMBOLSO_PROGRAMA }o--|| PROGRAMA : "financia" INFORME_KPI_PROGRAMA }o--|| PROGRAMA : "mide" INFORME_KPI_PROGRAMA }o--|| KPI_DEFINICION : "indica"

6. Roadmap de Implementación (4 Fases)

Enfoque iterativo e incremental: Fundación → Quick Wins → Plataforma → Valor Analítico.

0

Fase 0: Fundación y Gobernanza (Meses 1-3)

Objetivo: Establecer mandato, roles y catálogos base.

  • Gobernanza: Data Governance Charter, Data Council formado, Data Stewards asignados por dominio.
  • Políticas: Seguridad/Privacidad (Ley 1581), Retención (AGN), Clasificación Datos, Acceso.
  • Reference Data Inicial: CIIU 4.0, DANE Geo, Tipos Trámite, Clasif. Presupuestal, Métodos Pago, Estados Proy. Versionados y con API.
  • Inventario: Catálogo de sistemas fuentes (Legado, Actuales, Externos), dueños, frecuencia, calidad percibida.
Wiki/Confluence Jira/GitLab DBT Docs
1

Fase 1: Quick Wins - Master Data Crítico (Meses 3-8)

Objetivo: Resolver duplicidad Ciudadano/Predio (Core Tributario). Habilitar "Ventanilla Única".

  • MDM Hub Operativo: Golden Record Ciudadano (Merge Registraduría + Catastro + Tributario + Talento Humano).
  • Golden Record Predio: Unificación IGAC + Catastro Local + Tributario. Validación geoespacial (PostGIS).
  • APIs Unificadas: GET /ciudadanos/{id}, GET /predios/{codigo_catastral} para consumidores.
  • Limpieza Masiva: Reglas Match & Merge, deduplicación NIT (Proveedor/Empresa), estandarización direcciones.
MDM: Semarchy / Reltio / Open Source DB: Postgres + PostGIS API Gateway: Kong / Apigee
2

Fase 2: Plataforma Analítica y Transaccionales (Meses 6-12)

Objetivo: Lakehouse moderno. Ingesta unificada (Batch + CDC). Modelos dimensionales certificados.

  • Arquitectura Medalión: Bronze (Raw/Staging) → Silver (Clean/Conformed/MDM) → Gold (Business/Dimensional).
  • Modelos Estrella (Kimball) Prioritarios: Recaudo, Trámites, Contratación, Proyectos, Predial.
  • CDC Streaming: Debezium (Fuentes Transaccionales) → Kafka/Redpanda → Lakehouse (Merge/Update Near Real Time).
  • Self-Service BI: Power BI / Superset / Metabase sobre capa Gold. Roles y RLS.
Storage: S3/MinIO (Delta/Iceberg) Compute: Spark/Flink/DuckDB/Snowflake Orquestación: Airflow/Prefect CDC: Debezium + Kafka
3

Fase 3: Metadata, Calidad Automatizada y Contratos (Meses 9-14)

Objetivo: Observabilidad total, confianza en datos, contratos entre productores/consumidores.

  • Data Catalog Poblado: Linaje automático (OpenLineage desde Airflow/DBT/Spark), Diccionario técnico/negocio.
  • Data Contracts: Esquemas versionados, SLAs de frescura/calidad, notificaciones de breaking changes.
  • Quality Gates en Pipeline: Great Expectations / Soda Core. Bloqueo promoción Silver→Gold si falla.
  • Dashboards Data Health: % tablas documentadas, frescura, volumen, tasas error, cumplimiento SLA.
Catalog: OpenMetadata / DataHub Quality: Great Expectations / Soda Contracts: DBT / OpenLineage
4

Fase 4: Servicios Inteligentes e IA (Meses 12+)

Objetivo: Valor analítico avanzado: Predictivo, Prescriptivo, Generativo.

  • Modelos Predictivos: Evasión ICA/Predial (Scoring contribuyentes), Riesgo Proveedores, Demanda Trámites, Sobrecostos Proyectos.
  • Asistente Ciudadano (RAG): Chatbot sobre Glosario, Normativa, Trámites, Estado solicitudes. Human-in-the-loop.
  • Next Best Action: Recomendaciones inspectores (Rutas, Priorización fiscalización), Gestores cobro.
  • Simulador Presupuestal/Escenarios: What-if análisis impacto tasas, inversión, coyuntura macro.
MLOps: MLflow / Kubeflow / Vertex AI LLM: RAG (LangChain/LlamaIndex) + Vector DB Feature Store: Feast / Hopsworks

7. Matriz de Riesgos y Mitigaciones Arquitectónicas

RiesgoImpactoProb.Mitigación Arquitectónica
Duplicidad Ciudadano/Predio (Fuentes dispares sin clave única confiable) Crítico Alta MDM Hub con Match/Merge probabilístico + Reglas determinísticas (Nro Doc, Cod Catastral). Validación Registraduría/IGAC en tiempo real (API). Steward dueño de "Golden Record".
Calidad Referencia desactualizada (CIIU, DANE, Tarifas, Estructuras orgánicas) Alto Media Automatización ingesta RefData (Web Services DANE/DIAN/IGAC/Secretaría General). Data Contracts con owners. Alertas automáticas caducidad versión. Comité Datos aprueba cambios.
Latencia Recaudo → BI > 24h (Cierres contables tardíos, decisiones reactivas) Crítico Media Arquitectura CDC (Debezium) + Streaming (Kafka) → Lakehouse (Merge/Update). SLA 15 min medido y alertado. Particionamiento óptimo. Índices en claves de consulta frecuente.
Fuga datos sensibles (PII Ciudadano/Empleado/Proveedor) Crítico Media-Baja Privacy by Design: Pseudonimización en Capa Analítica (Silver/Gold). Tokenización reversible solo para roles autorizados. RLS estricto por Dependencia/Rol. Auditoría acceso completa (Log_Transacción). DPIA obligatorio nuevos proyectos.
Deuda técnica sistemas legado (FoxPro, VB6, Access, BD sin API, esquemas cerrados) Crítico Alta Patrón Strangler Fig: APIs Anti-Corruption Layer sobre legado. Ingesta por archivos planos/CSV validados (con checksum y metadatos) si no hay API. Priorizar migración fuentes críticas (Tributario, Catastro, Contratación). Documentación ingeniería inversa.
Falta adopción cultura de datos (Catálogo vacío, Calidad baja, "Excel culture", Resistencia cambio) Alto Alta Data Literacy Program obligatorio. Data Champions por dependencia. Métricas uso Catálogo/Calidad en Evaluación Desempeño. Quick Wins visibles (ej. Dashboard Recaudo Diario automático). Comunicación constante logros.
Cambio normativo frecuente (Reformas tributarias, Leyes transparencia, Estándares DANE/MinTIC) Medio Media Capa Reference Data versionada con vigencias. Data Contracts versionados (SemVer). Arquitectura modular: cambios en RefData no rompen Transaccional/Analítica. Monitoreo fuentes oficiales (Diario Oficial, DANE, MinTIC).

8. Alineación Normativa y Estándares (Contexto Colombia)

La arquitectura cumple y habilita el cumplimiento del marco legal colombiano vigente.

Norma / EstándarAplicación Concreta en la Arquitectura
Ley 1712/2014 (Transparencia y Acceso Información Pública)Metadatos abiertos (DCAT-AP.co), API Datos Abiertos, Catálogo Publicable, Retención documental automatizada, Log_Transacción inmutable.
Ley 1581/2012 + Dec. 1377/2013 (Protección Datos Personales - Habeas Data)Privacy by Design, Consentimiento gestionado en Master Data, Derechos ARCO (APIs Acceso/Rectificación/Supresión/Oposición), DPIA obligatorio, Pseudonimización en capa analítica, Roles de Custodio/Encargado.
Decreto 1081/2015 (Art 2.2.3.5.1) - MECI (Modelo Estándar Control Interno)Trazabilidad completa (Linaje), Auditoría técnica (Log_Transacción), Segregación funciones (RLS/RBAC), Plan Continuidad (Backups/DR documentados en Metadatos), Gestión Riesgos (Matriz integrada).
Resolución 0090/2018 (AGN) - Tablas Retención Documental (TRD)Tablas Retention_Policy mapeadas a TRD. Disposición final documentada y auditable. Jobs de purga/archivo automáticos con certificación.
Estándares DANE (CIIU 4.0, División Político-Administrativa, Clasificaciones estadísticas)Reference Data Obligatorio. Sincronización automática programada. Mapeo local → Estándar Nacional. Validación en origen (FK a catálogos DANE).
Esquema Nacional Interoperabilidad (ENI - MinTIC)APIs REST/JSON, OAuth2/OpenID Connect, Metadatos DCAT-AP.co para Portal Datos Abiertos, Formatos abiertos (CSV, JSON, XML, Parquet), Servicios web documentados (OpenAPI/Swagger).
CONPES 3918/2018 (Política Gobierno Digital)Ciudadano en el centro (Master Data Ciudadano único), Interoperabilidad por defecto, Datos Abiertos proactivos, Analítica para decisiones basadas en evidencia, Arquitectura empresarial alineada.
Ley 1755/2015 (Código de Trámites)Catálogo Tipo_Tramite versionado, SLA por trámite en metadatos, Trazabilidad completa ciclo de vida (Radicado → Respuesta), Canales digitales habilitados.
Ley 80/1993 & Ley 1150/2007 (Régimen Contractual Estatal)Modelo Contratación alineado SECOP II, Trazabilidad Adiciones/Prórrogas/Suspensiones, Publicación obligatoria (SECOP), Control presupuestal (RP/CP) en transaccional.

9. Resumen Ejecutivo para Toma de Decisiones

Esta arquitectura representa la Especificación Base (Baseline) validada técnicamente. Requiere aprobación directiva y asignación de recursos para ejecución.

DimensiónEstado Actual (Implícito en Doc Fuente)Estado Objetivo (Arquitectura Propuesta)Gap Principal / Acción Requerida
Gobernanza Incipiente (Liderada solo por Jefatura Inteligencia Tributaria) Data Governance Board transversal (Alcaldía) + Stewards por dominio (Tributario, Catastro, Contratación, Talento Humano, Proyectos) Formalizar Decreto/Resolución creando Consejo de Datos. Asignar presupuesto y tiempo (20% Stewards).
Master Data Silos funcionales (Catastro, Tributario, Talento Humano, Contratación, Planeación separados, datos inconsistentes) MDM Hub Unificado (Ciudadano, Predio, Proveedor, Empresa, Empleado, Programa, Proyecto). Golden Records certificados. Proyecto de Integración/Migración datos históricos. Definición reglas Match/Merge. Limpieza masiva inicial.
Reference Data Hojas de cálculo / Tablas sueltas en cada BD / Versiones obsoletas / Sin APIs Reference Data Hub centralizado, versionado (SemVer + Fechas), API-first (REST/OData), FK enforcadas en toda la plataforma. Limpieza catálogos actuales + Automatización ingesta fuentes oficiales (DANE, DIAN, IGAC, MinHacienda).
Transactional / Analítica Sistemas operacionales desconectados. Volcado manual a Excel para reportes. Sin histórico confiable. Cierres lentos. Lakehouse/DW Moderno con CDC Near Real Time. Modelo Dimensional Certificado (Kimball). Self-Service BI gobernado. Implementar CDC en motores legacy / Middleware de extracción. Definir modelos dimensionales (Workshops negocio).
Metadatos Documentación dispersa (Word/Excel) o inexistente. Desconocimiento linaje. Sin métricas calidad. Data Catalog Activo con Linaje automático, Calidad (Data Contracts), Glosario Negocio, Políticas Retención, Diccionario Técnico. Selección herramienta (OpenMetadata/DataHub/Comercial) + Población inicial (Ingeniería Metadatos 2-3 meses).
Analítica Avanzada / IA Reportes estáticos, reactivos, baja confianza, sin capacidad predictiva. Self-Service BI + Data Science/ML (Predictivo: Evasión, Riesgo, Demanda; Prescriptivo: Next Best Action; Generativo: Chatbot Ciudadano). Cultura de datos + Plataforma MLOps + Casos de uso priorizados con ROI claro (Ej: Modelo Evasión Predial = $$ Recaudo).
Próximos Pasos Inmediatos (Decision Points)
  1. Aprobación de este Baseline por Comité Directivo SH y Comité Gobierno Digital Alcaldía.
  2. Designación formal de Data Stewards (5 dominios) y Data Architect líder.
  3. Presupuesto Fase 0-1 (Gobernanza + MDM Hub + Limpieza Ciudadano/Predio). Estimado: COP $XXX MM (Requiere estimación detallada).
  4. Contratación Plataforma: Decisión Build vs Buy (MDM, Lakehouse, Catalog, BI). Proceso licitatorio / convenio marco.
  5. Kick-off Fase 0: Talleres de Governance Charter, Inventario Sistemas, Políticas Privacidad/Seguridad.

Arquitectura de Datos - Secretaría de Hacienda, Alcaldía de Armenia, Quindío

Documento derivado del PDF "ARQUITECTURA DE DATOS SECRETARÍA DE HACIENDA - ACTIVIDAD: HACIENDA INTELIGENTE (2026)"

Metodología: Capacity WORKS (GIZ) | Modelo Calidad: EFQM | Estándares: ENI, DANE, AGN, MECI

Generado para revisión técnica y directiva. Versión 1.0 - Baseline.

© 2026 Alcaldía de Armenia. Uso interno institucional.