Arquitectura de Software - Stakeholders

Retomando las sobre notas arquitectura de software (ver otras notas abajo), en esta ocación voy a hablar de los stakeholders.

Los stakeholders (interesados) son todas aquellas personas o entidades que tienen alguna participación, injerencia o interés en el sistema. Ejemplo de stakeholders son: usuarios del sistema, programadores, diseñadores, dueño del producto, organizaciones con las cuales el sistema interactúa, gerente de la Software Factory, organización que desarrolla el sistema, etc. Cada uno de ellos tiene diferentes preocupaciones y necesidades y esperan que sean satisfechas o aun mejor, que sean óptimas.

Una de las tareas más importantes del arquitecto de software es poder lograr identificar con la mayor precisión posible el conjunto de stakeholders antes de comenzar a construir y diseñar la arquitectura, dado que estos producen un impacto directo sobre el sistema y en particular sobre la arquitectura. La correcta ejecución de esta tarea no es responsabilidad única del arquitecto de software, sino que debe trabajar conjuntamente con ingenieros a cargo de la ingeniería de requerimientos. Dicho esto, queda claro que los stakeholders influyen y restringen en las decisiones que un arquitecto debe tomar. La arquitectura de un sistema está influenciada por aspectos técnicos, por el negocio y por el contexto social que lo rodea. Así los stakeholders competirán entre sí, principalmente porque cada uno de ellos querrá que el arquitecto le de prioridad a sus necesidades y que la arquitectura tenga determinadas características que él desea, por sobre las que otros stakeholders.

Ejemplo:

Stakeholder	Intereses
Cliente	Costo, Calidad, Vida del proyecto, Posibilidad de hacer cambios
Usuarios	Facilidades de uso del sistema, seguridad, Personalización, configuración, etc.
Proveedor del sistema	Ganancia y amortización de los costos, adherencia a los procesos internos, calidad, reusabilidad.
Desarrolladores	Conocer la arquitectura, estándares de desarrollo y componentes reusables. Facilidades para hacer cambios.
Administrador del sistema	Simple configuración, monitoreo o administración de los servicios, disponibilidad, escalabilidad.

El arquitecto deberá siempre, en la medida de sus posibilidades, consensuar con los stakeholders las necesidades reales y compensarlas para lograr obtener un conjunto de características que por un lado deje contentos a todos los stakeholders y por otro permita construir la mejor arquitectura posible.

En este sentido las tareas que un arquitecto debe realizar son:

1. Entender las reales restricciones del sistema. 
2. Manejar las expectativas de los stakeholders. 
3. Negociar las prioridades del sistema. 
4. Identificar conflictos.

Otros notas: Vista Contextual y Diagrama conceptual
Definiciones básicas