A thought: Could language be the new architecture?

What if we stop treating organisations as machines or even as living systems, and instead view them as collections of conversations, vocabularies, and narratives that shape how value is understood, created, and exchanged?

What would this be like?

How would this Language-Based Analysis (LBA) manifest; how would it work? Instead of mapping: Systems, functions, and capabilities, we might map:

• meanings
• terms
• framings
• narratives
• spoken/written interactions
• data vocabularies and taxonomies

And then ask:

What language is used by each actor to describe their world, and how does that language shape (or distort) the exchange of value?

How is this different from traditional enterprise architecture (EA)?

I guess there would be similar but different tasks:

Where would LBA fit in the enterprise transformation?

We would engage our customers with an LBA approach:

• Instead of as-is/to-be capability maps?
• Before any tech re-platforming?
• As the foundational diagnosis of misalignment between business and data, policy and digital, or product and customer?
• To make visible the invisible contracts that define how value is exchanged or perceived?

Example: Supply chain transformation via Language-Based Analysis

We were looking back at large scale transformations over the years and considering the example of a supply-chain transformation at a major FMCG company (this is where this whole idea begins to seem bonkers).

A company like this will have a complex, global supply chain – with dozens of factories, thousands of suppliers, and millions of customer touchpoints.

In a traditional enterprise architecture approach, the supply chain might be broken down into functional components like:

“Procurement → Manufacturing → Logistics → Warehousing → Distribution”

But in a Language-Based Analysis (LBA) approach, we don’t start with structure – we start with conversation.

We’d start by analysing what do the teams actually say?

Instead of mapping process flows, we’d begin by analysing the language used by each part of the supply chain, for example:

Demand planning team: Talks in terms like “confidence intervals,” “forecast horizon,” “demand signal noise.”

Manufacturing operations: Talks about “batch sizes,” “changeover efficiency,” “plant utilisation.”

Logistics: Refers to “load consolidation,” “delivery windows,” “on-time in-full (OTIF).”

Sustainability team: Focuses on “carbon intensity per SKU,” “embedded emissions,” “scope 3 visibility.”

Each group is operating with a valid model – but their language frames their reality differently, creating misalignment in expectations and incentives.

Conflicting metaphors = conflicting decisions (and reduced congruence)

Language can describe and list things, but it’s also metaphorical. LBA reveals that even common metaphors are loaded with different assumptions:

“Just-in-time” suggests precision, minimal waste, tight tolerances. “Resilience” implies buffers, optionality, and slack.

These ideas often clash in planning conversations.

For example, a planner might suggest holding 3 weeks of buffer stock “for resilience,” while the finance lead counters that this “kills working capital”

LBA surfaces these underlying narrative conflicts early – before they become programme blockers.

Value framing: Everyone’s speaking in a different currency

Different teams may describe “value” in ways that don’t align:

Procurement: “lowest total landed cost”

Sustainability: “climate-positive procurement strategy”

Customer service: “maximising fill rate without backorders”

Finance: “protecting gross margin”

These are not just different metrics – they’re different worldviews. LBA helps make this visible.

Semantic mismatches create hidden friction and prevent reaching congruence

Misunderstandings are often subtle and systemic:

“Product availability”

• To the warehouse team: “stock is in the system.”
• To the retailer: “I can get it on the shelf tomorrow.”

“SKU rationalisation”

• To marketing: “reduce range clutter.”
• To production: “minimise changeovers.”
• To supply chain finance: “optimise carrying cost.”

“Forecast accuracy”

• Planning means statistical precision.
• Sales means “we hit the number we told the board.”
• Operations means “can we trust it enough to schedule labour?”

Each of these semantic mismatches leads to poor handovers, rework, and misaligned decisions.

We could then build a semantic map of:

• Shared concepts
• Conflicts in terminology
• Gaps in understanding
• Lost meaning in handovers
• Incomplete or ambiguous data labels

And this might reveal that there are gaps in understanding:

