Día 256: reír para decidir mejor tu arquitectura (y tu próximo sprint)

Abramos con una tensión real: cada vez que el negocio pide “salir rápido”, TI enfrenta el dilema entre entregar hoy o sostener mañana. Hay presión por nuevas funcionalidades, integrations con terceros, ideas de IA, auditorías de seguridad, y sistemas legados que “siguen funcionando… hasta que no”. En esa fricción nacen frases que todos hemos dicho u oído. Nos hacen reír, pero también son señales. Si las escuchas seguido, probablemente estás tomando decisiones de arquitectura, desarrollo o modernización bajo supuestos frágiles.

Este 13 de septiembre, Día 256, lanzamos un pequeño homenaje: Office Survivor, un juego simple para reírnos de nuestro día a día y de esas frases eternas. Está en https://zopitech.cl/256/. La invitación es lúdica, pero el objetivo es serio: transformar chistes internos en criterios claros para priorizar, diseñar y operar mejor.

A continuación, una guía práctica: qué esconden esas frases, cómo decidir entre construir, comprar o integrar, cuándo modernizar y cuándo no, y acciones concretas para las próximas semanas.

Lo que las frases esconden (y cómo convertirlas en decisiones)

• “Es un cambiecito de dos horas”

- Señal: subestimación de impacto y falta de diseño. Probable deuda técnica no visible. - Riesgo: acoplamientos ocultos, pruebas insuficientes, retrabajo. - Qué hacer: exigir un “mini RFC” de una página con alcance, dependencias y rollback. Si no cabe en una página, no son dos horas.

• “En mi local funciona”

- Señal: entornos inconsistentes y configuraciones manuales. - Riesgo: bugs intermitentes en QA/producción, ciclos lentos. - Qué hacer: estandarizar entornos con contenedores y IaC; pruebas de contrato y datos seed reproducibles. Pipeline mínimo: build → test → deploy a un ambiente staging aislado.

• “Mándalo a producción y vemos”

- Señal: urgencia operativa sin controles. - Riesgo: incidentes, brechas, pérdida de confianza interna. - Qué hacer: feature flags y despliegue canario. Definir SLOs y un plan de reversa con tiempos claros. Si no hay rollback probado, no se libera.

• “Hagamos microservicios”

- Señal: solución antes del problema. - Riesgo: sobrecosto operativo, duplicación de datos, orquestación compleja. - Qué hacer: partir con un monolito modular con límites de dominio claros. Microservicios solo cuando el ritmo de cambio y los límites de autonomía lo justifiquen (equipos distintos, escalamiento selectivo, ciclos de despliegue independientes).

• “Pónganle IA”

- Señal: expectativa de salto rápido de valor por moda. - Riesgo: desalineación con métricas de negocio, costos ocultos, compliance. - Qué hacer: definir el caso de uso y su KPI (tiempo de atención, precisión, conversión). Probar en circuito cerrado, con datos acotados y gobernanza. Si no hay dato de calidad o métrica, no es el momento.

• “No hay tiempo para pruebas”

- Señal: cronogramas que ignoran calidad operativa. - Riesgo: deuda que se paga con intereses en producción. - Qué hacer: priorizar pruebas de contrato e integración en flujos críticos, y automatizar smoke tests post-deploy. Mejor 3 pruebas que muevan la aguja que 100 que nadie mantiene.

• “Eso es cosa de TI”

- Señal: silo entre negocio y tecnología. - Riesgo: requisitos ambiguos, soluciones técnicamente buenas pero poco útiles. - Qué hacer: Product Owners con métricas de negocio, roadmaps compartidos y priorización conjunta. Cada épica debe mapearse a una métrica de resultado (ingreso, costo, riesgo, satisfacción).

• “Después refactorizamos”

- Señal: posponer arquitectura necesaria. - Riesgo: crecimiento del monolito espagueti. - Qué hacer: regla del boy scout: cada cambio deja el código un poco mejor. Programar refactors con límite de tiempo (p.ej., 15% de la capacidad de sprint) y objetivos concretos (reducir acoplamientos, extraer módulo).

Usar estas frases como “alarmas” ayuda a decidir con intención. No se trata de prohibirlas, sino de gatillar la pregunta correcta en el momento correcto.

Marcos rápidos de decisión: construir, integrar o modernizar

1) Construir vs comprar vs integrar vs envolver (wrap)

• Construir aplica cuando:

- El proceso es diferenciador del negocio. - Hay incertidumbre que exige iterar producto-tecnología. - Se requiere control fino de experiencia o performance.

• Comprar/Integrar aplica cuando:

- El proceso es commodity (facturación estándar, RRHH, CRM generalista). - El time-to-value manda y el TCO de mantener código propio no cuadra. - Hay ecosistema maduro de APIs y conectores.

• Envolver (wrap) aplica cuando:

- Hay legado estable que no conviene reescribir completo. - Necesitas exponer capacidades vía APIs, eventos o ETL sin tocar el core.

Criterios duros para decidir (ordenados):

• Diferenciación del proceso (alta → construir; baja → comprar/integrar).
• Time-to-value (corto → comprar/integrar; largo y estratégico → construir gradual).
• TCO a 3 años (licencias, nube, soporte, equipo, compliance).
• Riesgo regulatorio/seguridad (datos sensibles pueden inclinar a construir o a un SaaS con certificaciones y controles demostrables).

2) Modernizar sin parar el negocio

• Enfoque “Strangler Fig”: envolver el sistema legado con una capa anticorrupción, extraer capacidades una a una hacia servicios nuevos, redirigir tráfico de forma progresiva.
• Cuándo NO aplica: latencias extremas en tiempo real sin presupuesto para doble escritura o sincronización; ventanas de mantenimiento reguladas que impiden migraciones graduales.
• Señales de que sí aplica: módulos con límites claros, reportes que ya fluyen por ETL, capa de APIs factible, urgencia por exponer datos a nuevas apps.

