Table of Contents
A pesar de que no haya un servicio informal y compartida de lo que es el servicio de la arquitectura de software, por ejemplo en Wikipedia, me sigue inspirando la comparación con la arquitectura de construcciones. En el sentido de que se suele pensar en la responsabilidad de un arquitecto de construcciones como la de tener la visión de la construcción, definir la disciplina (andamios, plan de construcción y la manera de transmitir la visión) con la que se va a construir el servicio. Y hoy me gustaría hablar sobre la importancia o papel de un arquitecto de software.
Principales responsabilidades de un arquitecto de software
Hablamos ahora de los planos por ejemplo, en el software hay una comparación y tiene exactamente las mismas responsabilidades. Por ejemplo:
- La responsabilidad de ser el “guardián de la visión”, en el sentido de que tiene que tener en todo momento la visión técnica, dirección técnica en la que atender al sistema en base al matching con los requerimientos del sistema.
- Por otro lado, tiene que saber/conocer la disciplina con la que se va a construir el sistema, por ejemplo entorno de desarrollo o las estimaciones o la parte de DevOps e incluso la metodología de base (DDD, Integración Contínua… todas las prácticas cotidianas)
- Capacidad de transmitir este conocimiento, tanto la visión como la disciplina.
Importancia de seguir documentando
Sigo pensando, a pesar de llevar muchos años en el Agile y en el Extreme Programming que hay una parte de documentación que sigue siendo muy importante. Por lo tanto, creo que el arquitecto de software, entre otras cosas, ha de seguir generando la documentación necesaria a transmitir la visión del sistema, aparte de ser miembro del equipo, facilitar las decisiones técnicas y un poquito ser el formador del equipo.
Necesidad de tener un arquitecto de software
Considero que en línea general las decisiones de arquitectura son muy frágiles (críticas), en el sentido de que una decisión equivocada puede generar errores de mucho coste en el ámbito de la construcción de software. Opinión basada en mi experiencia.
Estamos hablando de que puede perfectamente cambiarte una semana de desarrollo a dos años. Tampoco de puede pretender que todas las decisiones de arquitectura de tomen bien, pero un arquitecto con experiencia tomará bien el 90% de las decisiones y ahorrará mucho dinero y desgaste al equipo.
Sobre la puntualización sobre lo que es la diferencia de lo que es el punto de vista de un arquitecto de software y un programador. Considero que un arquitecto de software es un desarrollador, no puede ser otra cosa. Un arquitecto de software no debería dejar el contacto o bien con el código o bien con otros recursos de infraestructura/sistemas. Pero con temas operativos, parte del oficio del arquitecto de software es ser parte del equipo.
La diferencia entre un arquitecto de software y un desarrollador
Arquitecto de software – antes de ser un título, es más bien una manera de pensar según la cual el arquitecto piensa de forma matemática o llamemoslo criterio racional sobre un conjunto de decisiones que son masivas.
Un desarrollador– Este puede permitirse tomar una decisión específica de un momento específico. El arquitecto de software cuando tome esta decisión piensa en esa decisión tomada y implementada 10 mil veces y el coste que puede tener eso.
Una parte importante de este tipo de decisiones masivas es la componentización de software, a nivel macro incluso. Es decir, cómo se compone el sistema. El problema es, como comentaba antes, “arquitecto de software” es un estado mental, una forma de pensar, no es un diploma.
Suscríbete a nuestro newsletter para estar al día de los eventos, meet ups y demás artículos!
