Mitos sobre la Arquitectura de Software

En este post me refiero por Arquitectura específicamente a la Arquitectura de Solución. La que se diseña para la construcción de un producto de software.

Mito 1: La arquitectura de un sistema es Documentación

Típicamente la palabra documentación trae una carga negativa de juicios que nos llevan a pensar que es algo repetitivo, que se hace posteriormente para cumplir, que agrega poco valor en general. Bajo esa definición de documentación la arquitectura definitivamente no lo es. La arquitectura se enfoca en diseñar efectivamente la solución a construir y en mucho menor grado en la posterior formalización de estos diseños. Diseñar la arquitectura de la solución en etapas tempranas acorta los tiempos de construcción, evita el retrabajo, mejora la mantenibilidad del sistema resultante y sienta bases sólidas para cumplir los atributos de calidad que el negocio requiere.

Construirías una casa si ver antes la maqueta y los planos?.

Mito 2: Sólo aplica para sistemas grandes y complejos

Antes de poner un bloque debes saber dónde se deben poner bloques y con qué objetivo, esto aplica independientemente de si construirás una pared, una casa o un edificio. Lo que suele ocurrir es que para sistemas muy pequeños la arquitectura es obvia o tradicional, mientras que para sistemas grandes hay muchas alternativas a considerar. En un sistema grande la arquitectura es difícil de comprender y asimilar en su totalidad. Todo sistema independientemente de su tamaño requiere una arquitectura, en muchos casos vale reutilizar una conocida.

Para un sistema web en el que sólo haces login y llenas dos formularios, definirías típicamente una arquitectura de este estilo; una capa de interfaz, una capa de acceso a repositorio, algún componente de fachada entre estas capas, algunos objetos de negocio en los que viaja la información y excepciones para el manejo de errores. Podríamos pintar un par de diagramas de clase y un diagrama de secuencia con la interacción de los componentes. A eso le agregamos una selección de tecnología a usar y Voila! tenemos una arquitectura hecha en 5 minutos para un sistema que se programa en medio día. Necesitábamos una arquitectura? por supuesto que si!.

He escuchado muchas veces decir "nosotros no necesitamos arquitectura porque todos los sistemas los hacemos igual y son sencillos"... ahh entonces reutilizan siempre la misma arquitectura que ya tienen diseñada y todos la conocen bien. Tienen un activo de conocimiento intangible y no se han dado cuenta.

Mito 3: La arquitectura no tiene nada que ver con el negocio

La arquitectura debe diseñarse justamente para garantizar que la solución de cumplimiento a las necesidades de negocio. En un proceso formal partes por definir metas para la arquitectura en función de una norma como ISO-9126 de atributos de calidad de software. Seguridad, rendimiento, tolerancia a fallas, etc, etc... son atributos de calidad que se establecen dadas las necesidades del negocio, de la arquitectura de la solución depende lograr o no su cumplimiento y por lo tanto que el negocio cuente con la herramienta adecuada.

Definiciones como la del SEI (http://www.sei.cmu.edu/architecture/index.cfm) que establece en su formato de arquitectura los Stakeholder's Viewpoints, definen estrategias para acercar el documento de arquitectura a los involucrados del negocio, definiendo la trazabilidad entre las expectativas de estos y el diseño planteado para cumplirla.

La tendencia es que cada vez más la arquitectura es visible al negocio. Así como los planos y maquetas en ingeniería civil son de mucho interés para quien solicita la construcción de una casa. Aprendamos de la madurez de la ingeniería civil y sus 2000 años de ventaja sobre la ingeniería de software, construirían su casa sin comprender antes la arquitectura planteada? definitivamente no.

Mito 4: la arquitectura es necesaria o no según la tecnología a utilizar o el conocimiento del equipo sobre la tecnología que aplica

La arquitectura parte de un diseño agnóstico a la tecnología, que puede ser implementado y desplegado en diversas tecnologías y plataformas según lo que mejor se adecue a la necesidad o los skills con que el equipo cuente. No hay tecnologías que requieran o no arquitecturas, lo que ocurre es que algunas establecen en mayor o menor grado una arquitectura de referencia, incluso las herramientas de construcción te pueden llevar de la mano a implementar un estilo arquitectónico particular.

Si se desea construir una solución mantenible y en base a mejores prácticas el diseño debe hacerse haciendo uso de los elementos del estilo arquitectónico que la tecnología propone, aprovechando sus capacidades.

El diseño de la solución en función de las necesidades del negocio siempre es necesario. La arquitectura debe proponer estrategias claras para cubrir los atributos de calidad esperados del sistema y las expectativas del negocio, apalancándose en las fortalezas que plantea la tecnología utilizada.

Mito 5: Es un documento complejo que sólo consume el propio arquitecto

El diseño de arquitectura tiene implicaciones directas en presupuesto, en costos de operación del procesos de negocio que soporta o automatiza, en la agilidad y efectividad que tendrán sus operarios, en la capacidad de aprovechar ese activo en futuros retos de negocio o nuevos productos. También otros impactos más técnicos como la mantenibilidad a futuro, la convivencia con otros elemento de la plataforma tecnológica o la capacidad que el equipo actual tenga para hacerse cargo de su mantenimiento.

Es de gran utilidad la analogía con la ingeniería civil en este punto. Al construir un edificio los que solicitan la obra y que luego usarán el edificio desean estar involucrados en entender el diseño que se seguirá. Maquetas y planos son herramientas efectivas de comunicación entre los arquitectos e ingenieros y quienes contratan labora. Estar involucrados en estos diseños garantizará que la obra cubra las expectativas.

Es necesario entender la construcción de sistemas de software como ingeniería, son obras en las que se invierten grandes cantidades de dinero y producen un activo que será utilizado por años. Según métricas conocidas más del 60% del costo de un sistema durante todo su ciclo de vida se produce después que es puesto en producción y este costo depende en gran medida de la arquitectura que se haya diseñado.

En resumen…
1) La Arquitectura de Software no es opcional, puede ser más o menos compleja.
2) Es de gran valor ($$) que los responsables del negocio que solicitan la construcción de un producto de software se involucren en la evaluación de su arquitectura.