Proceso para la creación de la Arquitectura

Hoy quiero contarles acerca de un modelo que he adoptado para la construcción y entrega de la Arquitectura de Software, el cual lo he relacionado con éxito al interior de la compañía para la cual trabajo y que considero, bien puede adaptarse a cualquier tipo de especialidad de la Arquitectura Empresarial.

Cuando era desarrollador escuchaba hablar constantemente acerca de varias metodologías de desarrollo. Durante mucho tiempo apliqué RUP, XP y metodologías AGILES, usé PSP y TSP como procesos de desarrollo. Pero durante todo ese tiempo nunca oí hablar de metodologías orientadas a la generación de la Arquitectura de Software, aún luego de comenzar a estudiar y al día de hoy he tenido muy pocas referencias.

Quiero aclarar que existen varios modelos y  frameworks bastante conocidos para la Arquitectura Empresarial que son confrontados a profundidad en unas entregas muy completas de Microsoft, estas pueden estudiarse en este link.

Pues bien, el método al que me refiero es ACDM, Architecture Centric Design Method o Método de Diseño Centrado en la Arquitectura. Es un modelo que está hecho para adaptarse a los procesos internos de una empresa y se enfoca principalmente en crear la Arquitectura de Software a través de una práctica estándar. Este método fue creado por la universidad Carnegie Mellon, y en este link pueden descargar un brochure completo para su implementación.

Ya que la presentación que relaciono cuenta toda la información relevante, enfocaré este artículo en explicar cómo relacioné el método a los procesos internos. Espero que el caso de éxito sea suficiente para su completo entendimiento. Cabe aclarar que es requisito leer primero la información contenida en el pdf.

Para contextualizar el segundo protagonista de este artículo, el proceso de desarrollo usado  en mi empresa es RUP, el cual se une a un modelo de mejora continua, CMMI nivel 3, que parece ser ya muy común. En general, bajo este contexto, el ciclo de vida del producto se supone así: modelado de negocio, requisitos, análisis y diseño, implementación, pruebas y despliegue. Por su parte, ACDM, cuenta entonces con 7 etapas, aunque yo agrupé las etapas de producción, por lo que trabajo realmente con 8.

Como es evidente, la generación de la Arquitectura de Software se ubica en el análisis y diseño de RUP,  pero debe estar presente en todo el ciclo de vida del producto. basado en dicha premisa, la siguiente es la relación que establecí para cada estado del ciclo de vida del producto, áreas de proceso de CMMI y las etapa de ACDM:

Mapeo entre el ciclo de vida del producto en RUP, algunas áreas de proceso de CMMI y etapas de ACDM.

Realmente, en CMMI, toda la labor de construcción de un producto se incluye en las actividades propias de Technical Solution (TS) y esto incluye la Arquitectura. En todo caso, expondré mi punto de vista y la relación que he planteado.

Descubrir los Motivadores Arquitecturales

Esta etapa parece una actividad propia de la Arquitectura de Negocio para la Arquitectura Empresarial, pero, es importante siempre tener claro que conocer el negocio y sus objetivos es la mejor manera de generar soluciones de valor. Esta etapa describe los argumentos o preocupaciones que aclaran cuáles son las necesidades de realizar la  documentación Arquitectural desde el punto de vista estratégico, técnico y funcional. Esta es una tarea importante pues traza el objetivo de la investigación o del diseño que se realiza. Los motivadores son propios del negocio, pueden ser capturados en el momento en que se realiza el modelado del negocio y los requisitos.

Es importante entender que conocer los motivadores nos permite establecer las metas de la Arquitectura, los atributos de calidad. Por ejemplo, un motivador de negocio podría ser: Ampliar la presencia de nuestro producto en el mercado, de lo que implícitamente extraemos que las peticiones o transacciones en línea se podrían incrementar o que vamos a requerir una solución que permita escalar acorde a dicho objetivo.

Establecer Alcance del Proyecto

