7 Arquitectura de soluciones
7.1 Que es arquitectura
Uno de los libros que tenemos como literatura fija en el curriculum de la ixpantia Academy es “The architecture elevator de Gregory Hohpe. Uno de los puntos que Hohpe resalta es el hecho de que un buen arquitecto tecnico se caracteriza por su capacidad de comunicar sobre cosas complejas. Esto no se puede hacer solamente con palabras, porque con palabras cada persona se imagina su propia figura en su cabeza. Estas diferencias en interpretaciones son las que un arquirecto busca anticipar y evitar.
Porque de nada sirve que todos nos imaginemos una casa con 4 paredes y un techo, cuando la mitad del equipo empieza a reunior las herramientas y materiales para un techo de paja, la otra mitada para un techo de zinc. Si recien se dan cuenta de la diferencia cuando terminamos de levantar las paredes ya tenemos un gasto de dinero y esfuerzo grande, que no se puede recuperar.
Seguramente te puedes recordar casos en el contexto donde estás donde es fenomeno se dió, y puedes darle otro nombre a techo, paja y zinc para reflejar lo que viste. Es muy común, y se hace aún más dificil cuando hay que satisfacer la expectativas de una gerencia que quizas quiere “movernos a un mundo AI” o “simplemente subirlo a la nube”. Traducir esas expectativas a algo que se puede ejecutar y da soluciones que añaden valor al negocio, que se pueden mantener y escalar y que dejan el camino abierto para evolución y mejora continua es al gran reto que tiene un arquitecto.
7.2 Quien puede ser arquitecto
Si tienes una idea y le dedicas tiempo a buscar como se podria implementar y llevar a que funcione en el negocio ya esta haciendo algo de arquitectura. Y si sigues practicando esto y añades cada vez más profundidad y experiencia técnica de poco en poco te conviertes en un arquitecto de productos de datos en forma. Buenos arquitectos no necesariamente tienen una formación técnica, a veces vienen de otras area de conocimiento y llegaron a lo que son iterando sobre su deseo de implementar soluciones.
En nuestr opinion lo más importante es el deseo de querer experimentar y buscar soluciones que no son immediatamente obvias. Tipicamente el equipo de TI esta entre el public meta que hay que convencer para hacer algo de una forma nueva, que no se ha acostumbrado hacer hasta el momento.
Hemos visto en la practica que una buena forma de comunicar sobre arquitura es a travez de documentación. Hoy en dia el arquitecto no solamente tiene como publico humanos, pero tambien agentes genAI que interpretan lo que esta escrito. Como genAI es fundamentalmente asociativo, se vuelve aun más importante se explicito sobre lo que estamos construyendo y porque. Y se hace importante documentar el alcance de lo que estamos haciendo. Un LLM siempre parte de un punto totalmente generico sin contexto de nuestra organizacion, clientes o forma de trabajar. Esto a diferencia de un colega que ya entra con expectativas y conocimiento de las mejores practicas que se han implementado.
En organizaciones pequeñas a veces no hay un tamaño del equipo lo suficientemente grande para tener un arquitecto dedicado. En estos casos, el rol de arquitecto puede ser compartido entre varios miembros del equipo, cada uno con responsabilidades específicas. Por ejemplo, un ingeniero puede ser responsable de la arquitectura de la base de datos, mientras que otro puede ser responsable de la arquitectura de la interfaz de usuario.
Lo importante es que el resultado se documente de manera clara y concisa, asegurando que todos los involucrados puedan entender y seguir las decisiones tomadas.
7.3 Que es lo minimo requerido de una arquitectura
Aun cuando todos los roles de una organización grande existen, un arquitecto de infraestructura, un equipo de Software Reliability Engineering (SRE) y un responsable de seguridad cibernetica, muchas veces necesitamos poder arquitecturar una solucion. La primera version de un producto de datos, más si es algo innovador, tiene que existir como un MVP para poder despues pasar por todos los filtros de calidad y seguridad para llevarlo a produccion en la organizacion.
En un equipo de profesionales de datos tipicamente esta el conocimiento para hacer una primera version de la arquitectura, y lo que vemos despues de haber ejecutado cientos de proyectos, es que si logramos completar una documentacion inicial con el equipo que esta en la ejecución vamos a estar bien preparados. El conjunto de documentos minimos es.
Un contrato de servicio - un documento que describe los objetivos de negocio que buscamos lograr hacer y como podemos medir que logramos estos objetivos. Esto funciona lo mejor cuando el lenguaje esta muy cercano al negocio, lo cual es más dificil en la practica de lo que parece. Hasta los interesados del negocio tienen la tendencia a empezar con conceptos técnicos como “latencia baja”, “concurencia”, pero eso no tiene sentido si no sabemos que estamos tratando de hacer. Por ejemplo, si estamos tratando de mejorar la experiencia de usuario, entonces debemos medir la satisfacción del usuario, no la latencia. Latencia puede ser una de multiples factores técnicos que impactan esa satisfacción. Pero tipicamente es mucho más facil reducir la latencia de un sistema (requiere presupuesto) que mejorar la satisfacción del usuario (requiere conocimiento del negocio). Además, el contrato de servicio debe incluir indicadores clave de rendimiento (KPIs) que permitan medir el éxito del proyecto.
Un contrato de datos - un documento donde incluimos la proveniencia, la nomenclatura y requerimientos de calidad de los datos que vamos a consumir en la solucion. Tener este documento ayuda mucho en la comunicación con otros equipos, y nos permite lograr un acuerdo (por eso la palabra contrato) sobre los datos que vamos a tener disponibles para nuestro producto de datos. Además nos da una referencia para poder dejar claro que los datos de entrada cambiaron y ya no esta acorde a lo que acordamos. Ser reactivos a cambios en datos upstream tiene un costo muy alto a la hora de mantener un producto de datos a largo plazo y lograr desarrollo regualar para evolucionar el producto de datos a nuevas versiones con más funcionalidad solicitada por el negocio.
Una figura del modelo de despliegue - muchos se va a referir a esto como “la arquitectura” porque es una imagen, y nuestra referencia del concepto de arquitecto para mucho es la construccion de una casa. Buscamos mostrar esto regularmente, con todos los componentes y su estado en los tres ambientes de despliegue que existen, que como minimo siempre son desarrollo, pruebas y producción.
Si estas immerso en el desarrollo y despliegue regular de un producto de datos es facil olvidar que nada de esto es obvio para las demás personas. Y tendemos a mantener las cosas a como fueron diseñadas inicialmente. Por ejemplo, quizás llevamos la ejecución de un proceso de preparación de datos a un entorno serverless, cuando a lo largo del tiempo resulta que la carga de computo es menor y predecible. En ese caso ya no tiene mucho sentido serverless y el costo en tiempo y complejidad ya es mayor que ejecutarlo en una VM con demás componentes de la solución. Solo al mostrarlo y explicarlo regularmente se nos hacen visibles estas posibilidades de mejora y optimización.
Además ayuda enormemente en la gestion de expectativas del negocio. Muchas veces hay un supuesto de que lo que pudieron ver en staging es lo que ya esta en producción. Haciendo el desface de versiones entre los diferentes ambientes visibible en cada reunion de seguimiento ayuda a evitar ese tipo de confusiones. A veces ha dependencias en el entorno de produccion que no nos permiten hacer la última version desarrollada disponible al negocio.
Este es un ejemplo de como se puede mostrar el modelo de despliegue de una solución de datos en diferentes ambientes de desarrollo, pruebas y producción. Es parte de nuestro template para reuniones de seguimiento de proyectos.
En nuestro equipo usamos una filmina con el modelo de despliegue en las reunion es semanales, y la actualizamos semana a semana. Los cambios a veces son sutiles, y es facil olvidar actualizarlo, lo que lo vuelve en una responsabilidad conjunta de mantenerlo al dia. La figura tiende a estar un paso adelante de la documentación, por ejemplo - y es importante que todos tengamos un lugar para ir a ver cual es el estado actual. Es responsabilidad de todos en el equipo en la ejecución mirarlo y avisar si hay algo que ya es diferente, o un componente que falta.
7.4 Herramientas de dibujo
Sin excepción alguien que empieza a hacer dibujos de arquitectura de soluciones empieza a buscar e intersarse por software especializados para hacerlo. De las que hemos intentado incluyend Visio (Microsoft), Enterprise Architect (Spark Solutions), Diagrams.net (JGraph Ltd), Lucid, PlantUML, y otros que no se nos occurre el nombre ahora a escribirlo. O bien en lenguajes para automatizarlo como Mermaid, Mingrammer, tikz y otros.
Esta muy bueno navegar a travez de todas estas soluciones, porque te enseña algo sobre como otros buscan hacer dibujos. Pero al implementarlos, muchas veces terminas dedicando más tiempo pensando en como hacer algo en la herramienta, en vez de usar el tiempo y la energia para penser en como mejor arquitecturar una solución. Esto aplica en una forma aún más marcada si vas a imponer la herramienta sobre los demás. Despues de muchos años y cientas de horas invertidas, lo que mejor escala a un equipo, lo que da más apertura a colaboración y edición colaborativa, y lo que más expresividad da, es una presentación en Google Presentations, Libreoffice Impress o Microsoft Powerpoint. Una vez adoptado es bueno crear un template en conjunto, para que puedan lograr que las figuras se vean bonitos - lo que es importante para el buy-in a nivel gerencial.
Para arrancar a dibujar es muy buena practica usar alguna herramient con la que te sientes muy comodo. Un lapiz y papel, a para algunos una herramienta como excalidraw son muy buenos para tener cerca al hacer un primer bosquejo, o al buscar alternativas. Quieres tener algo que te ayude a pensar, analisar y preparar la mejor forma para comunicarlo con otros. No hay una sola forma de hacerlo. El libro de Hohpe que referenciamos arriba es una muy buena introduccion la importancia de dibujos.
7.5 Recomendaciones
Lo que quizimos aclarar en la seccion de arriba es que no hay construccion y desarrollo sin un plan de lo que se ha de construir. Esto aplica aun más cuando hay multiples personas involucradas en la construcción. Ese plan de lo que se va construir lleva a un marco de referencia común que va más alla de decisiones de infraestructura. Implica un acuerdo sobre como llamamos las cosas, y como estan estructuradas las dependencias.
A la hora de construir, y a la hora de resolver problemas y mantener el producto de datos hacia el futuro, este acuerdo se hace muy valioso. Documentarlo es relativamente poco esfuerzo y nos permite regresar al mantenenimniento de un producto de datos que quizás no hemos cambiado en mucho tiempo, pero que necesita algun cambio para ajustarse a la nueva situación de negocio.