En este artículo discutiremos uno de los aspectos más importantes de ser arquitecto de software, la mentalidad del arquitecto.
Si tu trabajo actual es técnico, como desarrollador o líder de equipo, entonces probablemente estés pensando en el trabajo que realizas desde el punto de vista del desarrollo de software. Pero, como verás en este artículo, este no siempre es el punto de vista más adecuado para un arquitecto. El arquitecto a menudo debe tomar una decisión basada en otros factores que a veces son ajenos a un desarrollador.
Pero, para ser un arquitecto realmente bueno, hay que adaptarse a un nuevo punto de vista, que lo convertirá en un activo real para la organización. Entonces, hablemos de esta nueva mentalidad que debe tener el arquitecto de software.
Comprende el negocio
El mayor cambio de mentalidad que debe realizar para ser un buen arquitecto es comprender el negocio en el que participa su cliente o empleador.
Ahora bien, esto puede sonar trivial. Supuestamente, todos en la organización saben lo que está haciendo la empresa, ¿verdad? Bueno, eso suele ser solo parcialmente cierto.
Estoy seguro de que todos los empleados de Microsoft saben que Microsoft desarrolla software como Windows y Office y que tiene una de las nubes públicas más grandes del mundo. También estoy seguro de que todos los empleados de Amazon saben que Amazon vende una gran selección de artículos, desde libros hasta alimentos frescos. Pero eso no es suficiente.
Déjame contarte una historia. Hace un par de años, una empresa en el campo de IoT se acercó a mí. Era una empresa de tamaño medio y contaba con unos 600 empleados en todo el mundo. Estaba familiarizado con esta empresa y sabía vagamente lo que estaban haciendo, pero no era suficiente. Entonces, agarré mi PC y comencé a leer sobre la empresa.
Al día siguiente en la reunión, para su sorpresa, pude contarles sobre los fundadores, su línea de productos, los ingresos y las ganancias y tener en cuenta que la empresa no cotizaba en bolsa en ese momento, los competidores, etc. Esto los dejó muy impresionados y acordamos trabajar juntos ese mismo día.
Pero no cuento esta historia para enseñarte tácticas de marketing, aunque es muy eficaz. La lección realmente importante aquí es que, para ser de valor para la organización, debes tener un conocimiento profundo del negocio de la organización. Tienes que saber qué mantiene despierto al CEO por la noche.
Tienes que entender cuáles son sus debilidades y fortalezas, con quién compiten y cuál es su estrategia de crecimiento. Solo después que comprendas todo esto podrás comenzar a hablar de arquitectura y tecnología.
Uno de los errores más comunes que cometen los arquitectos es que ven los sistemas en los que están trabajando como un sistema independiente aislado del resto de la organización. Pero, así no puede funcionar.
Cada organización es un organismo vivo con muchas partes móviles, y el arquitecto debe comprender cómo se integra el sistema en este organismo vivo y qué papel juega esta parte. Entonces, para recapitular, recuerda siempre comprender el negocio antes de comenzar a trabajar en la arquitectura.
Define las metas del sistema
Una vez que hemos entendido el negocio y hemos averiguado todo lo que hay que aprender sobre él, ahora observa el sistema específico en el que vamos a trabajar. Lo primero que hay que tener en cuenta son las metas del sistema. Es importante notar que no estamos hablando aquí de lo que debería hacer el sistema; esas no son metas sino requisitos y es importante distinguir unos de otros.
Cuando hablamos de metas, estamos hablando del efecto que tendrá el sistema en la organización. Este efecto puede ser casi cualquier cosa, pero debe quedar claro cómo afectará a los resultados de la organización.
La razón por la que debemos ser plenamente conscientes de los objetivos del sistema es que, como arquitectos, siempre debemos pensar en el panorama completo. Debemos saber cuál es el entorno en el que va a operar nuestro sistema y cuáles son las principales tareas que va a abordar.
Por lo general, el cliente debería decirte cuáles son las metas del sistema, pero no siempre es así. Una vez tuve un cliente que me pidió que diseñara la arquitectura de un sistema específico para él. Las especificaciones del sistema eran claras. El valor de los servicios y las pantallas ya estaban definidos, y parecía una tarea fácil. Sin embargo, cuando comenzamos a discutir el lugar del sistema en la organización, descubrimos que casi nadie iba a usar el sistema tal como está. Había muchos otros sistemas que realizaban tareas similares, aunque de una manera menos cómoda. Pero los usuarios ya estaban acostumbrados a esos sistemas y simplemente no había un incentivo lo suficientemente fuerte para que cambiaran al nuevo.
Terminamos cambiando casi todo el alcance y la funcionalidad de los sistemas, y el producto final fue un sistema mucho más pequeño, pero mucho más enfocado y efectivo.
Echemos un vistazo a algunos ejemplos:
- Nuevo sistema de RRHH para una empresa orientada al producto. El objetivo es agilizar el proceso de selección, atrayendo así mejores candidatos. Esto, por supuesto, ayudará a la empresa a crear mejores productos con mayor rapidez, aumentando así los ingresos.
- Nuevo sistema de información para reportar y mapear incidentes delictivos en la ciudad. El objetivo aquí es mejorar la respuesta policial para cada incidente y alentar a los nuevos residentes a migrar a la ciudad. Por supuesto, también hay una agenda oculta aquí. Este sistema ayudará a que el alcalde sea reelegido en las próximas elecciones.
- Aplicación móvil para ventas flash. La organización aquí es una startup pequeña y joven con solo tres desarrolladores. El objetivo aquí es doble:
- Generar el dinero lo más rápido posible y,
- Atraer inversionistas.
Trabaja para los clientes de tu cliente
Uno de los aspectos más importantes del trabajo del arquitecto es identificar quién es el cliente. Eso puede sonar un poco estúpido. ¡Por supuesto que sé quién es mi cliente! ¡Es el que me paga! Bueno, sí, pero también no. En casi todas las organizaciones, el arquitecto forma parte del departamento de TI. No importa si el arquitecto es un empleado de la organización o un consultor que trabaja con la organización. Es contratado por la gente de TI, pero la gente de TI tiene clientes y estos son los usuarios finales de la aplicación y estos son los tipos para los que debería trabajar.
¿Qué significa eso? Significa que tu mentalidad debe estar orientada hacia el cliente de tu cliente. Significa que, con cada decisión que tomes, debes preguntarte cuál será el efecto de esta decisión en el cliente de tu cliente. Significa que se prioriza la comodidad del cliente de tu cliente por sobre la comodidad de tu cliente.
Veamos un ejemplo. Uno de los sistemas recientes en los que trabajé fue un sistema que mostraba datos basados en la telemetría recibida de estaciones remotas. Uno de los dilemas que tuvimos es qué hacer cuando la base de datos durante la telemetría está fuera de línea. Este fue un escenario que tuvimos que considerar, ya que el Departamento de TI no podía comprometerse con un SLA concreto de la base de datos.
La solución que se nos ocurrió fue mostrar un mensaje claro al usuario final de que hay un problema con el sistema y pedirle que vuelva a intentarlo más tarde. Este es un comportamiento bastante común para tal escenario. Sin embargo, el cliente preguntó si podemos encontrar una solución intermedia que le permita ver los datos, pero no realizar modificaciones.
Lo pensamos detenidamente y se nos ocurrió una solución que hizo nuestra arquitectura mucho más complicada. Introdujimos una capa de almacenamiento en caché dedicada que duplicaba los datos y se utilizaba cuando la base de datos estaba fuera de línea.
Mi cliente, que era un equipo de desarrollo, trabajó mucho más duro. Pero el cliente de mi cliente, el usuario final, estaba extremadamente satisfecho con esta solución y elogió la voluntad de ayudarlo y pensar de manera innovadora.
Ahora podría decir que trabajar con el cliente es el trabajo de un analista de sistemas, no del arquitecto. Esto suele ser correcto, pero a veces un proyecto se lleva a cabo sin el analista de sistemas a bordo. E incluso si hay uno, aún es necesario comprender el entorno del cliente para poder tomar las mejores decisiones para él.
En este caso, el arquitecto no reemplaza al analista de sistemas, pero es una muy buena idea unirse con él para algunas reuniones y conocer a los clientes personalmente.
A veces, verás que tu cliente, el departamento de TI, no utiliza al cliente como cliente. Se referirán a los usuarios finales como colegas, compañeros de trabajo o incluso esos tipos molestos que siempre piden cosas. En este caso, tu trabajo puede ser un poco más difícil. Tienes que, no solo cambiar tu forma de pensar, sino también la de ellos.
Habla con las personas adecuadas en el idioma adecuado
Otro aspecto importante del trabajo del arquitecto es saber hablar con diferentes personas de la organización.
Aquí está la regla general: Ten en cuenta siempre qué es lo que realmente le importa a la persona con la que estás hablando.
Si puedes adaptarte a los mejores intereses de la persona con la que estás hablando, podrás lograr mucho más. Por cierto, esta regla es correcta no solo para los arquitectos, por supuesto, sino para cualquiera que intente lograr algo para alguien. Veamos algunos ejemplos.
El jefe de proyecto solo se preocupa por el éxito del proyecto y no le importa qué tecnología se utilizará o cuán asombrosa sea la arquitectura. Cuando hables con él sobre tus planes para la arquitectura, siempre enfatiza cómo contribuirá al éxito del proyecto.
Evitar frases como, “¡este es el último y mejor patrón y serás el primero en probarlo! Podríamos publicar un blog al respecto.” Esta frase solo lo asustará, e inmediatamente se imaginará cómo esta tecnología no probada causará retrasos y concesiones obligadas en el futuro.
En su lugar, intenta algo como, «esta nueva tecnología puede ayudarnos a escribir el código dos veces más rápido, para que podamos recortar nuestro cronograma y presupuesto acorde a esta realidad». Este es un lenguaje que un jefe de proyecto comprende, y estará más que feliz de ayudarte, asumiendo que tienes razón, por supuesto.
Ahora miremos al líder del equipo. Él es un geek incondicional y le encanta programar. Pasa al menos una hora todas las noches leyendo publicaciones de blogs técnicos y siempre está al día con los avances recientes en la industria del software.
Si deseas incorporarlo y convertirlo en un firme defensor de tu arquitectura, habla con él utilizando un lenguaje técnico. Dile, “¿Has oído hablar de la última versión de Angular? Lo vamos a utilizar”. O, “ya sabes, las funciones como servicio son geniales. ¿Qué te parece que lo vamos a probar en este proyecto? ”. Él estará más que feliz de caminar contigo cuando le hables de esta manera.
La última persona a la que miramos es la gerente general. Ella es una persona muy orientada a los negocios y siempre busca el resultado financiero. Si quieres explicarle cuáles son las ventajas de la arquitectura en la que estás trabajando, nunca menciones las palabras técnicas de moda.
Ella es el tipo de persona que cuando escucha «microservicios» o «almacenamiento en caché» o incluso «Java», inmediatamente pierde el interés y deja de escuchar. Sin embargo, si le vas a decir esto: “La arquitectura que diseñé garantizará la continuidad del negocio y podrá hacer frente a las altas cargas esperadas durante las rebajas del Black Friday”, entonces ve donde a ella. Ella te escuchará y agradecerá el trabajo que estás haciendo.
Entonces, para recapitular: Siempre ten en cuenta lo que realmente le importa a la persona con la que estás hablando. Intenta estar en sus zapatos, no en los tuyos, y luego muéstrale cómo tu trabajo contribuye a sus intereses.
Este artículo se basa en extractos del curso “La Guía Completa para Llevar a Ser un Arquitecto de Software” (“The Complete Guide to Becoming a Software Architect”) por Memi Lavi, disponible en la plataforma Udemy, un curso que recomendamos para todo arquitecto de software o profesional de las TI.