Discovering Architecture
While building products, I often find myself searching for patterns rather than solutions.
A solution solves a problem, and pattern explains why similar problems keep arriving at similar solutions.
Recently I noticed something interesting, different industries, different technologies, different objectives, yet somehow they all seem to move towards the same destination: Architecture.
At first glance this sounds obvious, buildings have architecture, software has it too, and businesses have organizational structures.
But the more I looked at it, the more I realised architecture might be much bigger than any individual discipline, perhaps architecture is not something we build. Perhaps architecture is something we discover.
More Than Buildings
Most people hear the word architecture and immediately think of buildings, blueprints, construction sites, engineering calculations., physical structures, yet buildings are merely one expression of architecture.
If we remove the concrete, steel, glass and materials, something interesting remains; A set of relationships, rules, and intentional decisions that determine how individual parts contribute to a larger whole. That idea can exist almost anywhere.
- City has architecture.
- Business has it.
- website has architecture.
- So does software platform. And even knowledge itself can be architected.
The physical structure is simply one manifestation of a much deeper concept. Architecture is ultimately the organisation of complexity, and it seems to appear wherever humans attempt to create something meaningful at scale.
The Problem That Repeats Itself
One thing I've learned while building products is that complexity rarely arrives all at once.
It accumulates.
- Feature becomes ten features.
- Page becomes one hundred pages.
- Customer becomes a thousand customers.
- Decision becomes a process, and later an operation
Growth creates complexity. Complexity creates uncertainty. Uncertainty creates friction.
Eventually every successful system encounters the same question. How do we continue growing without losing control? This is where architecture enters the conversation. Not because architecture is fashionable, but because it becomes necessary, without structure, complexity eventually overwhelms the system that created it.
This pattern appears repeatedly throughout technology, the solutions change and underlying problem remains remarkably consistent.
Software Architecture
Software engineering provides one of the clearest examples when developers first begin writing software, the focus is often on implementation;
Can the feature work?
Can the application run?
Can the problem be solved?
These are important questions. However, they eventually become insufficient, ss systems grow, the challenge shifts, and the question is no longer whether software works today - it becomes whether software can continue working tomorrow...
Or next year. Or after ten additional teams begin contributing to it, this is where Software Architecture emerges, concepts such as modularity, separation of concerns, service boundaries and component design were not invented to impress engineers.
They emerged because complexity demanded structure, the architecture became more important than the code itself. The code was merely the material. The architecture determined how the material behaved.
Domain-Driven Design and Meaning
One supporting pattern that fascinates me is Domain-Driven Design (DDD). DDD encourages teams to model software around real-world concepts rather than technical implementation details. At first this sounds like common sense, yet many systems are designed around databases, frameworks, and technical shortcuts rather than actual business understanding.
DDD attempts to reverse this. It places language at the centre of architecture:
- Meaning before implementation.
- Understanding before construction.
What I find interesting is that this principle extends far beyond software. The strongest startups often behave similarly. They understand the problem deeply before optimising the solution. They design around reality rather than convenience.
Again, architecture emerges, not through technology, but through understanding.
APIs, SDKs and Reusable Thinking
The internet itself provides another fascinating example. Imagine if every application had to reinvent communication from scratch:
- Every integration.
- Every connection.
- Every interaction.
The modern internet would not scale.
Instead, industries adopted APIs (Application Programming Interfaces). APIs create structure between systems. They define:
- Expectations.
- Responsibilities.
- Boundaries.
- Rules of engagement.
SDKs (Software Development Kits) build upon the same idea. They package knowledge into reusable components so future builders do not need to start from zero.
Both APIs and SDKs demonstrate a recurring principle: architecture is often less about creation and more about coordination. The better the architecture, the easier it becomes for independent systems to work together.
Design Systems Are Architecture for Creativity
One of the most misunderstood examples of architecture may be Design Systems. Some people view them as collections of reusable components:
- Buttons.
- Forms.
- Layouts.
- Design tokens.
- Style guides.
But that description misses the bigger picture.
A design system is not primarily about consistency. It is about scalability. Without a design system:
- Every designer solves the same problem repeatedly.
- Every team invents its own conventions.
- Every project creates new complexity.
Design systems convert creativity into reusable assets. They create shared language, shared expectations, and shared patterns.
Paradoxically, structure enables more creativity because less energy is spent rebuilding foundations. The architecture absorbs the repetition, allowing humans to focus on innovation.
Infrastructure as Code
Infrastructure as Code (IaC) provides another compelling example. Historically, infrastructure was configured manually. Servers were provisioned individually, settings existed inside documentation or people's memories, scaling became difficult, and reliability became inconsistent.
Then a shift occurred. Infrastructure itself became:
- Structured.
- Versioned.
- Documented.
- Reusable.
Infrastructure stopped being a collection of machines. It became architecture, a blueprint capable of reproducing itself.
This idea continues to influence cloud computing today because it transforms operational knowledge into repeatable systems. Again, architecture appears as a response to complexity.
Content, Knowledge and AI
The same evolution is happening within content. Many websites still think in pages. Modern systems increasingly think in models:
- Articles.
- Authors.
- Products.
- Categories.
- Relationships.
- Metadata.
- Taxonomies.
- Knowledge graphs.
These concepts may sound technical, but they all solve the same challenge:
How do we organise information so it remains meaningful as it grows?
This question has become even more relevant in the age of AI. Artificial Intelligence systems perform best when information has structure. Relationships matter. Context matters. Metadata matters.
The future of intelligent systems may depend less on the quantity of information and more on the quality of its architecture. Once again, architecture appears where complexity expands.
Maybe Architecture Is a Natural Outcome
The more examples I encounter, the harder it becomes to ignore the pattern.
- Buildings.
- Software.
- Design systems.
- APIs.
- Infrastructure.
- Content.
- Knowledge.
- Artificial intelligence.
Different industries. Different terminology. Yet they repeatedly arrive at similar conclusions:
- Structure scales.
- Patterns preserve understanding.
- Architecture reduces ambiguity.
Perhaps this is why mature industries eventually become architectural. Not because architecture is trendy, and not because architects influence every field, but because complexity forces us to think in systems.
And systems require structure.
When Architecture Becomes Complexity
There is, however, a counterargument worth exploring.
If architecture is so valuable, why do some of the world's most successful systems feel overwhelmingly complex?
Take Google as an example. Many builders will remember using Google Analytics years ago when it felt comparatively straightforward. Today, the ecosystem surrounding analytics, advertising, tagging, reporting, attribution, integrations, APIs, and data pipelines is significantly larger.
For some users, it feels unnecessarily complicated. For others, incredibly powerful. Both perspectives may be correct.
Is complexity evidence of poor architecture, or can it be the result of successful architecture operating at extraordinary scale?
As systems grow, new requirements emerge:
- New customers.
- New regulations.
- New integrations.
- New expectations.
Every addition introduces complexity. Architecture does not eliminate it; it attempts to organise it.
Google did not become complex by accident. Its products evolved alongside billions of users, millions of businesses, and decades of technological change. The challenge was never simplicity, but maintaining usefulness while expanding capability.
That distinction matters. Architecture is often misunderstood as a path to simplicity. I increasingly see it as a framework for surviving complexity.
Perhaps that is why concepts such as:
- Domain-Driven Design.
- Software Architecture.
- Design Systems.
- APIs.
- Infrastructure as Code.
continue appearing across industries. They are not attempts to avoid complexity, but to organise it.
The question is no longer whether complexity will arrive. The question becomes whether our architecture will be prepared when it does.
Closing Thoughts
I don't think architecture is reserved for engineers, designers, or planners.
It is a way of thinking. A way of approaching complexity before it approaches us.
The more I build, the more I look for the structures behind successful outcomes:
- Systems behind products.
- Patterns behind processes.
- Structures behind scale.
Maybe architecture exists everywhere because complexity exists everywhere. Or perhaps it simply emerges when we build with intention.
If you've encountered similar patterns in your work, I'd be interested to hear your perspective.
Connect with us or visit the Proposal page.
- Challenge the idea.
- Expand it.
- Introduce a pattern I haven't considered.
Some of the most useful architectures begin as conversations.
Top comments (0)