Arquitectura de TI. Déjame decirte por qué

¡¡Nos encanta dibujar !!

(Miguel Angel Coll) (2 de julio de 2020)

Invertí los últimos 5 años en mi carrera trabajando en la función de Arquitectura de TI. Todos esos años, tuve que justificar la mera existencia de la función Arquitectura incluso para mí. A veces también nos sentimos como intrusos rodeados por las personas que realmente hacen el trabajo (desarrolladores y operaciones de sistemas).

Después de 5 años todavía estoy convencido de que la arquitectura importa, déjame darte algunos argumentos para Pruébelo.

La mejor relación calidad-precio

Si tengo que elegir solo una misión para la arquitectura de TI, elegiré esta. Los departamentos y plataformas de TI suelen estar creciendo. Algunas porque la empresa está creciendo, otras porque la empresa está en medio de una Transformación Digital. En cualquier caso, el resultado es el mismo, año tras año tienes más sistemas, más equipos, más complejidad.

Me gusta simplificar demasiado una plataforma de TI de la siguiente manera:

La función principal de la arquitectura es mantener la relación con el El costo de la plataforma de TI y el valor que ofrece en buena forma.

Hace un tiempo trabajé en una empresa de viajes con un modelo de negocio basado en la distribución de productos online a través de API. Esas API estaban fuertemente acopladas a un enorme sistema monolítico basado en Oracle Exadata. Eso significa que cada vez que aumentamos el tráfico de la API (y el tráfico crecía más que la Tasa de conversión) necesitamos escalar verticalmente nuestra base de datos.

La arquitectura impulsa la eficiencia de la plataforma de TI

La propuesta de arquitectura en ese momento era desacoplar los servicios de API creando una nueva capa de microservicios en la nube para manejar todo el tráfico con menores costos mientras se mantiene la infraestructura de la base de datos solo para la reserva y las operaciones (que desafortunadamente no crecen exponencialmente). El resultado fue que no se necesitó más infraestructura nueva para la base de datos en los años siguientes y una mejor relación entre el tráfico y los costos de TI.

Use el mismo lenguaje

No se preocupe, estoy sin hablar de lenguajes de programación (java, python, etc.). Como arquitecto, estoy más que abierto a la diversidad con cierto control (no caos). Aquí me refiero a Integridad conceptual término que leí por primera vez en Mes del hombre mítico y otros ensayos sobre ingeniería de software de Frederick P . Brooks Jr.

En el libro, Fred Brooks explica cómo crecen los equipos de TI y cómo ese crecimiento impacta en su productividad. Para Fred, uno de los mayores problemas que debe abordar cuando intenta escalar un equipo de TI es la comunicación entre equipos. Para paralelizar las tareas, necesita que los equipos sean lo más independientes posible. Pero, tan pronto como todos los equipos trabajen en una plataforma interconectada, necesitamos cierta comunicación entre los equipos. Es en esos escenarios cuando tener un lenguaje común es clave para el éxito.

Todavía recuerdo conversaciones interminables con mis antiguos compañeros de equipo discutiendo sobre qué es un sistema, un componente tecnológico, una interfaz o un bloque de construcción. Si trabaja en un gran departamento de TI, probablemente sepa lo frustrante que es que los equipos nombren las cosas de manera diferente. A veces es incluso peor cuando usan el mismo nombre para diferentes cosas.

Un ejemplo común de ese último es nombrar una aplicación monolítica con un solo nombre. Incluso si tiene sentido (ya que es un monolito), cuando quieras romper ese monolito, necesitarás más detalles. La introducción de diferentes nombres para la base de datos, la interfaz, el modelo de datos, etc. ayudará en el proceso.

Incluso si se encuentra en un departamento de TI pequeño o en uno más grande, siempre es un buen momento para comenzar con una convención de nomenclatura, un catálogo de servicios / sistemas / soluciones, etc. Nunca se sabe qué tan grande será en el futuro.

Acerca de la integridad conceptual, desnudo conmigo, cuanto antes, mejor.

Forzar conversaciones de diseño

En mi mente, cada solución a un problema siempre comienza con un análisis de la situación y diseño de la solución antes de implementarla. La realidad para un equipo de desarrollo es que cada semana tenemos nuevos problemas sobre la mesa para resolver. Después de algunos meses de rutinas Business as Usual, los equipos comienzan a funcionar en piloto automático y solo encuentran soluciones a los problemas sin pensar demasiado en las implicaciones a mediano y largo plazo.

