El rol del arquitecto

Cada vez está más de moda tener un "arquitecto de software" en el sector de sistemas. Sin embargo, muchos son los que se quejan de que dicho rol es un invento, o una mera forma de hacerte creer que te ascendieron o que cambiaron tus responsabilidades.

Existen empresas donde esta realidad es cierta. Donde los arquitectos son simplemente desarrolladores con otro título. Donde en vez de darle todo el aumento de sueldo que quería esa persona, le dieron la mitad y le propusieron ascenderlo de puesto. Todo muy lindo, todo muy rico (diría un amigo) pero es cualquiera eso.

El arquitecto de verdad debe poder ver a través de una gran cantidad de aspectos en los desarrollos de software. Tiene tareas a nivel micro como a nivel macro. Por ejemplo, un arquitecto debería ser quien dictamine los estándares de calidad de la empresa a nivel código, base de datos, interfaces, etc. Sin embargo, también debe ser alguien capaz de unir dos sistemas gigantes e integrarlos para que funcionen correctamente.

Mi opinión personal es que además debe ser un programador innato, capaz en cualquier aspecto que involucre esa función:

• Código
• Conocimiento de tecnologías
• Mentalidad científica
• Capaz de depurar cualquier cosa
• Mente abierta
• Etc

Además de ser un programador, debe poseer algunas habilidades sociales. Las suficientes para interactuar con otros colegas programadores y con personal de jerarquía. Ya que un arquitecto debe poder:

• Entender qué es lo que se necesita
• Crear ideas novedosas que puedan impulsar la productividad
• Idear proyectos de desarrollo para esas ideas
• Impulsar la aprobación de dichos proyectos
• Y muchas veces, liderar los mismos

O sea que tiene que tener algunas características de líder de proyecto y de analista funcional y técnico.

¿Entonces un arquitecto es un gurú?

No necesariamente. Aunque siempre conviene que sea así. La razón es simple: El arquitecto implícitamente toma decisiones a mediano y largo plazo, que afectarán el futuro de la empresa de acá a unos 2, 5, o hasta 10 años. Incluso más.

Las propuestas y las micro y macro decisiones que tome van a enmarcar el futuro de la forma de hacer software en la empresa. Este es un punto que generalmente todos pasan de largo. La responsabilidad de un arquitecto es tal que puede llevar a la empresa al fracaso de no haber sido bien elegido o de haberse tomado malas decisiones. Y lo que es peor, no lo vas a ver venir hasta que sea tarde.

Claro que esto es un idealización de lo que debería ser un arquitecto. Un transformador interno de los sistemas de información de la empresa. En lo posible, una persona devota que no sólo estudie y se actualice constantemente, sino que también busque participar de la comunidad de investigación en software, para llevar el software cada vez a un nivel mayor.

No se trata solamente de hacer frameworks, o se dictaminar cómo deberían relacionarse unas clases. Esas serían tareas de un arquitecto junior. El arquitecto de verdad debe ver el futuro, pesar los diferentes factores y tomar decisiones. 

Decisiones bien tomadas podrían hacer que la empresa pueda iniciarse en otras tecnologías que antes no exploraba (como por ejemplo, una empresa dedicada a .NET que pueda moverse a IPHONE, por dar un ejemplo).

Y si el presupuesto y el conocimiento son suficientes, podrá desarrollar productos tan baratos y fáciles de mantener que los márgenes de ganancia serían muy importantes.

¿Ahora, cuál es el seniority de un arquitecto?

Esta pregunta me hace acordar a un aviso de computrabajo que ví hace un tiempo. Buscaban un project leader "junior". Entonces me puse a pensar... qué significa ser junior en este cargo?

¿Debe saber programar? Mínimamente, para poder estimar las tareas con precisión. Porque sino serán los desarrolladores quienes las estimen, y no él (esto no quiere decir que no pueda corroborar fechas con los dev).

¿Debe saber analizar? Totalmente. Muchas veces los requerimientos deben ser analizados por el TL al no haber un analista técnico disponible. Aún así, el TL debería tener en claro de qué vá el software a desarrollarse, y no ser una mera máquina de métricas y estimaciones.

¿Debe tener estudios? Absolutamente. No me parecería correcto que un líder de proyecto "lidere" a personal que es más capaz que el mismo. La típica frase "El que sabe, sabe, y el que no, es jefe" es tan triste y real que lo llegamos a tomar como una joda. Pero la posta es que las situaciones donde se aplican son justamente los grandes baches que una empresa debe corregir al instante. Un "jefe" o "líder" incapaz provocará grandes daños económicos imperceptibles a la empresa, por el simple hecho de que no genera ni la mitad de lo que puede generar un TL decente.

