Helix-The Architecture of Context

In the previous HELIX articles, we've explored a few ideas that are becoming central to how we think about architecture.

Artificial Intelligence shouldn't be treated as something separate from Enterprise Architecture.

Architecture begins with decisions.

And good decisions require us to understand the business value, trade-offs, and constraints surrounding them.

But there is something underneath all this that we don't always explicitly talk about.

Context.

Before we decide what to build, we need to understand where we are.

Before we decide which technology to use, we need to understand why we need it.

And before we decide whether a particular architecture is appropriate, we need to understand the environment in which it will operate.

This is where I believe context becomes one of the most important capabilities of an architect.

What Do We Mean by Context?

As architects, we work with context every day, even if we don't always explicitly call it out.

Context is the information that helps us understand what is happening, where we are, what matters, and why a particular decision may make sense.

For us, context can include:

Business objectives

Business capabilities

Organizational structure

Existing applications

Data

Infrastructure

Platforms

Security requirements

Regulatory constraints

Operational maturity

Available skills

Budget

Risk appetite

Customer expectations

Time horizon

None of these exist in isolation.

They interact.

And together they describe the environment in which our architecture has to work.

That's why two organizations can have exactly the same business problem and still require very different architectures.

The Same Decision Can Have Different Answers

Consider a simple question:

Should we move this workload to the cloud?

It sounds like a technology question.

But as architects, we know it isn't that simple.

What is the workload?

How sensitive is the data?

What regulations apply?

What infrastructure already exists?

What skills are available?

What is the expected growth?

What availability is required?

What does the business need over the next five years?

What will migration cost?

What will staying where we are cost?

Once we start asking these questions, the original question changes.

It is no longer:

"Should we use cloud?"

It becomes:

"Given our business, technical, financial, regulatory, and operational context, where does cloud make sense?"

That is an architectural question.

Context Makes Decisions Meaningful

We often hear statements such as:

"Cloud is better."

"Kubernetes is the way forward."

"Microservices are more scalable."

"AI should be everywhere."

These statements may be based on valid experiences.

But they aren't architectural decisions yet.

Architecture requires us to understand why something is appropriate.

And that "why" comes from context.

A technology can be technically excellent and still be the wrong choice for a particular organization.

Reference Architecture Is a Starting Point

Reference architectures are incredibly useful.

They give us proven patterns, common approaches, design principles, and lessons learned from previous implementations.

But we should be careful about treating them as blueprints that can simply be copied.

A reference architecture tells us:

"This approach has worked in a particular class of environments."

It doesn't automatically tell us:

"This is the right architecture for our organization."

As architects, we need to ask:

What is similar?

What is different?

Which assumptions still apply?

Which assumptions don't?

What constraints are different?

What needs to change?

The value of an architect is often found in that gap between reference and reality.

Architecture Is About Situational Awareness

I increasingly believe that one of the most important skills for an architect is situational awareness.

Not simply knowing what technologies exist.

Not simply knowing architecture frameworks.

But understanding what is happening around the system.

What is happening in the business?

What is changing?

What constraints are emerging?

What risks are increasing?

What capabilities are becoming strategic?

What assumptions are becoming outdated?

A technically strong architect without situational awareness can still make poor architectural decisions.

Because architecture is not designed in a vacuum.

Context Has a Time Dimension

There is another aspect of context that is easy to overlook.

Time.

An architecture that was right five years ago may not be right today.

That doesn't necessarily mean the original architecture was wrong.

The context may simply have changed.

The business may have grown.

The technology landscape may have changed.

Costs may have changed.

Regulations may have changed.

Security threats may have changed.

The organization's capabilities may have changed.

This is why architecture should not be treated as something that is "finished."

It needs to evolve with the environment around it.

Context Is Not Just Technical

One of the mistakes we can make as technical professionals is to define context primarily in technical terms.

But business context often matters more.

Imagine two organizations considering the same technology.

One is trying to reduce operational costs.

The other is trying to create a completely new revenue stream.

The technology may be identical.

The business objective isn't.

That changes how we evaluate value, risk, cost, speed, and even success.

Architecture therefore needs to connect technical context with business context.

Technology Without Context Becomes Technology-Driven Architecture

This is where things can go wrong.

A new technology appears.

It is exciting.

Everyone is talking about it.

Organizations begin asking:

"Where can we use this?"

The question has already been reversed.

Instead of:

Business problem → Capability → Architecture → Technology

we end up with:

Technology → Excitement → Search for a problem

We've seen this happen with many technologies.

AI makes this temptation even stronger because the pace of innovation is so high.

But "new" doesn't automatically mean "relevant."

The architect's responsibility is to understand where the technology belongs — and where it doesn't.

A Simple Context Lens

Before making an architectural decision, perhaps we should pause and ask five simple questions:

Business What are we trying to achieve?

Environment What exists today?

Constraints What limits our choices?

Capabilities What can the organization actually build and operate?

Time How might this context change?

These questions don't give us the answer.

They give us something more important.

They help us ask better questions.

The Connection to AI

This is where the idea becomes particularly interesting.

While exploring AI architecture, we have started talking increasingly about context.

An intelligent system needs more than a model.

It needs information about the situation surrounding the request.

Who is asking?

What are they allowed to access?

What business process are they involved in?

What organizational knowledge is relevant?

What policies apply?

What happened previously?

What is happening now?

This is where the idea of an AI Context Layer begins to emerge.

And this is where I think there is an interesting parallel between architecture and intelligence.

We as architects need context to make good decisions.

Intelligent systems need context to support useful decisions.

But is enterprise AI context simply RAG?

Or is it something much broader?

That's the question I want to explore next.

Part 2: From Context to Intelligence

In Part 2, we'll move from the context surrounding an architectural decision to the context required by an intelligent system.

We'll explore questions such as:

Is RAG enough to provide enterprise context?

Where do identity and permissions fit?

How do business processes become context?

What role does organizational knowledge play?

How should policies and governance become part of context?

Does operational state need to be part of an AI system's context?

Where does MCP fit?

How does context influence AI reasoning and actions?

And perhaps most importantly, who should own and govern enterprise context?

This is where I believe the architectural conversation around AI becomes much more interesting.

Closing Thought

We often ask:

"What should we build?"

Perhaps the better first question is:

"What is our context?"

Because without context, decisions become assumptions.

Without good decisions, architecture becomes technology selection.

And without architecture, even the most capable technology can struggle to create meaningful business value.

Context gives meaning to decisions.

And that is where we'll continue the HELIX journey in Part 2.

About Helix

HELIX is an evolving architectural framework that I am building to give structure and meaning to my thoughts, experiences, and continuous learning across Enterprise Architecture, Platform Engineering, and Artificial Intelligence.

This is my personal learning journey, and every article reflects my current understanding as HELIX continues to evolve