Arquitectura IT según Ingenia: El Ingenial Journey

Existen muchas definiciones y entendimiento sobre lo que significan las prácticas de arquitectura IT, y muchos mitos sobre qué es y que no es. Sin meternos demasiado en esas discusiones, la definición que mas nos gusta por es las siguiente, porque da una vision holística de todo lo que representa:

Una arquitectura es el conjunto de decisiones significativas sobre la organización de un sistema de software que define los principios que guían el desarrollo, los componentes principales del sistema, sus responsabilidades y la forma en que se interrelacionan.

Hablamos entonces de arquitectura como las prácticas, métodos y herramientas que permiten tomar aquellas decisiones significativas en el momento mas adecuado, para organizar los componentes de una solución de software y definir sus responsabilidades.

En los párrafos anteriores hablamos de decisiones significativas. Veamos un poco a que nos referimos con eso. Las decisiones arquitecturales son aquellas que:

• Afectan a muchas partes del sistema.
• Suelen ser difíciles de cambiar.
• Le dan estructura y organización al sistema.
• Muchas de ellas deben tomarse en forma temprana.

Muchas veces se cae en el error de olvidarnos que todas las decisiones que tomamos como arquitectos están enmarcadas en una empresa, y debe servir para dar soporte a los propósitos de la misma. Es ahi donde entre en juego la arquitectura empresarial, como el diseño y modelado coherente de los diferentes estados de una organización y los sistemas que soportan sus procesos, en un estado actual y futuros, a través de decisiones conscientes en todos sus dominios: Negocio, Información, Aplicación, Datos e Infraestructura.

En el siguiente diagrama se puede ver como todos los componentes en una organización conviven y se soportan unos al otro, cada uno soportando la creación de valor de la que es objeto la empresa:

El negocio representado por las personas son soportadas por actividades enmarcadas en procesos que guían la forma en que la empresa cumple su misión. Estas actividades por su parte son soportadas por sistemas (en el mejor de los casos) ya sea automatizándolas, o sistematizando su soporte para hacer más eficiente su ejecución. Estas aplicaciones se integran entre si, y comparten datos para ser parte del ecosistema de aplicaciones que hacen que una organización sea lo que es. Y por último pero no menos importante son los componentes de infraestructura (físicos o lógicos) que soportan a las aplicaciones de la manera en que es requerido.

Si todos los componentes no se soportan entre si como parte de un mismo ecosistema, se rompe el alineamiento entre la estrategia de la empresa y IT, y es en ese punto donde es imposible que IT muestre el valor que tiene para el negocio. Es por eso que es tan importante la arquitectura empresarial y sus prácticas.

Le hemos dado una definición a arquitectura, y hablamos de su alcance y la importancia de no perder de vista los aspectos de negocio, tecnológicos y su evolución, pero en conjunto.

Ahora hablaremos sobre la manera de abordar problemáticas que se resuelven desde la arquitectura. En Ingenia hemos creado un método de trabajo, en base a nuestra experiencia en el tema, que acordamos llamar el “Ingenial journey” ya que se trata e un viaje que recorremos en cada uno de los desafíos que encaramos. El mismo lo podemos resumir en el siguiente gráfico:

Describir el journey completo es lleva mucho mas que un par de párrafos, pero intentaremos resumirlo en sus aspectos clave.

En primer lugar, antes de comenzar cualquier ejercicio de arquitectura, tenemos que tener claridad sobre cuales son los reales puntos de dolor del problema en cuestión y cual es la situación de la que partimos, lo que nos limitará las alternativas que podamos encarar para resolver el problema, pero también será nuestra guía para encontrar la o las soluciones más acordes a la situación.

Una vez que tengamos claridad sobre el punto de partida, debemos trabajar con visión de negocio y tecnológica en identificar cuales son los objetivos y resultados que se espera luego de la ejecución del proceso de arquitectura, de la manera mas medible posible. El uso de objetivos SMART es de suma utilidad. Esto sucede en la etapa que denominamos Visión, y su resultado es el Business / IT Visión, nuestro norte.

