The architecture of Adaptive Software Systems

In Implementing Adaptive Software Delivery: Six Strategies, we examined how organizations build adaptability across culture, decision-making, collaboration, delivery, and user engagement. Of these strategies, one serves as the foundation: Create options enabling architectures.

Adaptive delivery requires optionality, which is sustainable only when the system’s architecture makes change safe, fast, and cheap. This is the point of Option-Enabling Architecture (OEA), Flexion’s evolution of Robert C. Martin’s Clean Architecture. Martin argues that software succeeds by keeping options open as long as possible. His ideas greatly influenced Flexion. OEA builds on his teachings and adapts them to the challenges we faced when building systems for our clients.

Clean architecture

Traditional architectural approaches rely heavily on up-front structural design, identifying layers, defining abstractions, and trying to lock in an ideal high-level structure early. But real systems rarely behave as early assumptions predict. Requirements shift, stakeholders reinterpret priorities, integrations evolve, and new technologies continuously disrupt the landscape.

Clean Architecture offered an alternative, emphasizing the dependency rule (“higher-level policies should not depend on lower-level details”) to help teams preserve flexibility. But the industry often misinterprets Clean Architecture as a template describing fixed concentric rings, suggesting predefined folder structures. As Flexion learned through years of teaching and applying Clean Architecture, those interpretations sometimes led to rigidity rather than flexibility.

To be clear, that misinterpretation was ours, not Martin’s. Clean Architecture itself leans heavily on refactoring and emergent design. But when we taught it internally, many people fixated on the diagrams in Martin’s book as something to implement up front. OEA is our way of reframing those same underlying principles into a small set of rules and practices that make emergent, refactoring-based architecture more natural in day-to-day work.

OEA is our practical evolution of Martin’s ideas: a refactoring-based, emergent architectural discipline that:

• Avoids defining structure up front
• Allows real change to reveal real boundaries over time
• Enables architecture to scale both up (to enterprise patterns) and down (to individual functions)

This is precisely the spirit of our six strategies, which assert that adaptability requires separating the what from the how, designing as you go, and evolving systems as their context evolves.

Architecture for anything with structures of varying importance

While OEA originated as a software practice, its principles apply to any system with structure, whether technical, organizational, or experiential. The key observation is simple:

When components vary in business importance, more important ones should not depend on less important ones.

You don’t want changes in less important tactics (that can happen more frequently) to require changes in strategic behaviors. This creates risk and fear, along with the unintended side effects and bureaucracy that accompany them.

OEA’s rules apply wherever this importance variance exists:

• In software (domain logic vs. UI details)
• In business processes (policy decisions vs. workflow preferences)
• In product design (core metaphors vs. surface styling)
• In enterprise architecture (mission-critical capabilities vs. tactical technologies)

Examples range from aircraft systems to video games to insurance platforms. These are structures where some elements must remain stable while others evolve.

In that sense, OEA is less an invention than an application of how resilient and adaptive systems are generally composed. Its unique benefit lies in capturing a structural pattern found in many domains: it safeguards more important behaviors by insulating them from frequent, noisy changes at the edges.

In other words, OEA is not about code. It is about the general system structure under uncertainty.

Growing an architecture

It starts with being deliberate about when to introduce a new process or component. The principle is simple: we want as few discrete processes as possible, but we don’t want changes for one set of interests, for example, claims policy, to put at risk the behaviors required by a different, independent set of interests, such as security. Robert Martin calls these distinct sources of change, usually tied to a particular stakeholder or role, “axes of change.”

We group behaviors driven by a single axis of change into a single component to keep the number of components low. But when a module blends behaviors belonging to different axes of change, we split it into separate components so each interest has its own space and changes that don’t affect the others.

In practice, we often start with a single process and split it only when new axes of change emerge within it. This process causes the system to grow and differentiate, like a biological organism developing through embryonic development. We don’t create a holistic architecture up front. Instead, we grow it by exercising discipline at module boundaries at all scales in direct response to stakeholder interactions and evolving needs.

The graphic illustrates a fundamental shift in perspective: from Clean Architecture’s system-level view, shown as concentric rings on the left, to a zoomed-in focus on refactoring the boundary between any two adjacent processes on the right. It’s easy to see how Clean Architecture is naturally associated with defining a system’s overall structure, while OEA emphasizes the repeated application of local boundary rules. Over time, these local improvements cause an application-specific architecture to emerge.

OEA’s three rules: Small, powerful, and universal

OEA isn’t simply about adding boundaries to your system; everyone does that. It’s about finding the right boundaries and ensuring that every dependency across them flows in the right direction. Once a process splits into two adjacent ones, we create option enabling boundaries between them by following three rules:

1. The Dependency Rule

Martin’s original rule says that “source code dependencies must point only inward, toward higher-level policies.” We reframe this as “more important structures must not depend on less important ones.” Importance is defined from the business’s point of view, so critical behaviors stay insulated from tactical churn.

2. The Good-Fences Rule

Boundaries between processes and components should be simple and testable. This makes it easy to replace implementations, evolve designs, or explore options.

3. The Invasive-Species Rule

Third-party tools, frameworks, and other external dependencies must not “invade” the entire system; they should be localized to as few modules as possible, ideally to a single module. Otherwise, they permeate the structure, creating exposure to external risks and limiting your options.

These rules are applied through continuous refactoring as new requirements, discoveries, and axes of change emerge. OEA encourages teams to identify desire paths in real system use and align the structure accordingly.

Refactoring as the engine of adaptive architecture

OEA assumes:

• You cannot reliably predict future change
• You should not build for speculative needs
• You can, however, shape architecture through ongoing micro adjustments

