No
necesitamos arquitectos.
Claro
que NO. Somos un equipo de desarrolladores competentes, todos muy
capaces, genios comprobados y mal apreciados, somos la crema y nata
de la tecnología, los ases de la codificación, los reyes de los
lenguajes y las tecnologías. NO. Nosotros no necesitamos ningún dinosaurio con pretensiones de Anciano de la Matrix que venga a
decirnos lo que Nosotros, amos y señores, ya sabemos. Los
arquitectos son para equipos de retardado y cuasi idiotas.
Y….
este, mis queridos lectores, es el modo de pensar de muchos equipos
de desarrollo en la actualidad.
Como
dijo un querido amigo, llenos de concreciones y nada de
abstracciones.
Pero, adentrándonos en el tema, primero necesitamos resolver algo, ¿cual
es el rol del arquitecto de software en un equipo de desarrollo?
Muchos
piensan que el arquitecto es el responsable de definir los
componentes estructurales y comunicacionales de un proyecto de
software. Y eso es verdad. Pero es baladí por ser una obviedad. En
palabras del Dr Lecter “eso es Incidental”.
Otros
ven al arquitecto como la versión técnico funcional del Jefe de
Proyectos. Algo así como el hombre del látigo, el negrero que en el
buque de esclavos marcaba el ritmo a golpes de tambor. Un tirano cuyo
trabajo es imponer sus designios y “mariquismos” detallistas a
los genios y esclavizados desarrolladores.
Digamos
que esto, en cierta medida, es también verdad, pero sólo en parte.
Es parte de las tareas del arquitecto el dirigir algunos aspectos técnicos del proyecto, pero, nuevamente, ese no es el rol central del
arquitecto.
Y
están los que ven al arquitecto como un Dios del Olimpo,
inalcanzable en su mundo de Patrones y estructuras, un ser supremo
que, de vez en cuando, se digna a bajar a la tierra y brindar un poco
de luz a los parias y demás humanos, quienes deberán obedecer y
celebrar ese maravilloso día de epifanía.
No haré comentarios respecto a esto último por ser absolutamente
Verdad!! jajajajajaja, bromeo.
Pero
no, tampoco ese es el rol principal de dios, digo, perdón, del
arquitecto.
Amigos,
el arquitecto es el responsable de la CALIDAD.
Si
el arquitecto toma decisiones pobres, la calidad del proyecto será
pobre.
Si
el arquitecto toma decisiones adecuadas, la calidad del proyecto será
elevada.
Cómo
delegue o implemente el arquitecto esa responsabilidad sobre la
calidad puede variar, y de hecho lo hace, y mucho. Quizá use la
integración continua, patrones de diseño, anti-patrones, pruebas
funcionales, pruebas de integración, pruebas automáticas,, pruebas
de calidad estática, esquemas de comunicación, esquemas de capas, políticas de seguridad, esquemas de gestión, virtualización,
paralelización, criptografía, y un largo etcétera.
Pero,
al fin y al cabo, la calidad de un proyecto de software es
responsabilidad directa del arquitecto. Ese es su rol principal.
Y
entonces, ¿necesitamos arquitectos?
Claro
que Yes.
Y
por una simple razón.
Porque
necesitamos a quien echarle la culpa. Sobre todo cuando las cosas
van mal. Y es allí cuando contar con un arquitecto es una gran
ventaja!!! jajajjaja.
Suena
a chiste, pero es verdad.
Un
arquitecto debe hacerse responsable de sus decisiones. De la calidad
del proyecto. De la calidad de código. De la calidad funcional y
operativa. De toda la calidad. Y sea buena o mala El es el
responsable de eso.
Si
su arquitecto no toma buenas decisiones, CÁMBIELO.
Pero
consiga otro mejor.
A
arquitecto muerto, arquitecto puesto.
"El primer matrix que diseñé era casi perfecto, una obra de arte. Preciso. Sublime. Un éxito solo equiparable a su monumental… fallo."
ResponderEliminar-Como mi primer gran sistema!!!! jajajajaja