Hoja de trabajo - martin-hendricks/MISO-PROYECTO-FINAL-SOLVENTA GitHub Wiki

📋 Hoja de trabajo

Hoja de trabajo con objetivos, restricciones y requisitos de calidad. Épicas e historias de usuario en la plataforma escogida (DevOps, Jira).

Objetivos

Objetivo 1

Criterio Detalle del Objetivo
Objetivo de negocio Alcanzar una cartera de 5 millones de pólizas activas
Descripción del objetivo Lograr una base consolidada de 5 millones de pólizas activas mediante ventas directas y canales embebidos, soportando el alto volumen transaccional sin degradación de la experiencia de usuario.
Tiempo de cumplimiento 36 meses
Mejora esperada al negocio Crecimiento exponencial en el Market Share, consolidando el modelo de negocio masivo con un alto volumen de ingresos por primas.
Cómo considera que pueda afectar la arquitectura del sistema este objetivo Afecta críticamente el Desempeño (Escalabilidad). se deben aplicar tácticas de manejo de recursos como "mantener múltiples copias de procesamiento" e "introducción de concurrencia". Esto obliga a usar el patrón de Microservicios para escalar independientemente el dominio de pólizas. Estas decisiones definirán la Vista de Concurrencia y la Vista de Despliegue para distribuir la carga en múltiples nodos.

Objetivo 2

Criterio Detalle del Objetivo
Objetivo de negocio Construir una red de más de 30 socios de distribución
Descripción del objetivo Integrar a más de 30 aliados estratégicos (bancos, aerolíneas, e-commerce) exponiendo el catálogo y cotización a canales de terceros vía API de forma embebida.
Tiempo de cumplimiento 36 meses
Mejora esperada al negocio Reducción del costo de adquisición de clientes (CAC) y diversificación de los canales de venta.
Cómo considera que pueda afectar la arquitectura del sistema este objetivo Impacta fuertemente la Facilidad de Integración, la Facilidad de Modificación y la Seguridad. Arquitectónicamente, exige un API Gateway para aislar las peticiones. Para facilitar la modificación, requerimos un "bajo acoplamiento" entre los componentes internos y los socios externos mediante el uso de interfaces (APIs). Además, requerirá aplicar tácticas de seguridad como la "autenticación" y "autorización" de cada socio mediante tokens o certificados.

Objetivo 3

Criterio Detalle del Objetivo
Objetivo de negocio Expandir la operación a México, Chile y Perú
Descripción del objetivo Habilitar la plataforma core para operar en tres nuevos países, adaptando el sistema a las normativas locales de Open Finance y protección de datos, sin afectar el núcleo del sistema.
Tiempo de cumplimiento 36 meses
Mejora esperada al negocio Diversificación del riesgo geográfico y aumento drástico del mercado total direccionable (TAM).
Cómo considera que pueda afectar la arquitectura del sistema este objetivo Tensiona la Facilidad de Modificación. En entornos de alta demanda transaccional sabemos que cada cambio regulatorio no puede romper el core. Se sugiere lograr esto buscando "mantener una alta cohesión" en los componentes y reduciendo el acoplamiento. Se requiere una modularidad estricta (ej. Arquitectura Hexagonal) para aislar las adaptaciones de pasarelas de pago y entidades locales en adaptadores específicos sin tocar la lógica de negocio central.

Objetivo 4

Criterio Detalle del Objetivo
Objetivo de negocio Sostener un ratio combinado saludable soportado por suscripción basada en datos
Descripción del objetivo Mantener la rentabilidad mediante la automatización de la evaluación de riesgos y fijación de precios en tiempo real, enriqueciendo el perfil del cliente con datos de Open Data y Open Finance.
Tiempo de cumplimiento 36 meses
Mejora esperada al negocio Reducción significativa del fraude, control de la siniestralidad y optimización de márgenes operativos.
Cómo considera que pueda afectar la arquitectura del sistema este objetivo Afecta la Latencia. Al depender de fuentes externas impredecibles, es necesario aplicar tácticas como "ocultar los microservicios mediante el uso de una API Gateway" para enmascarar fallas. Para el procesamiento de datos asíncrono y la trazabilidad de decisiones actuariales, se sugiere utilizar una Arquitectura Orientada a Eventos (Event Sourcing), aislando las consultas complejas de los comandos de suscripción, aplicando el patrón CQRS para no bloquear los hilos principales.