Basado en las preocupaciones o en los motivadores Arquitecturales, se establece cuál es el alcance de la investigación, del diseño documentado o de la solución propuesta. El alcance puede ser descrito en términos de tiempo (Denominado alcance horizontal), en términos de funcionalidad o en una combinación de ambas. El alcance del proyecto se extrae de los requisitos y debe ser claro para lograr cumplir las expectativas.

En la etapa de análisis es posible confirmar el alcance, si bien este ya fue acordado con el cliente, puede suceder que debido a alguna restricción tecnológica, el alcance deba limitarse.

Crear o Refinar la Arquitectura

El método sugiere la evolución de la Arquitectura diseñada. Si bien no es tan práctico ver tanta información, es importante describir cada uno de los pasos que se ejecutaron para llegar a las conclusiones documentadas. Para documentar esta evolución hago uso de la administración de la configuración (CM), área de proceso que pertenece al proceso de soporte en CMMI.

Es común leer que la Arquitectura es diseño pero que el diseño no siempre es Arquitectura. Para no debatir este tema, simplemente asumí que esta etapa de ACDM se relaciona a la fase de análisis y diseño.

Revisión de arquitectura

La revisión de la Arquitectura me recuerda todas aquellas fases de revisión de pares que se ejecutan en PSP y TSP. Ya que esta es una forma de garantizar la calidad, hago uso del área de proceso denominado Aseguramiento de la Calidad de Producto y Proceso de CMMI (PPQA) a través de 1 revisión de pares y 2 inspecciones de calidad que he denominado Comité de Arquitectura y Comité de Desarrollo. Por parte del ciclo de vida, la revisión de la Arquitectura se continúa haciendo en análisis y diseño, pues esta será su artefacto para la implementación.

Va o no va a Producción

Producción, como yo la he contemplado, es la fase de implantación en el ciclo de vida del producto. El Documento de Arquitectura de Software es entonces el artefacto a entregar a nuestros clientes, es decir: desarrolladores, analistas de calidad, gerentes de proyecto, etc.

Decidir qué está listo para ser entregado depende de que las decisiones arquitecturales que hemos documentado, cumplan las metas planteadas. Las metas pueden ser cumplidas de forma evidente o requerir la experimentación para soportarlas. Cuando no estoy aún seguro de los datos que he generado, es siempre posible usar en esta etapa el área de procesos de Análisis y Resolución de Decisiones (DAR), o comúnmente conocida como Toma de Decisiones Formales. Las decisiones liberadas se documentan y registran para trazabilidad a través de la CM.

Experimentación

Este es tal vez la etapa más importante de la investigación o del diseño. En la experimentación se debe recopilar toda la información posible que se genere de las herramientas usadas.   La experimentación debe ser clara y fácilmente reproducible, es el soporte a cada una de las decisiones y puede ser referenciada de otros documentos en caso que aplique, por lo que no dudo en usar nuevamente las herramientas que el área de CM me da. Los datos de los experimentos se usan como soporte en caso de recurrir a DAR y deben ser lo suficientemente convincentes para que al entregar a producción estos puedan ser constantemente medidos.

Planeación de Producción

Se inicia la entrega de la documentación y los diseños generados.  En este momento el análisis y el diseño debe haber finalizado para la arquitectura, mas no para el producto. La planeación siempre es una responsabilidad de la Gerencia y en este caso no es distinto, permite definir en qué orden se realizará la entrega, si se entregará todo y, en conjunto con el Arquitecto, se define cuáles equipos participarán y todo a través del área de proceso de Planeación del Proyecto (PP).

Producción

Momento en el que el artefacto generado por la Arquitectura está en manos del área de desarrollo listo para implementación o se está usando como base para la ejecución de las recomendaciones descritas. Básicamente cualquier diseño o prototipo que requiera ser materializado en  código, tablas o componentes es la salida esperada en este punto del ciclo de vida. Producción se extiende incluso hasta la implantación, pues lo resultados de las mediciones a los atributos de calidad deben constantemente ser asegurados.