Las complejidades empresariales como la estructura organizativa, procesos comerciales, sistemas de información, relación con el cliente y entre otros son un desafío significativo para la arquitectura empresarial (AE). La gestión de la complejidad se vuelve crucial para permitir que una organización responda de manera rápida y eficiente a los cambios en los mercados, regulaciones e innovaciones.
Muchas de las iniciativas de la AE suelen centrarse en cómo gestionar la complejidad en TI, hasta que se hace evidente que la complejidad es, en su mayoría, una consecuencia directa de la complejidad empresarial.
La descomposición es un proceso fundamental en la AE para manejar la complejidad y la incertidumbre en una organización. Consiste en dividir una entidad o sistema en partes más pequeñas y manejables, permitiendo así abordar de manera más efectiva los desafíos empresariales. En el contexto de la arquitectura empresarial, la descomposición implica agrupar las funciones en dominios o funciones según la sinergia o autonomía.
Descomposición funcional
El enfoque más natural para realizar una descomposición es comprender primero las funciones que realiza la organización (es decir, las funciones empresariales).
Una función es una colección de datos y puntos de decisión estrechamente relacionados (por ejemplo, "Pagos" es una función). Estas funciones no agregan mucho valor por sí mismas, sino que forman parte de un macroproceso que proporciona valor. Por ejemplo, un pago por sí solo no tiene mucho significado, generalmente se realiza en el contexto de un intercambio específico de valor o servicio.
La primera acción a tomar es crear una taxonomía (o, más precisamente, una ontología) para describir de manera consistente las funciones realizadas en toda la empresa. Luego, varios procesos, productos o servicios pueden describirse como una combinación de esas funciones.
Si aceptamos (aunque no es aceptado en todas partes y dudo que alguna vez lo sea) que la AE se centra en la complejidad de TI, entonces la AE no es responsable de la complejidad relacionada con la existencia de procesos, productos o servicios. La creación o eliminación de estos es generalmente una consecuencia directa de decisiones empresariales. Sin embargo, la AE debe encargarse de catalogarlos y asegurarse de que se incorporen en otros procesos empresariales, como los procesos de recuperación ante desastres o continuidad del negocio. Además, la AE debe relacionar esto con la taxonomía funcional y la arquitectura de TI.
Esto puede volverse muy complejo rápidamente debido a la gran cantidad de procesos, productos y servicios, incluyendo sus diversas variaciones, que la mayoría de las organizaciones tienen. Por lo tanto, es importante dividir o descomponer la complejidad en partes manejables para facilitar conversaciones significativas.
Descomposición por dominio
Una forma de hacer esto a nivel empresarial es agrupar las funciones en particiones (dominios) según la sinergia o autonomía (como lo describe Roger Sessions en su libro Simple Architectures for Complex Enterprises), para todos los productos/servicios que respalden un negocio en particular. Este enfoque se basa en el concepto matemático de equivalencia. Debido a que diferentes funciones en diferentes contextos pueden tener relaciones de equivalencia distintas, las funciones pueden aparecer en múltiples dominios. Una de las funciones de la AE es evaluar y validar si esas funciones son realmente autónomas o si existe la posibilidad de agrupar funciones aparentemente duplicadas en un nuevo dominio.
Al agrupar las funciones en dominios según la sinergia o autonomía, podemos adaptarnos rápidamente a los cambios del entorno empresarial, evolucionar de manera independiente y simplificar la comprensión de la arquitectura. Además, podemos reutilizar soluciones, mantener consistencia y establecer estrategias específicas para cada dominio, lo que nos permite tomar decisiones más efectivas y lograr una respuesta rápida y eficiente a las demandas cambiantes.
Una vez que se identifican los dominios, es posible aplicar el pensamiento de EA "tradicional" a un dominio en particular, porque ese dominio tiene un tamaño manejable. Por "EA tradicional" me refiero a la aplicación de Zachman, TOGAF, PEAF o cualquiera de las numerosas metodologías que existen. Más específicamente, a ese nivel, es posible establecer una estrategia u objetivo de sistemas de información significativo para un dominio en particular que respalde directamente los objetivos de agilidad empresarial.
La falacia de la descomposición funcional
Una vez que llegas al nivel de dominios, la descomposición funcional ya no es tan útil para la arquitectura de soluciones. Lo que suelen hacer los arquitectos es construir componentes o servicios reutilizables que realicen las diferentes funciones de la partición. Pero, en realidad, esto puede generar más complejidad en lugar de menos (y, por lo tanto, menos agilidad), como demuestra Jüval Lowy en su libro The Zen of Software Architecture.
Cuando hablamos de arquitectura de software, la verdadera razón para modularizar es manejar la volatilidad o incertidumbre y asegurarnos de que los cambios en una parte de la arquitectura no afecten negativamente a otras partes en el futuro. Hacer esto nos permite mantener la flexibilidad, de manera que las áreas cambiantes de la aplicación puedan actualizarse con frecuencia y con poco impacto en el resto de la aplicación.
Al echarle un vistazo a una arquitectura de software desde esta perspectiva, es posible que se descubra un conjunto de componentes/módulos/servicios bastante distinto a los que serían evidentes al descomponerlo de manera funcional. Un argumento clave que Jüval utiliza en su presentación es que (parafraseándolo un poco) las funciones, en general, dependen mucho del contexto en el que se utilizan, por lo que tenerlas en servicios separados podría requerir hacer suposiciones a menudo imposibles sobre todos los posibles contextos en los que las funciones podrían ser llamadas.
En este sentido, los componentes, módulos o servicios identificados pueden verse como opciones en cuanto a qué se hace o cómo se hace, dentro del contexto de un sistema más grande con partes cambiantes.
Dominios como Arquitectura Empresarial
Cuando consideras cada dominio y su relación con otros, hay mucha incertidumbre sobre cómo van a evolucionar. Para ser flexibles, cada dominio debe asumir que los otros son una parte volátil de la arquitectura y diseñar en consecuencia. Así cada uno puede evolucionar (más o menos) independientemente, con pocos puntos de coordinación y sin comprometer la arquitectura empresarial al hacer que los diferentes dominios repliquen los comportamientos de sus dependencias.
Para poder trabajar sobre volatilidad necesitamos que:
- La inversión debe expresarse en términos de impacto en una o más dominios.
- Las dominios deben establecer sus propias estrategias de implementación.
- Los principios ágiles deben acordarse en función de cada dominio.
- Los estándares de arquitectura deben acordarse en función de cada dominio.
- Las dominios deben definir componentes internamente reutilizables relevantes solo para esa dominio.
- Las dominios deben exponer su comportamiento a otros de manera consistente en toda la organización
En las startups, no es necesario que los dominios estén alineados organizativamente. Sin embargo, en otras culturas organizacionales (burocráticas), alinear las funciones de arquitectura empresarial, como TI u operaciones (al menos), con los dominios puede ayudar a acelerar los cambios de arquitectura (recordemos, solo tenemos el 2% del tiempo para hacerlo como he explicado en la entrada El problema del 2%) y los cambios culturales necesarios.
Algunos de los beneficios de utilizar descomposición basada en volatilidad son:
- Flexibilidad: Al agrupar las funciones en dominios y diseñar teniendo en cuenta la volatilidad, se logra una mayor flexibilidad para adaptarse a los cambios en los mercados, regulaciones e innovaciones. Esto permite una respuesta rápida y eficiente a las demandas cambiantes del entorno empresarial.
- Agilidad: Cada dominio puede evolucionar de manera independiente, sin comprometer la arquitectura empresarial en su conjunto. Esto proporciona la capacidad de realizar cambios con mayor rapidez y menor impacto en otras partes del sistema.
- Reducción de la complejidad: Al agrupar las funciones en dominios, se facilita la comprensión y la conversación significativa sobre la arquitectura. Esto ayuda a reducir la complejidad y a abordar los desafíos empresariales de manera más efectiva.
- Facilita la toma de decisiones: Al tener dominios más pequeños y autónomos, se simplifica la toma de decisiones relacionadas con cada dominio. Los equipos pueden establecer estrategias, principios y estándares específicos para su dominio, lo que facilita las decisiones y la implementación de cambios.
- Reutilización y consistencia: Permite definir componentes internamente reutilizables en cada dominio. Esto fomenta la reutilización de soluciones y la consistencia dentro de la organización. Los dominios pueden exponer su comportamiento de manera consistente en toda la organización, lo que facilita la integración y la colaboración.