Tener la función de arquitectura integrada en los equipos de desarrollo siempre ayuda en aumentar las conversaciones de diseño para encontrar las mejores soluciones a los problemas que enfrentamos.

Además, me gusta desafiar el proceso de desarrollo de la vieja moda donde el diseño se ve como algo que se debe hacer justo al comienzo de un proyecto.En el artículo The Architect Elevator: visitando los pisos superiores , Gregor Hohpe describe perfectamente mi comprensión del rol de la arquitectura:

“… Entonces, en lugar de confiar todas las decisiones cruciales a una persona, el riesgo del proyecto se puede reducir en minimizando el número de decisiones que son irreversibles .”

La arquitectura tiene que estar presente en todo el proceso de desarrollo . De hecho, si está trabajando en Agile, tomará decisiones en cada iteración.

Discusiones de estrategia

Como técnico de TI, me encantará estar en la junta directiva de la empresa teniendo y discusiones técnicas detalladas. La realidad para las empresas medianas y grandes es que los miembros de la junta no pueden permitirse profundizar demasiado en los detalles. Pero, ¿la junta de la empresa debería tomar decisiones sobre estrategia sin comprender la situación de las TI?

En el mundo actual, solo hay unas pocas empresas que pueden decir que las TI no están en el centro de su estrategia. Entonces, ¿quién es el responsable de trasladar la estrategia a TI y viceversa? – ya sabes la respuesta.

Una de nuestras mayores contribuciones en el equipo de arquitectura de TUI Destination Experiences fue dibujar un modelo de arquitectura de destino. El TAM permite que las personas que no son de TI comprendan nuestras principales soluciones y sistemas y cómo están conectados a los flujos de valor de nuestra empresa. Después de distribuir el TAM, la mayoría de nuestras conversaciones estratégicas comenzaron mirando cómo se ve nuestra arquitectura y cómo deberíamos adaptarnos a una nueva situación.

Pero tenga cuidado, un modelo de arquitectura de destino no está destinado a ser estático. imagen de la arquitectura «tal cual» y «futuro». Intentar hacer ese tipo de ejercicio terminará con algo efímero que se ajusta a un proyecto específico. En mi opinión, es mejor concentrarse en dibujar los componentes principales de su arquitectura y seleccionar las cosas que desea conservar (porque son el núcleo de su negocio) y señalar las cosas que necesitará cambiar o evolucionar.

Primera diapositiva de la presentación de TAM

Recuerde siempre lo que dijo Dee Hock, fundador de Visa:

Un propósito y principios simples y claros dan lugar a un comportamiento inteligente complejo. Las reglas y regulaciones complejas dan lugar a un comportamiento estúpido simple.

Hasta el infinito y más allá

La obsesión por ser ágil a veces es transformar los equipos de TI en tomadores de decisiones a corto plazo . Como ya comentamos, debemos estar seguros de que las decisiones que tomamos hoy están preparadas para el futuro. A veces significa tener una visión clara de la estrategia a largo plazo. A veces significa tener cuidado de no quedar atrapado en una solución que no se ajuste a su futuro. La mayoría de las veces significa asegurar un nivel predeterminado de calidad y poder adaptarse a lo que venga.

Como ya comentamos, la Arquitectura tiene que trabajar también a nivel estratégico. Eso significa que probablemente tendrá información fresca sobre las posibilidades futuras que podrían afectar a la plataforma de TI. A veces, esos cambios estratégicos son incluso confidenciales. Poder influir en algunas decisiones tratando de evitar los movimientos de arrepentimiento es a veces una tarea difícil porque las personas no informadas nunca entenderán la verdadera razón detrás.

En algún momento, estábamos en medio de la debate sobre la mejora de la arquitectura de la plataforma B2C. Realmente tiene sentido mejorar mucho la arquitectura. Pero, algunos sabíamos que estábamos en conversaciones para adquirir una empresa que sustituya a nuestra plataforma B2C.

Créame, no siempre es fácil ser arquitecto, pero hay que pensar siempre en lo que es lo mejor para la empresa.

Y también…

… También nos encanta dibujar y haremos que la oficina sea mucho más genial.

El equipo de desarrollo tiene discusiones utilizando un diagrama de arquitectura

Espero esta publicación modesta contribuir en el futuro a comprender un trabajo tan hermoso.

Migue Coll, Jefe de dominio de tecnología en Tui Destination Experiences.