Restricciones de negocio

Restricción de Negocio 1: Greenfield (sin sistemas heredados)

Restricciones de negocio
Descripción de la restricción Solventa nace en 2026 sin sistemas heredados. No existe un core asegurador, un modelo de datos previo ni integraciones internas que reutilizar. El diseño parte desde cero.
Usuario que expresa esta restricción CEO / Junta directiva, CTO / Arquitectura.
Justificación para esta restricción El caso impone un modelo fintech greenfield. Quedan cerradas las estrategias brownfield (reuso de un core existente, strangler sobre un monolito legado o migración incremental desde un sistema anterior).
Cómo considera que pueda afectar la arquitectura del sistema esta restricción Obliga a elegir y justificar estilo, persistencia y fronteras sin anclarse a un sistema previo. Toda la complejidad operable debe caber en el equipo actual; no se hereda operación, datos históricos ni conocimiento de un core antiguo.

Restricción de Negocio 2: Equipo reducido y evolución organizacional

Restricciones de negocio
Descripción de la restricción El equipo es reducido (4 personas en el ciclo de arquitectura) y el sistema debe poder crecer con el negocio. La complejidad organizacional aumenta con la escala, pero no está disponible el día uno.
Usuario que expresa esta restricción CEO / Junta directiva, CTO / Arquitectura, Equipos de desarrollo.
Justificación para esta restricción Un diseño que exija muchos equipos, un área SRE dedicada o un proceso de release pesado no es operable al inicio. La arquitectura debe ser evolutiva, no presuponer la organización de los 36 meses.
Cómo considera que pueda afectar la arquitectura del sistema esta restricción Favorece una modularidad que permita crecer el equipo después, sin exigir esa organización al arranque. Limita el número de desplegables y la carga operativa que el equipo de 4 personas puede sostener.

Restricciones de tecnología

Restricción de Tecnología 1: Infraestructura exclusiva en nube pública
Descripción de la restricción El sistema se diseña, construye y ejecuta en una plataforma de nube pública (AWS, GCP o Azure). Queda prohibida la infraestructura física local (on-premises) y los servidores dedicados tradicionales.
Usuario que expresa esta restricción CEO / Junta directiva, CTO / Arquitectura.
Justificación para esta restricción El caso impone nube primero como decisión ya tomada. Cierra el espacio de diseño on-premises. La elasticidad, el multi-zona y el autoescalado no forman parte de esta restricción: son requisitos de escalabilidad.
Cómo considera que pueda afectar la arquitectura del sistema esta restricción Impide dimensionar un data center propio o un core en servidores dedicados. El proveedor de nube queda como premisa de despliegue; las metas medibles de capacidad se especifican en los escenarios de calidad, no aquí.

Restricción de Tecnología 2: Stack de implementación ya decidido
Descripción de la restricción El dominio se implementa en Python. El cliente web se implementa en Angular. El cliente móvil se implementa en Android / Kotlin. No se introduce un segundo runtime de negocio ni se unifica web y móvil en un único cliente híbrido.
Usuario que expresa esta restricción CTO / Arquitectura, Equipos de desarrollo.
Justificación para esta restricción El caso no prescribe estilo arquitectónico, pero el equipo ya fijó el stack de entrega. Esa decisión cierra alternativas (otro backend, solo web responsiva, o un único cliente híbrido) y no es un atributo de calidad.
Cómo considera que pueda afectar la arquitectura del sistema esta restricción Acota librerías, empaquetado y pipeline a ese stack. Cómo se exponen las APIs a cada canal (API única vs. BFF) y las capacidades de cámara, biometría u offline son requisitos funcionales o de integración, no esta restricción.

