Mamá, de mayor quiero ser Arquitecto (de Software)

Tras unos cuantos años de experiencia como desarrollador, ya empiezas a estar contento con tu código. Cada vez se parece más a lo que llamamos "Clean Code", no concibes un desarrollo sin su correspondiente cobertura de test y haces tus pinitos con TDD, empiezas a detectar y a aplicar patrones de diseño y la algorítmica no es una palabra desconocida para ti. Sabes quién es gente como Uncle Bob, Martin Fowler y The Gang of Four no es un grupo musical para ti. Ya se te puede considerar un profesional del desarrollo.

Y es en este momento, tras tener más conocimiento de este mundillo, cuando se ha despertado en ti el gusto por temas, digamos que, con un nivel de abstracción superior. Has empezado a tener gustillo por las arquitecturas software y como el llamado "Arquitecto" de tu equipo es una persona respetada por ti, has decidido que eso es lo que quieres hacer. Quieres elevar tu discurso. Quieres ser un "Arquitecto de Software".

Como es de esperar, para poder ser algo, lo primero de todo es saber qué es eso, qué lo define, y qué conocimientos y habilidades necesitas para ser considerado así. Es lo que vamos a intentar dar aquí (o al menos una versión de tantas posibles).

Pero vamos a empezar al revés. Vamos a empezar diciendo qué no es (o qué no debería ser).

  • Un arquitecto software no es alguien que se pase el día de reunión en reunión. Su trabajo no es atender reuniones en las que, si no hay nada que discutir, lo crea.
  • Un arquitecto software no es alguien superior a un desarrollador ni a cualquier otro rol de un equipo.
  • Un arquitecto software no es alguien que se pase el día haciendo dibujitos donde muestra su dominio del diseño de software.
  • Un arquitecto software no es alguien cuyo trabajo se mida en la cantidad de documentación que genera.
  • Un arquitecto software no es alguien que fuerce al equipo de desarrollo a implementar la arquitectura que él ha diseñado.
  • Un arquitecto software no es alguien que posea la verdad absoluta, de manera que no atienda a sugerencias.
  • Un arquitecto software no es alguien que nunca desarrolle, porque ese sea trabajo de "desarrolladores mundanos"
  • Un arquitecto software no es alguien que piense que algo es mejor cuanto más complicado sea.

Estos síntomas está definiendo a alguien no tiene claro cuál es su rol en su equipo, o si lo tiene claro, no lo está aplicando correctamente.

Un buen arquitecto software se debería definir por el tipo de tareas que puede desempeñar y la habilidades que posee que le permiten desempeñarlas.

  • Conoce los patrones de diseño básicos, que serán las herramientas más potentes de las que dispondrá. De hecho, no se detiene en los básicos, sino que profundiza en los más complejos y los anti-patrones existentes.
  • Presta gran importancia a la calidad. La elaboración de sistemas mantenibles, seguros, escalables,….es algo que siempre tiene en meten.
  • Prueba y comprende diferentes stacks tecnológicos. Conoce sus ventajas y desventajas y esto seguramente no se obtenga simplemente mirando un informe o unas slides, sino que las probará. No es necesario conocer todas las tecnologías pero sí tener un conocimiento profundo de las más relevantes en su área y sobre todo, tener una base sólida sobra la que añadir diferentes contexto.
  • Analiza y comprende los patrones utilizados en distintos entornos tecnológicos, además de saber aplicar los adecuados.
  • Es curioso y busca a su alrededor oportunidades para ampliar sus conocimientos.
  • Conoce qué es importante y lo sabe diferenciar, evitando desperdiciar tiempo. Además, en función de ello sabe priorizar.
  • Conoce sus límites y no toma decisiones a la ligera sobre las que no tiene el suficiente conocimiento.
  • Evalúa múltiples opciones antes de tomar una decisión, estudiando la idoneidad de cada una en función de la situación.
  • Ataca los problemas desde diferentes puntos de vista buscando la solución más sencilla. Saber dar un paso atrás para ver los problemas desde la distancia.
  • Sabe simplificar los problemas complejos.
  • Tiene un "side project". Algo que usa para examinar nuevas tecnologías o al menos para pensar de forma distinta a lo que lo hace en su día a día.
  • No lo prueba todo. Esto simplemente es imposible, y de una manera estructurada sabe elegir qué merece la pena investigar.
  • El Clean Code es una de sus máximas y es consciente que es la mejor documentación que puede haber.
  • Cuando es posible y tiene sentido, elabora otro tipo de documentación. También sabe diferenciar cuando es posible y cuando tiene sentido.
  • Sabe comunicar sus ideas de la manera correcta, haciéndose entender.
  • Sabe adaptar su discurso a distintos interlocutores, llegando al nivel de abstracción adecuado para cada uno, siempre con el objetivo de tener discusiones fluidas donde haga llegar sus ideas.
  • Tiene conocimientos básicos sobre gestión de proyectos. Sabe balancear entre las distintas variables de la gestión de un proyecto (costes, calidad,…..) y es consciente del impacto que sus decisiones pueden tener en la vida de los proyectos.
  • Es consciente del performance de sus soluciones y trabaja con él en mente tratando de que siempre sea bueno, sabiendo cuándo se puede y/o debe sacrificar para conseguir otros objetivos.
  • Participa en la comunidad. Sabe que es una de las mejores fuentes de conocimiento y el mejor sitio donde compartir idea, así que participa en eventos, meetups,….tanto como asistente como aportando en ocasiones.
  • Es consciente del valor que aportan las certificaciones técnicas, llegando a certificarse de las que son interesantes y le aportan.
  • Tiene un ojo constante puesto sobre el sector, examinando las tendencias en base a informes, documentos o incluso blogs y publicaciones de compañeros. Probablemente él mismo aporte a estas publicaciones teniendo un blog propio o colaborando con alguno.

Conclusiones

Esta enorme lista podría ser más grande aún, pero sirve para hacerse una idea de lo que debería ser un Arquitecto Software. Sin duda todos estos puntos no se pueden puntuar con un 0 y un 1, sino que hay muchos grados de cumplimento, pero si queremos llamarnos a nosotros mismos Arquitectos, de una manera u otra deberemos tener en mente estas características.

Seguramente sólo los más capaces podrán cumplir todas estas características, pero si actuamos y tomamos decisiones con estos conceptos en la cabeza, podremos decir que estamos en el camino de convertirnos en Arquitectos de Software.

 

Guía de Posibilidades Profesionales en el Ecosistema de Java