Mapping Everything Except Culture

The Missing Domain, Part 1

It was 2016. I was on a flight to the Channel Islands, summoned by a CIO I had worked with briefly on an earlier engagement. His wealth management firm had just gone live with the first phase of a core platform replacement. They were moving from a two-decade-old mainframe onto a then-modern fourth-generation platform. The methodology had been textbook correct. Requirements elicitation had run for months with the users in the room. The vendor selection had been rigorous. Phase one had been delivered on schedule. And now, two weeks after go-live, the work had stopped.

The same users who had sat through the requirements workshops, who had signed off the designs, who had watched the demonstrations and agreed the system was fit for purpose, were now finding fault with almost every step of the process. The system, they said, was unworkable. Unfit for purpose. Rejected.

“I need you to tell me what went wrong,” the CIO said.

I spent the first week listening.

The week of listening

What I remember of that week is a set of composite voices, the same observations offered in slightly different words by people across every function. There was no single failure to point to. The system worked. The business logic was correct. The integrations had held. The training had been delivered. When I asked users to walk me through a specific step that was broken, they would demonstrate it, and it would work, and then they would say something like, “but there is just too much.”

Too much what?

Too much change, they said. Too many screens. Too many new fields. Too many processes that used to take one click and now took three, or the other way round. One user, sitting in a small office stacked with papers that predated the mainframe, put it to me like this. “I have done this same job, broadly the same way, for a long time. Now I do not recognise my own desk.” Another was blunter. “It is as though someone moved the furniture in every room of the house overnight, and now they are asking us why we keep bumping into things.”

The CIO had done everything the change management textbooks asked of him. He had run the awareness campaigns. He had scheduled the training. He had briefed the board. He had delivered the programme on schedule and within budget. What he had not done, because no framework had asked him to, was measure whether his organisation could absorb the quantity of change he was asking it to absorb. He had mapped the process, the data, the technology and the people. He had not mapped the cultural capacity. And that is the component that decided whether the new system lived or died.

This is the argument of this piece, and of the short series that follows. Business architecture, as a discipline, is silent on culture. Every other major component of the operating model has a reference framework, a notation, a modelling convention. Culture does not. The silence is not accidental. It is a choice. And the cost of that choice shows up on the day you go live.

What the reference models say, and do not say

Let me walk through what I mean by silence.

Open the Business Architecture Body of Knowledge, the BIZBOK, which is the closest thing the discipline has to a canonical text. You will find the foundational domains described with precision. Capability Maps. Value Streams. Information Concepts. Organisation Structures. You will find extensions for initiatives, products, stakeholders, policies, performance and strategy. You will find diagrams, heat maps, traceability tables and cross-mappings for every one of them. You will not find a primary domain dedicated to culture. The word appears, of course, inside discussions of change management and organisation. It appears as context. As environment. As something that the architecture operates within. It is never itself an object of architectural work.

Open the TOGAF standard, which covers enterprise architecture more broadly. TOGAF does slightly better, in the sense that it acknowledges culture exists. It asks you to consider it during stakeholder analysis. It offers a diagnostic called the Business Transformation Readiness Assessment, which touches culture obliquely. But there is no modelling technique for culture, no notation, no recommended artefact, no culture equivalent of a capability heat map. The readiness assessment is a checklist, not a map. Culture is treated as a contextual consideration. The weather in which the architecture will operate. Not the landscape being mapped.

Open the Operating Model Canvas, which many transformation teams use because it is lighter than either of the above. You will find a block for Suppliers. A block for Locations. A block for Information. A block for Management Systems. A block for Organisation. A block for Processes. You will not find a block for Culture. You will find People, but people are modelled as roles, competencies and capacities, not as a cultural system.

The pattern repeats across the major tools. Ross, Weill and Robertson’s operating model work. Burlton’s process architecture. The Zachman framework. Capability-based planning. In every one of them, culture is either absent or peripheral. It is the thing the architect is expected to navigate, not the thing the architect is expected to describe.

A practitioner reading this will probably want to push back with the obvious objection. Culture is covered, just not by us. It is covered by change management. It is covered by organisational development. It is covered by HR. And that is true. But notice what the objection concedes. Culture enters the programme downstream, after the architecture has been designed, after the capabilities have been mapped, after the target operating model has been signed off. By the time the change management workstream gets hold of it, the architecture is fixed, and culture becomes a variable to be managed towards the architecture rather than a variable the architecture was shaped around. That is not a neutral division of labour. It is a specific choice about where culture sits in the sequence of design decisions. And that choice is why CIOs in the Channel Islands, and everywhere else, keep getting caught out on go-live day.

So why the silence?

There are several defences the discipline offers, implicitly if not explicitly, for the absence of culture from its reference models. They deserve a proper hearing before they are challenged.

The first is that culture is intangible. It cannot be mapped with the precision the discipline expects of its artefacts. A capability can be scored on a heat map. A value stream can be decomposed into stages. Information can be modelled as entities and relationships. Culture, the argument goes, resists that kind of treatment, and the discipline has quietly decided that what cannot be modelled cleanly does not belong in the reference model.