Requisitos de calidad

Historias de arquitectura en Jira

Historias de arquitectura en Jira (SOLV, label HA)

6.1 Latencia

Cotización embebida

EC-LAT-01 — Operación normal

Elemento Definición
Fuente Socio de distribución
Estímulo Solicita una cotización mediante la API
Artefacto Capacidad de cotización y motor de rating
Ambiente Producción a carga nominal
Respuesta Calcula y retorna la cotización
Medida p95 ≤ 250 ms extremo a extremo
Prioridad (A,A) — ASR

EC-LAT-02 — Horario pico

Elemento Definición
Fuente Socio de distribución
Estímulo Solicita una cotización mediante la API
Artefacto Capacidad de cotización y motor de rating
Ambiente Producción en horario pico con alta concurrencia
Respuesta Calcula y retorna la cotización
Medida p99 ≤ 500 ms extremo a extremo
Prioridad (A,A) — ASR

Perfilamiento en línea (vida hipotecario)

EC-LAT-03 — Operación normal

Elemento Definición
Fuente Proceso de originación de un banco aliado
Estímulo Solicita el perfilamiento de un cliente con consentimiento vigente
Artefacto Capacidad de perfilamiento y capa de integración externa
Ambiente Producción a carga nominal
Respuesta Construye el perfil de riesgo y genera la oferta personalizada
Medida p95 ≤ 400 ms
Prioridad (A,A) — ASR

EC-LAT-04 — Pico de originación

Elemento Definición
Fuente Proceso de originación de un banco aliado
Estímulo Solicita el perfilamiento de un cliente con consentimiento vigente
Artefacto Capacidad de perfilamiento y capa de integración externa
Ambiente Producción durante el pico de cierres de fin de mes
Respuesta Construye el perfil de riesgo y genera la oferta personalizada
Medida p99 ≤ 800 ms
Prioridad (A,A) — ASR

Suscripción y emisión automática

EC-LAT-05 — Operación normal

Elemento Definición
Fuente Cliente asegurado
Estímulo Acepta la oferta de seguro recibida
Artefacto Capacidades de suscripción, cobro, firma y emisión
Ambiente Producción operando a carga nominal
Respuesta Decide la suscripción, procesa el cobro y emite la póliza
Medida p95 ≤ 1,5 s desde la aceptación hasta la póliza emitida
Prioridad (A,A) — ASR

EC-LAT-06 — Horario pico

Elemento Definición
Fuente Cliente asegurado
Estímulo Acepta la oferta de seguro recibida
Artefacto Capacidades de suscripción, cobro, firma y emisión
Ambiente Producción operando en horario pico de transacciones
Respuesta Decide la suscripción, cobra la prima y emite la póliza
Medida p99 ≤ 3 s desde la aceptación hasta la póliza emitida
Prioridad (A,A) — ASR

Dependencia degradada

EC-LAT-09 — Cotización con dependencia degradada

Elemento Definición
Fuente Socio de distribución
Estímulo Solicita una cotización
Artefacto Capacidad de cotización y caché de perfil
Ambiente Producción con un proveedor que no responde dentro de su presupuesto
Respuesta Completa la cotización con el valor de respaldo disponible
Medida p95 ≤ 250 ms del journey de cotización
Prioridad (A,A) — ASR

Consulta de póliza y estado de siniestro

EC-LAT-11 — Consulta de estado de siniestro

Elemento Definición
Fuente Cliente asegurado
Estímulo Consulta el estado de un siniestro en curso
Artefacto Modelo de lectura de siniestros
Ambiente Producción en condiciones regulares
Respuesta Retorna el estado vigente del siniestro
Medida p95 ≤ 150 ms
Prioridad (A,A) — ASR

6.2 Escalabilidad

Campaña masiva de socio

EC-ESC-01 — Caudal sostenido