Un poco me estuve yendo de tema, y podría seguir analizando qué clase de background debería tener un TL, que si bien se fijan, no analicé ninguna de las tareas que tiene que hacer un TL.

Pero a lo que voy es que en ese aviso me imaginé "si pido más de X no me van a tener en cuenta" y simplemente concluí "gano más como desarrollador". Es evidente que si incluyeron la palabra JUNIOR en un aviso es porque quieren pagar poco. Además, conozco personas que no tienen idea de sistemas y arrancaron a trabajar de project leader DIRECTAMENTE, sin background alguno. "¿Qué es una tabla?" <--- No se sorprendan cuando les pregunten eso. De pedo conocen una tabla en excel en el mejor de los casos. Desconfíen muchísimo de gente así. No es culpa de ellos que los hayan endulzado con un cierto sueldo y responsabilidades, cargo y beneficios, cuando ellos no tenían idea de lo que se necesita para ser efectivo en ese puesto. Pero después estarán atrapados por siempre al menos que decidan estudiar por su cuenta. Ser TL y después moverse a un puesto de desarrollador Junior no es una opción.

Lo mismo ocurre con los arquitectos. No pueden ser arquitectos quieren no tienen un importante background en programación. Es evidente. ¿Qué arquitectura vas a diseñar si todavía no sabes lo que es un patrón? ¿Qué clase de decisiones vas a tomar si nunca tuviste que romper y re-armra un sistema? No señores, un arquitecto JUNIOR debe ser como mínimo un programador Senior. Y estamos hablando de unos 4 años de experiencia continuada como mínimo.

Yo tengo una idea del seniority del arquitecto que quizás no aplica a la concepción actual de muchos. Estamos acostumbrados a ver el seniority como un simple título que se gana con el tiempo. Sin embargo, tenemos desarrolladores que después de 5 años siguen siendo unos soquetes. Y después ta el pibe ese que hace un año que está y es un bocho. Sin embargo, quien es "Senior"?

Se pueden ir imaginando hacia donde voy:

• JUNIOR: Alguien que ha programado mucho pero no ha adquirido grandes conocimientos en arquitectura y desarrollo de software. No lideró equipos ni tiene demasiados conocimientos técnicos mas allá de los que ganó con su experiencia laboral. Sin embargo, DEBE ser un Senior en programación, al menos en términos temporales. El JUNIOR en Arquitectura es alguien dispuesto a aprender, y nunca puede ser el cabecilla del sector. Es decir, no puede tomar decisiones que afecten demasiado al futuro de la empresa. Es probable que en esta categoría apenas esté aprendiendo UML.
• SEMI-SENIOR: Es aquel que ya tiene muchos más conocimientos que el JUNIOR, y obviamente es SENIOR en programación. Conoce UML, conoce arquitecturas, conoce patrones, conoce tecnologías. Sin embargo, le falta aprendizaje, y probablemente, capacidad. Quizás no tenga la mente muy abierta, o no sea tan creativo como uno quisiera, por lo que sus decisiones pueden ser erradas muchas veces, debido a un mal proceso de análisis, o porque simplemente no vió las fallas básicas en sus propuestas. En mi opinión, es un recurso útil, siempre y cuando esté bajo un arquitecto SENIOR.
• SENIOR: Este es el real transformador de la empresa. El que destruye y re-construye los cimientos bajo los cuales se produce software. Es como que levante una máquina de ensamblaje diferente todos los días en una fábrica de hamburguesas. Es el que toma las decisiones y generalmente son acertadas (luego analizaremos el concepto de decisióna acertada en arquitectura). Es el cabecilla del sector de arquitectura y el que se debe encargar de resolver los problemas de sistemas. Porque sistemas resuelve los problemas de todos, pero nadie resuelve los problemas de sistemas.

Es dentro de este concepto de Arquitecto Senior que para mí se encuentra la verdadera utilidad del rol del arquitecto. Conozco sólo 2 arquitectos de este calibre. Uno es un ingeniero que se nota que sabe, y el otro es un magíster que rediseño muchísimas cosas a nivel sistemas en una multinacional monstruosa. Mas allá de que las cosas que hizo no fueran lanzar un cohete a la luna, el apoyo a la propuesta y la implementación que logro son dignas de notar.