3) Arquitectura para equipos pequeños (que quieren moverse rápido)

• Monolito limpio + dominios (bounded contexts) + módulos independientes + interfaces claras.
• Catálogo de eventos internos (aunque no salgas a microservicios aún). Diseñar con publicación-suscripción en mente reduce el costo de un futuro desacople.
• Cuando pasar a microservicios: equipos dedicados por dominio, cuellos de botella de despliegue, necesidades de escalado selectivo, límites de responsabilidad claros.
• Trade-off: microservicios suben el costo operativo (observabilidad, redes, orquestación, seguridad). No se justifican si la complejidad de negocio es baja o el equipo es pequeño.

4) Calidad operativa pragmática (SRE-lite)

• Definir SLOs de 2–3 métricas críticas (latencia p95, tasa de errores, disponibilidad) y un budget de error por trimestre.
• Monitoreo y alertas accionables (sin tormenta de notificaciones). Alertas solo si requieren intervención humana.
• Postmortems sin culpa: causas, acciones, dueño y fecha. Aprendizaje institucional sobre heroísmo individual.

Checklist de señales de alerta (si marcas 3 o más, es hora de cambiar)

• Más del 30% de los sprints se van en “parches urgentes”.
• No existe staging representativo ni datos de prueba repetibles.
• Releases sin rollback probado.
• Decisiones de arquitectura impulsadas por herramientas, no por dominios.
• Nadie puede explicar en una página el flujo end-to-end de un proceso core.
• Métricas de negocio desconectadas del roadmap técnico.

Si te reconoces aquí, modernizar con foco de negocio es más seguro que seguir acumulando deuda.

Tácticas concretas para la próxima quincena (0–30 días)

• Mapear frases a riesgos: toma 10 tickets recientes y anota qué “frase-alarmas” aparecieron. Asigna un riesgo por ticket (entorno, pruebas, dependencia, seguridad). Tendrás tu backlog de mejoras técnicas priorizado.
• Pipeline básico CI/CD: un repositorio, build reproductible, pruebas mínimas, despliegue automatizado a staging, y promoción manual a producción con checklist.
• Feature flags + canario: activa en un servicio visible (pero no crítico). Define umbrales y rollback automático.
• Contratos de integración: publica un contrato (OpenAPI/AsyncAPI) y valida en CI. Disminuye roturas silenciosas.
• Observabilidad mínima: logs estructurados, trazas en la ruta crítica y 3 métricas doradas (latencia, tráfico, errores). Tableros compartidos TI/negocio.
• Seguridad esencial: secretos fuera del código, MFA para accesos sensibles, inventario de dependencias y parches.
• Métricas de negocio enlazadas a la plataforma: define 3 indicadores que tu equipo pueda mover con cambios técnicos (p. ej., tiempo de onboarding, tasa de abandono, pedidos por minuto). Úsalas para priorizar.

Estas acciones no requieren reorganizar la empresa. Requieren foco y un par de semanas disciplinadas.

Cómo acompañamos sin vender humo

Nuestro enfoque es ejecutivo y técnico a la vez. Diseñamos, integramos y modernizamos software e infraestructura con una regla: cada recomendación debe ser accionable y medible. Algunas capacidades que solemos combinar:

• Arquitectura orientada a negocio: dominios, KPIs y un mapa de decisiones claro.
• Desarrollo web/móvil y APIs: desde monolitos modulares hasta servicios desacoplados.
• Integraciones, IoT/telemetría y data para operación.
• IA aplicada cuando hay datos, objetivo y control de riesgo.
• Ciberseguridad pragmática: identidad, hardening, secretos, continuidad.
• DevOps/Linux/cloud: automatización e infraestructura como código.
• Operación y mantenimiento: monitoreo, incidentes y mejora continua.
• Staff augmentation para acelerar con equipos mixtos.

Puedes revisar más en /servicios y explorar historias en /casos-de-exito. Si trabajas con equipos regionales o en inglés, también tenemos referencias en /en/services y /en/case-studies.

Día 256: juega, ríete y prioriza (Office Survivor)

En https://zopitech.cl/256/ armamos un Office Survivor con esas frases que amamos odiar. Es un respiro, pero también una forma de poner sobre la mesa temas que evadimos cuando hay fuego.

• Úsalo en tu próxima daily o retrospectiva: que cada casilla de risa dispare una mejora concreta.
• Compártenos tu frase estrella: en serio, es “material de mejora continua”. Nos recuerda que la tecnología es un deporte de equipo y que, con buen diseño y foco, casi cualquier reto se puede abordar sin vender promesas mágicas.

Agradecemos las risas que generamos juntos a diario. Son la punta visible de problemas interesantes que vale la pena resolver bien.

Cierre: del meme al roadmap (y una conversación franca)

Si en los últimos dos meses escuchaste varias de estas frases y te dolieron por verdaderas, probablemente ya tienes el caso para:

• Evaluar construir, integrar o envolver con criterios de negocio, no de herramienta.
• Modernizar por estrangulamiento en lugar de reescribir todo.
• Subir el estándar operativo sin frenar producto.

Partamos con un diagnóstico breve y accionable, enfocado en 90 días y en tus prioridades. Conversemos sin compromiso: /contacto. También podemos ajustar el alcance para un piloto pequeño y medible.

Mientras tanto, pásalo bien con Office Survivor en https://zopitech.cl/256/. Celebremos el Día 256 con humor… y con decisiones que hagan sobrevivir (y crecer) a tu operación.