10 aspectos a considerar si te interesa la arquitectura de software

Hace mucho que esta idea ronda por mi cabeza:

¿Qué necesito para ser un arquitecto?

Creo que es la consecuencia de tantas conversaciones con mis amigos o conocidos en eventos de tecnología.

Por mi parte –como apreciación personal– les comparto que he tenido la suerte de haber trabajado como arquitecto en más de un proyecto de tecnología y que este tipo de experiencias me ha ayudado a diferenciar entre las funciones que debería realizar un arquitecto y encontrarme con algunos malosentendidos a consecuencia del rol.

Consecuencias de una mala arquitectura
[Code Complete, Steve McConnell, 2004]

Con “malentendidos” me refiero a que me he topado con frases como “nuestro proyecto no necesita un arquitecto” o “ese rol no debería existir” o “los arquitectos no saben programar”, y la verdad es que, así como hay buenos profesionales, también los hay de aquellos que no saben hacer bien su trabajo y que por lo general son los responsables de muchos inconvenientes.

Lo bueno de estas experiencias es que –casi siempre– logramos conseguir –gracias a la apertura del equipo con el que estaba– que el trabajo se pueda realizar de manera exitosa.

En fin, desde mi perspectiva, creo que cada rol existe gracias a una necesidad en particular y de ser así, debería cumplir con algunos criterios fundamentales. El rol del arquitecto no es una excepción, así que he preparado algunos aspectos que me gustaría compartir con ustedes:

1. Saber programar: No hay que ser un experto en programación pero es importante contar con la experiencia suficiente para entender el código del equipo de trabajo, hablar su idioma y claro, participar en los code review.

2. Enseñar con el ejemplo: Si bien es cierto este es un criterio básico de liderazgo, aquí se debe reforzar a nivel técnico, pues todo diseño o presentación debe ir acompañado con código de ejemplo. Sí, con esto me refiero a “la demo” y claro está, no tiene que ser algo completamente funcional pero debe demostrar la factibilidad de nuestra propuesta.

3. Conceptualizar: Esta capacidad será complicada de adquirir si creemos que un arquitecto tiene que ser un programador con mucha experiencia. La clave para acortar el camino, es dejar dejar de pensar en líneas de programación para hacerle un espacio a los componentes y sus tipos de integración.

4. Ser estratégico: Lo “fácil” de esto, es diseñar soluciones flexibles (fáciles de modificar o extender). Lo complicado viene cuando olvidamos los objetivos del negocio y sus respectivas restricciones. Esto implica que tengamos la facilidad de conversar tanto técnicamente, como en términos del giro del negocio. Luego de superar esta barrera, debemos proyectar lo que podría ocurrir en el futuro.

5. Presentar efectivamente: Como regla general, toda propuesta de arquitectura debe ser concreta, de fácil entendimiento y claro, con una “demo” que evidencie la factibilidad de nuestro trabajo. Esto pasa a segundo plano cuando tenemos que enfocarnos en ser concretos y convincentes al momento de explicar nuestras ideas.

6. Ser humilde: Debemos eliminar cualquier tipo de barrera a consecuencia del “poder que llevas por tener este rol”. Una forma de acortar distancias es dejar el ego a un lado para escuchar sugerencias, aceptar nuestros errores y si se da el caso, pedir disculpas de la única forma en la que se deberían pedir, con honestidad y sin condiciones.

7. Estudiar y poner en práctica: Además de reforzar nuestros soft skills, necesitamos entender la importancia de la [construcción de software], la [programación orientada a objetos], los beneficios del [código limpio], comprender los [patrones de diseño], averiguar sobre los [tipos de arquitectura] que existen en el mercado, las [nuevas tendencias de arquitectura] y claro, debemos [programar] en nuestros ratos libres.

8. Leer: Los líbros técnicos tienen que ser algo normal en nuestras vidas, pero también debemos incluir cualquier otro tipo de lecturas. El tópico queda a nuestra elección.

9. Preguntarnos ¿qué más podríamos hacer? Esto aplica al diseño en el que estamos trabajando, pero tiene más sentido cuando lo revisamos en nuestra vida profesional (pues lo natural es que evolucionemos a arquitectos empresariales) y ¿por qué no? también deberíanos hacernos la pregunta a nivel personal.

10. Sentido común: Yo creo que esto es algo que se puede entrenar y que podría tomar más tiempo del que pensamos, no por algo dicen que termina siendo “el menos común de los sentidos”. Pero no nos desanimemos, tomemos un momento para respirar y revisar si estamos construyendo un [homeromóvil] cuando lo que realmente necesitamos es algo tan simple como un skate.

Desde un punto de vista netamente personal, creo que cada aspecto tiene muchos requisitos y restricciones que se deben ir superando en el camino y si llega el momento en el que te das cuenta de que no te estás divirtiendo, pues es posible que tengas revisar otra vez si te gusta lo que estás buscando, o mejor aún, no presionarte pues nadie es perfecto y menos, un excelente arquitecto.

Un abrazo, JD

2 thoughts on “10 aspectos a considerar si te interesa la arquitectura de software”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.