• Planning uses probabilistic models, but operations wants commitments. For example, a planner might say: “There’s an 80% chance we’ll need that SKU in week 42,” but Ops asks: “Look, do I order it or not?”
• Sustainability uses a future-forward, impact-oriented language, while procurement is often contract-anchored in today’s prices.

Legacy data labels hide meaning

A field in SAP labelled “Product Class” is used:

• By sales to mean product category (e.g. “personal care”)
• By R&D to mean technical platform (e.g. “sulfate-free formulations”)
• By logistics to determine storage requirements (e.g. hazardous, refrigerated)

These mismatches cause data integrity issues, failed automation, and flawed reporting.

For this FMCG company, the supply chain isn’t just a flow of goods – it’s a network of conversations about those goods. Language-Based Analysis can show where those conversations align, where they break down, and where transformation requires semantic, not just systemic, change.

How could this method link language to value exchange?

A key innovation here: language becomes the infrastructure of value exchange.

We’re analysing:

• Internal dialects (Finance vs Ops vs Design)
• Value contracts embedded in documents, workflows, and platforms
• Narratives that determine investment, urgency, or inertia

We’re looking at how:

• Language creates poor levels of congruence across functions
• Language shapes expectations, permissions, and obligations
• Misunderstandings cost money, trust, or time

Practical LBA Tools (I’m just making this up to get the thinking out…)

This different approach also suggests creating different tools and artefacts:

(The language drift report has nothing to do with Gran Turismo, it’s a way of understanding the degree of divergence, I can imaging this involving spider diagrams?)

## Broader implications of the approach

When you start looking at organisations through a language lens, the potential applications go way beyond just digital transformation.

Inclusion

LBA helps surface accessibility and comprehension issues. In many large organisations, people are excluded not because of capability, but because the language used is overly technical, abstract, or filled with jargon.

For example, someone in a warehouse might struggle to understand a new planning dashboard because it’s designed with finance terms.

Or neurodiverse employees might interpret certain metaphors differently — leading to misunderstanding or stress.

LBA can help you design communication that is genuinely inclusive — by spotting which terms confuse, exclude, or alienate people.

AI Alignment (because it’s not going away, and if we simply focus on improving current processes things will not end well)

LBA makes sure AI systems are trained on the right kind of language.

As organisations increasingly use LLMs (like CoPilot or internal GPT-style tools), bots, and automated data pipelines, it becomes essential to make sure those systems understand the contextual meaning of terms used internally.

For example:

A bot trained on general English might misunderstand “product class” if that term means something specific in the customer’s organisation organisation.

LBA can ensure your AI tools are:

• Trained on the real, domain-specific language the people use.
• Aligned with how our customer’s teams define value, make decisions, and interpret data.

Change Management

With LBA, you’re not just training people on new systems — you’re aligning shared language. Traditionally, change programmes train people how to use new tools or follow new processes.

But often what people struggle with is:

• Understanding why the change is happening.
• Adapting to new terms, metrics, or labels.

For example:

A new CRM system might use the term “opportunity” — but that might mean different things to marketing, sales, and delivery. LBA ensures you’re aligning the meaning, not just the mechanics — helping people understand, adopt, and own the change more effectively.

So where does all this leave us?

“Transformation fails not because systems don’t connect, but because meanings don’t align.”

Language-Based Analysis re-centres the conversation around:

• Meaning
• Value
• Alignment

It treats communication as the architecture, not just a layer on top of it. It allows transformation to start with dialogue.

Fun quote: Barthes argued that meaning is created not by the author but by the reader. Translate that into enterprise transformation: the organisation isn’t defined by top-down architecture alone, but by the language acts (and interpretations) of its people. The enterprise can be drawn in an org chart, but is actually defined by what is said and understood.

In  Leadership   Transformation   Culture
Tags: Strategy, Consulting, Vision, Business design, Enterprise architecture, Service design, Org design, Organisational culture
(comments disabled)