Es decir, que esta clase de Arq Senior son pesos pesados. Y obviamente, ¿a quién vas a dejar que tome las riendas de cómo se hace el software en tu empresa? A un peso pesado! Uno capaz de hacerse cargo de tremenda tarea.

Lamentablemente este no es el concepto de SENIOR que se maneja hoy en día. Pero esta consideración es más para las empresas que para los empleados. Para que analicen si lo que realmente quieren es un arquitecto, y si lo quieren, entonces que estén dispuestos a encontrar un "Senior" de verdad.

Esto no indica que los Junior y SemiSenior (según mi concepción) no sean útiles, pero no son suficientes.

Finalmente, para ir cerrando. 

¿Qué es una decisión acertada en arquitectura de software?

Desde mi propio punto de vista, una decisión acertada puede ser de diferente índole. La primera que nos vamos a encontrar, que creo que es la más común, es aquella decisión que es una mejora aceptable o incluso considerable sobre un esquema de trabajo actual.

Es decir, una decisión que permite al esquema evolucionar en el sentido necesario para que la arquitectura pueda seguir evolucionando más adelante. Por dar un ejemplo bobo, pasar de no tener capas de aplicación a tener UI, negocio y datos, es una mejora notable y acertada. Algo considerablemente acertado sería cambiar el framework actual de base de datos que no tiene soporte para nada excepto SQL SERVER  a un framework que soporte cualquier tipo de base de datos, y sólo requiera que se desarrolle algún que otro componente para hacerlo compatible con ORACLE, DB2, etc.

Pero esas decisiones acertadas son las más simples. Son transformadoras a nivel micro ya que cambian nuestra forma de programar y producir software, pero no cambian radicalmente el modo en que opera la empresa.

Pensemos ahora qué pasaría si mis decisiones permiten a la empresa aumentar en un 300% la productividad, aligerando la carga de trabajo de todos los desarrolladores, pudiendo dentro de unos pocos meses poder estar con viento a favor en las fechas de entrega en vez de estar siempre atrasados. Esa "magia" que logró el arquitecto (que podría ser con un framework empresarial potente, bien diseñado, y con capacitaciones eficaces a los programadores) podría realmente transformar la realidad de la empresa. Quizás ahora se puede aceptar más trabajo sin reclutar recursos adicionales. Este tipo de decisión acertada "que tiende a macro" es transformadora, pero no abrió ningún mercado nuevo. Como mucho puede llevar a la empresa a otro nivel económico, pero es sólo una inyección de evolución. Este es otro tipo de decisión acertada, que grotescamente llamada inyección evolutiva, o podríamos llamar como transformadora de la productividad.

Ahora que pasaría si gracias a nuestras decisiones la empresa puede competir con grandes gigantes como IBM, Microsoft, Apple, etc? Sigue siendo una transformadora de productividad, pero de tal nivel que el cambio es muy "sarpado", a falta de mejor palabra. Transforma tu empresa mediana en un conglomerado y temido competidor. Pero no deja de ser el mismo tipo de decisión.

Ahora, podríamos llegar a decidir hacer un framework para una tecnología que no conocemos. Imaginemos que somos expertos en .NET y decidimos ampliar nuestros conocimientos para desarrollar en IPHONE, IPAD, etc. Necesitaríamos investigación, tiempo, presupuesto, personal, y mucho brainstorming. Pruebas de concepto, pruebas de todo tipo, proyectos piloto, etc. Pero a la larga, si nuestras decisiones fueron correctas, hemos transformado a la empresa y ampliado el mercado en el cual puede participar. Nuestras decisiones aquí fueron posibilitadoras de un cambio muy importante. Tiene su nombre en la teoría de sistemas de información, pero ya me olvidé cual es. Vamos a llamarle por ahora decisión de expansión de mercado.

Es parecido, aunque no es lo mismo, hacer todo eso pero para MOVERSE de mercado, y no ampliarse. Abandonar .NET en este ejemplo. Eso sería una decisión transformadora de dirección.

Ahora, ¿cuándo es acertada la decisión y cuando no?

Pues cuando te vá bien chamaco. Y eso se vé cuando lo notas tanto en los empleados, en la empresa, y en los clientes y proveedores.

Hay más tipos de decisión que creo que existen, como las transformadoras de proceso (cambiar la forma en la que se gestiona), transformadoras de mentalidad, etc. Pero el post ya me ha quedado larguísimo y yo tengo que volver a trabajar!

Después de tanto tiempo inactivo al menos les dejo con un buen super post. Y me viene bien hacer este brainstorming para "idealizar" qué es un arquitecto de software, cargo que empiezo a cubrir desde hoy.