Architecture pulled by need, tested at Gemba, governed through the Knowledge Base

Most architecture is pushed.

A central team develops models, principles, standards, roadmaps, patterns, diagrams, and governance artefacts. These may be technically correct. They may even be elegant.

But too often they arrive late, in the wrong form, for the wrong audience, and at the wrong level of detail.

The people doing the work are left with either too much architecture, too little, or architecture they cannot use.

That is how architecture becomes shelfware.

Kanban Architecture turns the logic around.

It treats architecture as something pulled by need, not pushed by function.

When people at Gemba need an architectural view to understand work, solve a problem, decide, test a change, or improve a process, they should be able to pull the knowledge they need in the form they can use.

Not as a theoretical model.

As workwear.

The basic idea

Kanban Architecture applies the Kanban logic of pull to organisational knowledge.

The question is not:

What architecture artefacts should the architecture function produce?

The better question is:

What architectural knowledge do people need, at the point of work, to understand, coordinate, improve, and adapt?

• A team aiming to improve a process might require a value stream overview.
• A data owner could need to understand the relationships defined by the Common Data Model behind a report.
• A manager might want to identify which capability is impacted by a system change.
• A product team may need to visualise where AI modifications influence work, decisions, data, accountability, and outcomes.
• A governance forum could require a consequence map prior to approving an intervention.
• Meanwhile, a frontline team might benefit from a straightforward working model that displays affected areas, ownership, involved data, underlying assumptions, and associated risks.

Kanban Architecture makes architectural knowledge available when the work demands it.

It assumes a foundation

Kanban Architecture is not architectural free-for-all. It assumes a stable foundation already exists.

That foundation includes:

• a Business Capability Model — what the organisation must be able to do
• a Common Data Model — what the organisation deals with and how meaning is structured
• a Knowledge Base / Knowledge Operating System — where shared models, definitions, assumptions, relationships, lessons, and patterns are governed and reused
• clear governance, decision rights, accountability, and stewardship
• enough trust for people to use the knowledge, test it, challenge it, and improve it

The foundation is crucial because pulling without structure leads to chaos. Conversely, structure without pull results in shelfware. Kanban Architecture bridges these two failures by using stable models to facilitate local adaptation.

The role of AI

AI changes what is possible.

In the past, architectural views were often expensive to produce, difficult to tailor, and slow to update. That encouraged centralised production and specialist control.

AI can help translate governed knowledge into usable working views.

It can help people ask:

• What capability is affected?
• Which value stream does this sit in?
• What business processes are involved?
• What data does this use or create?
• Which systems support the work?
• Who owns the decision?
• What assumptions are being made?
• What risks or unintended consequences might appear?
• What should be checked at Gemba?
• What does this mean for customers, staff, cost, compliance, learning, or trust?

Used well, AI becomes a translator between the Knowledge Base and the work.

• It does not replace architects.
• It does not replace judgement.
• It does not remove governance.
• It helps people create or adapt the architectural view they need, when they need it, at the level they can use.

The architect’s role changes. Architects become stewards of model integrity, coherence, patterns, quality, and learning. They do not have to draw every view themselves.

They have to make sure the views being pulled are grounded in the right knowledge.

Architecture at Gemba

Kanban Architecture belongs at Gemba.

• That is where work happens.
• That is where assumptions are tested.
• That is where gaps become visible.
• That is where people discover whether the model helps or gets in the way.

A model that cannot survive contact with work is not useless.

It is unfinished.

At Gemba, people can test whether the capability model explains the work, whether the value stream shows the real flow, whether the process model captures the real handoffs, whether the data model reflects actual meaning and redundancy, and whether the operating model explains decisions, accountability, risk, and consequence.

This is not a failure of architecture.

This is architecture learning.

The model goes to work, meets reality, gets challenged, and returns stronger.

The Ukraine lesson

This is not about romanticising war; it is about learning under consequence.

Ukraine’s defence has shown the importance of rapid adaptation, short feedback loops, bottom-up innovation, frontline learning, and the ability to quickly turn experience into changed practice. RAND describes Ukraine’s wartime experience as involving rapid technological development, informal innovation, and a need to strengthen the way lessons are captured and applied.

HCSS makes the same broader point: Ukraine’s rapid adaptation has been driven by short feedback loops, experimentation, innovation, leadership, training, and organisational adaptability.

NATO’s lessons-learned guide also frames Ukraine’s frontline experience as a source of learning for Ukraine, NATO allies, and partners, stressing the value of shared knowledge and situational awareness during crisis.

