Para crear una arquitectura o determinar la validez de una arquitectura existente se empieza por identificar las características arquitectónicas ("-ilities"). Para lograr esto el arquitecto debe:
- Comprender el dominio del problema.
- Trabajar con los stakeholders para establecer lo que es verdaderamente importante desde la perspectiva del negocio.
Un arquitecto extrae las características arquitectónicas de al menos tres fuentes:
- Requerimientos de negocio
- Requerimientos funcionales y restricciones
- Del conocimiento implícito del dominio
En esta oportunidad hablemos sobre lo que implica extraer las características arquitectónicas a partir de los requerimientos de negocio.
Extraer las características arquitectónicas desde los requerimientos de negocio
Los requerimientos de negocio describen las metas de una organización. Un arquitecto debe ser capaz de identificar las características arquitectónicas correctas. Por ejemplo, ¿es la escalabilidad la característica más importante, o es la tolerancia a fallos, la seguridad o el rendimiento? Tal vez el sistema requiere las cuatro características combinadas.
La comprensión de los objetivos de negocio permite al arquitecto traducirlas en "-ilities", lo que luego constituye la base de decisiones arquitectónicas correctas y justificables. La mayoría de las características arquitectónicas se obtienen escuchando a los stakeholders y colaborando con ellos para determinar qué es importante desde la perspectiva del negocio.
Aunque esto puede parecer una actividad sencilla, el problema es que los arquitectos y los stakeholders del negocio hablan idiomas diferentes. Los arquitectos hablan de escalabilidad, interoperabilidad, tolerancia a fallos y disponibilidad. Los stakeholders del negocio hablan de fusiones y adquisiciones, satisfacción del usuario, time to market y ventaja competitiva.
Lo que sucede es un problema de "lost in translation" en el que el arquitecto y el stakeholder del negocio no se entienden entre sí. Los arquitectos no tienen ni idea de cómo crear una arquitectura que apoye la satisfacción del usuario, y los stakeholders del negocio no entienden por qué los arquitectos ponen tanta atención y hablan de disponibilidad, interoperabilidad y tolerancia a fallos en la aplicación. Los arquitectos deben a menudo decodificar el lenguaje del dominio en equivalentes de ingeniería.
Afortunadamente, suele haber una traducción de los objetivos del negocio a las características arquitectónicas, tal como se describe en la siguiente imagen:
Recuerda que normalmente un objetivo de negocio implica satisfacer la combinación varias características arquitectónicas y hay que tener cuidado de no caer en la trampa de concentrarnos en uno sólo de ellos.
No comments:
Post a Comment