2. Preguntas, supuestos y riesgos
Conclusión. El AS-IS (la situación actual) no venía dado, así que se formuló como hipótesis y cada duda quedó como un par: la pregunta que se haría a los stakeholders (personas o áreas con autoridad sobre una decisión) y el supuesto con el que se avanzó. Cada pregunta dice qué decisión de arquitectura cambia si la respuesta es otra. Hay 15 preguntas, 27 supuestos y 9 riesgos. Las ocho que más mueven la arquitectura son P1, P2, P3, P5, P6, P7, P9 y P11.
2.1 Preguntas y supuesto adoptado
TI significa tecnología de la información, el área de sistemas de AndesRetail.
| # | Pregunta | A quién | Supuesto adoptado | Decisión que cambia |
|---|---|---|---|---|
| P1 | ¿El OMS orquesta hoy pago y despacho, o solo registra y enruta órdenes? | TI | S1: solo registra y enruta | Dueño de la saga: la capa o el OMS |
| P2 | ¿Quién es dueño del stock vendible (físico menos reservado)? | Negocio, bodega | S2: nadie hoy; la capa crea el servicio de disponibilidad y reservas | Modelo de reserva y fuente de verdad |
| P3 | ¿ERP y WMS emiten eventos o permiten leer sus cambios? | TI | S3: no emiten eventos; lectura de cambios viable en la base del ERP, sondeo incremental en el WMS | Cómo se alimenta el modelo de lectura y qué frescura se promete |
| P4 | ¿Qué volúmenes hay en día normal y en promo; cuántos SKU, tiendas y partners? | Negocio, TI | S4: 200 consultas por segundo en base, 2.000 en pico, 50.000 SKU (stock keeping unit, el código de cada producto vendible), 40 ubicaciones, 10 partners, 20.000 órdenes al día | Dimensionamiento de cache, mensajería y cuotas |
| P5 | ¿Cómo es el enlace entre on-prem y AWS (Amazon Web Services)? | Infraestructura | S5: VPN sitio a sitio, sin enlace dedicado | La ruta de las APIs no puede depender del enlace |
| P6 | ¿Qué desactualización de stock y precio es aceptable para el negocio? | Negocio | S6: stock, segundos; precio, hasta un minuto. La verdad se verifica al reservar | Frescura objetivo, umbral de stale, ventana de tolerancia de precio |
| P7 | ¿La pasarela ofrece checkout alojado, tokenización y webhooks firmados? | Seguridad | S7: sí; la capa nunca ve datos de tarjeta | Alcance de PCI DSS (Payment Card Industry Data Security Standard, el estándar de seguridad de la industria de tarjetas; sección 5.5) y diseño de payment-service |
| P8 | ¿Dónde viven OMS y CRM y qué APIs exponen? | TI | S8: SaaS o nube, con API REST | Diseño de los adaptadores |
| P9 | ¿Los marketplaces aceptan confirmación asíncrona de la orden? | Negocio, partners | S9: sí, respuesta 202 con estado consultable y webhooks | Frontera entre sync y async en crear orden |
| P10 | ¿Hay restricciones sobre dónde pueden residir los datos personales? | Legal, seguridad | S10: sin restricción de región; aplica la Ley 1581 de 2012 de Colombia | Región de AWS, cifrado, retención de datos personales |
| P11 | En las órdenes de marketplace, ¿quién cobra: el marketplace o AndesRetail? | Finanzas, negocio | S11: depende del canal; el diseño soporta ambos con payment.mode (CAPTURE o PREPAID) |
Si la saga llama o no a la pasarela |
| P12 | ¿Qué ventanas de mantenimiento y qué disponibilidad tienen ERP y WMS? | TI | S12: ventanas nocturnas semanales | Tiempo máximo que la capa sirve dato desactualizado y tamaño de los colchones |
| P13 | ¿Las tiendas físicas venden del mismo inventario que los canales digitales, y cada cuánto lo reportan al WMS? | Operación de tiendas | S13: sí comparten inventario; el WMS se entera en menos de un minuto | Colchón de seguridad por SKU y canal |
| P14 | ¿Cuál es el costo de una sobreventa frente al de una venta perdida? | Negocio | S14: la sobreventa cuesta más (reembolso, reclamo, sanción del marketplace) | Qué tan conservadores son colchones y vencimientos |
| P15 | Si el precio cambia mientras el cliente paga, ¿cuánto tiempo se respeta el precio que vio, y el ERP distingue una corrección de un cambio comercial? | Negocio, TI | S15: se respeta lo mismo que dura la reserva del canal (15 minutos por defecto); el ERP registra el motivo de cada cambio de lista de precios, y una corrección invalida de inmediato las versiones anteriores | Ventana de tolerancia de precio y campo correction de PriceChanged (ADR-015) |
2.2 Supuestos adicionales, sin pregunta asociada
| # | Supuesto |
|---|---|
| S16 | Los partners pueden adoptar OAuth2 Client Credentials en el plazo del MVP |
| S17 | Existe o se puede formar un equipo de plataforma de al menos una persona desde el MVP |
| S18 | Hay un entorno de pruebas de la pasarela de pagos |
| S19 | El sku es el mismo identificador en ERP, WMS y OMS; si no, el adaptador mantiene la tabla de equivalencias |
| S20 | La conciliación completa del WMS corre a las 03:00 hora de Colombia (08:00 UTC), fuera de la ventana de mantenimiento del WMS; el código de bodega del WMS es el locationId canónico, y si no, el adaptador mantiene la equivalencia |
| S21 | El ERP permite leer su catálogo y su lista de precios completos por páginas (una foto), además de sus cambios: la lectura de cambios solo trae lo posterior a su activación, y el modelo de lectura necesita el estado inicial. El erp-adapter la lee una vez, al arrancar sin cursor guardado |
| S22 | El ERP guarda cada precio como una fila con vigencia (validFrom, validTo), varias por SKU, canal y lista, como los registros de condición de un ERP: un precio programado es una fila nueva, no la modificación del vigente. Un alcance no tiene más de 10 filas no vencidas a la vez |
| S23 | El ERP no borra filas de precio ni les cambia el validFrom: una fila que deja de regir se cierra con validTo. Si el ERP borrara una fila, su ventana seguiría publicada hasta vencer; la salida sería identificar cada fila por su número de registro de condición |
| S24 | Las ubicaciones (tiendas y bodegas) son un conjunto acotado, del orden de cientos: por eso location puede ser etiqueta de una métrica y el SKU no (ADR-021) |
| S25 | Una suscripción de webhooks se pausa cuando una entrega agota sus 8 intentos y no hubo ninguna entrega exitosa en 24 horas; la reactiva el partner o ops-admin |
| S26 | Cada sistema comprado del AS-IS se dibuja en el C4 de contenedores con aplicación y base de datos, sin nombrar tecnología. El lote nocturno WMS a ERP es la integración 11 y el enlace entre la nube y el on-prem es el de la pregunta 5 (VPN sitio a sitio). Cómo llegan los marketplaces al WMS y al ERP no está definido: se dibujan directo |
| S27 | Los identificadores que un partner envía en la orden (externalOrderId, SKU, tienda, cliente) caben en 64 caracteres de letras ASCII, dígitos y ., _, : y -. Si uno trae espacios, barras u otros caracteres, el partner los traduce antes de llamar, como traduce sus estados (ADR-026) |
Los volúmenes de S4 son cifras para dimensionar, no datos del cliente. Todas las decisiones posteriores que dependen de ellos lo dicen.
2.3 Riesgos
| # | Riesgo | Probabilidad | Impacto | Mitigación | Señal temprana |
|---|---|---|---|---|---|
| R1 | La capa acumula lógica de negocio y se vuelve un ESB (Enterprise Service Bus: bus de integración centralizado que termina siendo cuello de botella) | Media | Alto | Gateway delgado por diseño, formato corto de rutas, reglas de dependencias en el pipeline, revisión de arquitectura de todo servicio nuevo | Peticiones de "una transformación pequeña" en el gateway |
| R2 | La capa se vuelve punto único de falla: si cae, caen todos los canales | Baja | Muy alto | Tres zonas, servicios sin estado, degradaciones preparadas, presupuesto de error con alertas | Consumo del presupuesto de error |
| R3 | Dato desactualizado provoca sobreventa | Media | Alto | Reserva atómica como verdad, colchones, frescura medida y con alerta, conciliación nocturna | Deriva de inventario, rechazos después de aceptar |
| R4 | El supuesto S1 es falso y hay doble orquestación con el OMS | Media | Alto | Validarlo en la primera semana; la saga está aislada en un servicio y se puede reducir a un pase directo al OMS | Estados que cambian en el OMS sin evento de la capa |
| R5 | El enlace on-prem o la lectura de cambios del ERP no rinden lo esperado | Media | Medio | Sondeo incremental como respaldo, tópico crudo para reproceso, umbral de stale |
Frescura creciente en horas pico |
| R6 | Adopción lenta de los partners | Alta | Medio | Entorno de pruebas, documentación generada de los contratos, convivencia con la integración vieja y fecha de retiro acordada | Partners sin tráfico en el entorno de pruebas |
| R7 | La operación de Kafka, la malla y el clúster supera la capacidad del equipo | Media | Medio | Servicios administrados, plantilla de servicio, runbooks, empezar con lo mínimo | Alertas ignoradas, despliegues que se frenan |
| R8 | Convivencia: canales no migrados venden sin reservar | Alta durante la migración | Medio | Colchón mayor temporal, migrar primero los canales de más órdenes | Deriva de inventario concentrada en ciertos SKU |
| R9 | Un precio mal cargado a la baja se sigue vendiendo durante la ventana de pago | Media | Medio | Ventana de tolerancia igual al vencimiento de la reserva, no mayor; el ERP marca las correcciones y una corrección invalida las versiones anteriores (ADR-015) | Órdenes aceptadas con una versión de precio ya reemplazada |
El riesgo R4 merece una línea más: si el OMS ya orquesta pago y despacho, la saga de la capa sobra en parte. El daño está acotado porque la saga vive en un solo servicio con contratos propios; reducirla a un pase directo al OMS no toca a los canales ni a los demás servicios.