The lesson is not “copy the military.”

The lesson is this:

In rapidly evolving situations, survival hinges on individuals staying grounded in reality and sensing changes, adapting swiftly, improvising, testing new approaches, and refining them without waiting for the entire system to respond.

This demands a common purpose, shared skills, trust, autonomy, feedback, and sufficient structure to ensure coherent adaptations.

Kanban Architecture embodies this principle within organisational knowledge—avoiding endless approval processes and top-down architectural decisions. Instead, it relies on trusted individuals leveraging shared knowledge precisely when needed.

Pull, not chaos

Kanban Architecture doesn’t imply that everyone should create their own architecture. Doing so would recreate the chaos that architecture aims to resolve. Instead, the pull should originate from a governed Knowledge Base.

The Knowledge Base provides:

• common language
• capability structure
• CDM entities and relationships
• value streams
• business processes
• stakeholder perspectives
• KPIs
• system relationships
• cost and activity knowledge
• assumptions
• decision rights
• lessons learned
• governance patterns
• approved definitions and standards

People pull from that foundation.

AI helps shape what is pulled into a useful view.

Gemba tests whether the view is real.

Architects steward what is learned back into the model.

That is the learning loop.

A simple pattern

Kanban Architecture can be expressed as a working pattern:

1. Need appears at Gemba
   A team faces a decision, problem, improvement, risk, opportunity, or change.
2. Knowledge is pulled
   The team pulls relevant architectural knowledge from the Knowledge Base.
3. AI helps translate
   AI helps create a usable view: capability, value stream, process, CDM, decision map, consequence map, or operating model view.
4. People test the view
   The people doing the work test whether the view matches reality.
5. Action is taken
   The view supports improvement, decision-making, intervention, governance, or learning.
6. The Knowledge Base is updated
   What is learned returns to the shared model.

The point is not to produce more diagrams. The point is to make agile and responsive action possible.

What this changes

Kanban Architecture shifts the focus. Architecture is no longer solely created by specialists for organizational use. Instead, it becomes a resource that the organization actively employs. This doesn’t diminish the role of architects; it elevates it. As architectural knowledge is shared more broadly, the underlying models need to be consistent, governed, reliable, and practical. The architect’s role transforms from merely producing documents to acting as a steward of the organization’s understanding.

What it prevents

Kanban Architecture helps prevent several common failures:

• architecture produced too late to shape the decision
• models that are correct but unusable
• process changes disconnected from capability
• AI use disconnected from accountability
• data work disconnected from meaning and integrity
• governance based on presentation rather than consequence
• local improvement that damages the wider system
• transformation that removes the tacit knowledge holding the work together
• projects that deliver artefacts without building capability

It helps people see the system before they change the part.

The discipline required

Kanban Architecture needs discipline.

• Without discipline, it becomes random diagram generation.
• Without governance, it becomes local improvisation.
• Without trust, people will not expose what is really happening.
• Without data integrity, AI will translate confusion.
• Without Gemba, the model will drift away from reality.
• Without architects, the Knowledge Base will lose coherence.
• Without feedback, the organisation will not learn.

So, the formula is not:

AI plus architecture equals adaptation.

The formula is closer to:

Shared knowledge plus AI, tested at Gemba, governed through stewardship, and improved through use.

That is different.

And far more powerful.

Closing reflection

Kanban Architecture is driven by needs, shaped by context, tested at Gemba, governed by the Knowledge Base, and refined through use. Its goal isn’t to make the organization appear architected, but to enable people to understand their work sufficiently to improve it.

That is the shift:

• From shelfware to workwear.
• From expert artefact to shared knowledge.
• From architecture as documentation to architecture as learning infrastructure.
• From model control to model use.
• From central push to disciplined pull.
• From diagram to action.

Kanban Architecture is not architecture made smaller.

It is architecture made usable.

🤿 For a deep dive

• Subject Area: Enterprise Architecture — Foundation of Shared Knowledge
• Subject Area: Business Capability Model — Structuring What the Organisation Must Do
• Subject Area: Data Modelling — Negotiating Meaning

Explore further

This article connects to the broader framework:

• Ethical Domain — how constraints shape decisions
• Sensemaking Domain — how organisations interpret reality
• Relational Domain — how trust and coordination emerge
• Learning Domain — how knowledge is created and tested
• Action Domain — how intent becomes capability

To understand more on Purpose detailed Subject Areas, visit the Deep Dive section.

📖See the Books