Digitalizar de extremo a extremo: ciclos de vida, ley de Conway y el caso móvil
Digitalizar "de extremo a extremo" significa que el dato fluye sin cortes desde donde se produce hasta donde se decide con él. Conseguirlo es un problema de organización y método tanto como de tecnología: hay que elegir cómo se construye, y el resultado reproducirá la estructura de quien lo construya. Y cuando un extremo es un dispositivo que no siempre está conectado, la arquitectura clásica cliente/servidor deja de encajar.
1Ventajas y riesgos de digitalizar de extremo a extremo
| Ventaja | Qué significa |
|---|---|
| Dato único (single source of truth) | El peso de la báscula es el mismo número en producción, almacén y factura |
| Sin reintroducción | Nadie teclea en el ERP lo que ya está en el SCADA |
| Trazabilidad | De una lata se sabe de qué captura salió y a quién se vendió |
| Visibilidad en tiempo real | Dirección ve qué produce cada línea ahora, no en el informe del mes |
| Automatización de flujos | Un pedido web genera la orden de fabricación sin intervención |
| Base para analítica e IA | Predecir demanda, detectar fallos, optimizar rutas |
2Ciclos de vida: cascada, iterativo, ágil
Cascada (waterfall): requisitos → diseño → implementación → pruebas → despliegue → mantenimiento, cada fase termina antes de empezar la siguiente. Winston Royce la describió en 1970 como arriesgada y proponía iterar; la industria adoptó el diagrama y olvidó la advertencia. Variante: el modelo en V (cada fase de construcción tiene enfrente su fase de prueba), habitual en automoción, aeronáutica, dispositivos médicos.
Iterativo e incremental: construir una versión pequeña que funcione, aprender, ampliar. El modelo en espiral (Boehm, 1986) añade análisis de riesgos en cada vuelta.
Ágil (Manifiesto Ágil, 2001): métodos iterativos con entregas frecuentes. Scrum (sprints de 1-4 semanas) y Kanban (flujo continuo con límite de trabajo en curso). DevOps y entrega continua llevan la iteración hasta el despliegue.
| Favorece cascada / V | Favorece iterativo / ágil |
|---|---|
| Requisitos conocidos, estables, verificables | Requisitos inciertos o que se descubren usando el producto |
| Coste del error alto e irreversible (marcapasos, avión, planta química) | Coste del error bajo y reversible (una web, una app interna) |
| Regulación que exige documentación previa (sanidad, aeronáutica) | Sin regulación de proceso |
| Contrato a precio cerrado | Equipo interno o contrato por tiempo y materiales |
| Componentes físicos con plazos largos | Todo es software |
Ágil e IA en 2026. Los agentes de código (UD1-09) aceleran la iteración hasta que el cuello de botella pasa a ser saber qué se quiere. De ahí el spec-driven development: escribir primero una especificación que el agente implementa — un artefacto de aspecto "cascada" dentro de un bucle rapidísimo, porque el coste de construir ha bajado tanto que vuelve a compensar pensar antes.
3La ley de Conway
- Departamentos que no se hablan producen sistemas que no se integran; la ventaja "dato único" se consigue cuando comercial y almacén acuerdan qué es un "pedido", no con un conector.
- Un equipo de "front" y otro de "back" produce una API con fricción en el medio; un equipo por funcionalidad produce funcionalidades completas. Los microservicios son la ley de Conway aplicada deliberadamente (los "equipos de dos pizzas" de Amazon).
- Maniobra inversa de Conway: si se quiere una arquitectura concreta, organizar los equipos para que la produzcan. Team Topologies (2019) da el vocabulario: equipos alineados a un flujo de valor, de plataforma, habilitadores y de subsistema complicado.
Para el proyecto, el organigrama de la sección 1 del informe se convierte en un dato de arquitectura.
4El caso móvil: cuando un extremo no está siempre conectado
Una app móvil parece el cliente perfecto de cliente/servidor. En la práctica encaja mal, por seis motivos:
- Conectividad intermitente: tiene que funcionar con datos locales (SQLite/Room, Core Data/SwiftData, Realm, Drift).
- Sincronización y conflictos: "gana la última escritura" (simple, pierde datos), event log, o CRDT (Figma, Apple Notes, Automerge/Yjs) — no hay solución universal.
- El servidor inicia conversaciones: las notificaciones push pasan por un tercero (FCM, APNs).
- No se despliega cuando se quiere: la API tiene que ser compatible hacia atrás y versionada; conviven versiones distintas.
- Recursos del dispositivo: batería, datos móviles, almacenamiento.
- Cómputo local cada vez más capaz: modelos de IA en el dispositivo por privacidad y latencia (ver UD2-04).
Consecuencia para el proyecto: si la empresa elegida tiene un extremo móvil, la sección 5 del informe tiene que decir qué datos viven en el dispositivo, cómo se sincronizan y qué pasa en conflicto. "Se conecta a la API" no es una arquitectura.
5Para debatir en clase
- Un hospital quiere digitalizar la historia clínica de punta a punta. ¿Cascada o ágil? ¿Para qué parte cada uno? ¿Qué pasa con la ley de Conway entre servicios médicos que no se hablan?
- Una app de reparto: el repartidor marca "entregado" sin cobertura y, antes de sincronizar, el cliente cancela el pedido desde la web. ¿Qué gana? ¿Quién decide?
- Un agente de IA puede generar en una tarde lo que antes llevaba un sprint. ¿Sigue teniendo sentido un sprint de dos semanas?
- Busca un fracaso reciente de implantación de software y clasifica su causa: ¿ciclo de vida, organización, tecnología?
✓Autoevaluación — puntos que debes dominar
Adaptado de 05-ciclos-de-vida-conway-y-el-caso-movil.md.