Max Headroom 
UNCLASSIFIED
One of the principles in our upcoming book Architecture as Code is the ability for architects to design automated governance checks for important architectural concerns, creating fast feedback loops when things go awry. This idea isn’t new—Neal and his coauthors Rebecca Parsons and Patrick Kua espoused this idea back in 2017 in the first edition of Building Evolutionary Architectures, and many of our clients adopted these practices with great success. However, our most ambitious goals were largely thwarted by a common problem in modern architectures: brittleness. Fortunately, the advent of the Model Context Protocol (MCP) and agentic AI have largely solved this problem for enterprise architects.
Fitness Functions
Building Evolutionary Architectures defines the concept of an architectural fitness function: any mechanism that provides an objective integrity check for architectural characteristics. Architects can think of fitness functions sort of like unit tests, but for architectural concerns.
While many fitness functions run like unit tests to test structure (using tools like ArchUnit, NetArchTest, PyTestArch, arch-go, and so on), architects can write fitness functions to validate all sorts of important checks…like tasks normally reserved for relational databases.
Fitness functions and referential integrity
Consider the architecture illustrated in Figure 1.
In Figure 1, the team has decided to split the data into two databases for better scalability and availability. However, the common disadvantage of that approach lies with the fact that the team can no longer rely on the database to enforce referential integrity. In this situation, each ticket must have a corresponding customer to model this workflow correctly.
While many teams seem to think that referential integrity is only possible within a relational database, we separate the governance activity (data integrity) from the implementation (the relational database) and realize we can create our own check using an architectural fitness function, as shown in Figure 2.
In Figure 2, the architect has created a small fitness function that monitors the queue between customer and ticket. When the queue depth drops to zero (meaning that the system isn’t processing any messages), the fitness function creates a set of customer keys from the customer service and a set of customer foreign keys from the ticket service and asserts that all of the ticket foreign keys are contained within the set of customer keys.
Why not just query the databases directly from the fitness function? Abstracting them as sets allows flexibility—querying across databases on a constant basis introduces overhead that may have negative side effects. Abstracting the fitness function check from the mechanics of how the data is stored to an abstract data structure has at least a couple of advantages. First, using sets allows architects to cache nonvolatile data (like customer keys), avoiding constant querying of the database. Many solutions exist for write-through caches in the rare event we do add a customer. Second, using sets of keys abstracts us from actual data items. Data engineers prefer synthetic keys to using domain data; the same is true for architects. While the database schema might change over time, the team will always need the relationship between customers and tickets, which this fitness function validates in an abstract way.
Who executes this code? As this problem is typical in distributed architectures such as microservices, the common place to execute this governance code is within the service mesh of the microservices architecture. Service mesh is a general pattern for handling operational concerns in microservices, such as logging, monitoring, naming, service discovery, and other nondomain concerns. In mature microservices ecosystems, the service mesh also acts as a governance mesh, applying fitness functions and other rules at runtime.
This is a common way that architects at the application level can validate data integrity, and we’ve implemented these types of fitness functions on hundreds of projects. However, the specificity of the implementation details makes it difficult to expand the scope of these types of fitness functions to the enterprise architect level because they include too many implementation details about how the project works.
Brittleness for metadomains
One of the key lessons from domain-driven design was the idea of keeping implementation details as tightly bound as possible, using anticorruption layers to prevent integration points from understanding too many details. Architects have embraced this philosophy in architectures like microservices.
Yet we see the same problem here at the metalevel, where enterprise architects would like to broadly control concerns like data integrity yet are hampered by the distance and specificity of the governance requirement. Distance refers to the scope of the activity. While application and integration architects have a narrow scope of responsibility, enterprise architects by their nature sit at the enterprise level. Thus, for an enterprise architect to enforce governance such as referential integrity requires them to know too many specific details about how the team has implemented the project.
One of our biggest global clients has a role within their enterprise architecture group called evolutionary architect, whose job is to identify global governance concerns, and we have other clients who have tried to implement this level of holistic governance with their enterprise architects. However, the brittleness defeats these efforts: As soon as the team needs to change an implementation detail, the fitness function breaks. Even though we often couch fitness functions as “unit tests for architecture,” in reality, they break much less often than unit tests. (How often do changes affect some fundamental architectural concern versus a change to the domain?) However, by exposing implementation details outside the project to enterprise architects, these fitness functions do break enough to limit their value.
We’ve tried a variety of anticorruption layers for metaconcerns, but generative AI and MCP have provided the best solution to date.
MCP and Agentic Governance
MCP defines a general integration layer for agents to query and consume capabilities within a particular metascope. For example, teams can set up an MCP server at the application or integration architecture level to expose tools and data sources to AI agents. This provides the perfect anticorruption layer for enterprise architects to state the intent of governance without relying on implementation details.
This allows teams to implement the type of governance that the strategically minded enterprise architects want but create a level of indirection for the details. For example, see the updated referential integrity check illustrated in Figure 3.
In Figure 3, the enterprise architect issues the general request to validate referential integrity to the MCP server for the project. It in turn exposes fitness functions via tools (or data sources such as log files) to carry out the request.
By creating an anticorruption layer between the project details and enterprise architect, we can use MCP to handle implementation details so that when the project evolves in the future, it doesn’t break the governance because of brittleness, as shown in Figure 4.
In Figure 4, the enterprise architect concern (validate referential integrity) hasn’t changed, but the project details have. The team added another service for experts, who work on tickets, meaning we now need to validate integrity across three databases. The team changes the internal MCP tool that implements the fitness function, and the enterprise architect request stays the same.
This allows enterprise architects to effectively state governance intent without diving into implementation details, removing the brittleness of far-reaching fitness functions and enabling much more proactive holistic governance by architects at all levels.
Defining the Intersections of Architecture
In Architecture as Code, we discuss nine different intersections with software architecture and other parts of the software development ecosystem (data representing one of them), all expressed as architectural fitness functions (the “code” part of architecture as code). In defining the intersection of architecture and enterprise architect, we can use MCP and agents to state intent holistically, deferring the actual details to individual projects and ecosystems. This solves one of the nagging problems for enterprise architects who want to build more automated feedback loops within their systems.
MCP is almost ideally suited for this purpose, designed to expose tools, data sources, and prompt libraries to external contexts outside a particular project domain. This allows enterprise architects to holistically define broad intent and leave it to teams to implement (and evolve) their solutions.
X as code (where X can be a wide variety of things) typically arises when the software development ecosystem reaches a certain level of maturity and automation. Teams tried for years to make infrastructure as code work, but it didn’t until tools such as Puppet and Chef came along that could enable that capability. The same is true with other “as code” initiatives (security, policy, and so on): The ecosystem needs to provide tools and frameworks to allow it to work. Now, with the combination of powerful fitness function libraries for a wide variety of platforms and ecosystem innovations such as MCP and agentic AI, architecture itself has enough support to join the “as code” communities.
Learn more about how AI is reshaping enterprise architecture at the Software Architecture Superstream on December 9. Join host Neal Ford and a lineup of experts including Metro Bank’s Anjali Jain and Philip O’Shaughnessy, Vercel’s Dom Sipowicz, Intel’s Brian Rogers, Microsoft’s Ron Abellera, and Equal Experts’ Lewis Crawford to hear hard-won insights about building adaptive, AI-ready architectures that support continuous innovation, ensure governance and security, and align seamlessly with business goals.
O’Reilly members can register here. Not a member? Sign up for a 10-day free trial before the event to attend—and explore all the other resources on O’Reilly.
AI & ML, Research
Radar
