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.
No hay comentarios.:
Publicar un comentario