¿Eres un arquitecto de software?

Tomado del original (en inglés) en infoq.com.

La linea que divide el desarrollo de software y su arquitectura es engañosa.  Algunos dirán que esta no existe y que la arquitectura es simplemente una extensión del proceso de diseño hecho por los desarrolladores.  Otros harán de esto un enorme abismo que solo puede ser crusado por desarrolladores avanzados que creen que debes resumir los componentes fundamentales en lugar de detenerte en esos detalles molestos de implementación. Como siempre, hay un balance pragmático en algún lado a mitad del camino, lo cual hace surgir una pregunta interesante sobre como moverte de un lado a otro.

Algunos de los factores clave que a menudo se utilizan para diferenciar la arquitectura del software de su diseño y su desarrollo incluyen un aumento de la escala, un aumento en el nivel de abstracción y un aumento en la importancia de la toma de decisones correctas en el diseño.
La arquitectura del software es acerca de tener visiones holísticas y teniendo una vista general para entender como el sistema trabaja como un todo.  Mientras esto puede ayudar a difrenciar el desarrollo de la arquitectura de software, no necesariamente permite entender como alguien cambia de actividades de desarrollo a las de arquitectura. Tampoco ayuda a identificar quién hará un buen trabajo de arquitectura, ¿como harás para contratar a la gente correcta o sabrás si tu eres un arquitecto de software?

La experiencia es una buena referencia pero necesitas profundizar más

Llegar a ser un arquitecto de software no es algo que simplemente pase de la noche a la mañana o con un ascenso. Es una función, no un rango.  Es un proceso evolutivo donde gradualmente ganarás la experiencia y confianza que necesitas para ejecutar tu función.

Hay un número de cualidades que puedes buscar en un arquitecto de software y su experiencia pasada es a menudo un buen puntaje para calificar su habilidad en el desempeño de su papel.  Aunque la función de un arquitecto de software es muy variado, se necesita profundizar para entender el nivel de participación, la influencia, el liderazgo y la responsabilidad que ha sido demostrada a través de un número de ámbitos diferentes. Hablando ampliamente, la arquitectura de software en la mayoría de los proyectos puede ser dividida en dos fases; la arquitectura es definida y luego es liberada.


Definición de la arquitectura del software

El proceso de definición de la arquitectura parece bastante simple.  Todo lo que tienes que hacer es identificar cuáles son los requerimientos y diseñar un sistema que los satisfaga.  Pero en realidad no es tan simple y el papel de arquitectura de software puede varia ampliamente dependiendo de que tan comprometido estas y que tan seriamente visualizas tu papel.  Como el siguiente diagrama muestra, la parte de la definición de la arquitectura puede ser dividida en un número de elementos diferentes.

1. Manejo de requerimientos no-funcionales: Los proyectos de software a menudo quedan atrapados con los usuarios que preguntan sobre las características que desean, pero rara vez se les pregunta que requerimientos no-funcionales (o cualidades del sistema) necesitan.  Algunas veces los actores dirán que "el sistema debe ser rápido", pero eso es muy subjetivo.  Los requerimientos no-funcionales necesitan ser específicos, medibles, alcanzables y capaces de ser probados si vamos a cumplirlos.  La mayoría de los requerimientos no-funcionales son técnicos por naturaleza y a menudo tienen una alta influencia sobre la arquitectura del sofware.  Entender los requerimientos no-funcionales es una parte crucial, pero hay una diferencia entre asumir cuáles son los requerimeintos y llevarlos a cabo.  Después de todo, ¿Cuántos sistemas has visto que genuinamente necesiten ser operacionales 24x7?

2. Definición de la arquitectura: Con los requerimientos no-funcionales capturados, el siguiente paso es empezar a pensar sobre como vas a solucionar los problemas indicados por los actores y definir la arquitectura.  Se puede decir que cada sistema tiene una arquitectura, pero no que cada sistema tiene una arquitectura definida.  Y ese realmente es el punto aquí. El proceso de la definición de la arquitectura te permite pensar sobre como vas a tomar los requerimientos junto con las restricciones impuestas y resolver el problema.  La definición de la arquitectura es sobre introducir estructura, directrices, principios y ligerazgo a los aspectos técnicos del proyecto de sofware.  Definir la arquitectura es tu trabajo como arquitecto pero hay una gran diferencia entre diseñar un sistema desde cero y extender uno ya existente.

