Uno de los principios de nuestro próximo libro. Arquitectura como código es la capacidad de los arquitectos de diseñar comprobaciones de gobernanza automatizadas para cuestiones arquitectónicas importantes, creando ciclos de retroalimentación rápidos cuando las cosas salen mal. Esta idea no es nueva: Neal y sus coautores Rebecca Parsons y Patrick Kua abrazaron esta idea en 2017 en la primera edición de Construyendo arquitecturas evolutivasy muchos de nuestros clientes adoptaron estas prácticas con gran éxito. Sin embargo, nuestros objetivos más ambiciosos se vieron frustrados en gran medida por un problema común en las arquitecturas modernas: fragilidad. Afortunadamente, la llegada del Protocolo de contexto modelo (MCP) y la IA agente han resuelto en gran medida este problema para los arquitectos empresariales.
Funciones de fitness
Construyendo arquitecturas evolutivas define el concepto de función de idoneidad arquitectónica: cualquier mecanismo que proporciona una verificación objetiva de integridad de las características arquitectónicas. Los arquitectos pueden pensar en las funciones de aptitud como pruebas unitarias, pero por cuestiones arquitectónicas.
Si bien muchas funciones de aptitud se ejecutan como pruebas unitarias para probar la estructura (usando herramientas como ArchiUnidad, Prueba NetArch, PyTestArch, arco-iretc.), los arquitectos pueden escribir funciones de aptitud para validar todo tipo de comprobaciones importantes… como tareas normalmente reservadas para bases de datos relacionales.
Funciones de fitness e integridad referencial.
Considere la arquitectura ilustrada en la Figura 1.
En la Figura 1, el equipo decidió dividir los datos en dos bases de datos para una mejor escalabilidad y disponibilidad. Sin embargo, la desventaja común de ese enfoque radica en el hecho de que el equipo ya no puede confiar en la base de datos para hacer cumplir la integridad referencial. En esta situación, cada boleto debe tener un correspondiente cliente para modelar este flujo de trabajo correctamente.
Si bien muchos equipos parecen pensar que la integridad referencial solo es posible dentro de una base de datos relacional, separamos la actividad de gobernanza (integridad de los datos) de la implementación (la base de datos relacional) y nos damos cuenta de que podemos crear nuestra propia verificación utilizando una función de idoneidad arquitectónica, como se muestra en la Figura 2.
En la Figura 2, el arquitecto ha creado una pequeña función de fitness que monitorea la cola entre cliente y boleto. Cuando la profundidad de la cola cae a cero (lo que significa que el sistema no está procesando ningún mensaje), la función de aptitud crea un conjunto de claves de cliente desde cliente servicio y un conjunto de claves foráneas del cliente desde boleto servicio y afirma que todas las claves externas del ticket están contenidas en el conjunto de claves del cliente.
¿Por qué no consultar las bases de datos directamente desde la función de fitness? Abstraerlos como conjuntos permite flexibilidad: consultar en bases de datos de forma constante introduce una sobrecarga que puede tener efectos secundarios negativos. Resumiendo la verificación de la función de aptitud del mecánica La forma de almacenar los datos en una estructura de datos abstracta tiene al menos un par de ventajas. En primer lugar, el uso de conjuntos permite a los arquitectos almacenar en caché datos no volátiles (como claves de clientes), evitando consultas constantes a la base de datos. Existen muchas soluciones para cachés de escritura simultánea en el raro caso de que agreguemos un cliente. En segundo lugar, el uso de conjuntos de claves nos abstrae de los elementos de datos reales. Los ingenieros de datos prefieren claves sintéticas al uso de datos de dominio; Lo mismo ocurre con los arquitectos. Si bien el esquema de la base de datos puede cambiar con el tiempo, el equipo siempre necesitará la relación entre clientes y entradasque esta función de aptitud valida de forma abstracta.
¿Quién ejecuta este código? Como este problema es típico en arquitecturas distribuidas como los microservicios, el lugar común para ejecutar este código de gobernanza es dentro de la malla de servicios de la arquitectura de microservicios. Malla de servicio es un patrón general para manejar inquietudes operativas en microservicios, como registro, monitoreo, denominación, descubrimiento de servicios y otras inquietudes ajenas al dominio. En ecosistemas de microservicios maduros, la malla de servicios también actúa como un malla de gobernanzaaplicando funciones de aptitud y otras reglas en tiempo de ejecución.
Esta es una forma común en que los arquitectos a nivel de aplicación pueden validar la integridad de los datos y hemos implementado este tipo de funciones de aptitud en cientos de proyectos. Sin embargo, el especificidad La falta de detalles de implementación hace que sea difícil ampliar el alcance de estos tipos de funciones de aptitud al nivel de arquitecto empresarial porque incluyen demasiados detalles de implementación sobre cómo funciona el proyecto.
Fragilidad para metadominios
Una de las lecciones clave del diseño basado en dominios fue la idea de mantener los detalles de implementación lo más estrictos posible, utilizando capas anticorrupción para evitar que los puntos de integración comprendan demasiados detalles. Los arquitectos han adoptado esta filosofía en arquitecturas como los microservicios.
Sin embargo, vemos el mismo problema aquí en el metanivel, donde a los arquitectos empresariales les gustaría controlar ampliamente preocupaciones como la integridad de los datos, pero se ven obstaculizados por la distancia y la especificidad del requisito de gobernanza. Distancia Se refiere al alcance de la actividad. Si bien los arquitectos de aplicaciones e integración tienen un alcance de responsabilidad limitado, los arquitectos empresariales, por su naturaleza, se ubican en el nivel empresarial. Por lo tanto, para que un arquitecto empresarial aplique una gobernanza como la integridad referencial requiere que conozca demasiadas específico detalles sobre cómo el equipo ha implementado el proyecto.
Uno de nuestros mayores clientes globales tiene un rol dentro de su grupo de arquitectura empresarial llamado arquitecto evolutivocuyo trabajo es identificar preocupaciones de gobernanza global, y tenemos otros clientes que han intentado implementar este nivel de gobernanza holística con sus arquitectos empresariales. Sin embargo, la fragilidad frustra estos esfuerzos: tan pronto como el equipo necesita cambiar un detalle de implementación, la función de fitness falla. Aunque a menudo presentamos las funciones de aptitud como “pruebas unitarias para arquitectura”, en realidad, fallan con mucha menos frecuencia que las pruebas unitarias. (¿Con qué frecuencia los cambios afectan alguna preocupación arquitectónica fundamental versus un cambio en el dominio?) Sin embargo, al exponer los detalles de implementación fuera del proyecto a los arquitectos empresariales, estas funciones de aptitud se rompen lo suficiente como para limitar su valor.
Hemos probado una variedad de capas anticorrupción para las metapreocupaciones, pero la IA generativa y MCP han proporcionado la mejor solución hasta la fecha.
MCP y Gobernanza Agentica
MCP define una capa de integración general para que los agentes consulten y consuman capacidades dentro de un metascopio particular. Por ejemplo, los equipos pueden configurar un servidor MCP a nivel de arquitectura de integración o aplicación para exponer herramientas y fuentes de datos a agentes de IA. Esto proporciona la capa anticorrupción perfecta para que los arquitectos empresariales establezcan la intención de gobernanza sin depender de los detalles de implementación.
Esto permite a los equipos implementar el tipo de gobernanza que desean los arquitectos empresariales con mentalidad estratégica, pero crea un nivel de dirección indirecta para los detalles. Por ejemplo, consulte la verificación de integridad referencial actualizada que se ilustra en la Figura 3.
En la Figura 3, el arquitecto empresarial emite la solicitud general para validar la integridad referencial al servidor MCP del proyecto. A su vez, expone funciones de aptitud a través de herramientas (o fuentes de datos como archivos de registro) para llevar a cabo la solicitud.
Al crear una capa anticorrupción entre los detalles del proyecto y el arquitecto empresarial, podemos usar MCP para manejar los detalles de implementación de modo que cuando el proyecto evolucione en el futuro, no rompe la gobernanza por fragilidadcomo se muestra en la Figura 4.
En la Figura 4, la preocupación del arquitecto empresarial (validar la integridad referencial) no ha cambiado, pero los detalles del proyecto sí. El equipo agregó otro servicio para expertosque trabajan en tickets, lo que significa que ahora necesitamos validar la integridad en tres bases de datos. El equipo cambia la herramienta MCP interna que implementa la función de aptitud y la solicitud del arquitecto empresarial sigue siendo la misma.
Esto permite a los arquitectos empresariales establecer la gobernanza de manera efectiva. intención sin profundizar en los detalles de implementación, eliminando la fragilidad de las funciones de fitness de gran alcance y permitiendo una gobernanza holística mucho más proactiva por parte de los arquitectos de todos los niveles.
Definiendo las intersecciones de la arquitectura
En Arquitectura como códigoanalizamos nueve intersecciones diferentes con la arquitectura de software y otras partes del ecosistema de desarrollo de software (datos que representan una de ellas), todas expresadas como funciones de aptitud arquitectónica (la parte “código” de la arquitectura como código). Al definir la intersección de arquitectura y arquitecto empresarial, podemos utilizar MCP y agentes para indicar intención de manera integral, postergando los detalles reales a proyectos y ecosistemas individuales. Esto resuelve uno de los problemas persistentes de los arquitectos empresariales que desean crear circuitos de retroalimentación más automatizados dentro de sus sistemas.
MCP es casi ideal para este propósito, ya que está diseñado para exponer herramientas, fuentes de datos y bibliotecas de solicitudes a contextos externos fuera de un dominio de proyecto en particular. Esto permite a los arquitectos empresariales definir de manera integral una intención amplia y dejar que los equipos implementen (y evolucionen) sus soluciones.
X como código (dónde incógnita puede ser una amplia variedad de cosas) generalmente surge cuando el ecosistema de desarrollo de software alcanza un cierto nivel de madurez y automatización. Los equipos intentaron durante años hacer que la infraestructura como código funcionara, pero no lo hicieron hasta que aparecieron herramientas como Puppet y Chef que podían habilitar esa capacidad. Lo mismo ocurre con otras iniciativas “como código” (seguridad, políticas, etc.): el ecosistema necesita proporcionar herramientas y marcos que le permitan funcionar. Ahora, con la combinación de potentes bibliotecas de funciones de fitness para una amplia variedad de plataformas e innovaciones de ecosistemas como MCP y IA agente, la arquitectura en sí tiene suficiente soporte para unirse a las comunidades “como código”.
Obtenga más información sobre cómo la IA está remodelando la arquitectura empresarial en Software Architecture Superstream el 9 de diciembre. Únase al anfitrión Neal Ford y a un grupo de expertos que incluyen a Anjali Jain y Philip O’Shaughnessy de Metro Bank, Dom Sipowicz de Vercel, Brian Rogers de Intel, Ron Abellera de Microsoft y Lewis Crawford de Equal Experts para escuchar ideas obtenidas con esfuerzo sobre la creación de arquitecturas adaptables y listas para IA que respalden la innovación continua, garanticen la gobernanza y la seguridad, y alinearse perfectamente con los objetivos comerciales.
Los miembros de O’Reilly pueden registrarse aquí. ¿No eres miembro? Regístrese para una prueba gratuita de 10 días antes del evento para asistir y explorar todos los demás recursos sobre O’Reilly.
#Cómo #agente #potencia #gobernanza #arquitectura #OReilly
