La línea entre el desarrollo de software y la arquitectura de software es complicada. Algunas personas te dirán que no existe y que la arquitectura es simplemente una extensión del proceso de diseño realizado por los desarrolladores. Otros se darán cuenta de que es un abismo enorme que solo pueden cruzar los desarrolladores altaneros que creen que siempre debes abstraer tus abstracciones y no quedarte estancado por esos molestos detalles de implementación. Como siempre, hay un equilibrio pragmático en algún punto intermedio, pero plantea la interesante pregunta de cómo te mueves de uno a otro.
La experiencia es un buen indicador, pero debes mirar más profundamente
Convertirse en un arquitecto de software no es algo que simplemente sucede de la noche a la mañana o con una promoción. Es un papel, no un rango. Es un proceso evolutivo donde gradualmente ganará la experiencia y la confianza que necesita para asumir el papel.
Hay varias cualidades diferentes que se pueden buscar en un arquitecto de software, y su experiencia pasada a menudo es un buen indicador de su capacidad para asumir el papel. Sin embargo, dado que el papel de un arquitecto de software es variado, debe profundizar para comprender el nivel de participación, influencia, liderazgo y responsabilidad que se ha demostrado en varias áreas diferentes. En términos generales, la arquitectura de software en la mayoría de los proyectos se puede dividir en dos fases: la arquitectura se define y luego se entrega.
Definición de la arquitectura del software
El proceso de definición de la arquitectura parece bastante sencillo. Todo lo que tienes que hacer es descubrir cuáles son los requisitos y diseñar un sistema que los satisfaga. Pero en realidad no es tan simple y el rol de la arquitectura de software puede variar enormemente dependiendo de qué tan comprometido esté y cuán seriamente vea su rol. Como se muestra en el siguiente diagrama, la parte de definición de arquitectura en el rol se puede desglosar en varios elementos diferentes:
- Gestión de requisitos no funcionales. Los proyectos de software a menudo se quedan atrapados preguntando a los usuarios qué características desean, pero rara vez les preguntan qué requisitos no funcionales (o cualidades del sistema) necesitan. A veces los interesados nos dirán que «el sistema debe ser rápido», pero eso es demasiado subjetivo. Los requisitos no funcionales deben ser específicos, medibles, alcanzables y comprobables si vamos a satisfacerlos. La mayoría de los requisitos no funcionales son de naturaleza técnica y a menudo tienen una gran influencia en la arquitectura del software. Comprender los requisitos no funcionales es una parte crucial del rol, pero hay una diferencia entre asumir cuáles son esos requisitos y desafiarlos. Después de todo, ¿cuántos sistemas has visto que realmente necesitan estar operativos 24×7?
- Definición de la arquitectura. Con los requisitos no funcionales capturados, el siguiente paso es comenzar a pensar en cómo vas a resolver los problemas establecidos por las partes interesadas y definir la arquitectura. Es justo decir que cada sistema de software tiene una arquitectura, pero no todos los sistemas de software tienen una arquitectura definida. Y ese es realmente el punto aquí. El proceso de definición de arquitectura te permite pensar cómo vas a tomar los requisitos junto con las restricciones impuestas y resolver el problema. La definición de arquitectura se trata de introducir estructura, pautas, principios y liderazgo en los aspectos técnicos de un proyecto de software. Definir la arquitectura es tu trabajo como arquitecto de software, pero hay una gran diferencia entre diseñar un sistema de software desde cero y extender uno existente.
- Selección de tecnología. La selección de tecnología suele ser un ejercicio divertido, pero tiene una serie de desafíos cuando se consideran los costos, las licencias, las relaciones con los proveedores, la estrategia tecnológica, la compatibilidad, la interoperabilidad, el soporte, la implementación, las políticas de actualización, los entornos de usuario final, etc. La suma de estos factores a menudo puede hacer que una tarea simple de elegir algo como una tecnología de cliente enriquecida sea una pesadilla completa. Y luego está la cuestión de si las tecnologías realmente funcionan. La selección de tecnología tiene que ver con la gestión del riesgo: reduciendo el riesgo donde hay alta complejidad o incertidumbre e introduciendo el riesgo donde hay beneficios para tener. Las decisiones tecnológicas deben tomarse teniendo en cuenta todos los factores, y todas las decisiones tecnológicas deben revisarse y evaluarse. Esto incluye los principales bloques de construcción para un proyecto de software hasta las bibliotecas y los frameworks que se introducen durante el desarrollo. Si estás definiendo una arquitectura, también debes estar seguro que las elecciones de tecnología que se están haciendo son las correctas. Nuevamente, hay una gran diferencia entre evaluar la tecnología para un nuevo sistema y agregar tecnología a un sistema existente.
- Evaluación de la arquitectura. Si estás diseñando software, debes preguntarte si tu arquitectura funcionará. Para mí, una arquitectura funciona si satisface los requisitos no funcionales, proporciona la base necesaria para el resto del código y proporciona una plataforma suficiente para resolver el problema comercial subyacente. Uno de los mayores problemas con el software es que es complejo y abstracto, lo que dificulta la visualización de las características de tiempo de ejecución de los diagramas UML o del código en sí. Llevamos a cabo una serie de diferentes tipos de pruebas a lo largo del ciclo de vida de desarrollo de software para darnos la confianza de que el sistema que estamos entregando funcionará cuando se implemente. Entonces, ¿por qué no hacemos lo mismo para nuestras arquitecturas? Si puedes probar su arquitectura, puedes probar que funciona. Y si puedes hacer esto lo antes posible, puedes reducir el riesgo del proyecto más que simplemente desear que ocurra lo mejor.
- Colaboración de la arquitectura. Es inusual que cualquier sistema de software viva de forma aislada y muchos tienen que entenderlo. Esto abarca desde el equipo de desarrollo inmediato que necesita comprender y aceptar la arquitectura, hasta otras partes interesadas que tienen un interés desde el punto de vista de seguridad, base de datos, operaciones, mantenimiento, soporte, etc. Para que un proyecto de software sea exitoso, debes colaborar estrechamente con todas las partes interesadas del sistema para garantizar que la arquitectura se integre con éxito con su entorno. Desafortunadamente, la colaboración de arquitectura dentro del equipo de desarrollo rara vez ocurre, y mucho menos con las partes interesadas externas.
Entrega de la arquitectura del software
Es la misma historia con la entrega de arquitectura, donde el rol de la arquitectura de software puede variar dependiendo del nivel de compromiso entre los elementos que contribuyen a un proyecto de software exitoso.
- Propiedad del panorama general. Para llevar la arquitectura a una conclusión exitosa, es importante que alguien posea el panorama general y venda la visión durante todo el ciclo de vida del desarrollo de software, evolucionando a lo largo del proyecto si es necesario y asumiendo la responsabilidad de garantizar que se entregue con éxito . Si ha definido una arquitectura, tiene sentido permanecer continuamente involucrado y evolucionar su arquitectura en lugar de elegir entregársela a un «equipo de implementación».
- Liderazgo. Tener una visión más amplia es un aspecto del liderazgo técnico, pero hay otras cosas que deben hacerse durante la fase de entrega de un proyecto de software. Estos incluyen asumir la responsabilidad, proporcionar orientación técnica, tomar decisiones técnicas y tener la autoridad para tomar esas decisiones. Como arquitecto, debes asumir el liderazgo técnico para garantizar que todo está bajo cuidado y que el equipo se dirija en la dirección correcta de forma continua. La posición del arquitecto de software es inherentemente sobre el liderazgo y, aunque esto parece obvio, muchos equipos de proyecto no obtienen el liderazgo técnico que necesitan, y los arquitectos suponen que una entrega exitosa no es necesariamente su problema.
- Orientación y tutoría. El asesoramiento y la tutoría es una actividad que se pasa por alto en la mayoría de los proyectos de desarrollo de software, ya que muchos miembros del equipo no obtienen el apoyo que necesitan. Si bien el liderazgo técnico se trata de dirigir el proyecto en su conjunto, hay momentos en que las personas necesitan asistencia. Además de esto, el entrenamiento y la tutoría proporcionan una forma de mejorar las habilidades de las personas y ayudarlas a mejorar sus propias carreras. Esto es algo que debería caer directamente dentro del ámbito del arquitecto de software, y claramente hay una gran diferencia entre entrenar a su equipo en arquitectura y diseño versus ayudarlos con sus problemas de codificación.
- Aseguramiento de la calidad. Incluso con la mejor arquitectura y liderazgo del mundo, una entrega deficiente puede hacer que fracase un proyecto exitoso. El aseguramiento de la calidad es una gran parte del papel de un arquitecto, pero es más que solo hacer revisiones de código. Por ejemplo, necesitas una línea base contra la cual asegurarte, y esto significa la introducción de estándares y prácticas de trabajo. Desde una perspectiva de desarrollo de software, estos podrían incluir estándares de codificación, principios de diseño y herramientas de análisis de código fuente hasta el uso de herramientas de integración continua, pruebas unitarias automatizadas y cobertura de código. Es seguro decir que la mayoría de los proyectos no aseguran la calidad lo suficiente y, por lo tanto, debes descubrir qué es importante y cerciorarte de que esté lo suficientemente asegurado. Para mí, las partes importantes de un proyecto son cualquier cosa que sea arquitectónicamente significativa, crítica para el negocio, compleja o altamente visible. Solo necesitas ser pragmático y darte cuenta que no necesariamente puedes asegurar todo, haciendo algo en lugar de no hacer nada.
- Diseño, desarrollo y pruebas. Lo último que cae directamente dentro del rol de un arquitecto de software es el diseño, desarrollo y prueba. Ser un arquitecto «manos a la obra» no significa necesariamente que debas involucrarte en las tareas de codificación del día a día, pero sí significa que estás continuamente involucrado en el proyecto, ayudando activamente a darle forma y entregarlo. Dicho esto, ¿por qué las actividades de codificación del día a día no deberían ser parte del papel de un arquitecto? La mayoría de los arquitectos son codificadores experimentados, por lo que tiene sentido mantener esas habilidades actualizadas. Además, el arquitecto puede experimentar el mismo dolor que todos los demás en el equipo, lo que a su vez los ayuda a comprender mejor cómo se ve su arquitectura desde una perspectiva de desarrollo. Muchas compañías tienen políticas que impiden que los arquitectos de software participen en actividades de codificación porque sus arquitectos son «demasiado valiosos para emprender ese trabajo básico». Claramente, esta es la actitud equivocada. ¿Por qué dejar que sus arquitectos hagan todo ese esfuerzo para definir la arquitectura si no van a dejar que contribuyan a su entrega exitosa? Por supuesto, hay situaciones en las que no es práctico involucrarse a nivel de código. Por ejemplo, un proyecto grande generalmente significa un «panorama general» más general que cuidar, y puede haber momentos en los que simplemente no tengas tiempo. Pero en términos generales, un arquitecto que codifica es más efectivo y más feliz que un arquitecto que observa desde el costado de la cancha.
¿Eres arquitecto de software?
Independientemente de si ves la línea entre el desarrollo de software y la arquitectura como un abismo mítico o enorme, los elementos anteriores resaltan que el nivel de experiencia de las personas en el rol de la arquitectura de software varía considerablemente dependiendo de cuán comprometidos estén y cuán seriamente vean su rol. La mayoría de los desarrolladores no se despiertan un lunes por la mañana y se declaran arquitectos de software. Ciertamente, yo no lo hice así, y mi ruta hacia la arquitectura de software fue en gran medida un proceso evolutivo. Dicho esto, sin embargo, hay una alta probabilidad de que esos mismos desarrolladores ya estén asumiendo partes de la función de arquitectura de software, independientemente de su cargo.
Hay una gran diferencia entre contribuir a la arquitectura de un sistema de software y ser responsable de definirlo tú mismo, con un continuo de habilidades, conocimiento y experiencia necesarios en las diferentes áreas que conforman el rol de la arquitectura de software. Depende de ti cruzar la línea entre el desarrollador de software y el arquitecto de software, pero comprender tu propio nivel de experiencia es la primera parte del viaje.
Sobre el Autor
Dependiendo de su punto de vista, Simon Brown es un arquitecto de software que codifica o un desarrollador de software que comprende la arquitectura. Cuando no está desarrollando software con .NET o Java, a Simon generalmente se lo puede encontrar consultando, haciendo coaching o entrenando. Simon también ha escrito libros sobre Java, presentado en eventos de la industria y ha organizado un curso de capacitación llamado Arquitectura de Software para Desarrolladores, que se basa en su escrito sobre arquitectura de software en Codificando la Arquitectura. Puedes ponerte en contacto con Simon por correo electrónico o Twitter.
Este artículo ha sido traducido desde su original en inglés, el que se encuentra en la siguiente dirección:
https://www.infoq.com/articles/brown-are-you-a-software-architect/