Elemento Definición
Fuente Socio de distribución
Estímulo Lanza una campaña que multiplica el tráfico por 100x
Artefacto Capacidad de cotización y su infraestructura elástica
Ambiente Producción durante un pico comercial inducido
Respuesta Sostiene el caudal completo de cotizaciones
Medida Escalar de 500 a 50.000 cotizaciones/min conservando el p95 (autoescalado ≤ 60 s).
Prioridad (A,A) — ASR

EC-ESC-02 — Reacción del autoescalado

Elemento Definición
Fuente Controlador de autoescalado
Estímulo El caudal supera el umbral de escalado
Artefacto Controlador de autoescalado de la capacidad de cotización
Ambiente Producción durante la rampa inicial de la campaña
Respuesta Incorpora la capacidad adicional al balanceo
Medida Capacidad ampliada disponible en ≤ 60 s desde el disparo, conservando el p95 de las transacciones.
Prioridad (A,A) — ASR

Evento paramétrico masivo

EC-ESC-03 — Absorción del pico

Elemento Definición
Fuente Proveedor externo de telemetría
Estímulo Genera una ráfaga de eventos paramétricos
Artefacto Canal de eventos y su almacenamiento de rezago
Ambiente Producción durante un evento externo masivo
Respuesta Recibe y persiste el flujo aplicando contrapresión
Medida Absorber ≥ 1.000.000 de eventos en 10 min con contrapresión y sin pérdida.
Prioridad (A,A) — ASR

Crecimiento del ecosistema de socios

EC-ESC-04 — Aislamiento de carga entre socios

Elemento Definición
Fuente Un socio de distribución que excede su cuota
Estímulo Genera un volumen de solicitudes por encima de lo contratado
Artefacto Capa de exposición de APIs y control de cuotas
Ambiente Producción con 50 socios operando de forma concurrente
Respuesta Contiene el exceso dentro de la cuota del socio que lo genera
Medida El 100 % de los socios no infractores conserva su p95
Prioridad (A,A) — ASR

6.3 Seguridad

Consentimiento Open Finance

EC-SEG-03 — Revocación del consentimiento Open Finance

Elemento Definición
Fuente Cliente
Estímulo Revoca el consentimiento otorgado para el uso de sus datos financieros
Artefacto Gestión de consentimiento y autorización de acceso a datos
Ambiente Producción en operación normal, con consentimientos y accesos activos
Respuesta Registra la revocación y restringe el acceso a las capacidades que usaban esos datos
Medida Revocación efectiva en ≤ 5 minutos
Prioridad (A,A) — ASR

Explicabilidad y auditoría de decisiones

EC-SEG-04 — Auditoría interna

Elemento Definición
Fuente Actuaría
Estímulo Exige justificar el precio de una póliza emitida
Artefacto Motor de rating y suscripción, y registro de decisiones
Ambiente Auditoría posterior con reglas y fuentes ya cambiadas
Respuesta Reconstruye la decisión con las reglas y señales vigentes al momento
Medida 100 % de las decisiones de suscripción reconstruibles
Prioridad (A,A) — ASR

Ataque o fraude en línea

EC-SEG-07 — Abuso de la API

Elemento Definición
Fuente Actor malicioso externo
Estímulo Genera un patrón anómalo de solicitudes
Artefacto Capa de exposición de APIs y detección de anomalías de tráfico
Ambiente Producción bajo ataque, con tráfico legítimo concurrente
Respuesta Bloquea el origen infractor y mantiene el servicio para el tráfico legítimo
Medida Bloqueo en ≤ 1 segundo desde el inicio del patrón
Prioridad (A,A) — ASR

EC-SEG-08 — Siniestro simulado

Elemento Definición
Fuente Actor malicioso con una cuenta comprometida
Estímulo Reporta un siniestro simulado
Artefacto Capacidad de siniestros y motor de detección de fraude
Ambiente Producción bajo intento de fraude
Respuesta Retiene el caso para revisión manual y conserva el registro del intento
Medida El 100 % de los casos marcados por el motor de fraude queda retenido con traza completa
Prioridad (A,A) — ASR

