Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 1.5 de 1.8 · Principiante · 18 min de lectura
Las partes interesadas, sus inquietudes y cómo las atiende la arquitectura
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
Todo sistema sirve a muchas personas, y no todas quieren lo mismo. Esta lección trata de encontrar a esas personas, entender qué les preocupa y gestionar abiertamente los conflictos.
Piensa en la construcción de una casa. La familia que vivirá en ella quiere espacio y luz. El banco que presta el dinero quiere que la casa valga lo que el préstamo. La oficina de urbanismo quiere que encaje en la calle. El constructor quiere planos que realmente se puedan construir, y los vecinos no quieren ruido por la noche. Todos ellos son partes interesadas, y lo que preocupa a cada uno es una inquietud. La arquitectura es el arte de escucharlos a todos y de decidir abiertamente dónde chocan sus deseos.
La norma internacional para la descripción de arquitecturas define una parte interesada de forma amplia: cualquier rol, persona, organización o clase de ellos, con un interés, derecho, participación o reclamación en el sistema. Así que una parte interesada suele ser una clase, como los pacientes o los ingenieros de guardia. Y basta con una reclamación: un regulador que nunca inicia sesión sigue siendo una parte interesada, porque puede impedirte operar. Algunas partes interesadas nunca están en la reunión: los desarrolladores que mantendrán el sistema dentro de cinco años, las personas con discapacidad que lo usarán y el público afectado por él. Parte del trabajo de un arquitecto es hablar por ellos.
Lo que le importa a una parte interesada es una inquietud: cualquier asunto de relevancia o importancia para ella. Puede ser una cualidad, un costo, un riesgo, una restricción, o si el equipo puede realmente construirlo. Las inquietudes todavía no son requisitos. El temor a otra caída como la del invierno pasado es una inquietud. Una disponibilidad del noventa y nueve punto nueve por ciento cada mes es un requisito derivado de ella. Recoge primero la inquietud con las propias palabras de la parte interesada, y luego precísala.
Con veinte o más grupos, no puedes dar a cada uno la misma atención. La matriz de poder e interés te ayuda a planificar. Esta es para un sistema de reservas de un hospital. El poder sube por el lateral, y el interés va por la parte de abajo. Mucho poder pero poco interés: mantenlos satisfechos. Aquí, el director financiero, la junta directiva del hospital y los reguladores. Mucho poder y mucho interés: gestiónalos de cerca. El patrocinador, el responsable clínico, el delegado de protección de datos y el product owner. Poco de ambos: vigílalos, como al proveedor de la pasarela de mensajes de texto y a otros equipos de TI del hospital. Poco poder y mucho interés: mantenlos informados. Y mira quién está aquí: los pacientes y sus cuidadores. Tienen poco poder formal, pero son los que más se juegan. Así que la matriz orienta la implicación, no qué inquietudes cuentan.
Las inquietudes son el vínculo entre las personas y la arquitectura. Las partes interesadas tienen inquietudes. Esas inquietudes se convierten en requisitos y escenarios, impulsan las decisiones arquitectónicas y determinan qué vistas del sistema dibujas. Después revisas con las partes interesadas: ¿se atienden sus inquietudes? Un diagrama que no responde a la inquietud de ninguna parte interesada es decoración.
En el ejemplo práctico, un hospital quiere que los pacientes reserven sus citas en línea. Los pacientes y sus cuidadores quieren reservar de forma fácil y accesible desde un teléfono, así que el frontend debe cumplir las normas de accesibilidad y no requerir ninguna app. El personal de recepción teme las reservas duplicadas, así que el sistema de administración de pacientes existente debe seguir siendo la única fuente de verdad de las franjas horarias. A operaciones le preocupan los picos de los lunes por la mañana y la capacidad limitada de ese sistema. Quieren una cola o un limitador de tasa delante de él, y guardar en caché qué franjas están libres. Ahí está el conflicto. La caché protege el sistema de administración de pacientes, pero el personal de recepción teme reservas duplicadas por datos desactualizados. La resolución propuesta: guardar en caché las franjas libres solo para mostrarlas, durante treinta segundos, pero confirmar cada reserva contra el sistema real. Fíjate en que este conflicto clave se dio entre dos grupos de perfil bajo.
Los conflictos como este son normales. Una arquitectura que contenta a todos suele significar que se ha ocultado un conflicto. Así que, primero, formula ambas inquietudes con precisión, para que la discusión trate de números y no de adjetivos. Muestra las opciones y sus consecuencias una al lado de otra. Después nombra a quién decide, porque algunos compromisos corresponden al patrocinador y no al arquitecto, y registra el resultado y sus razones. A menudo, preguntar a cada parte qué teme realmente revela un diseño que satisface a ambas.
Eso es todo sobre partes interesadas e inquietudes. La sección completa incluye una tabla de partes interesadas típicas y una forma paso a paso de analizarlas. A continuación, en la Sección uno punto seis, vemos cómo sopesar decisiones y compromisos. Nos vemos allí.
Lo que necesitas saber
- Una parte interesada es cualquier rol, persona, organización o clase de ellos con un interés, derecho, participación o reclamación en un sistema, incluidas las personas que nunca lo usan directamente, como los reguladores y los operadores.
- Una inquietud, en ISO/IEC/IEEE 42010, es cualquier asunto de relevancia o importancia para una parte interesada: cuentan las cualidades, los costos, los riesgos, las restricciones, la viabilidad y las cuestiones organizativas.
- Las inquietudes todavía no son requisitos: recógelas con las palabras de la parte interesada y luego conviértelas en escenarios de atributos de calidad medibles, restricciones o requisitos funcionales.
- La matriz poder/interés ayuda a planificar cómo implicar a cada parte interesada, pero no dice nada sobre qué inquietudes son las más importantes; los grupos con poco poder pueden ser los que más se juegan.
- Las inquietudes en conflicto son normales; el arquitecto las hace explícitas, cuantifica las opciones, nombra a quién decide y registra la justificación.
- Las inquietudes organizan la documentación de la arquitectura: cada punto de vista enmarca ciertas inquietudes, y cada vista muestra cómo las atiende el sistema.
Quiénes son las partes interesadas
Una parte interesada es cualquiera que tenga un interés legítimo en un sistema: las personas que lo usan, lo pagan, lo construyen, lo operan, lo regulan o se ven afectadas por él. ISO/IEC/IEEE 42010:2022, la norma internacional para la descripción de arquitecturas, define el término de forma amplia como un rol, cargo, individuo, organización o clase de ellos que tiene un interés, derecho, participación o reclamación en aquello que se describe. Dos rasgos de esa definición importan en la práctica. Primero, una parte interesada suele ser una clase y no una persona: "los pacientes" o "los ingenieros de guardia" en lugar de un individuo con nombre. Segundo, basta con una reclamación o un derecho: un regulador que nunca inicia sesión en tu sistema sigue siendo una parte interesada, porque puede impedirte operar.
La lista es más larga de lo que espera la mayoría de los equipos. Para un sistema comercial típico incluye:
Los usuarios (las personas que manejan el software en el día a día, a menudo varios grupos distintos); los clientes (quien paga, que puede no ser usuario en absoluto); el product owner o responsable de producto que decide qué se construye; el patrocinador que financia el trabajo y responde de su éxito; los desarrolladores, que deben entender y modificar el código; los testers, que deben poder preparar datos y observar el comportamiento; el personal de operaciones y los ingenieros de fiabilidad del sitio (SRE), que lo despliegan, lo monitorizan y lo recuperan a las tres de la mañana; el equipo de seguridad; el delegado de protección de datos cuando se tratan datos personales (conforme al RGPD (GDPR) del Reino Unido y de la UE, algunas organizaciones deben designar uno); el área jurídica y de compras, a la que le importan las licencias, los contratos y la responsabilidad; el área de finanzas, a la que le importan los costos de funcionamiento tanto como los de construcción; los reguladores y auditores; y los integradores externos, los otros equipos y empresas cuyo software llama al tuyo o es llamado por él.
Algunas partes interesadas faltan a todas las reuniones: los desarrolladores que mantendrán el sistema dentro de cinco años, el servicio de soporte que recibe las quejas, las personas con discapacidad que usarán la interfaz y los ciudadanos afectados por sus decisiones. Parte del trabajo de un arquitecto es hablar por quienes no están en la sala.
Inquietudes: lo que importa a las partes interesadas
En 42010, una inquietud es cualquier asunto de relevancia o importancia para una parte interesada. La palabra es deliberadamente amplia. Una inquietud puede ser una cualidad ("¿seguirá siendo rápida la página de reservas los lunes por la mañana?"), un costo ("¿cuánto costará operarlo al mes?"), un riesgo ("¿qué pasa si se cae el proveedor de SMS?"), una restricción ("¿deben quedarse en el Reino Unido los datos de los pacientes?"), una cuestión de viabilidad ("¿puede nuestro equipo construir esto con las habilidades que tiene?") o un asunto organizativo ("¿qué equipo es responsable de la integración con el sistema de los médicos de cabecera?").
Las inquietudes todavía no son requisitos. Suelen expresarse de forma vaga, con el vocabulario propio de la parte interesada, y a menudo son preocupaciones más que especificaciones. "No quiero otra caída como la del invierno pasado" es una inquietud; "el servicio de reservas está disponible el 99.9% de cada mes natural, medido en el balanceador de carga" es un requisito derivado de ella. Recoger primero la inquietud con las palabras de la parte interesada, y solo después precisarla, te obliga a ser honesto sobre de dónde viene un requisito y por qué importa.
Una misma inquietud suele ser compartida por varias partes interesadas, y una parte interesada suele tener muchas inquietudes. La seguridad es una inquietud del equipo de seguridad, del delegado de protección de datos, del patrocinador (que teme los titulares) y de los pacientes (que temen que se filtren sus historiales). Esa relación de muchos a muchos es exactamente la razón por la que 42010 trata las inquietudes como la bisagra entre las personas y la arquitectura: las decisiones responden a inquietudes, y las vistas se organizan en torno a las inquietudes que atienden.
Partes interesadas típicas y sus inquietudes
| Parte interesada | Inquietudes típicas | Lo que la arquitectura debe darles |
|---|---|---|
| Público | Velocidad, facilidad de uso, accesibilidad, que el sistema esté disponible cuando se necesita | Objetivos de tiempo de respuesta y de disponibilidad; una capa de interfaz capaz de cumplir las normas de accesibilidad |
| Clientes y patrocinadores | Valor de negocio, tiempo de comercialización, costo total, riesgo para la reputación | Un plan de entrega creíble, un modelo de costos y una lista de los principales riesgos |
| Product owner | Con qué rapidez se pueden añadir nuevas funcionalidades, cómo se mantienen abiertas las opciones | Estructura modular alineada con el dominio de negocio; pocas decisiones difíciles de revertir |
| Desarrolladores | Comprensibilidad, velocidad de compilación y de pruebas, propiedad clara | Límites de módulo limpios, una compilación local rápida, convenciones documentadas |
| Testers | Capacidad de prueba, datos de prueba controlables, comportamiento observable | Puntos de unión (seams) donde se pueden sustituir las dependencias; entornos de prueba parecidos a producción |
| Operaciones y SRE | Desplegabilidad, monitorización, recuperación, capacidad, carga de guardias | Comprobaciones de estado, logs, métricas y trazas; rollback seguro; runbooks |
| Equipo de seguridad | Superficie de ataque, identidad, secretos, respuesta a vulnerabilidades | Límites de confianza, diseño de la autenticación, estrategia de parches y de dependencias |
| Delegado de protección de datos | Base jurídica, minimización de datos, conservación, derechos de los interesados, transferencias | Un inventario de datos y una vista de flujo de datos; mecanismos de borrado y exportación |
| Área jurídica y de compras | Licencias, contratos, responsabilidad, dependencia del proveedor (lock-in) | Una lista de componentes y servicios de terceros con sus condiciones |
| Finanzas | Costo de construcción, costo de funcionamiento, previsibilidad de costos | Un modelo de costos por entorno y por unidad de uso |
| Reguladores y auditores | Cumplimiento de las normas del sector, evidencia de control | Registros de auditoría, trazabilidad desde el requisito hasta la prueba, decisiones documentadas |
| Integradores externos | Interfaces estables, versionado, documentación, entornos sandbox de prueba | Contratos de API publicados y una política de versionado |
Mapa de las partes interesadas: la matriz poder/interés
Con veinte o más grupos de partes interesadas no puedes dar a cada uno la misma atención. Una herramienta muy usada es la matriz poder/interés, que suele atribuirse a Aubrey Mendelow, cuyo artículo sobre las partes interesadas y el análisis del entorno data de 1981 (a menudo se cita como de 1991). Cada parte interesada se sitúa según el poder que tiene sobre el sistema (para financiarlo, aprobarlo, bloquearlo o cambiarle la forma) y el interés que muestra por él. Los cuadrantes sugieren una estrategia de implicación: gestionar de cerca (alto poder, alto interés), mantener satisfechos (alto poder, bajo interés), mantener informados (bajo poder, alto interés) y vigilar (bajo poder, bajo interés).
La matriz trata de la implicación, no de qué inquietudes cuentan. Los pacientes de un hospital tienen poco poder formal sobre el diseño de un sistema de reservas, pero son los que más se juegan, y algunas obligaciones legales (accesibilidad, protección de datos) existen precisamente para proteger a las personas con poco poder. Usa la matriz como recordatorio de con quién hablar y con qué frecuencia, y mantén un juicio aparte sobre qué inquietudes son críticas. Las posiciones también cambian: un regulador con poco interés se convierte en la parte interesada más interesada de todas la semana siguiente a una filtración de datos.
Una matriz poder/interés para un sistema de reservas de un hospital
Un análisis ligero de las partes interesadas
- IdentificarHaz una lluvia de ideas sobre las clases de partes interesadas con el patrocinador y el equipo, y luego contrasta la lista con un conjunto estándar (usuarios, quienes pagan, quienes construyen, quienes operan, quienes protegen, reguladores, integradores). Pregunta a cada grupo que encuentres: ¿con quién más deberíamos hablar?
- Recoger las inquietudesEntrevista a cada grupo importante u organiza un taller con él. Anota las inquietudes con sus propias palabras y luego apunta la cualidad, la restricción o el riesgo que hay detrás de cada una.
- Mapear y priorizarSitúa a las partes interesadas en la matriz poder/interés para planificar la implicación. Por separado, ordena las inquietudes según su impacto en el negocio y según cuánto restringen la arquitectura.
- Hacer explícitos los conflictosCuando dos inquietudes tiren en direcciones opuestas, pon el conflicto por escrito, nombra a las personas que deben ponerse de acuerdo y acuerda quién decide.
- Trazar y revisarVincula cada decisión significativa con las inquietudes que atiende, y repite el análisis en los hitos importantes, porque las partes interesadas y sus inquietudes cambian.
Las inquietudes en conflicto y cómo hacerlas explícitas
Las inquietudes entran en conflicto todo el tiempo, y una arquitectura que contenta a todos suele significar que un conflicto se ha ocultado en lugar de resolverse. El equipo de seguridad quiere que todo inicio de sesión esté protegido con autenticación multifactor; la representante de los pacientes señala que muchos pacientes mayores no tienen teléfono inteligente. Finanzas quiere un único servidor de base de datos pequeño; operaciones quiere una réplica en espera en un segundo centro de datos. El product owner quiere una nueva funcionalidad cada semana; los testers quieren tiempo para hacer pruebas de regresión de la integración con el sistema de administración de pacientes del hospital.
La aportación de un arquitecto no es elegir un ganador en silencio, sino hacer que el conflicto sea visible, cuantificado y tenga un responsable. En la práctica, eso significa cuatro cosas. Formula ambas inquietudes con precisión, idealmente como escenarios comprobables, para que la discusión trate de números y no de adjetivos. Muestra las opciones y sus consecuencias una al lado de otra: por ejemplo, MFA para el personal y para los pacientes que la elijan, con un código de un solo uso por mensaje de texto o por llamada a un teléfono fijo como alternativa. Nombra al responsable de la decisión: algunos compromisos corresponden al patrocinador o a un comité de riesgos, no al arquitecto. Registra el resultado y su justificación, para que, cuando alguien pregunte dentro de dos años por qué los pacientes pueden iniciar sesión sin MFA, la respuesta exista. La sección siguiente, Decisiones y compromisos, trata la mecánica de sopesar esas opciones.
Algunos conflictos se disuelven al examinarlos. Puede que el equipo de seguridad no necesite MFA para todas las acciones del paciente, solo para ver los resultados de las pruebas; puede que al grupo de pacientes le parezca bien en ese caso. Preguntar a cada parte por qué tiene esa inquietud, y qué resultado teme realmente, a menudo revela un diseño que satisface a ambas.
Adónde van las inquietudes
Cómo alimentan las inquietudes los requisitos y la documentación
Las inquietudes son la materia prima de dos actividades posteriores. La primera es la ingeniería de requisitos. Una inquietud sobre la velocidad se convierte en un requisito de atributo de calidad, que el Capítulo 2 te enseña a escribir como un escenario medible (fuente, estímulo, artefacto, entorno, respuesta y medida de la respuesta): consulta Escribir escenarios de atributos de calidad que se puedan probar. Una inquietud como "los datos de los pacientes deben quedarse en el Reino Unido" se convierte en una restricción, una decisión que ya se ha tomado por ti. Las inquietudes que resultan no afectar a la estructura del sistema se quedan como requisitos funcionales o de proyecto ordinarios.
La segunda es la documentación. 42010 organiza la descripción de una arquitectura en torno a las inquietudes: un punto de vista nombra las inquietudes que enmarca y las partes interesadas a las que sirve, y una vista aplica ese punto de vista a tu sistema. Las inquietudes del equipo de operaciones piden una vista de despliegue que muestre los servidores, las regiones y el failover; las del delegado de protección de datos piden una vista de flujo de datos que muestre por dónde viajan los datos personales y dónde se almacenan; los desarrolladores necesitan una vista de módulos que muestre qué depende de qué. Un diagrama que no responde a la inquietud de ninguna parte interesada es decoración. El Capítulo 4 trata esto a fondo en Vistas y puntos de vista.
La trazabilidad une las dos. Si puedes seguir una línea desde una parte interesada, pasando por una inquietud, hasta un requisito, una decisión y una vista, puedes responder a las dos preguntas que todo revisor acaba haciendo: ¿por qué está construido así y nos hemos olvidado de alguien?
Ejemplo práctico
Ejemplo práctico: las partes interesadas de un sistema de reserva de citas de un hospital
Un consorcio hospitalario regional quiere un sistema en línea para que los pacientes reserven, cambien y cancelen sus citas de consultas externas, en sustitución de la reserva por teléfono. Debe integrarse con el sistema de administración de pacientes (PAS) existente y enviar recordatorios por mensaje de texto. Este es el primer análisis de partes interesadas que podría elaborar un arquitecto en las dos primeras semanas.
| Pacientes, cuidadores | Inquietudes: reservar con facilidad desde un teléfono, accesibilidad (lectores de pantalla, texto grande), recordatorios, privacidad. Impacto en la arquitectura: frontend web adaptable que cumple WCAG 2.2 AA; sin necesidad de instalar una app; datos mínimos en pantalla. |
|---|---|
| Recepción y personal clínico | Inquietudes: ninguna reserva duplicada, listas de consulta que se correspondan con la realidad, menos llamadas telefónicas. Impacto: el PAS sigue siendo la única fuente de verdad de las franjas horarias; el sistema de reservas no debe tener su propia copia, que podría desviarse. |
| Resp. clínico | Inquietudes: las derivaciones urgentes no deben quedar desplazadas por las reservas rutinarias; seguridad clínica. Impacto: reglas de franjas horarias que son responsabilidad de los clínicos y configurables sin un lanzamiento; un caso de seguridad clínica (en Inglaterra, conforme a la norma DCB0129) que abarque el sistema. |
| Delegado de protección de datos | Inquietudes: los datos de salud son una categoría especial de datos según el RGPD (GDPR) del Reino Unido; minimización; conservación; auditoría. Impacto: una vista de flujo de datos, cifrado en tránsito y en reposo, registros de auditoría de quién vio qué, una política de conservación. |
| Equipo de operaciones | Inquietudes: los picos de los lunes por la mañana, la capacidad limitada del PAS, el soporte fuera de horario. Impacto: una cola o un limitador de tasa delante del PAS; caché de la disponibilidad de franjas con una caducidad corta; monitorización de los tiempos de respuesta del PAS. |
| Dir. financiero | Inquietudes: presupuesto fijo, costo de funcionamiento previsible, ahorro en personal del centro de llamadas. Impacto: servicios gestionados en la nube dimensionados para el pico; un modelo de costos por cada mil reservas. |
| Proveedor del PAS (integrador) | Inquietudes: ninguna carga no soportada sobre su sistema; uso exclusivo de su interfaz publicada. Impacto: integración a través de la interfaz del proveedor con límites de tasa acordados; un conjunto de pruebas de contrato. |
| Principal conflicto encontrado | Operaciones quiere guardar en caché la disponibilidad de franjas para proteger el PAS; el personal de recepción teme reservas duplicadas por datos desactualizados. Resolución propuesta: caché solo para mostrar (30 segundos), pero confirmar cada reserva contra el PAS en tiempo real, con un mensaje claro si la franja acaba de ocuparse. |
Siete grupos de partes interesadas produjeron al menos cinco decisiones con consecuencias estructurales (única fuente de verdad, limitación de tasa, registros de auditoría, reglas configurables, frontend accesible) antes de que se hubiera diseñado en detalle ninguna funcionalidad.
El conflicto de mayores consecuencias se dio entre dos grupos de perfil bajo, operaciones y el personal de recepción, ninguno de los cuales habría dominado una reunión del comité de dirección.
Cada fila se puede trazar hacia delante hasta un escenario de atributo de calidad, un registro de decisión y una vista, y hacia atrás hasta una clase de personas con nombre.
Preguntas frecuentes
¿De verdad el equipo de desarrollo es una parte interesada? Somos quienes lo construimos.
Sí. Los desarrolladores conviven con la arquitectura más tiempo que casi nadie, y sus inquietudes (tiempo de compilación, capacidad de prueba, propiedad clara) se traducen directamente en velocidad de entrega. La definición de 42010 no distingue entre quienes construyen y quienes usan.
¿Cuál es la diferencia entre una inquietud de una parte interesada y un requisito?
Una inquietud es el interés de fondo, a menudo vago ("quiero que sea fiable"). Un requisito es un enunciado preciso y verificable derivado de una o más inquietudes ("99.9% de disponibilidad mensual"). Varios requisitos pueden servir a una misma inquietud, y algunas inquietudes se convierten en restricciones.
¿Quién decide cuando dos partes interesadas con mucho poder no están de acuerdo?
Normalmente no el arquitecto solo. El arquitecto plantea las opciones y las consecuencias; la decisión corresponde a quien responde del resultado, normalmente el patrocinador o un comité de gobernanza. Acordar de antemano quién decide cada tipo de compromiso ahorra semanas de discusión.
Comprueba lo que has entendido
Nombra tres partes interesadas de un sistema comercial típico que rara vez asisten a las reuniones de diseño.
Por ejemplo: los desarrolladores que lo mantendrán en años futuros, el servicio de soporte, los usuarios con discapacidad, el personal de operaciones de guardia por la noche y los ciudadanos afectados por sus decisiones.
Un patrocinador dice "tiene que ser seguro". ¿Es una inquietud o un requisito?
Una inquietud. Hay que refinarla en requisitos específicos y comprobables, por ejemplo sobre autenticación, cifrado o registros de auditoría, antes de que pueda guiar las decisiones.
¿Por qué una inquietud, como la seguridad, puede pertenecer a varias partes interesadas a la vez?
Porque distintas personas temen distintas consecuencias de la misma cualidad: el equipo de seguridad teme los ataques, el delegado de protección de datos teme las filtraciones de datos personales, el patrocinador teme el daño a la reputación y los usuarios temen que se filtren sus datos.
¿Qué vincula una inquietud de una parte interesada con una vista de la arquitectura?
Un punto de vista: indica a qué inquietudes y partes interesadas sirve y cómo modelarlas, y la vista lo aplica al sistema.
Fuentes y lecturas recomendadas
¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.
Pregunta: “¿Cómo encuentro las partes interesadas que me faltan, y qué debo hacer cuando dos de ellas quieren cosas opuestas?”