ALEXANDER VIDAL TORREZ N° de Registro: 216095689

EL MAL ENTENDIDO ROL DE ARQUITECTO DE SOFTWARE

“La presencia forzada de un arquitecto de software que obliga a

ceñir la solución a una arquitectura diseñada al principio es más
un obstáculo que un elemento positivo en el proyecto. He podido
comprobar cómo en ciertos proyectos los desarrolladores
trabajaban más y dedicaban más tiempo a meter con calzador
algo en la arquitectura establecida que en hacer software útil.”

El Libro Negro del Programador nos centramos en aquello que solemos hacer
mal como desarrolladores y en las razones por las que fracasan los proyectos
software. En esta ocasión, me temo que la presencia de un super arquitecto de
software la vamos a describir más adelante como un obstáculo que como un rol
imprescindible.

Entre los muchos errores que se cometieron, el fundamental, a mi juicio, fue de

establecer claramente una persona con el rol de arquitecto de software para
que a partir de sus decisiones de diseño y arquitectura fuese desarrollándose el
universo software que debía constituir el proyecto y el éxito común del
grupo. Nada de esto sucedió, me temo, fundamentalmente por la mala
concepción entonces de lo que debía de ser un arquitecto.

 Posee una experiencia altísima para un determinado dominio

específico. Esto es, nadie puede considerarse arquitecto de software
para cualquier tipo de proyecto. 
 Ha pasado por muchos roles en su carrera . Esto viene a significar
muchos años de experiencia con diferentes perfiles.
 Ha trabajado en productos de muy diversa y heterogénea naturaleza. 
 Quizá este tipo de decisiones las deba tomar el líder técnico, pero
poniendo los pies en el suelo y en la realidad, vemos que este tipo de
cosas las decide casi siempre una misma persona. 
 Un arquitecto de software debe además saber liderar y guiar el trabajo
de un grupo de desarrolladores. En la teoría podemos ver este rol como
el de alguien que escribe sesudos documentos, pero en la práctica, si
existe, quien posee este rol no es más que uno más de nosotros que
ALEXANDER VIDAL TORREZ N° de Registro: 216095689

toma decisiones.Además, un desarrollador de base necesita conocer las

razones para las decisiones de diseño que él mismo no ha
tomado. Nada peor que programar de un modo encajonado dentro de
una arquitectura sin conocerla suficientemente. 
 En mi opinión muy pocas personas reúnen un perfil con estas
características, entre otras cosas es incluso raro conocer a alguien que
lleve más de diez o quince años programando, dado la frívola cultura
empresarial según la cual ascender significa más bien gestionar dejando
a un lado los asuntos técnicos..., problema del que hablamos
extensamente en este libro. 
 El desarrollo de software es quizá de las profesiones que más te obligan
a reinventarte continuamente dada la enorme y rápida evolución de
tecnologías, usos, herramientas, tipos de productos, etc. Como
consecuencia de todo esto, pocos se mantienen al pie del cañón durante
muchos años. 
 Insisto en lo de la mayoría de proyectos, ya que en aquellos en los que
intervienen múltiples agentes, por ejemplo, diversas compañías con
distintas responsabilidades en el proyecto, sí es necesario establecer
ordenadamente cómo y de qué manera las diversas piezas del puzzle
van a encajar. 

Por otro lado, no hay que confundir el rol de arquitecto con el de

responsable o líder técnico, aunque en muchas ocasiones coincidan en la
misma persona. Salvo que tengas una experiencia muy pero que muy
dilatada, cuando desarrollamos software desconocemos completamente
cómo vamos a resolver ciertos aspectos de la solución hasta que realmente
el problema lo tenemos de frente y de algún modo tenemos que salir
adelante.

De aquí la necesidad de otro tipo de enfoque cuando resolvemos problemas

software. Existen tantas incertidumbres a la hora de programar algo que el
único enfoque posible es hacerlo poco a poco, paso a paso. En esto
consiste básicamente el desarrollo ágil y todas sus variantes
metodológicas. Una de las características que más me gusta de lo ágil es
ALEXANDER VIDAL TORREZ N° de Registro: 216095689

que el diseño y arquitectura del sistema van surgiendo a medida que se

avanza en el desarrollo del mismo.

Al centrarnos en el desarrollo exclusivo de una parte o funcionalidad del

sistema nos damos cuenta de que la arquitectura de la aplicación no es algo
que debe ser pensada sesudamente al principio, sino que ésta surge
espontáneamente a medida que se van implementando poco a poco los
requisitos establecidos. Cierto tipo de arquitectura elástica general como
marco de desarrollo de la solución debe ser establecida, pero para esto no
hace falta un rol tan cerrado como para ocupar al 100% el trabajo de una
persona.

La verdad es que suena mucho mejor soy arquitecto de software que soy
programador, desarrollador de software, aunque la dedicación y experiencia
del segundo supere en varios niveles a las del primero. También he visto
cómo el desarrollo ágil ha tenido dificultades de penetración en grupos de
trabajo precisamente porque con él llega la abolición de ciertos roles
consideramos, digamos, más respetables. En desarrollo ágil, la arquitectura
emerge a medida que se avanza en la solución. En cierta medida se
desvanece así el rol de arquitecto de software.

Esta idea fue en su momento tan revolucionaria que creo que sólo los que
hemos visto fracasar proyectos por un diseño erróneo o una mala
arquitectura la hemos abrazado completamente.