6.5 Facilidad de modificación

Nuevo ramo de seguro

EC-MOD-01 — Alcance del cambio

Elemento Definición
Fuente Equipo de desarrollo
Estímulo Implementa un nuevo ramo sobre la plataforma en producción
Artefacto Módulos de producto, rating y suscripción
Ambiente Evolución planificada, en tiempo de desarrollo
Respuesta Confina la implementación a los puntos de extensión previstos
Medida El 100 % de los archivos modificados pertenece a los módulos de producto y rating
Prioridad (A,A) — ASR

Cambio en reglas de rating/suscripción

EC-MOD-03 — Regla de precio

Elemento Definición
Fuente Actuaría
Estímulo Ajusta la fórmula de precio de un producto
Artefacto Motor de rating
Ambiente Operación normal, con pólizas vigentes emitidas bajo las reglas anteriores
Respuesta Aplica la fórmula nueva de forma contenida en el motor de rating
Medida El 100 % del cambio se despliega sin redesplegar componentes ajenos al motor de rating
Prioridad (A,A) — ASR

EC-MOD-04 — Regla de aceptación de riesgo

Elemento Definición
Fuente Actuaría
Estímulo Ajusta la política de aceptación de riesgo
Artefacto Motor de decisión de suscripción
Ambiente Operación normal, con pólizas vigentes emitidas bajo las reglas anteriores
Respuesta Aplica la política nueva de forma contenida en el motor de suscripción
Medida El 100 % del cambio se despliega sin redesplegar componentes ajenos al motor de suscripción
Prioridad (A,A) — ASR

Reemplazo de un proveedor

EC-MOD-05 — Sustitución de un proveedor externo

Elemento Definición
Fuente Equipo de arquitectura e integraciones
Estímulo Sustituye un proveedor externo por otro
Artefacto Módulo de integración con proveedores externos
Ambiente Tiempo de desarrollo, con el sistema en producción
Respuesta Reimplementa el adaptador conservando la interfaz publicada
Medida El 100 % del cambio queda contenido en el módulo de integración
Prioridad (A,A) — ASR

6.6 Facilidad de integración

Alta de un nuevo socio embebido

EC-INT-01 — Alta por configuración

Elemento Definición
Fuente Equipo de plataforma
Estímulo Ejecuta el alta de un socio nuevo
Artefacto Contratos públicos de API y catálogo de configuración de socios
Ambiente Expansión comercial, con socios existentes ya operando
Respuesta Habilita al socio a partir de configuración declarativa
Medida El 100 % del alta se resuelve por configuración, sin modificar código
Prioridad (A,A) — ASR

Nueva fuente de Open Data/Open Finance

EC-INT-03 — Incorporación de una nueva fuente de datos

Elemento Definición
Fuente Nuevo proveedor de datos externo
Estímulo Se incorpora al perfilamiento
Artefacto Capa de adaptadores y modelo canónico interno
Ambiente Expansión del ecosistema de datos, con consumidores del perfil ya en producción
Respuesta Traduce la fuente al modelo canónico detrás de un adaptador
Medida El 100 % de los consumidores existentes continúa operando sin modificación
Prioridad (A,A) — ASR

Cliente web y móvil sobre la misma API

EC-INT-04 — Evolución compatible de contratos multicanal

Elemento Definición
Fuente Equipo de plataforma
Estímulo Publica una evolución compatible de las APIs de la plataforma
Artefacto Contratos de API consumidos por web, móvil y socios
Ambiente Producción con versiones distintas de clientes desplegadas simultáneamente
Respuesta Publica la nueva versión manteniendo operativa la anterior
Medida El 100 % de los clientes no modificados continúa operando sin requerir redespliegue
Prioridad (A,A) — ASR
⚠️ **GitHub.com Fallback** ⚠️