3. Selección de la tecnología: La selección de la tecnología es típicamente un ejercicio divertido pero tiene su lista justa de retos cuando te fijas en el costo, licenciamiento, relación con proveedores, estrategia de tecnología, compatibilidad, interoperabilidad, soporte, desarrollo, politicas de actualización, entornos de usuario final y aún mas.  La suma de estos factores puede a menudo hacer una tarea simple y convertirla en una completa pesadilla.  Y ahí está la pregunta de si las tecnologías en realidad funcionan.  La seleccion de tecnologías es todo sobre manejar riesgos; reducir riesgos donde existe alta complejidad o incertidumbre e introducir riesgos donde hay beneficios que obtener.  Las decisiones de tecnología se necesitan hacer tomando en cuenta todos los factores, y todas las decisiones deben ser revisadas y vueltas a evaluar.  Esto incluye los principales bloques de construcción para un proyecto de software hasta las librerias y frameworks que están siendo introducidos durante el desarrollo.  Si estás definiendo una arquitectura, también necesitas estar seguro que las elecciones que estan siendo tomadas son las correctas.  Otra vez hay una gran diferencia entre evaluar una tecnología para un nuevo sistema y agregar una tecnología a un sistema que ya existe.

4. Evaluación de la arquitectura: Si estas diseñando software, necesitas preguntarte a tí mismo si tu arquitectura funcionará.  Para mí, una arquitectura funciona si esta satisface los requerimientos no funcionales, provee los fundamentos necesarios para el resto del codigo y provee una plataforma suficiente para resolver los problemas de negocio subyacentes. Uno de los más grandes problemas con el software es que es complejo y abstracto, lo cual hace difícil visualizar las características en tiempo de ejecución desde diagramas UML o el código mismo.  Tenemos un número diferente de pruebas de todo el ciclo de vida de desarrollo del software que nos da la confianza de que el sistema que estamos liberando funcionará cuando sea mostrado. Entonces ¿por qué no hacemos lo mismo para nuestras arquitecturas? si puedes probar tu arquitectura, entonces puedes probar que esta funciona.  Y si puedes hacer eso tan pronto como sea posible, puedes reducir el total de riesgos de que el proyecto falle mas que simplemente esperar por lo mejor.

5. Colaboración de la arquitectua: Es inusual para un sistema que viva aislado y existe un par de personas que necesitan entender esto.  Esto va desde el equipo de desarrollo inmediato que necesitan entender la arquitectura hasta los actores que tienen un interes como seguridad, base de datos, operaciones, mantenimineto, soporte y más puntos de vista.  Para que un proyecto de sofware sea exitoso, necesitan colaborar muy de cerca con los encargados de sistemas para asegurar que la arquitectura se integrara satisfactoriamente con su entorno.  Desafortunadamente, la colaboracion en la arquitectura en el equipo de desarrollo rara vez ocurre, por no hablar de los actores externos.

Liberación de la arquitectura del software

También es la misma historia con la entrega de la arquitectura, donde el papel de la arquitectura del software puede variar dependiendo del nivel de compromiso a través de los elementos que contribuyen a un proyecto exitoso.

1. Apropiarse del panorama completo: Con el fin de llevar la arquitectura hacia una conclusión exitosa, es importante que alguien tenga el panorama completo y que venda la visión a lo largo del ciclo de vida del desarrollo de software, que evolucione a lo largo del proyecto si es necesario y que tome la responsabilidad de asegurarse que será entregado correctamente.  Si has definido una arquitectura, hace sentido permanecer continuamente comprometido y evolucionarla más que solamente dejarla en manos de un "equipo de implementación".

2. Liderazgo: Apropiarse del panorama completo es un especto técnico del liderazgo, pero hay otras cosas que necesitamos que esten hechas durante la fase de liberación de un proyecto.  Estas incluyen tomar responsabilidades, proveer orientación técnica, tomar decisiones técnicas y tener la autoridad para tomarl dichas decisiones.  Como el arquitecto, necesitas tener el liderazgo técnico para asegurar que todo esté caminando perfecto y que el equipo esté siendo dirigido en la dirección correcta y continuamente.  La posición del arquitecto es inherentemente sobre liderazgo y aunque esto suene obvio, muchos equipos que realizan proyectos no tienen el liderazgo técnico que necesitan, con arquitectos asumiendo que una liberación exitosa no es necesariamente su problema.

