Arquitectura de software

Para empezar, quiero citar al ingeniero de software Martin Fowler en su obra Patterns of Enterprise Application Architecture (2003), cap. Architecture, pág. 29:

La industria del software se deleita en tomar palabras y estirarlas en una miríada de significados sutilmente contradictorios. Uno de los mayores afectados es “arquitectura”. Tiendo a ver “arquitectura” como una de esas palabras impresionantes, utilizadas principalmente para indicar que estamos hablando de algo importante. Pero soy lo suficientemente pragmático como para no dejar que mi cinismo obstaculice la atracción de personas hacia mi libro. :-)

“Arquitectura” es un término que muchas personas intentan definir, con poco acuerdo. Hay dos elementos comunes: uno es la descomposición de más alto nivel de un sistema en sus partes; el otro, decisiones que son difíciles de cambiar. También se está comprendiendo cada vez más que no hay una única manera de establecer la arquitectura de un sistema; más bien, hay múltiples arquitecturas en un sistema, y la percepción de lo que es significativo arquitectónicamente es algo que puede cambiar a lo largo de la vida de un sistema.

De vez en cuando, Ralph Johnson hace una publicación verdaderamente notable en una lista de correo, y lo hizo sobre arquitectura justo cuando estaba terminando el borrador de este libro. En esta publicación, señaló que la arquitectura es algo subjetivo, un entendimiento compartido del diseño de un sistema por parte de los desarrolladores expertos en un proyecto. Comúnmente, este entendimiento compartido se presenta en forma de los componentes principales del sistema y cómo interactúan. También se trata de decisiones, en el sentido de que son las decisiones que los desarrolladores desearían haber tomado correctamente desde el principio porque se perciben como difíciles de cambiar. La subjetividad también entra en juego aquí, porque si descubres que algo es más fácil de cambiar de lo que pensabas, entonces ya no es arquitectónico. Al final, la arquitectura se reduce a las cosas importantes, sea lo que sea eso.

Entonces, un arquitecto de software puede tomar decisiones que involucren a un sistema en más de un nivel sin comprometer la integridad del mismo.

Responsabilidades

Las responsabilidades que tiene un arquitecto de software se presentan así normalmente:

• Planeamiento de requerimientos
• Prototipado
• Uso de estándares de software
• Documentación de la arquitectura (frameworks, componentes y librerías, por el vicio del lenguaje, a utilizar)
• Posdesarrolllo (involucramiento en las etapas del ciclo de vida del software)

Habilidades duras

Un arquitecto de software requiere un amplio conocimiento técnico, incluyendo comprensión de varios lenguajes de programación, marcos de trabajo, y patrones de software. También necesita habilidades sólidas de codificación para liderar equipos de desarrollo, evaluando la calidad del código y comunicando tareas de manera clara. Además, es crucial que tengan conocimientos sobre tecnologías en la nube para seleccionar y aplicar las herramientas adecuadas. Comprender el dominio específico del negocio es esencial para resolver problemas de manera efectiva y comunicarse eficazmente con la alta dirección (seniors, principales, managers, el CTO)

Habilidades blandas

- Dado que los arquitectos de software orientan a los equipos técnicos y promueven estándares de calidad y una visión de producto adecuada, deben poder ganar autoridad y respeto.

- Un arquitecto se comunica con partes interesadas, analistas de negocios e ingenieros, explicando los beneficios de emplear ciertas tecnologías o aplicar un patrón específico. Deben poder explicar asuntos complejos de manera simple.

- Un arquitecto de software gestiona el diseño del sistema y debería poder identificar riesgos de manera oportuna, aplicando su conocimiento, experiencia y habilidades para encontrar la mejor solución.

- Un producto de software exitoso logra mucho con recursos mínimos. Un arquitecto de software debe saber cómo priorizar tareas y organizar su equipo para un trabajo eficiente.

- Los arquitectos de software participan en reuniones con clientes, colaboran con equipos y tienen discusiones con la alta dirección. Para manejar un horario ocupado, deben ser organizados.

- Un arquitecto guía a los equipos hacia el objetivo a través de obstáculos. Deben pensar de manera creativa para proponer alternativas y resolver problemas rápidamente.

Maryna Medushevska, Julio 20 de 2022, ¿Qué hace un arquitecto de software? Rol, habilidades y responsabilidades

Camino para convertirse en uno

Como muchos otros puestos, el arquitecto de software es uno dependiendo al rubro al que se dirige. Para evitar respuestas abstractas, aquí hay un gráfico denominado “Roadmap” que contiene los diversos caminos que existen para trabajar en esta posición de trabajo. De paso, también está mucho contenido de este post. Cabe aclarar que casi siempre un arquitecto de software es arquitecto después de tener experiencia como desarrollador o ingeniero de software.

https://roadmap.sh/software-architect

Aquí hay algunos consejos que provienen de Matt Shealy de RedHat:

Si quieres convertirte en arquitecto de software, aquí hay algunas acciones clave que debes tomar:

1. Amplía tus habilidades técnicas, aprendiendo múltiples lenguajes de programación.
2. Toma más responsabilidades en proyectos y lidera equipos si es posible.
3. Busca un mentor en el campo de la arquitectura de software para recibir orientación.
4. Continúa tu educación con entrenamiento externo y busca certificaciones relevantes.
5. Aprovecha las oportunidades dentro de tu organización actual para demostrar tu interés y capacidad para el rol de arquitecto de software.