Aprovecho una publicación que vi en estos días en linkedIn y en la que participe con un comentario, para hacer mi publicación de este mes, en donde les daré un poco de mi visión sobre los roles de arquitectos de software, de soluciones y empresarial, términos altamente usados, y en mi forma de pensar, muy mal usado últimamente.
1. ¿Qué es un arquitecto empresarial?: Elijo empezar por este, pues es tal vez el rol en que mas me he especializado en mis últimos años laborales. Es un perfil difícil de explicar y creo que se convirtió en una visión de “subir de nivel” de muchos arquitectos y por eso mismo muchos empezaron a auto-proclamarse en este nuevo concepto de “moda”.
La arquitectura empresarial en mi opinión es un método, una forma en la que las organizaciones pueden orientar todos sus esfuerzos en un objetivo común o arquitectura “to Be”. Pongamos un ejemplo: La empresa ACME esta pensando en que es momento de digitalizar algunos de sus servicios hacia el cliente final y para esto tiene distintos proyectos en una lista entregada por un consultor, debe implementar un sitio web transaccional, una aplicación móvil, automatizar algunos procesos usando un bpm, debe realizar un proyecto de transformación cultural para que exista una nueva cultura digital en la empresa y al final como objetivo debe vender mas y crecer en clientes explotando estos nuevos canales. ¿Por dónde empezaría usted? ¿Cómo organizaría los proyectos? ¿Cómo mediría el logro de los objetivos planteados?
Arquitectura Empresarial ha sido un método que personalmente he usado durante los últimos años para darle forma este tipo de ejercicios corporativos que van más allá de administrar proyectos, y que tocan definitivamente aristas de procesos, personas y tecnología. Un buen arquitecto empresarial tendrá entonces la capacidad de diagramar y explicar la situación actual de los elementos que serán impactados por estos cambios en términos de software/hardware, pero también en términos de procesos de negocio y personas. Debe también construir un estado futuro o “to-be” basado en los proyectos a ejecutar y en la visión a largo plazo (en este momento puede identificar otro grupo de proyectos que no se habían identificado antes) y para esto se usa el change management y la fase de oportunidades y soluciones si es que el arquitecto aplica un framework como TOGAF.
Posteriormente, con estados actuales y futuros, puede identificar transiciones y estas pueden priorizarse según por ejemplo el valor generado, o hacer lo más rápido primero (quick wins), eso depende de cada empresa y cada arquitecto, pero al final, plantea un mapa de transiciones que permiten visualizar como va avanzando la organización hacia los objetivos señalados. Es un constructor de ruta en esa fase, que permite además validad constantemente el alineamiento de los objetivos con lo que se esta trabajando y con la visión de la empresa. Es además siempre un evangelizador de los procesos de transición de las empresas, un mediador, por esta razón en muchos casos es un perfil optimo para procesos de transformación digital entre otros rubros.
Debe el arquitecto empresarial saber programar, pienso que siendo purista no, no es necesario ni es su rol. No simplemente por ser un buen programador te haces arquitecto de software, ni por ser arquitecto de software un buen arquitecto de soluciones, ni por ser un buen arquitecto de soluciones entonces eres un buen arquitecto empresarial, no es una escala de ascenso son roles diferentes.
Ahora, programar es siempre una gran ventaja competitiva, porque más allá de saber escribir líneas de código, asegura tu capacidad mental estructurada para solventar problemas y organizar soluciones, una cualidad clave para cualquier arquitectura y para cualquier profesión, por lo que saberlo siempre es un plus, pero no es el rol necesario ni un conocimiento que un AE deba dominar.
2. ¿Qué es un arquitecto de soluciones?: Yo siempre he visto a los arquitectos de soluciones como unos traductores de necesidades, pues son capaces de saber de todo, comprender los conocimientos técnicos necesarios, pero también entender las necesidades de negocio. Es un rol que debe tener conocimientos técnicos, pero no necesariamente de programación pues no todos los problemas se solucionan programando. Por lo que debe conocer el contexto técnico de la solución que esta planteando, si la solución es software, pues si, debe saber mucho de programación, de infraestructura, de la nube, de un método de trabajo con devops, de una aplicación de agile, entre otras cosas. Se encarga entonces de mapear la solución end-to-end de un problema. Volvamos a nuestra empresa ACME, ahora que ya tenemos la arquitectura empresarial del punto uno, debemos definir técnicamente por ejemplo con un arquitecto de soluciones, como nos aseguraremos de que la primera transición de la vista de aplicaciones se concrete de una forma adecuada. Si por ejemplo esta empresa como parte de su primera transición identifica la necesidad de construir una aplicación móvil, este arquitecto debe asegurar el diseño de este componente dentro de los componentes ya existentes y de validar que pueda convivir de manera adecuada, que se consideren todas las implicaciones, que se considere el contexto de infraestructura de la empresa, y sobre todo que, si solucione el problema (de acá su nombre), entre otros. Es el que se asegura que esos nuevos componentes encajen en lo existente, y que la armonía y funcionamiento esperado se alcancen.
3. ¿Qué es el arquitecto de software?: Lo primero y mas importante para mi es diferenciar este rol del rol de líder técnico, porque un líder es justamente eso, quien lidera, y honestamente no todos los arquitectos de software son los mejores líderes. Para aclarar esta definición, creo que los vendedores de software la tienen clara, siempre que te visitan llegan con su vendedor del área de ventas lógicamente, y con su arquitecto de software, que es el apoyo técnico que esta para contestar tus preguntas más específicas. Y es que le arquitecto de software debe dominar un producto(s) técnicamente. Debe dominar además su diseño técnico, los patrones de arquitectura usados, como se despliega de manera optima en la infraestructura y obviamente debe ser un maravilloso programador, y dominar todas las aristas tecnológicas de su(s) aplicaciones, desde la capa de datos hasta la capa de presentación. Es por lo tanto posible que el arquitecto de software programe y considero que definitivamente debe saber hacerlo, de lo contrario va a dar opiniones y diseñar sin fundamentos. Ahora, nuestra empresa ACME identifica como uno de los proyectos para esta transición la necesidad de una aplicación móvil como mencione en el punto 2, el arquitecto de soluciones ya construyo un mapa general y encajo esta nueva pieza, pero ahora debemos hacer un zoom a esa nueva pieza y definir cómo será construida. Este es el rol en donde el arquitecto de software brilla, puede que no sea el líder del equipo porque en ACME se ha implementado un modelo de trabajo usando SCRUM como guía, por lo que el SCRUM MASTER esta liderando al equipo, pero el arquitecto de software tiene un papel fundamental en el equipo pues es quien construirá los planos de la aplicación móvil, y seguramente intervendrá en el proceso de desarrollo. No necesariamente es el MEJOR de todos programando, eso es otro concepto erróneo, pero si es una persona con unas capacidades técnicas sobresalientes y de convencimiento de equipo, pues, si su diseño no convence a los programadores, todos sabemos que ellos terminaran haciéndolo como lo consideren adecuado, todos, todos los ingenieros en sistemas somos tercos y arrogantes.
Una vez me preguntaron si un arquitecto puede hacer los tres roles, yo considero que sí, depende el tamaño de la empresa y del proceso, porque créanme cada una de estas cosas son grandes cantidades de trabajo si quieren hacerse bien y de verdad. También alguien me dijo si ser arquitecto de soluciones era “mas” que ser arquitecto de software, en mi visión no, simplemente son cosas diferentes.
Seguramente muchos no estarán del todo de acuerdo con esta publicación, la arquitectura sobre todo en tecnología ha sido una discusión de alcances, por lo que al final cada quien lo interpreta y lo ajusta a sus necesidades, lo importante es saber que todos estos roles son fundamentales para llevar a cabo procesos de construcción de tecnología y transformaciones de todo tipo en las organizaciones, es como ya lo dije en una entrada pasada, la diferencia entre comprar tecnologías porque si, a tener un real road map de transformación, un conjunto de roles que de ser ejercidos por las personas correctas con las habilidades adecuadas, aseguran que usted tenga un mapa adecuado y ordenado, unas inversiones que en realidad solucionen sus problemas y en caso de requerirse software, tener la certeza de la calidad de su diseño y durabilidad en el tiempo.