Cuando empecé como programador, hace ya muchos años, el jefe de proyecto era el responsable del proyecto, tanto desde el punto de vista técnico como organizativo. Principalmente interactuaba con los analistas y los analistas programadores, cuya función era dibujar cajitas que modelaban el sistema que los que estábamos por debajo, los programadores, debíamos convertir en código. También existía otro rol que dibujaba cajitas, el arquitecto, que solía ejercer de analista jefe, y era el que más sabía de software. En esa época me preguntaba cuales eran exactamente sus responsabilidades técnicas, y qué diferencia había entre el trabajo realizado por un arquitecto y por un analista, más allá de la diferencia jerárquica dada por su experiencia y supuestos conocimientos. Para mi todos dibujaban cajitas y líneas entre ellas, todos diseñaban el software.
Hoy en día siguen existiendo arquitectos, analistas y programadores. También hay ingenieros de software y un sinfín de personas con etiquetas diferentes que se dedican a producir software. La verdad es que da igual el nombre que tenga cada uno. Desde el punto de vista técnico, los sistemas, las aplicaciones, el software, lo que se implementa, se llame como se llame, se tiene que definir. Y en este sentido, una pregunta que me he venido haciendo durante muchos años es qué diferencia existe entre la Arquitectura y el Diseño de Software, que son las especialidades que deciden cuál tiene que ser esta definición.
“Architecture represents the significant design decision that shape a System, where significant is measured by cost of change”
Grady Booch
El cliente conoce las necesidades de su negocio, sabe lo que necesita para ser más competitivo, más eficiente, o simplemente mejor que su competencia. Lo que no sabe es cuales pueden ser las soluciones tecnológicas que le permitirán conseguir sus objetivos.
Por este motivo, acude a quien le pueda proporcionar las herramientas que le permitan evolucionar su negocio: Arquitectos y/o Diseñadores de Software. Estos se encargan de conversar con él para entender el problema y averiguar los beneficios que quiere obtener. Se esfuerzan en entender QUÉ se quiere hacer y PARA QUÉ, para poder definir CÓMO se va a construir la herramienta que se necesita. Queda claro entonces que el objetivo, tanto de la Arquitectura como del Diseño de Software, es producir un modelo o representación del sistema que describa su comportamiento, que describa CÓMO tiene que ser el sistema, desde el punto de vista técnico, para poder satisfacer las necesidades del cliente. Lo que sigue sin quedar claro es qué diferencias hay entre hacer Arquitectura o Diseño de Software.
Yo, que soy un apasionado del deporte, veo similitudes con las diferencias que hay entre estrategia y táctica. Para mi, la estrategia define la manera como se va a jugar. Se basa en las herramientas de las que se dispone y de los valores que se tienen. Define la identidad e indica la dirección que deben tomar las decisiones que se toman durante el juego. La táctica, en cambio, va de tomar decisiones concretas en situaciones concretas, dadas unas condiciones determinadas. Eso sí, en el marco definido por la estrategia.
La estrategia no define ningún protocolo ni procedimiento que te condicione. Creo que la Arquitectura del Software va de eso, de Estrategia, de definir el marco en el que el sistema debe poder evolucionar, sin limitarlo y sin que el coste financiero y técnico de la evolución sea inasumible. Define las características del sistema que le permiten mantener la integridad mientras se adapta a los cambios funcionales y del entorno; define la identidad del sistema en términos técnicos; y establece la dirección en la que se deben tomar las decisiones clave del diseño para definir esta identidad, para asegurar que se hace lo que se necesita para crear un sistema que funcione. Define las reglas del juego, e impacta en el proyecto a dos niveles:
- A nivel organizativo
- Simplifica la comunicación externa
- Ayuda a comunicar el diseño de alto nivel a los stakeholders del proyecto, para que tengan claro que se ha entendido el qué y se ha definido el cómo
- Simplifica la comunicación interna
- Ayuda a proporcionar el contexto del sistema (responsabilidades y dependencias) a los ingenieros para que sean capaces de desarrollar la parte que tengan asignada con más eficiencia y calidad.
- Simplifica la comunicación externa
- A nivel técnico
- Permite asociar los requerimientos funcionales y no funcionales del sistema con los objetivos.
- Permite reducir el coste del mantenimiento y de la evolución del sistema, anticipando los principales tipos de cambios que podrían ocurrir y asegurando que se puedan facilitar estos cambios
- Permite incrementar la reutilización de componentes existentes y la integración con legacy Software y/o Software de terceros.
Durante bastante tiempo he leído sobre Arquitectura de Software, hasta que un día encontré una definición que me pareció bastante acertada: «Architecture represents the significant design decisions that shape a System, where significant is measured by cost of change», escrito por Grady Booch. Según Booch «significant design decisions» son las decisiones que tienen un coste elevado cuando se cambian, siendo el coste directamente proporcional al impacto estratégico producido. Podrían ser las decisiones, que una vez tomadas, son difíciles de revertir, las que si se toman correctamente contribuyen en reducir el coste y el impacto de futuros cambios que podrían desestabilizar el sistema o retrasar su evolución. Martin Fowler también habla, en su paper “Who needs an Architect?”, sobre lo que significa “difícil de cambiar” y sobre el rol de los Arquitectos.
La definición de Booch me gusta porque explicita el hecho de que todas las decisiones de Arquitectura son de Diseño, pero no todas las decisiones de Diseño lo son de Arquitectura. Lo son sólo las importantes. Además, incide en el hecho de que todas las decisiones de Diseño están dirigidas por los cambios que ocurren, ya sea en los requerimientos, en el entorno o en las herramientas.
Más concretamente, la respuesta a las siguientes preguntas ayudaría a definir como tiene que ser un sistema a nivel estructural y de comportamiento para que encaje con el entorno y se adapte cuando cambie:
- ¿Qué se debe asegurar a nivel de sistema para tener éxito y que el sistema sea el que se espera?
- ¿Qué funcionalidades y propiedades debe tener el sistema? ¿Qué implica esto en términos de prioridades técnicas?
- ¿Qué mecanismos arquitecturales se necesitan para resolver el problema eficientemente?
- ¿Qué puede cambiar en el ecosistema en el que se tiene que implantar el sistema? ¿Qué implican estos cambios para el sistema?
- ¿Qué impacto tiene el sistema en los ecosistemas con los que interacciona?
El hecho que la arquitectura incluya el conjunto de decisiones importantes del diseño, no significa que las decisiones que no sean de arquitectura no sean importantes para el éxito del proyecto. Son importantes a otro nivel, ya que permiten definir la estructura interna del sistema y garantizar que se comporta según las especificaciones. Este diseño de más bajo nivel incluye la definición de las partes en las que se divide el sistema y sus relaciones, así como la definición de las estructuras de datos.
Justamente, de este diseño más detallado es en lo que me voy a centrar en este blog. En cómo construir diseños eficientes escribiendo código entendible y que garantice el comportamiento esperado. Si te interesa, no te pierdas la próxima publicación!
Deja una respuesta