La arquitectura trata sobre el equilibrio

Balancear los intereses de los stakeholders con los requerimientos técnicos

Cuando pensamos en la arquitectura software, intentamos pensar primero en las actividades técnicas clásicas, como modularizar los sistemas, definición de interfaces, asignación de responsabilidades, aplicación de patrones de diseño, mejora de rendimiento.

Como arquitectos también debemos considerar la seguridad, usabilidad, compatibilidad, administración de entregables, y opciones de despliegue, entre otras cosas.

Pero estas características técnicas y de procedimiento necesitan estar equilibradas con las necesidades de los stakeholders y sus intereses. Recogiendo los “intereses de los stakeholders” y enfocarnos en el análisis de requerimientos podemos asegurar completamente que se cumplan las especificaciones requeridas del software a ser desarrollado.

Analizando a las partes interesadas, y sus intereses, en el proceso en el cual una organización desarrolla software, y la organización en sí misma, se revelan el último conjunto de prioridades que conciernen a un arquitecto software. La arquitectura de software equilibra este conjunto de prioridades, a corto y largo plazo, de forma apropiada al contexto actual.

Considerando, por ejemplo, el departamento de ingeniería de “software como un servicio de negocio”. Ciertamente el negocio tiene algunas prioridades, tales como reuniones de obligaciones contractuales, generación de ingresos, asegurar al cliente como referencia, contener costes, y creando activos tecnológicos de valor. Las prioridades de negocio se pueden traducir a las prioridades departamentales como asegurar la funcionalidad y corrección, y los “atributos de calidad” del software a desarrollar, así como asegurar la productividad del equipo de desarrollo, asegurando la sostenibilidad y capacidad de auditoría de las operaciones de desarrollo, y luego la adaptabilidad y longevidad de los productos software.

Este es el trabajo de un arquitecto, no solo crear software funcional y de calidad para los usuarios, sino también hacer eso mientras equilibra otras prioridades departamentales, con el interés de contener costes del CEO (consejero delegado) de negocio (empresa), con el interés por la “facilidad de administración” de las operaciones de personal (staff), con el interés por la “facilidad de aprendizaje” y la “facilidad de mantenimiento” de los futuros miembros del equipo, y por su puesto con las mejores prácticas de la profesión de arquitecto software.

El arquitecto puede elegir conscientemente inclinar la balanza a favor de una prioridad a corto plazo, pero tiene que mantener un buen equilibrio a largo plazo para llevar a cabo realmente un buen trabajo. Y el equilibrio encontrado debe ser adecuado al contexto actual, considerando factores como el tiempo de vida esperada del software, su criticidad para el negocio, y la cultura tecnológica y financiera de la organización.

Resumiendo, la arquitectura de software es más que simplemente las clásicas actividades técnicas, es un equilibrio entre los requisitos técnicos y los requerimientos de negocio de los interesados en el proyecto.

Autor Randy Stafford

Versión original en : Architecting is about balancing


Enlaces relacionados:
Principios de desarrollo software ("Equilibrio")

- FIN -