In a recent article, “Why Does Development Slow?”, Kent Beck argues that we keep software adaptable by “tidying,” meaning small, continuous refactorings that restore lost optionality as systems evolve. OEA is our disciplined approach to doing precisely that: tidying not just code within modules, but the boundaries and dependencies between them so that optionality is preserved at every scale.

None of this is the industry norm. There are two prevailing patterns. First, dependency direction is not dictated by level of importance, but by the direction of process invocation; the invoker depends on the invokee. Second is framework-centric; pick a popular framework, follow its defaults, and hope your people don’t have to think too hard about structure. That can feel efficient in the short term, but it quietly allows tools and vendors to dictate architecture and become liabilities or vulnerabilities when you can least afford it.

OEA goes the other way. It expects teams to consider axes of change, levels of importance, and directions of dependency. That means there is a learning curve. It takes intentional up‑front effort, training, and new routines in code reviews and design conversations to make OEA a habit rather than an exception. The payoff is an architecture that remains adaptable long after frameworks and fashions change.

This mirrors how Clean Architecture itself describes architecture as the discipline of “leaving options open”, Martin’s core insight. OEA operationalizes that insight through everyday behaviors.

As new user stories arrive, user needs evolve, and integrations introduce new constraints, the system’s boundaries and dependencies are reshaped through refactorings. Teams split modules when multiple axes of change creep in. They merge modules when things change for the same reason. They adjust boundaries to maintain a healthy dependency path.

The result isn’t a planned architecture. It is an emergent one, an architecture that fits the system’s lived trajectory.

OEA works at every scale

Most architectural methods address one scale: application-level structure. OEA is unique in that it applies equally well to:

• A single function
• A class or module
• A microservice or bounded context
• A product ecosystem
• An entire enterprise architecture

Because the rules are local and importance-based, OEA uniquely enables systems of any scale to preserve essential business agility and adaptability, regardless of how technology or requirements evolve.

For example:

• At the function level, OEA helps avoid tangling domain logic with tactical input and output behaviors
• At the application level, it ensures business rules never depend on frameworks
• At the enterprise level, it prevents mission-critical systems from being governed by tactical vendor choices

This multi-scale applicability is why Flexion describes architecture as “anything with structure,” not merely software.

OEA in the age of AI

Because OEA predates the current AI wave, it’s easy to wonder whether the rise of AI models and AI agents makes these ideas obsolete. In reality, it does the opposite: it makes them more critical.

OEA focuses on the structure of interdependent components in systems and systems-of-systems, regardless of how those components are implemented. It doesn’t care whether compiled code, a serverless function, a SaaS product, an LLM, or a human-run process carries out a behavior. What matters is which pieces depend on each other and which should be insulated from which, based on their relative importance to the organization.

It’s a fallacy to imagine a future where we simply ask AI to “build the complete system” and call it done. There is no objective boundary to the system, and we don’t expect a single AI model to replace the entire planet of interacting software. Models and agents will have scope and be components within larger integrated structures, much as human brains are nodes in today’s socio-economic and ecosystem networks.

That means tomorrow’s software architectures will be large, heterogeneous networks of components, some of which will be AI models and AI agents, sitting alongside conventional services, databases, commercial off-the-shelf (COTS) products, and human workflows.

OEA still applies:

• The dependency rule helps ensure core policies and mission-critical capabilities do not depend on any particular AI model or vendor API
• The good-fences rule encourages simple, explicit contracts around AI-powered components so they can be swapped, experimented with, or rolled back safely
• The invasive-species rule pushes teams to wrap AI and COTS tools with adapters so they don’t silently shape and unsafely influence the entire system

AI doesn’t replace architecture. AI becomes another participant in the architecture. OEA provides the discipline to safely plug powerful, unpredictable components, such as AI models, into a broader system without letting them dictate the structure or lock you into a path you later regret.

Why OEA matters for business leaders

Adaptive organizations win not by predicting correctly, but by positioning themselves to adapt rapidly regardless of what happens. OEA directly enables:

Faster pivots

OEA allows teams to pivot focus or functionality without tearing apart what’s already built. For example, when our CMS Modern Claim Adjudication Development Services (MCADS) client shifted priorities from dental to professional claims, the OEA-based system pivoted in a single sprint.

Parallel paths

OEA makes this possible by defining boundaries that cleanly separate what from how, enabling multiple hows simultaneously. In one of our projects with CMS Data Systems Architecture Modernization (DSAM), three AWS runtimes (EC2, Lambda, Batch) were tested in parallel until one met all requirements and withstood the operational stress.

Reduced rewrite risk

Systems evolve and modernize continuously rather than accumulating structural debt that eventually forces a ground-up rebuild.

Strategic optionality

The organization retains the freedom to adopt new tools, integrate new partners, plug in AI models, and respond to new regulations without disruption.

This is exactly the outcome the Six Strategies article describes when urging organizations to “separate core from tactical concerns, avoid uncontrolled dependencies and keep boundaries simple and testable.”

OEA is the practical, operational method for doing so.

Conclusion: Architecture as an adaptive advantage

Robert C. Martin taught the software world that architecture is not about today’s decisions. It is about preserving tomorrow’s choices. OEA extends and operationalizes that principle in complex, living environments where change is continuous, multi-directional, and unpredictable.

By making architecture emergent, importance-driven, and refactoring-centered, OEA allows organizations to:

• Move faster
• Reduce risk,
• Capitalize on uncertainty
• Keep options open at every level of the enterprise

In a world where disruption is constant and AI is accelerating it, OEA transforms architecture from a constraint into a strategic advantage. The next time you design a system, ask not just “will this work?” but also “can this adapt forever?”

Explore our case studies to learn how Flexion applies OEA to help clients respond to change, reduce risk, and move fast in complex environments.