En esta etapa, donde logramos visualizar el estado futuro al que queremos llegar, contamos con algunas herramientas muy útiles a nuestro favor. La primera y más importante son los atributos de calidad, y la segunda son las restricciones, sobre las cuales hablamos resumidamente hace unos párrafos. Sobre los atributos de calidad podemos decir que guían a un arquitecto a entender con claridad la forma en que un sistema debe cubrir los requerimientos funcionales, y es en conjunto con ellos que una solución cumplirá con los objetivos planteados. Por ejemplo, por mas que una solución cumpla a la perfección con lo definido funcionalmente, no será de mucha utilidad si su rendimiento es malo, o si su nivel de disponibilidad es bajo. Es por eso que en esta etapa es vital poner foco en la clara y correcta definición de los mismos, teniendo en cuenta el otro concepto del que hablamos, las restricciones. Estas, muchas veces vistas cómo enemigas, identificadas de manera temprana pueden ser nuestras aliadas, ayudándonos a converger en la mejor solución realizable. Tenemos que tener en cuenta que la mejor solución no es independiente de su contexto, sino que una arquitectura debe definir la mejor solución en una situación dada, para que una organización en ese momento pueda cumplir los propósitos que se propone, teniendo en cuenta las tecnologías existentes, el tiempo con el que contamos para implementar la solución, los skills que tenemos a nuestras manos, y el tiempo de vida que tendrá el software que diseñamos. Es por esto que muchas veces el trabajo de arquitectura es un trabajo de diseño por restricciones, mas que una tarea de creación libre.

Recién una vez que tenemos comprendidos de donde partimos (as-is) y lo que queremos lograr una vez que lleguemos a destino, tanto desde la visión de negocio y tecnológica, es que nos podemos embarcar en la etapa de creación, como un proceso creativo iterativo y con mucho peso de la experiencia y criterio, para la toma de las decisiones de arquitectura que darán forma a la solución TO-BE. En esta actividad suceden:

• La identificación de los building blocks conceptuales, sus responsabilidades y cómo interactúan entre sí.
• La determinación de alternativas tecnológicas para cumplir los roles definidos por los building blocks identificados, y cual de esas alternativas es mas adecuada teniendo en cuenta la situación actual, restricciones y diversión de la organización, entre otros.
• La definición de skills, roles y método de trabajo que la organización deberá tener para poder explotar al máximo la solución definida.
• La identificación de iniciativas, o work ítems, que deben sucederse para lograr transitar el camino que lleva de la situación actual (as-is) a la to-be definida.

La definición de la solución objetivo es solo un paso más en el journey (importantísimo) pero no es todo. Si no nos enfocamos en acompañar el tránsito de un estado a otro, aprendiendo en el camino y ajustando las decisiones, la arquitectura quedará solo en un hermoso documento que no cumpla los objetivos inicialmente planteados. Para lograr que las decisiones tomadas se cristalicen en una organización 2.0 que explote las bondades de la arquitectura definida, debemos cómo arquitectos acompañar en la adopción y llevar la solución que nos imaginamos.

Cuando en la sección anterior recorrimos el Ingenial Journey, hablamos de la solución como algo abstracto, y tal vez pueda darse a entender de esa manera como solo una solución formada por componentes de software y hardware interrelacionados que en conjunto dan servicio a los objetivos de una organización.

Creemos a una solución como algo que va más allá de software y hardware, sino también de cómo las personas interactúan entre sí, y los métodos y procesos que definen la mejor forma de trabajar en conjunto para explotar las tecnologías al máximo. Al fin y al cabo seguimos siendo las personas quienes creamos el software, por lo que no es posible dejar de entender cómo trabajamos para lograr cumplir nuestro cometido.

Es en ese contexto que el Ingenial journey también es atravesado por la definición de roles, prácticas y skills necesarios para que la adopción, la etapa final del recorrido, sea realmente sostenible.

Es necesario tener en cuenta como se realizará la evolución de las piezas de software y hardware, no solo teniendo en cuenta a la modificabilidad como un atributo de calidad, sino definiendo los procesos, roles y métodos que guiarán la gestión de configuraciones, el aseguramiento de calidad y el ciclo de vida de las aplicaciones.

No tiene sentido pensar en un sistema que esté disponible 99,95% del tiempo sin pensar en cuales son los cambios que una organización debe darse en su forma de trabajo para implementar DevOps y prácticas como CI/CD, por ejemplo, ni como asegurar la operación y el monitoreo contínuo de las mismas.

Si no pensamos en como organizamos los equipos de desarrollo, la gestión de las necesidades del negocio, el aseguramiento de la calidad, los despliegues y el soporte operativo (solo por nombrar alguno de los puntos claves del ciclo de vida de una aplicación) no lograremos que nuestras arquitecturas sobrevivan en el tiempo de manera adecuada. Es por eso que van de la mano.

En el siguiente video les comparto mayor detalle de estos conceptos, en una charla que forma parte de un conjunto de encuentros que estamos teniendo para compartir experiencias en el marco de la cuarentena, de manera abierta.