Soon after joining a new company in a chief architect role, I was asked to review an architecture pattern. The company was beginning an effort to build a new digital product portfolio, and reuse was a central part of the strategy for the broader transformation.
But it wasn’t framed as, “Do you think this is good?” It was framed more as, “This will work, right?” And a surprisingly large number of people wanted me to say yes.
There were, of course, clear problems.
The biggest was that it remained highly conceptual while collapsing specific technologies into the same construct.
But it didn’t matter. We had an enormous task ahead of us. Reuse was not going to matter for some time because we had complex things to build first, and I wasn’t going to fight a pattern battle yet.
Two years later, when we began implementing reuse, the pattern was still reasonably correct conceptually, but nonsensically off from an implementation standpoint. It stayed still, mired in conceptual irrelevance, while an enormous amount of engineering effort had moved forward instead.
This is where architecture patterns begin to break down, not because they are wrong, but because they remain at the level of concept.
The Problem of Conceptual Excess
I’ve written extensively about conceptual excess and will continue to do so. It’s not that I don’t see value in framing things conceptually. It’s just that when it comes to patterns, they have to be applied.
Architecture patterns have to hold up, which is challenging because they typically depend on a sense of stillness that rarely holds true in software engineering.
They can provide useful initial structure. But they only work when applied at the right level and at the right time.
When treated as complete solutions, they either become a problem or are already so unimportant that it doesn’t matter.
At the end of the day, a pattern should in some way specify that a computer is going to do something. If it doesn’t get to that point at some level, it’s probably nonsense.
To understand why, it helps to be precise about what an architecture pattern actually is.
What Is an Architecture Pattern
A Working Definition
Architecture patterns are typically advertised as recurring, proven solutions to common system design problems within a given context. They attempt to define the fundamental structural organization of a solution: the system, its components, their responsibilities, and how it all interacts.
They come in a few different sizes:
Architecture Style
An architecture style is a conceptual template for solving a structural problem (e.g., microservices, event-driven, layered). It’s best if these are technology- and vendor-neutral. They specify design approaches, ideally without telling you exactly how to implement a solution.
Reference Architecture
A reference architecture is a map of best practices for a specific domain or technology stack. They tend to be more specific than architecture styles and often include specific product lists, such as an e-commerce reference architecture using AWS.
Implementation Framework
An implementation framework is typically a large collection of principles, templates, checkboxes, and guardrails for evaluating an architecture and providing scaffolding for implementation. They tend to be evaluative and normative, telling you how to approach and measure effectiveness with a vendor solution (e.g., AWS WAF).
These distinctions are useful, but they don’t tell you how patterns actually function once work begins.
How Patterns Work in Practice
Architects often use patterns to pre-shape the space in which problems will be solved. This typically focuses on what kinds of components will exist, how they are allowed to interact, where boundaries are drawn, and what tradeoffs are acceptable.
Ideally, they don’t simply say, “Use publish-subscribe.” They say, “Components should not call each other directly; they should communicate through events.” That’s a constraint that implies the pattern.
Meanwhile, developers tend to use patterns implicitly and inferentially. They don’t say, “Let’s introduce a cache-aside pattern.” They say, “We should use cache-aside for performance, so the cache is populated on demand instead of loading everything into memory.”
If we want patterns that are useful, we have to address both perspectives. Because when those perspectives align, patterns can be genuinely useful.
Good Architecture Patterns
Some patterns are durable because they balance architecture and implementation. A few examples at varying levels of scope include publish-subscribe, pipes and filters, model-view-controller, and pilot light.
More recently, patterns for incorporating generative AI into enterprise systems are taking shape, although many echo long-standing staples of computer science and systems engineering.
To make this concrete, consider Retrieval-Augmented Generation (RAG).
Example: Retrieval-Augmented Generation (RAG)
How the Pattern Works
This pattern combines a generative model with a retrieval layer that selects and injects relevant external knowledge at query time. This allows the system to generate responses grounded in current data while preserving the model’s ability to reason and compose language.
That structure only matters if it produces meaningful outcomes.
Why It Works at a Business Level
It works at a business level because it keeps enterprise data under control rather than embedding it in the model. It supports governance, auditability, and updates, reduces cost compared to continuous fine-tuning, and aligns with how organizations already manage information across documents, records, and systems of record.
In short, RAG separates knowledge from generation, allowing systems to stay current and controlled without retraining the model.
At its simplest, the pattern operates as follows:
Basic Flow
- Retrieve relevant documents or data
- Inject that context into the prompt
- Generate a response grounded in that context
Underneath that simplicity is a set of important technical constraints.
Why It Works Technically
It works technically because it separates model capability from the knowledge source, avoiding retraining for every update while improving accuracy and reducing hallucination risk.
It also forces explicit handling of context, ranking, and relevance, which introduces some latency and complexity and makes retrieval quality and underlying data quality critical dependencies. Overall, the tradeoff is clear: you gain accuracy, control, and flexibility at the cost of added latency and system complexity.
Why This Is a Good Pattern
It captures the core structure of the approach, consisting of the model, retrieval, and context assembly, while making the tradeoffs explicit. It is fundamentally technology-agnostic, even as tools evolve, and reflects a stable constraint that models do not inherently know your data.
What to Watch Out For
It goes wrong when it’s treated as plug-and-play, with poor retrieval quality, weak handling of ranking and chunking, and no clear data boundaries, while also being mistaken for a complete system rather than a component pattern.
Even with those risks, the pattern provides directionality and enough technical detail to scaffold this type of capability within a system.
Not all patterns hold up this well in practice, though.
Bad Architecture Patterns
What Makes a Pattern Bad
A bad architecture pattern usually starts by pretending to be more complete than it is. It gets packaged as a solution instead of directionality, so teams adopt it without understanding where it applies, where it doesn’t, and what must surround it to make it work.
The pattern hides its assumptions, skips over boundary conditions, and collapses important concerns such as data ownership, lifecycle, and operational behavior into something that looks deceptively simple.
What you end up with is not guidance but aphorisms, and this received wisdom doesn’t survive sustained contact with real systems.
Why Bad Patterns Fail in Practice
Technically, bad patterns fail because they ignore the mechanics that actually make systems work. They gloss over how data is shaped and retrieved, how decisions are made about relevance and timing, and how failure modes are handled when dependencies degrade or disappear.
They create the illusion of reuse while introducing hidden coupling and operational fragility, often shifting complexity into places that are harder to observe and control. Whereas a good pattern constrains and clarifies, a bad one obscures and defers, leaving the hard parts for later.
A well-known example illustrates this problem clearly.
Example: The Strangler Fig Pattern
The Strangler Fig Pattern2 is a migration approach, defined through a clever metaphor, in which parts of a legacy system are replaced over time.
The idea is that instead of replacing a large system all at once, a new one can be built around the edges of the old one.
How It Works
A typical architecture following this pattern will use some type of proxy layer in front of both the old and new systems to intercept and route requests based on a mapping of feature sets. It might involve two completely separate systems or one system being modularized.
While it may sound logical, tempting even, the Strangler Fig Pattern is laughingly unlikely to work at scale on even mildly sophisticated systems.
What almost invariably happens is that the new effort is abandoned because of the overly simplistic pattern, and instead of one system you hate, you now have two, plus some type of integration system or subsystem you probably hate even more.
The issue is not the idea of incremental replacement itself, but how the pattern frames it.
Why This Is a Bad Pattern
As an incremental replacement approach, the Strangler Fig Pattern misrepresents how complex systems actually behave. While it describes an elegant, albeit overly simplistic modernization strategy, it also obscures the staying power of almost every existing system and the organization that maintains it.
Treating a large system as something that can simply be incrementally replaced over time turns a difficult structural problem into a comforting metaphor that, invariably, will not survive contact with the source system.
What to Watch Out For
When confronted with overly simplistic, conceptual architecture patterns, look at them pragmatically. Maybe one will inspire direction or at least provide a starting point for a solution. Just be careful not to fall for the trap of conceptual excess.
But overall, patterns need a structure to attach to.
Bringing Patterns Back to the Architecture Blueprint
This evaluation has focused on architecture patterns that are well known and, in some cases, common across industry, computer science, and software engineering. But there is another kind of pattern that is far more useful in practice.
As you formalize your architecture into a blueprint form, you have the opportunity to leverage that load-bearing structure for repeatability. You can align architecture styles generally, associate them with types of assets, and apply them directly to specific assets.
We will cover how to develop the architecture blueprint top down and bottom up, and how to use it in a middle-out manner that incorporates patterns and standards, in the article Applying Patterns and Standards Through the Architecture Blueprint.
The Computer Is Going to Do Something
Join me in an ongoing, practical examination of enterprise architecture, systems engineering, and technology operations.
Notes:
1. Headline image generated by Gemini and ChatGPT.
2. Strangler Fig Pattern (Wikipedia) accessed April 28, 2026.
Leave a Reply