This is a real argument, and I will return to it properly in a later piece. For now, the short answer is that it proves too much. Capabilities are context-specific. Value streams are context-specific. Every target operating model is a local artefact. What the discipline has done for those domains is develop shared notation, shared patterns, and shared techniques that allow context-specific work to be executed consistently across engagements. Anthropology and organisational psychology have been producing mappable, repeatable models of culture for decades. The discipline has not declined to adopt them because adoption is impossible. It has declined because it has not seriously tried.

The second defence, and the one that deserves the most honest examination, is that culture is political. The architect who attempts to map it will end up describing things the sponsors of the architecture do not want described. The gap between the culture the board believes exists and the culture the organisation actually enacts is almost always uncomfortable, and in large organisations it is frequently significant. I have sat in rooms where that gap, named plainly, would have ended the programme before it started. Not because naming it was wrong, but because the people who needed to hear it were the same people who had spent years defending the conditions that produced it.

The practising architect learns this early, and often painfully. The self-preserving response is to leave culture alone: to map what can be mapped, to deliver what has been commissioned, to build the capability heat map that everyone will nod at in the design review, and to stay well clear of the question nobody asked. I have done this myself. Most experienced practitioners have. The incentive structure of the engagement model — where the architect is employed by the organisation to produce the architecture the organisation has decided it wants — actively discourages the kind of cultural diagnosis that might challenge the premise of the commission. Naming this is not a criticism of individual practitioners. It is a description of a structural problem in how the discipline is deployed. The political architect is a rational response to a political environment. But rationalising it does not make it less expensive, and the Channel Islands was not an unusual case. The cost of that silence shows up in every programme that collapses between design sign-off and go-live.

There is also a territorial dimension to the silence, but it largely follows from the political one. Culture is said to be owned by other functions — HR, organisational development, the change management workstream — and the architect who reaches into it is told they are trespassing. This is not an independent reason for the absence of culture from reference models. It is a post-hoc rationalisation for a boundary that serves everyone's comfort rather than the programme's success. By the time the change management workstream gets hold of culture, the architecture is fixed. Culture becomes a variable to be managed towards the architecture rather than a variable the architecture was shaped around. That is not a neutral division of labour. It is a specific choice about sequence, and the choice has consequences.

What it cost in the Channel Islands

I went back to the CIO at the end of that first week with a diagnosis and a proposal. The programme was not failing because of technology. It was not failing because of process. It was failing because the rate of change had exceeded the organisation’s capacity to absorb it, and nobody had measured that capacity because the reference model we were all working from did not include it as a component.

The proposal was to slow the rollout. Not abandon it. Not rebuild it. Slow it. And to run a cultural intervention alongside it.

What we ran was not elegant. It was a sequence of departmental workshops, one per function, where I asked the users to list every pain point they had lived with on the mainframe. Then I walked them through, feature by feature, how the new platform removed each one. Then I showed them the gain points, the features the old system had never offered, using a simple value proposition structure to frame what they were being given that they had not had before. And then we ran the two systems in parallel, in a model office environment, so users could feel the comparison with their own hands and their own data before it became their only option.

The intervention was not culture mapping in any academic sense. It was a pragmatic attempt to do retrospectively, under pressure, the work that should have been done before go-live. The rollout recovered. The business absorbed the system. The programme completed, later than planned and at higher cost than planned, but it completed.

The lesson I took from the engagement, and have been chewing on in every programme since, is this. None of that remedial work would have been necessary if the reference model had asked the CIO to map the cultural capacity of his organisation before we started drawing capability heat maps. The firm had three cultures operating inside it at the time: the one it said it wanted, the one it professed in its policy documents, and the one it actually enacted each day. We had built the architecture against the middle one, the espoused culture. The enacted culture was the one that had to live with the new system, and it could not keep up.

The architecture was textbook correct. The culture the architecture was being imposed on was not in any textbook.

The current in the river

Mapping an organisation without mapping its culture is like drawing a river without noting which way the water flows. You can be technically accurate about the shape, the width, the depth, the tributaries and the delta. You can still be useless to anyone who has to navigate it. The direction and the force of the current decides everything that actually happens in the water, and if you have not captured those, you have not captured the river.

Business architecture, as it is currently taught and practised, draws the river without the current. The discipline has chosen precision about the mappable components over honesty about the un-mapped ones. That choice is defensible only if the un-mapped components are marginal to outcome. Culture is not marginal. It is the current.

What is coming

This is the first piece in a short series called The Missing Domain, on what business architecture refuses to see.

The next piece revisits the three cultures that sit inside every organisation: the desired, the espoused, and the enacted. The argument is that transformation programmes do not fail at the capability layer or the process layer. They fail at the gap between those three cultures, and that gap is where most architecture currently stops looking.

The third piece takes on the intangibility defence directly. There are mature empirical frameworks for modelling culture — Schein's three layers, the Competing Values Framework, Denison's model — that have been available to the discipline for decades. The piece argues that the profession has not failed to find them. It has chosen not to adopt them, and the distinction between those two positions matters.

The fourth piece is the harder one. It looks at the political architect: why practitioners who know the culture gap exists learn to leave it alone, what happens when they do not, and what a more honest engagement model might look like for the architect who wants to do this work without ending their career doing it.

If you have watched a textbook-correct programme collapse at go-live, I suspect you already know the silence I am writing about. I would be curious to hear where you have seen it.