ConTodo ERP — Arquitectura Empresarial (TOGAF-lite): Negocio, Aplicación, Datos y Tecnología
ConTodo ERP — Arquitectura Empresarial (TOGAF-lite)
Propósito. Este entregable consolida los quince documentos de agentes y los tres debates críticos en una Arquitectura Empresarial (EA) única y gobernada, siguiendo un enfoque TOGAF-lite (fases ADM B–Negocio, C–Sistemas de Información/Aplicación y Datos, D–Tecnología). Es el artefacto de alto nivel que articula por qué (negocio) → qué (capacidades) → cómo (aplicaciones, datos) → sobre qué (tecnología), y que sirve de marco rector para los entregables de detalle (arquitectura de solución, modelo de datos, plan de infraestructura). No reemplaza al ADR maestro técnico; lo enmarca.
Disclaimer (anti-overclaiming). Una EA es un mapa, no el territorio. Las cuatro capas que siguen reflejan el estado objetivo (target) de ConTodo a 18–24 meses, no el día 1. Donde el detalle técnico expone contradicciones entre agentes (región AWS, tipo de
tenant_id, doble pipeline de eventos, costos de IA/BI omitidos), esta EA no las oculta: las eleva a decisiones de arquitectura pendientes (sección 9), porque una EA que pinta coherencia inexistente es peor que ninguna. Toda decisión es reversible solo a un costo; las de Capa de Datos (tenancy) son las menos reversibles.
0. Resumen ejecutivo
ConTodo es un ERP SaaS cloud-native multi-tenant para PYMEs y medianas de Perú/LATAM (vertical inicial: textil, importadoras, comercializadoras, distribuidoras, manufactura ligera). Su tesis: entregar la profundidad fiscal de un producto local (CPE, SIRE, detracciones, PCGE) con la economía y el time-to-value de un SaaS (onboarding ≤ 5 días, TCO 40–60% menor que SAP B1), capturando el sweet spot "alto cumplimiento SUNAT + bajo costo PYME" que ningún competidor ocupa hoy.
| Capa EA | Decisión rectora | Riesgo dominante |
|---|---|---|
| Negocio | Cumplimiento SUNAT como núcleo de confianza (no add-on); land-and-expand por módulos; vertical textil primero | Cambios normativos SUNAT en pleno desarrollo |
| Aplicación | Monolito modular Rails (modular monolith) con bounded contexts alineados a los 18 módulos; SPA React desacoplada vía contrato OpenAPI | Stack analítico (Kafka/Cube) contradice el principio "deliberadamente aburrido" |
| Datos | Shared Schema + Row-Level Security (pooled-first) con Silo on-demand para enterprise; OLTP PostgreSQL separado de OLAP (DW dimensional Kimball) | Fuga cross-tenant vía connection pooler (RDS Proxy × SET) — riesgo #1 |
| Tecnología | AWS gestionado (ECS Fargate, RDS Multi-AZ, ElastiCache, S3, CloudFront/WAF); IaC Terraform; CI/CD gated | Costo real 2–3× el modelado al incluir IA y BI; equipo de 4–6 opera 15+ servicios |
1. Marco metodológico (TOGAF-lite)
Adoptamos un subconjunto pragmático del TOGAF ADM, suficiente para una organización pre-Serie A sin caer en la burocracia de un framework completo:
| Fase ADM | Pregunta | Insumo (agente) | Sección |
|---|---|---|---|
| B — Negocio | ¿Qué valor, para quién, con qué capacidades? | CEO, PM, ERP-Consultant, Textil, Importaciones | §2, §3 |
| C — Aplicación | ¿Qué sistemas/módulos lo realizan? | PM, Solution Architect, Rails, Frontend | §4 |
| C — Datos | ¿Qué información gobierna y cómo se aísla? | Solution Architect, Data&BI, Ciberseguridad | §5 |
| D — Tecnología | ¿Sobre qué infraestructura corre? | DevOps&AWS, Solution Architect, Ciberseguridad | §6 |
| E/F — Roadmap | ¿En qué orden se entrega? | PM, CEO, debates | §7, §8 |
| G/H — Gobierno | ¿Cómo se decide y controla? | Debate-02 (técnico) | §9, §10 |
2. Capa de Negocio (ADM B)
2.1 Motivadores estratégicos (vista de drivers)
| Driver de negocio | Objetivo | KPI / North Star | Capacidad que lo habilita |
|---|---|---|---|
| Tejido PYME mal servido (Excel + desktop legacy + ERP sobredimensionado) | Capturar el sweet spot SUNAT+precio | Empresas activas; ARR | Cumplimiento Tributario, Onboarding |
| Cumplimiento SUNAT como gancho de venta | ≥ 99.5% CPE aceptados al 1er intento | % aceptación SUNAT | Facturación Electrónica, SIRE |
| Time-to-value diferencial | 1ª factura ≤ 5 días | Mediana días a 1ª factura | Onboarding self-service, plantillas verticales |
| Land-and-expand (módulos premium) | NRR ≥ 115% | Net Revenue Retention | Catálogo modular de capacidades |
| IA como copiloto financiero (no add-on) | ≥ 8 h/mes ahorradas por usuario contable | Horas ahorradas | Inteligencia Aumentada |
| Expansión LATAM (Andina + México + CA) | 7 mercados a 2036 | ARR USD 70–90M | Cumplimiento pluggable por país |
North Star Metric (PM): Documentos electrónicos válidos procesados por mes por tenant activo — captura simultáneamente adopción, valor operativo y dependencia (stickiness) del producto.
2.2 Stakeholders y personas (actores de negocio)
| Actor | Rol | Dolor | Outcome esperado |
|---|---|---|---|
| Gloria | Contadora / Jefa Contabilidad | Cierre manual; PLE/SIRE en herramientas separadas | Asientos automáticos, SIRE en 1 clic, EEFF en tiempo real |
| Marco | Gerente / Dueño PYME | No ve márgenes ni caja proyectada | Dashboard de caja, márgenes por línea, alertas IA |
| Lucía | Jefa de Almacén | Descuadres de stock, sin valorización | Kardex multi-almacén valorizado en línea |
| Ana | Jefa de Compras / Importaciones | Costeo de importación en Excel; DUAs sueltas | Costeo DAM prorrateado automático |
| Diego | Vendedor / CRM | Cotiza fuera del sistema | Cotización → pedido → factura en un flujo |
| Admin Tenant | Configurador | Setup de empresas/sucursales/roles | Multiempresa/sucursal/rol con aislamiento |
| Partner Contable / Integrador | Ecosistema | — | Marketplace, export PLE/SIRE, API |
2.3 Cadena de valor de negocio (procesos núcleo)
2.4 Modelo de negocio (vista de monetización)
Cobro por empresa (tenant) + por usuario activo, con módulos premium desbloqueables (land-and-expand). El tier de entrada es de adquisición; el margen aparece desde el tier 2. SKU Soberanía/Dedicado (Silo) como upsell enterprise.
| Tier | Público | Módulos núcleo | Precio (PEN/mes) | ~USD |
|---|---|---|---|---|
| Emprende | Micro 1–3 usuarios | CPE, Ventas, Inventario, Caja, PLE | S/ 99 | ~26 |
| Crece | Pequeña (8 us.) | + Compras, Kardex, Multialmacén, Tesorería, Contab. básica, SIRE | S/ 349 | ~93 |
| Pro / Mediana | Mediana | + Producción, Importaciones, EEFF, BI | (negociado) | — |
| Soberanía (Silo) | Enterprise regulado | Aislamiento físico (RDS dedicada) + BYOK | upsell premium | — |
Implicación EA: el modelo land-and-expand exige que la Capa de Aplicación sea modular (capacidades activables por tier sin reescritura) y que la Capa de Datos soporte pooled (margen) + silo (premium) — coherente con las decisiones de §4 y §5.
3. Mapa de Capacidades de Negocio (Business Capability Map)
El mapa de capacidades responde qué hace ConTodo y para sus clientes, con independencia de cómo se implementa. Es el puente entre la cadena de valor (§2.3) y el mapa de aplicaciones (§4.4).
3.1 Catálogo de capacidades (con criticidad y madurez objetivo)
| ID | Capacidad de negocio | Tipo | Módulos que la realizan | Criticidad | Fase |
|---|---|---|---|---|---|
| BC-01 | Gobierno y Cumplimiento Tributario | Dirección | ERP-Consultant transversal | Crítica | F0–F2 |
| BC-02 | Facturación Electrónica (CPE) | Núcleo | Ventas, Logística (GRE) | Crítica | F1 |
| BC-03 | Registros Electrónicos (SIRE/PLE) | Núcleo | Contabilidad, Compras, Ventas | Crítica | F1–F2 |
| BC-04 | Inventario y Kardex Valorizado | Núcleo | Inventario, Kardex | Alta | F1 |
| BC-05 | Ciclo Compra-Venta (Q2C / P2P) | Núcleo | Compras, Ventas, CRM | Alta | F1 |
| BC-06 | Contabilidad y Estados Financieros | Núcleo | Contabilidad, EEFF | Alta | F2 |
| BC-07 | Costeo de Importaciones (DAM) | Núcleo (vertical) | Importaciones | Media-Alta | F2 |
| BC-08 | Producción Textil (BOM) | Núcleo (vertical) | Producción | Media | F3 |
| BC-09 | Seguridad, IAM, RBAC/SoD | Soporte | Seguridad, Usuarios | Crítica | F0 |
| BC-10 | Gestión Multiempresa/Multisucursal | Soporte | Empresas | Crítica | F0 |
| BC-11 | Tesorería y Conciliación | Soporte | Tesorería | Media | F1–F2 |
| BC-12 | Logística y GRE | Soporte | Logística | Media | F2 |
| BC-13 | CRM y Gestión Comercial | Soporte | CRM | Media | F3 |
| BC-14 | RRHH y Planillas (PLAME/AFPnet) | Soporte | RRHH, Planillas | Media | F4 |
| BC-15 | Inteligencia de Negocio (BI) | Dirección | BI / Data Warehouse | Media | F4 |
| BC-16 | Inteligencia Aumentada (IA) | Dirección | IA | Media | F4 |
| BC-17 | Multimoneda / Multiidioma | Transversal | Plataforma | Alta | F0/F3 |
Regla de cobertura. Toda capacidad debe estar realizada por ≥ 1 aplicación y ≥ 1 conjunto de entidades de datos. Las capacidades Críticas (BC-01, 02, 03, 09, 10) son las que, si fallan, hacen desechable el producto en el mercado peruano y por tanto son bloqueantes del MVP.
4. Capa de Aplicación (ADM C — Sistemas de Información)
4.1 Principios de arquitectura de aplicación
- Monolito modular (modular monolith) Rails, no microservicios prematuros: un equipo de 4–6 no opera una malla de servicios. Los bounded contexts viven como módulos/engines dentro de un mismo despliegue, con fronteras de dominio explícitas.
- Frontend desacoplado: SPA React + TypeScript + Tailwind, comunicada con el backend vía contrato OpenAPI como única fuente de verdad de tipos (GraphQL pospuesto). No hay SSR salvo para superficie pública de comprobantes (pendiente de definir, ver §9 T3).
- Cumplimiento como capa aislada y versionada: el motor SUNAT (CPE, SIRE, PLE) se encapsula tras gateways (patrón Strategy:
ComprobanteGatewaycon SEE-propio + fallback OSE) para absorber cambios normativos sin tocar el dominio. - Async-first para integraciones externas: toda interacción con SUNAT/OSE/bancos/LLM pasa por colas Sidekiq con reintentos idempotentes.
- Activación por tier: las capacidades premium se habilitan por feature flags ligados al plan del tenant (land-and-expand).
4.2 Bounded Contexts (alineados a los 18 módulos)
4.3 Integración entre aplicaciones (eventos y contratos)
El acoplamiento entre contextos es por eventos de dominio, no por llamadas síncronas directas, para preservar autonomía de módulos. Decisión pendiente vinculante (§9 RT3/RT4): unificar el mecanismo de captura/propagación de cambios; existen hoy tres candidatos no reconciliados (Sidekiq/Redis, SNS/EventBridge, Kafka/MSK+Debezium). La EA recomienda outbox transaccional → EventBridge para integración y diferir CDC/Kafka a fase de escala, alimentando BI desde el mismo outbox en MVP.
| Productor | Evento de dominio | Consumidores | Mecanismo (target EA) |
|---|---|---|---|
| Ventas | FacturaEmitida | Cumplimiento (CPE→SUNAT), Contabilidad (asiento), Inventario (salida), BI | Outbox → EventBridge |
| Inventario/Kardex | MovimientoStock | Contabilidad (costo), BI, Producción | Outbox → EventBridge |
| Compras | CompraRegistrada | Contabilidad, Importaciones (costeo), RCE | Outbox → EventBridge |
| Tesorería | PagoCobranzaRegistrado | Contabilidad, BI (DSO/DPO) | Outbox → EventBridge |
| (cualquiera) | cambios de fila | BI/DW | CDC (Fase 3) o consumidor del outbox (MVP) |
4.4 Mapa de Aplicaciones (Application Portfolio)
4.5 Catálogo de aplicaciones/servicios y su rol
| Aplicación / Servicio | Tecnología | Realiza capacidades | Patrón |
|---|---|---|---|
| SPA ConTodo | React + TS + Tailwind | Toda la UI operativa | SPA, tipos desde OpenAPI |
| Dashboard Ejecutivo | React + Recharts | BC-15 (BI) | Embebido sobre capa semántica |
| API Rails | Rails 7 API | BC-01..14, 17 | Modular monolith, OpenAPI |
| Workers Sidekiq | Sidekiq + Redis | CPE, SIRE, reportes, IA, emails | Colas por prioridad, idempotencia |
| ComprobanteGateway | Rails (Strategy) | BC-02 | Anti-corruption + fallback OSE |
| SIRE Client | Rails | BC-03 | Cliente servicios web SUNAT |
| Capa semántica Cube | Cube | BC-15, BC-16 | Métricas-as-code + RLS |
| Servicios IA | LLM gateway + ML | BC-16 | Sobre capa semántica (no SQL crudo) |
| Data Warehouse | columnar (DuckDB/Redshift) | BC-15 | Estrella Kimball, separado del OLTP |
5. Capa de Datos (ADM C — Arquitectura de Datos)
5.1 Decisión rectora: tenancy
La decisión menos reversible de toda la arquitectura. ConTodo adopta Shared Schema + PostgreSQL Row-Level Security (pooled-first), con Silo on-demand (RDS dedicada vía Rails connects_to) para los pocos tenants enterprise que exijan aislamiento físico o residencia. Se descarta Separate-Schema (techo de escala ~3–5k schemas) y Database-per-Tenant universal (costo 2–40× y complejidad operativa inviable para un equipo de 4–6).
| Modelo | Aislamiento | Costo/tenant escala | Escala nº tenants | Veredicto |
|---|---|---|---|---|
| Shared Schema + RLS | Fuerte (motor) | ~US$ 0.2–2/mes | Decenas de miles | Elegido (default) |
| Separate Schema | Fuerte | Bajo-medio | ~3–5k (techo) | Descartado |
| Database-per-Tenant | Máximo | US$ 15–50+/mes | Limitado por ops | Silo on-demand (premium) |
5.2 Defensa en profundidad del aislamiento de datos
Riesgo de datos #1 (debate-02 RT1). RDS Proxy/PgBouncer en modo
transactionpuede multiplexar conexiones de forma que una variable de sesión mal scopeada filtre contexto entre tenants. Mitigación obligatoria: toda query corre en transacción conSET LOCAL; test de aislamiento que corra a través del pooler, no solo contra Postgres directo. Sin esto validado, "aislamiento garantizado por motor" es papel.
5.3 Convenciones canónicas de datos (resolver contradicciones)
| Convención | Decisión EA recomendada | Origen de la contradicción |
|---|---|---|
| Nombre de columna tenant | tenant_id (no company_id) | C2: 07/11/12/13 vs 08/10 |
| Tipo de dato tenant | BIGINT interno + UUID público | C3: UUID (11) vs BIGINT (07/08) |
| Moneda funcional | PEN; cada hecho monetario guarda monto origen + TC SBS + monto PEN | Data&BI S4 (NIC 21) |
| Particionado tablas calientes | LIST/HASH(tenant_id) + fecha en comprobantes, kardex, asientos | 07 ADR-04 (con caveat power-law) |
| Conservación CPE/XML | S3 versionado + CRR + lifecycle, retención ≥ 5 años (Art. 87 C.T.) | ERP-Consultant |
5.4 Dominios de datos (Data Domains) y propiedad
5.5 Modelo dimensional (resumen del DW)
OLTP y OLAP estrictamente separados (S1 Data&BI): el ERP nunca corre analítica pesada (proteger p95 < 300 ms). El DW usa esquema estrella Kimball, grano explícito por fact, SCD2 para dimensiones con historia, moneda dual en PEN.
| Tabla de hechos | Grano | Tipo |
|---|---|---|
fact_ventas | 1 línea de comprobante | Transaccional |
fact_compras | 1 línea de OC/factura | Transaccional |
fact_inventario_mov | 1 movimiento kardex | Transaccional |
fact_inventario_snap | 1 producto×almacén×día | Snapshot (semi-aditiva) |
fact_finanzas_gl | 1 línea de asiento | Transaccional |
fact_cobranzas | 1 documento por cobrar | Accumulating snapshot |
Capa semántica (Cube) como contrato único de KPIs (EBITDA, margen, rotación, DSO/DPO, liquidez) — una sola definición que sirve a dashboard, self-service e IA (NL2SQL sobre métricas gobernadas, no SQL crudo → menos alucinación, RLS preservada).
5.6 Gobierno de datos y cumplimiento
| Aspecto | Control |
|---|---|
| Aislamiento contractual | RLS + tenant_id en cada fact/dim del DW + tests de aislamiento en CI |
| Datos sensibles (PII planillas, certificados SUNAT) | Cifrado en reposo KMS; certificados en Secrets Manager (nunca en DB plana) |
| Auditoría | audit_logs append-only por tenant (hash-chain + WORM); CloudTrail |
| Derecho ARCO (Ley 29733) | Export/borrado por tenant — a diseñar (Shared Schema lo dificulta; §9 deuda #6) |
| Integridad contable | Test de balance Σdebe = Σhaber por asiento (dbt + constraint) |
6. Capa de Tecnología (ADM D)
6.1 Principios de tecnología
- Stateless compute, stateful gestionado (Fargate efímero; estado en RDS/ElastiCache/S3).
- IaC como única fuente de verdad (Terraform; cero cambios manuales en consola).
- Seguridad por defecto (cifrado KMS en reposo, TLS 1.2+ en tránsito, WAF al borde, IAM least-privilege).
- "Deliberadamente aburrido" — patrones probados; introducir tecnología exótica (Kafka/Redshift/GPU) solo cuando un disparador medible lo justifique (tensión real con Data&BI, §9 T5).
- Costo consciente (Graviton, Savings Plans, Spot selectivo) — pero con FinOps que incluya IA y BI (omitidos en el modelo original, §9 RT2).
6.2 Arquitectura tecnológica (vista de despliegue AWS)
6.3 Catálogo de plataforma tecnológica
| Capacidad técnica | Servicio AWS | Soporta capa |
|---|---|---|
| Compute web (stateless) | ECS Fargate (Rails/Puma) | Aplicación |
| Compute async | ECS Fargate (Sidekiq) — critical On-Demand | Aplicación |
| OLTP multi-tenant | RDS PostgreSQL 16 Multi-AZ + RLS | Datos |
| OLTP enterprise (silo) | RDS dedicada por tenant | Datos |
| Lectura/analítica | RDS Read Replicas → DW columnar | Datos |
| Cache / cola / sesiones | ElastiCache Redis | Aplicación/Datos |
| Pooling de conexiones | RDS Proxy / PgBouncer | Datos (riesgo #1) |
| Almacenamiento de objetos | S3 (SPA, CPE/XML, backups) | Datos |
| CDN + TLS + WAF | CloudFront + ACM + AWS WAF + Shield | Tecnología/Seguridad |
| DNS + failover | Route53 | Tecnología |
| Secretos / certificados | Secrets Manager + KMS | Seguridad |
| Observabilidad | CloudWatch + X-Ray | Tecnología |
| Backup / DR | AWS Backup (CRR a región DR) | Tecnología |
| IaC | Terraform (S3 backend + DynamoDB lock) | Gobierno |
| CI/CD | GitHub Actions (OIDC) + CodeDeploy blue/green | Gobierno |
6.4 Atributos de calidad (NFRs) y su realización tecnológica
| NFR | Objetivo | Mecanismo |
|---|---|---|
| Disponibilidad | 99.9% MVP → 99.95% madurez | Multi-AZ (RDS/ECS/Redis), blue/green, health checks |
| RPO / RTO | RPO ≤ 5 min / RTO ≤ 1 h (enterprise) | PITR + snapshots + warm standby cross-region |
| Latencia | p95 emisión CPE ≤ 3 s; ERP p95 < 300 ms | Async Sidekiq, read replicas, OLTP/OLAP separados |
| Escalabilidad | MVP → 5.000 tenants | Autoscaling Fargate, particionado, read replicas, sharding por cohorte (a futuro con disparador) |
| Seguridad | Ley 29733; base SOC2/ISO27001 | RLS, KMS, WAF, RBAC/SoD, audit hash-chain, vCISO+Vanta (a presupuestar) |
| Conservación fiscal | ≥ 5 años CPE | S3 versionado + Glacier + CRR |
6.5 Realidad del costo (corrección de gobierno)
El modelo de costos de infraestructura (DevOps) omite IA y BI, los diferenciadores que el negocio venderá. La crítica técnica (debate-02 §2.3) corrige:
| Escala | Costo modelado (infra base) | Costo realista (incl. IA+BI) | Margen infra |
|---|---|---|---|
| 5.000 tenants | ~US$ 20.600/mes (~US$ 4.1/cliente) | US$ 35.000–60.000/mes (~US$ 7–12/cliente) | 65–75% (no >80%) |
Implicación EA: el P&L (agente Finanzas) debe usar la cifra ajustada. La EA recomienda diferir MSK/Debezium/Redshift/Cube/Llama-VPC del MVP (BI = batch nocturno dbt+DuckDB; IA = Bedrock managed) para no operar 15+ servicios con un equipo de 4–6.
7. Trazabilidad inter-capas (matriz EA)
La prueba de una EA es que cada capa traza a la siguiente sin huérfanos. Muestra representativa:
| Negocio (driver) | Capacidad | Aplicación | Datos | Tecnología |
|---|---|---|---|---|
| Cumplimiento SUNAT como gancho | BC-02 CPE | ComprobanteGateway + Ventas | comprobantes (OLTP) + S3 XML/CDR | Sidekiq cola cpe, S3, Secrets Manager (cert) |
| SIRE automatizado (diferenciador) | BC-03 SIRE | SIRE Client + Contabilidad | sire_*, RCE/RVIE | Sidekiq cola sire, RDS |
| Control de stock valorizado | BC-04 Kardex | Inventario/Kardex | kardex particionado | RDS (lock por SKU+almacén) |
| Decisión basada en datos | BC-15 BI | Dashboard + Cube | facts/dims (OLAP) | DW columnar + read replica |
| Copiloto financiero IA | BC-16 IA | Servicios IA | capa semántica | LLM Gateway (Bedrock managed) |
| Onboarding ≤ 5 días | BC-10 Multiempresa | Empresas (insert + seed) | Shared Schema (tenant instantáneo) | RDS pooled |
8. Roadmap de transición (ADM E/F)
Alineado al roadmap de producto en horizontes de outcomes (no fechas rígidas):
| Fase | Estado EA objetivo | Capacidades nuevas | Hito comercial |
|---|---|---|---|
| F0 | Capa Plataforma + tenancy validada (incl. pooler+RLS) | BC-09, BC-10, BC-17 | 3 pilotos |
| F1 | MVP comercial+fiscal operativo | BC-02, BC-04, BC-05, BC-03 (básico) | Primeros clientes de pago |
| F2 | Capa Fiscal-Financiera completa | BC-06, BC-07, BC-12 | Reemplazo CONCAR/SISCONT |
| F3 | Vertical textil + multimoneda | BC-08, BC-13 | Penetración textil |
| F4 | Plataforma analítica + IA | BC-15, BC-16, BC-14 | Upsell, expansión LATAM |
9. Decisiones de arquitectura pendientes (gobierno ADM G)
La EA no inventa coherencia: eleva las contradicciones inter-documento a decisiones vinculantes a resolver en un ADR maestro antes de codificar.
| ID | Decisión pendiente | Recomendación EA | Severidad |
|---|---|---|---|
| C1 | Región AWS primaria (us-east-1 vs sa-east-1) | Elegir UNA y recostear; EA inclina a sa-east-1 si residencia/comercial pesa | Alta |
| C2/C3 | Nombre y tipo de tenant_id | tenant_id BIGINT interno + UUID público | Alta |
| RT1 | Pooler RDS Proxy × SET LOCAL (fuga cross-tenant) | Validar SET LOCAL en transacción a través del pooler antes del MVP | Crítica |
| RT3/RT4 | Pipeline de eventos (outbox vs CDC vs 3 buses) | Outbox→EventBridge (MVP); diferir Kafka/CDC a escala | Alta |
| C6/T5 | Stack de BI exótico vs "aburrido" | MVP: batch dbt+DuckDB; CDC/Redshift/Cube por disparador | Alta |
| RT2 | Costo IA+BI omitido del P&L | Modelo de costos consolidado único (margen 65–75%) | Alta |
| RT7 | Sharding sin disparador ni dueño | ADR de sharding con métrica gatillo antes de 1.000 tenants | Alta |
| Deuda #6 | Export/borrado por tenant (Ley 29733) | Diseñar desde F0 (Shared Schema lo dificulta) | Media |
| T3 | Superficie pública de comprobantes (SSR) | Definir si hay portal público de factura sin login | Media |
| RT9 | Compliance con 1 Security Engineer | vCISO + Vanta/Drata, presupuestado en P&L | Media-Alta |
10. Riesgos y oportunidades de la arquitectura empresarial
10.1 Riesgos (vista consolidada)
| ID | Riesgo | Capa | Severidad | Mitigación |
|---|---|---|---|---|
| RA1 | Fuga cross-tenant vía connection pooler | Datos | Crítica | SET LOCAL en transacción + test a través del pooler |
| RA2 | Cambios normativos SUNAT durante desarrollo | Negocio | Alta | Capa de cumplimiento aislada y versionada; OSE como buffer |
| RA3 | Costo real 2–3× por IA/BI ausentes del modelo | Tecnología | Alta | FinOps consolidado; diferir stack exótico |
| RA4 | Ausencia de ADR maestro (7 agentes sin contrato) | Gobierno | Alta | Sesión de reconciliación → ADR-MASTER vinculante |
| RA5 | Migración a escala bloquea a 5.000 tenants a la vez | Datos | Alta | expand/contract + pg-osc + runbook desde día 1 |
| RA6 | Equipo de 4–6 opera 15+ servicios gestionados | Tecnología | Alta | Reducir superficie MVP; contratar SRE antes de 500 tenants |
| RA7 | Pérdida de CPE (obligación 5 años) | Datos | Crítica | S3 versionado + CRR + Glacier; sin borrado físico |
| RA8 | Doble pipeline de eventos (outbox + CDC) | Aplicación | Alta | Elegir uno (outbox MVP); ADR vinculante |
| RA9 | Subestimación de Contabilidad/PCGE | Negocio | Alta | Spike temprano; contadora en el equipo |
10.2 Oportunidades
| ID | Oportunidad | Capa | Valor |
|---|---|---|---|
| OA1 | Tier "Soberanía" (Silo + BYOK + IA-en-VPC) como SKU premium | Negocio/Datos | Diferenciador enterprise vs Defontana/StarSoft; mayor ticket |
| OA2 | Pooled = margen SaaS alto + onboarding instantáneo (PLG) | Datos/Negocio | Crecimiento product-led; precio competitivo vs SAP B1 |
| OA3 | Capa semántica única (Cube) sirve a BI y a IA (NL2SQL) | Datos/Aplicación | Una sola verdad de KPIs; menos alucinación de IA |
| OA4 | Cumplimiento pluggable por país (DIAN, SII, SRI) reusa la EA | Aplicación | Habilita expansión LATAM sin reescritura |
| OA5 | Outbox como única fuente de eventos elimina Kafka en MVP | Tecnología | Ahorra ~US$ 1.5–2.5k/mes + complejidad operativa |
| OA6 | Tests de aislamiento cross-tenant en CI como activo de venta | Datos/Gobierno | Evidencia auditable que acelera SOC 2 |
| OA7 | FinOps por tenant (margen por tenant) | Tecnología | Identifica candidatos a silo o a upsell |
| OA8 | Benchmarks de sector textil/comercio sobre base instalada | Datos | Producto de inteligencia de mercado (respetando privacidad) |
11. Conclusión
La Arquitectura Empresarial de ConTodo es coherente de extremo a extremo: el motivador de negocio (servir al PYME peruano con cumplimiento SUNAT a precio accesible) baja limpiamente a un mapa de capacidades centrado en lo fiscal-financiero, se realiza en un monolito modular Rails con bounded contexts alineados a los 18 módulos y SPA React desacoplada, se apoya en una capa de datos pooled (Shared Schema + RLS) con silo on-demand que separa OLTP de OLAP, y corre sobre una plataforma AWS gestionada deliberadamente convencional.
El valor de esta EA no está en declarar que todo encaja, sino en exponer dónde aún no encaja: cinco contradicciones de severidad alta entre los agentes, un riesgo de fuga cross-tenant en la intersección pooler×RLS que sería un evento de extinción de marca para un ERP contable, y un modelo de costos que infla el margen al omitir IA y BI. La recomendación de gobierno es inequívoca: antes de la primera línea de código, una sesión de reconciliación que produzca un ADR maestro vinculante, valide el binomio pooler+RLS, consolide un único modelo de costos (margen realista 65–75%) y reduzca la superficie operativa del MVP. La arquitectura está a una semana de gobierno de ser excelente; sin ese gobierno, está a varios meses de descubrir sus fracturas en producción.