G07 - Cómo validar el encaje arquitectónico
Cómo validar el encaje arquitectónico
Contexto
Es parte de la etapa 7. El Product Manager no diseña la arquitectura técnica: verifica que la solución encaje en lo que ya existe y que se pueda operar y mantener. Cubre la dimensión de viabilidad de las tres dimensiones del diseño. Sin esta revisión no se pasa la compuerta C4.
Qué decide y qué no
| El Product Manager | Desarrollo |
|---|---|
| Qué capacidad necesita el proceso y por qué | Cómo se implementa |
| Si se reusa, se configura o se construye, con evidencia | Patrón técnico, lenguaje, componentes |
| Qué datos se necesitan y quién es su dueño | Modelo de datos, integración detallada |
| Qué riesgo de negocio se acepta | Controles técnicos de seguridad |
| Si el costo de operar se justifica con la hipótesis | Estimación técnica del costo |
Las seis revisiones
| Revisión | Qué verifica | Pregunta clave |
|---|---|---|
| 1. Sistemas existentes | Qué sistemas tocan hoy el proceso y cuál es el sistema de registro de cada dato | ¿La solución vive dentro de un sistema actual o crea uno nuevo? |
| 2. Integraciones | Qué información entra y sale, entre qué sistemas, con qué frecuencia | ¿Existe una interfaz oficial o dependemos de archivos y correos? |
| 3. Datos | Origen, calidad, dueño y vocabulario común | ¿El dato existe, es confiable y alguien responde por él? |
| 4. Seguridad y privacidad | Datos personales, accesos, cumplimiento legal y contractual | ¿Quién ve qué, y lo permite la ley y el contrato? |
| 5. Costo de operación y mantenimiento | Licencias, consumo, soporte, cambios futuros | ¿Cuánto cuesta al año y quién lo mantiene? |
| 6. Reuso vs. construir | Qué capacidad ya existe en la empresa | ¿Por qué no alcanza lo que ya tenemos? |
Datos: lo que más falla
| Atributo | Qué preguntar |
|---|---|
| Origen | ¿Qué sistema o persona lo genera primero? |
| Calidad | ¿Está completo, actualizado y sin duplicados? Pide una muestra real |
| Dueño | ¿Qué área responde por su exactitud? |
| Definición | ¿Todas las áreas entienden lo mismo con ese término? |
| Medición | ¿Permite calcular el indicador de la hipótesis? |
Pide la muestra, no la descripción
"El sistema tiene la fecha de alta" se confirma con 50 registros reales. Ahí aparecen los vacíos y los formatos distintos.
Reuso antes que construcción
Orden de preferencia, del más simple al más costoso:
- Cambiar el proceso sin tecnología nueva.
- Usar una función que ya existe y no se aprovecha.
- Configurar un sistema actual.
- Integrar sistemas existentes.
- Construir algo nuevo.
Cada salto al siguiente nivel necesita una razón escrita. Ver criterio de automatización.
Preguntas para desarrollo
- ¿Qué sistema es la fuente oficial de cada dato que usa la solución?
- ¿Hay una interfaz disponible o hay que construirla?
- ¿Qué pasa si la integración falla? ¿Cómo se detecta y quién se entera?
- ¿Qué datos personales o sensibles se procesan y dónde se guardan?
- ¿Qué permisos se requieren y quién los otorga?
- ¿Cuánto cuesta operar esto al mes con el volumen real del proceso?
- ¿Quién lo mantiene cuando cambie una regla de negocio?
- ¿Qué deuda técnica o riesgo se crea?
- ¿Qué parte se puede probar en un piloto acotado?
Señales de alerta
Un sistema nuevo para un problema de proceso
Si el desperdicio es una aprobación de más, la solución es quitarla, no construir un flujo digital para aprobarla más rápido.
El Excel como integración
Si la solución depende de que alguien descargue y suba un archivo, el desperdicio de transporte sigue ahí.
Dato sin dueño
Si nadie responde por la calidad de un dato, la solución hereda sus errores. Nombra al dueño antes de construir.
Costo de operar desconocido
Una solución barata de construir puede ser cara de operar. Sin cifra anual, la hipótesis no está completa.
Proceso general
Ventas: el área pide una aplicación para registrar oportunidades. La revisión muestra que el sistema comercial ya tiene ese módulo sin usar. La solución es configurarlo y capacitar, no construir. Planta: para medir paros se propone captura manual en tableta. El equipo ya registra paros en su controlador; se integra ese dato.
Ejemplo ilustrativo: seguros
Promotora de seguros: se pide una aplicación para que los agentes de seguros consulten el estatus de sus solicitudes. La revisión muestra que el sistema de emisión ya guarda ese estatus y que el portal de agentes de seguros existente puede mostrarlo. La solución es exponer el dato ahí, no construir otra aplicación.
Ejemplo ilustrativo: manufactura
Planta de manufactura: se pide una aplicación para que los supervisores vean en qué estación está parada la línea y por qué. La revisión muestra que el sistema de andon ya registra cada paro con su estación y su causa, y que el tablero de producción que cuelga sobre la línea puede mostrarlo. La solución es exponer el dato ahí, no construir otra aplicación.
Ejemplo ilustrativo: retail
Comercio electrónico: se pide una aplicación para que atención a clientes consulte el estatus de los pedidos en línea. La revisión muestra que el sistema del centro de distribución ya guarda ese estatus y que la consola de atención existente puede mostrarlo. La solución es exponer el dato ahí, no construir otra aplicación.
Criterio de cierre
- Sistemas que toca la solución identificados, con su fuente oficial de datos.
- Integraciones listadas con su mecanismo y qué pasa si fallan.
- Datos críticos con origen, dueño y muestra de calidad revisada.
- Datos personales y accesos revisados con el responsable de seguridad.
- Costo anual de operación y mantenimiento estimado y comparado con el valor de la hipótesis.
- Decisión de reuso vs. construir justificada por escrito.
- Desarrollo confirma viabilidad (compuerta C4).
- Resultado registrado en el Diseño de solución.
Fuentes
- The Open Group, TOGAF 9.2: Architecture Principles (maximizar el beneficio para la empresa, aplicaciones de uso común, dato como activo, dueño del dato, vocabulario común, seguridad de datos, control de la diversidad técnica, interoperabilidad).
Relacionado
- Diseño de solución
- Especificación de unidad agéntica
- G09 - Cómo supervisar agentes
- Módulo 7 - Diseño de solución y arquitectura
- G01 - Metodología de transformación de procesos
- Definición del rol
Ruta de lectura (7 de 9): ← G06 - Cómo diseñar e innovar la solución · índice · G08 - El Product Manager como Product Owner →