Arquitectura - Goal Driven Design (GDD)

Goal Driven Design (GDD)

Debemos procurar que cada cosa que hagamos aporte un poco a la recuperación de la calidad de vida que nos hemos encargado de destruir.

 

Tradicionalmente el diseño de arquitectura de software se ha basado en 4+1 vistas de Philip Kruchten y posterior a éstas han salido muchas otras de diferentes autores y empresas. Una de las que más me gusta es Attribute Driven Design (ADD) del SEI. Pero en resumen todas ellas pretenden comunicar de manera efectiva las decisiones de arquitectura que se tomen para el proyecto.

Goal Driven Design no es una metodología o un proceso de diseño de arquitectura. Es más bien una forma de enfocarse en lo más importante que es: Mejorar la calidad de vida de las personas a la vez que damos valor al negocio.

4+1 Vistas utiliza lo funcional como aquello mas importante en torno a lo cual debe girar el diseño arquitectónico, dejando relegadas las calidades sistémicas o requisitos no funcionales, aspectos en torno a los cuales gira la arquitectura en ADD.

Personalmente pienso que lo más importante no es el tema funcional, tampoco lo es el tema no funcional. Lo más importante es el impacto que vamos a generar sobre el negocio, sobre la calidad de vida de las personas, sobre el planeta, o sobre cualquier cosa en torno a la cual gire nuestro objetivo. A esta forma de ver la arquitectura la llamé Goal Driven Design. 

Haciendo investigaciones sobre el uso del nombre en internet me encontré con que ya había sido usado previamente por alguien mas, quien plantea argumentos similares a los míos pero que pienso, no van en contravía sino que simplemente se complementan (Ver http://johnnyholland.org/2011/11/goal-driven-design-decisions/). Quisiera también leyeran en éste punto un Post que escribí hace algún tiempo y que ayudara a complementar las ideas que les voy a exponer (Ver http://mauro2357.blogspot.com/2012/08/el-poder-del-por-que.html).

Goal Driven Design se apoya en los siguientes pasos para realizar el diseño arquitectónico. 

Análisis del problema 

• Entender el contexto del negocio: No tiene sentido tratar de ofrecer soluciones en un negocio del cual no tenemos ningún conocimiento. El objetivo de ésta actividad es ofrecer soluciones enmarcadas dentro de las restricciones de entorno de la organización.

• Identificar el proceso de negocio: Una vez se tenga un conocimiento general de la organización, debe entenderse el proceso de negocio del área que se vaya a intervenir. Su objetivo es poder identificar posteriormente la problemática.

• Analizar e identificar la problemática: Con el proceso de negocio identificado y entendido se puede realizar un análisis de éste para identificar los problemas (Oportunidades de mejoras) en cada una de sus partes. Ésta información se constituirá en el principal insumo para realizar un análisis de solución totalmente enfocado en solucionar la problemática.

Ver Entendiendo el negocio

Análisis de la solución.

• Plantear alternativas de solución (Necesidad de negocio): A partir de los problemas identificados se deben plantear alternativas que permitan solucionar dicha problemática. Este análisis entregará como salida un conjunto de necesidades funcionales orientadas totalmente a solucionar los problemas encontrados. 

"Al arquitecto no le importa lo que hace el sistema cuando se da clic, lo que le importa es la cantidad de clics que den sobre el botón". No debemos mal interpretar lo que dice ésta frase como que el arquitecto no debe tocar temas funcionales. Por supuesto que lo debe hacer (El sistema con el mejor desempeño sería aquel que no haga nada), mas no es su responsabilidad velar porque el sistema cumpla a cabalidad cada aspecto funcional. Su responsabilidad es velar por los atributos de calidad del software.

• Entender los atributos de calidad: Jamás vayan al negocio o a los analistas de tecnología a preguntar. ¿Qué performance debe tener la aplicación?, ¿cuál es la disponibilidad? o ¿el sistema debe ser flexible?. Las respuesta obvias serán: Menos de 1 segundo, 7x24, Si.

El entendimiento de los atributos de calidad debe hacerse desde el negocio mismo. Si entiendo el negocio, entiendo los atributos de calidad. Creen ustedes que las respuestas cambiarían si le preguntáramos a los interesados del negocio: ¿Qué impacto tiene para el negocio si la opción x del sistema tarda más de 3S en responder?, ¿Que implicaciones legales,  comerciales, operativas o de cualquier otra índole, hay si el aplicativo no presta servicio durante 2H?, ¿Que implicaciones legales hay si no logramos implementar un cambio de ley en menos de 2 Meses?

¡Expresemos los atributos de calidad en términos de negocio!.

• Conocer la plataforma tecnológica: No podemos proponer soluciones sin entender lo que ya existe. ¡No reinventemos la rueda! La solución final debe estar plenamente articulada con las soluciones existentes.

• Entender las restricciones técnicas: El conocimiento de la plataforma tecnológica aportará ciertas restricciones como sistemas legados, pero deben conocerse también las decisiones de diseño que se hayan tomado previamente, lineamientos de arquitectura al interior de la organización o cualquier otro elemento que limite la solución que podamos ofrecer.

• Entender las restricciones de negocio: Estas normalmente giran en torno a la triple restricción (Alcance-Tiempo-Costo-Calidad). Es importante tenerlas en cuenta para hacer lo mejor que podamos con los recursos disponibles.

• Construir la meta de diseño: A partir de toda la información recolectada a través de la realización de las actividades planteadas hasta el momento, se debe generar una meta de diseño en torno a la cual girará el diseño de la arquitectura.

Con la meta clara, diseñar una arquitectura se limita a la aplicación de patrones de diseño, uso de herramientas, y la experiencia del arquitecto para reflejar la meta identificada en esa arquitectura, pero en éste punto la parte dificil ya se hizo.

 

 En otro post diseñaremos una arquitectura dirigida por las metas.

Post relacionado. Diseño arquitectónico grupal