Architectural Decision Records: 4 aspectos infaltables a evaluar

A menudo como arquitectos nos encontramos que tenemos que tomar decisiones de todo tipo a la hora de darle forma a una solución. Tecnologías, patrones de diseño, atributos de calidad y restricciones son algunas de las cuestiones que generan desafíos interesantes en nuestro día a día. Pero qué pasa cuando llegamos al momento de evaluar alternativas de productos para cubrir algún componente de nuestra arquitectura? ¿Evaluamos los aspectos necesarios?

Architecture Decision Record (ADR)

El ADR es un documento donde se deja constancia de los motivos de una determinada decisión que influye notoriamente sobre la arquitectura. Se deja registrado entre otras cosas el contexto, las restricciones, las alternativas que se evaluaron y las conclusiones de esa evaluación teniendo en cuenta todo lo anterior . Seguramente dentro de unos años alguien se preguntará por qué estamos utilizando tal o cual tecnología o patrón de diseño y alli estará nuestro documento contando los por qué.

Normalmente en nuestro ADR es posible que se tengan que evaluar distintas alternativas. Por ejemplo, si tenemos más de un producto tecnológico en el mercado que cubra la misma necesidad será fundamental establecer una evaluación comparativa entre ellos tomando en cuenta capacidades que se puedan medir o evaluar para establecer conclusiones. Por ejemplo, podríamos evaluar usar Spring Boot o .NET Core para el desarrollo de microservicios y establecer una comparativa entre ellos.

Este articulo hace foco sobre algunos aspectos que consideramos muy importantes en la comparativa de alternativas. Es frecuente ver que no son tan tenidos en cuenta y muchas veces llevan a tomar decisiones equivocadas cuando no se evaluan o se evaluan incorrectamente.

Radar de un ADR sobre tecnologías de Service Mesh

A continuación el detalle de los que creemos infaltables a la hora comparar.

Madurez

Definitivamente la madurez de un producto es un aspecto clave a tener en cuenta. Y a menudo uno de los que más generan confusión en algunas decisiones que vemos en la industria.

Es bastante frecuente que a la hora de plantear la arquitectura de una solución se cometa el error de pensar que lo más nuevo o lo último del mercado es lo mejor y se pretenda ir al último grito de la moda (tecnológica) del momento. Pero a la hora de llegar a entornos productivos eso puede ser un problema. Dentro de los factores que son necesarios evaluar a la hora de entender si el producto está maduro o no, son los siguientes:

• Fecha de lanzamiento: esto nos puede dar la pauta de cuánto hace que está en el mercado.
• Fase en la que se encuentra (alpha,beta,stable): Seguramente no se pueda pensar en entornos productivos corriendo “alphas”
• Tamaño de la comunidad que tiene asociada: en el caso de los productos open source el tamaño de la comunidad asociada suele ser un factor determinante. Ciertamente la comunidad es la primer línea de defensa en caso de necesitar soporte o de mantener actualizado el producto.
• Cantidad de releases en un determinado periodo de tiempo: Si bien la cantidad de releases de un producto no es determinante, puede darnos una buena noción de actividad de sus desarrolladores.

Si juntamos todos los puntos anteriores tendremos una buena noción de la estabilidad de un producto y justamente la estabilidad de un producto es lo que lleva a la madurez del mismo.

Si la fecha del lanzamiento del producto tiene al menos 2 años de recorrido, si tiene liberada una versión estable, si el tamaño de la comunidad es amplio (sobre todo en Open Source) es probable que estemos hablando de un producto con la madurez suficiente para ser pensado en un ámbito productivo.

Soporte Técnico

Una de las cuestiones que no podemos dejar de evaluar es el nivel de soporte técnico que el fabricante puede ofrecer. Es frecuente ver implementaciones de productos en entornos productivos que carecen de soporte técnico comercial y que cuando fallan en entornos de alta escala, simplemente no existen canales adecuados para pedir ayuda. En este punto es importante evaluar correctamente el nivel de soporte técnico que se ofrece y cual es el necesario para el negocio. Shit happens!

Ejemplo de comparativa de soporte de Gitlab (https://about.gitlab.com/support/)

¿Quién más usa el producto?

La Installed base de un producto es en qué empresas efectivamente el producto evaluado se encuentra instalado y en uso. Y aquí vamos a detenernos en algo muy importante. Es frecuente ver que los fabricantes (sobre todo los productos más comerciales) publicitan en sus sitios los logos de las empresas que usan su producto. Esto intencionalmente puede darnos la medida de quienes son los que lo están usando. Pero aquí hay otra gran red flag. Muchas veces vemos como ese tipo de publicaciones son engañosas ya que si se hace foco en ellas en muchos casos se puede ver que solo se hace publicidad de empresas que solo probaron el producto. También en otros casos hemos visto cómo esas empresas publicitadas solo usan una fracción y no el producto completo. Es de vital importancia tener certeza al momento de evaluar que la installed base sea verdadera. A continuación algunas preguntas importantes sobre el producto a evaluar que pueden ser de utilidad para decidir.

• ¿Está publicado por el fabricante las empresas que lo adoptaron?
• ¿Existen testimonios reales (cargo, nombre y apellido) de personas responsables de empresas que usan el producto?
• ¿Se menciona si las empresas adoptaron el producto o solo lo testearon?
• Si lo adoptaron, ¿lo adoptaron en su totalidad?

Clientes publicados por Kong para su producto Kong Gateway

Roadmap

El roadmap de un producto es el conjunto de contenidos que nos permiten saber la visión y la dirección en la cual va el desarrollo del mismo. Como piensa el fabricante y cuales son los futuros pasos a seguir en el ciclo de vida de su producto. Es posible que muchas veces esto sea publicado de diferentes maneras. En algunos casos se grafica con una línea de tiempo marcando determinados hitos o muchas veces es más textual y solo nos da una idea de a donde va encaminado. En el marco de un roadmap ciertamente saber de donde se viene y hacia donde va nos da una imagen muy clara del punto actual en el cual se encuentra el producto. ¿Cuánto camino recorrió? ¿Cuánto le falta recorrer?

Ciertamente una gran red flag para cualquier producto, es no tener publicado su roadmap. Es decir no tenemos noción alguna por donde puede continuar el desarrollo de ese producto.

Roadmap publicado por Gitlab

Conclusiones

Como vimos más arriba es muy importante hacer foco en estos puntos a la hora de evaluar cuál alternativa tecnológica del mercado se ajusta mejor a nuestras necesidades como arquitectos. Muchas de ellas en ocasiones vemos que no son tenidas en cuenta cómo se debe. Vemos alternativas tecnológicas implementadas en entornos productivos con cero nivel de soporte técnico por parte del fabricante. Vemos productos recién implementados donde no se tuvo en cuenta su End of Life (momento en el cual el producto deja de recibir actualizaciones). Los invitamos como arquitectos a tener en cuenta los puntos anteriores a la hora de tomar decisiones.

Hasta el próximo artículo!