3. Entrenar y guiar: El entrenamiento y la guianza es una actividad que se suele pasar por alto en la mayoría de proyectos de desarrollo, con muchos miembros en el equipo sin el soporte que requieren.  Mientras el líder técnico intenta dirigir el proyecto como un todo, hay ocasiones en que ciertas personas necesitan asistencia.  Además de esto, entrenar y guiar provee una forma de mejorar las habilidades de la gente y ayudarlas a mejorar sus propias carreras profesionales. Esto es algo que recae directamente como un mandato para el arquitecto, pero claramente hay una gran diferencia entre entrenar a tu equipo en arquitectura/diseño y ayudarlos con sus problemas de codificación.

4. Asegurar la calidad: Incluso con la mejor arquitectura y liderazgo en el mundo, una liberación pobre puede causar que un proyecto de la vuelta del éxito al fracaso.  Asegurar la calidad es una parte amplia de la función de un arquitecto, pero esto es mas que solo hacer revisiones de código.  Por ejemplo, necesitas una linea de referencia como defensa para asegurarte, y esto significa la introducción de estándares y prácticas de trabajo.  Desde una persepectiva de desarrollo de software, estas pudieran incluir estándares de codificación, principios de diseño y herramientas de análisis de código fuente a través de una contínua integración, pruebas unitarias automatizadas y herramientas de cobertura de código.  Se puede decir que la mayoría de los proyectos no aseguran la calidad lo suficiente, por tanto necesitan imaginarse que es lo importante y garantizarlo suficientemente.  Para mí, las partes importantes de un proyecto son todas aquellas significativas arquitectónicamente, con lógica de negocios crítica, complejas y altamente visibles.  Solo necesitas ser pragmático y darte cuenta que no puedes necesariamente asegurar todo, de hacer algo más que no hacer nada.

5. Diseño, desarrollo y pruebas: La última cosa que recae sobre la función de un arquitecto es el diseño, el desarrollo y las pruebas.  Ser un arquitecto práctico no significa necesariamente que te tienes que involucrar en el día a día con las tareas de codificar, pero si implica que estes contínuamente involucrado en el proyecto, ayudando activamente a darle forma y a liberarlo.  Dicho esto, ¿porque las actividades diarias de codificar no son parte de la función del arquitecto? La mayoría de los arquitectos tienen bastante experiencia, entonces tiene sentido mantener esas habilidades actualizadas.  Además, el arquitecto puede experimentar el mismo dolor que todos los demás en el equipo, que a su vez ayuda a entender mejor como es vista su arquitectura desde la perspectiva de los desarrolladores.  Muchas compañías tienen políticas que previenen a los arquitectos de escribir código porque sus arquitectos son "tan valiosos como para ejecutar este trabajo cómodo".
Claramente es una actitud incorrecta ... ¿por qué dejar que tus arquitectos pongan todo su esfuerzo en definir la arquitectura si no vas a dejar que contribuyan a su liberación exitosa? Por su puesto que hay situaciones donde no es práctico que se involucren a nivel código.  Por ejemplo, un proyecto grande generalmente significa un panorama más amplio que cuidar y puede haber ocasiones donde simplemente no tengas el tiempo.  Pero generalmente hablando, un arquitecto que codifica es más efectivo y más feliz que un arquitecto que solo mira desde un extremo.

¿Eres un arquitecto de software?

A menos de que veas la linea entre el desarrollo de software y arquitectura como mítico o un amplio abismo, los elementos arriba resaltan que los niveles de experiencia de la gente con la función de arquitectura de software varía considerablemente dependiendo de que tan comprometidos están y que tan seriamente ven su papel.  La mayoría de los desarrolladores no despiertan en un Lunes por la mañana y se declaran a sí mismos ser arquitectos de software. Ciertamente no y mi camino en la arquitectura de software fue en gran medida un proceso evolutivo.  Habiendo dicho este pensamiento, hay una alta probabilidad de que los propios desarrolladores ya estén tomando en cuenta las partes que conforman la arquitectura de software, independientemente de su título laboral.

Hay una gran diferencia entre contribuir a la arquitectura de un sistema y ser el responsable de definirla tu mismo; con una continuidad de habilidades, conocimiento y experiencia necesaria a través de las diferentes áreas que forman la función de un arquitecto. Cruzar la línea entre el desarrollador y el arquitecto es tu decisión, pero entender tu propio nivel de experiencia es el primer paso en la jornada.

SimonBrown | Codificando la arquitectura (ingles) |
 Arquitectura de sofware para desarrolladores (ingles)