Organisational Architecture

Every organisation has an architecture - a set of design decisions that stack on top of each other, from strategic direction at the top to operational choices at the bottom. Most of the time, these decisions get made independently: someone redesigns the structure, someone else introduces new technology, a third team rethinks processes. The architecture is there whether you design it intentionally or not. The question is whether you've made those decisions in the right order.

What is Organisational Architecture?

Organisational Architecture is a framework for understanding how an organisation's design decisions relate to each other - and, critically, the order in which they need to be made. It maps the full stack from vision and strategy through to the people, processes, and technology that deliver value, showing how each layer depends on the one above it.

The concept isn't owned by any single thinker or consultancy. It draws on decades of organisational design thinking - from Jay Galbraith's Star Model, which established that strategy should drive structure, through to the various operating model frameworks like the POLISM Canvas that map how organisations translate intent into action. What Organisational Architecture adds is the explicit dependency logic: the recognition that these decisions form a stack, and that getting the sequence wrong creates problems that no amount of effort at the lower levels can fix.

Think of it as the difference between a list of ingredients and a recipe. Most organisational design frameworks give you the ingredients - strategy, structure, people, technology, culture. Organisational Architecture gives you the recipe: what depends on what, and in what order you need to resolve them.

How Organisational Architecture works

The architecture is a pyramid with seven layers, read top-down. Each layer rests on the one above it being resolved first. Alongside the pyramid, Culture and Leadership operates as a vertical force that shapes and is shaped by every layer.

The dependency logic is the key insight: you cannot make good decisions at any layer without having clarity on the layer above. Choosing technology before designing processes leads to workarounds. Designing processes before understanding your people leads to systems that fight human behaviour. Restructuring before defining your operating model leads to structures that look tidy on paper but create friction in practice.

Vision and Strategy

The starting point. What the organisation exists to achieve, and the strategic choices that guide everything below. This is not a mission statement exercise - it's the set of decisions about where to compete, what to prioritise, and what trade-offs to accept. Every layer in the architecture ultimately traces back to whether it serves these choices.

If the vision and strategy aren't clear, nothing below them can be resolved properly. Teams will optimise for different things, structures will reflect historical habit rather than current intent, and technology investments will solve yesterday's problems.

Target Operating Model

The translation layer. The Target Operating Model takes strategic intent and turns it into operational design principles - the end-to-end value chain, front office and back office boundaries, shared services, outsourcing decisions, and the interfaces between them. It answers the question: given our strategy, what kind of operating system do we need?

This is where many organisations skip a step. They jump from strategy straight to restructuring - moving boxes on an org chart without first defining the operating model those boxes are supposed to serve. The TOM is the bridge between "what we want to achieve" and "how we need to be arranged to achieve it."

Organisation Design

How the organisation arranges itself to deliver the operating model. This covers structures, reporting lines, role definitions, capabilities, and performance measures. The Star Model and McKinsey 7-S both operate at this level - they're frameworks for making the design decisions that sit within this layer.

The key dependency: organisation design should follow the operating model, not the other way around. When restructuring happens without a clear TOM, it tends to produce structures that reflect internal politics or inherited tradition rather than what the organisation needs to deliver. Structure should follow need.

The Operational Core: People, Process, Technology

Nested within Organisation Design sit three interconnected layers. Their order matters.

People come first. What capability, skills, and ways of working are needed to deliver? How many people, in what roles, with what knowledge? This isn't just headcount planning - it's about understanding what kind of human capability the organisation needs before designing the processes and systems those people will use.

Starting with people rather than technology is a deliberate choice. Too many transformation programmes begin with a technology platform and then expect people to adapt their working patterns around it. The dependency runs the other way: understand your people, then design processes that work with human behaviour, then choose technology that supports both.

Process comes next. The business and functional processes that support the organisation's objectives. Processes should be designed around what people need to do - not imposed as abstract workflows that look elegant on a diagram but create friction in practice. Good process design starts with "what are people trying to achieve?" not "what does the system require?"

Technology sits at the base of the operational core. The systems, platforms, and tools that enable delivery. Technology is an enabler, not a driver - it should be chosen to support the people and processes above it, not the other way around. This is where the dependency logic pays for itself: an organisation that has clarity on its people and processes will make far better technology decisions than one that leads with a platform selection.

Governance and Reporting

The foundation. Governance defines the arrangements for running the organisation efficiently and accountably - decision rights, reporting lines, performance oversight, risk management, and compliance. It sits at the base because it provides the structural accountability that holds everything above it together.

Governance is often treated as an afterthought - something bolted on once the "real" design work is done. In practice, unclear governance is one of the most common reasons that well-designed operating models fail to deliver. If nobody knows who decides what, or how performance is tracked, the architecture above it operates without a floor.

Culture and Leadership

Culture and leadership are not a layer in the stack - they operate as the climate the whole architecture sits in. Leadership shapes how every layer functions in practice, and culture determines whether the formal architecture matches the lived reality.

Edgar Schein's model of organisational culture is useful here: the visible structures and processes are only the surface. Beneath them sit the shared values and behavioural norms that determine how things get done day to day, and deeper still are the underlying assumptions that nobody questions. An architecture can be perfectly designed on paper and still fail if the culture works against it. Equally, a strong culture can compensate for architectural gaps - but only up to a point, and usually at a cost in energy and goodwill.

This is why culture wraps the pyramid rather than sitting as a layer within it. It permeates everything. A restructuring that ignores culture will be resisted. A technology change that conflicts with how people work will be circumvented. The architecture and the culture need to develop together.

How to use Organisational Architecture

The framework is most useful in three situations: when designing a new organisation (or a major part of one), when diagnosing why an existing design isn't working, and when planning a transformation that needs to touch multiple layers at once.

As a design sequence. When building something new - a new division, a post-merger integration, a fundamental restructuring - work through the layers top-down. Confirm the strategy before defining the operating model. Define the operating model before designing the structure. Design the structure before making people, process, and technology decisions. This doesn't mean each layer needs to be fully complete before the next one starts, but it does mean the direction needs to be set. Moving to the next layer before the one above it has stabilised creates rework.

As a diagnostic. When something isn't working, the architecture helps you locate the problem. If processes keep being redesigned but nothing improves, the issue might be one or two layers up - in the organisation design or the operating model. If technology investments keep missing the mark, the problem is likely in the process or people layers above. The framework reveals that many operational problems have structural causes, and many structural problems have strategic causes. Fixing symptoms at the wrong layer is one of the most expensive patterns in organisational life.

As a transformation map. Large-scale change often needs to touch several layers simultaneously. The architecture shows which layers are in scope and - just as importantly - which dependencies mean that changes need to be sequenced rather than run in parallel. A digital transformation that changes technology, processes, and roles at the same time needs to understand which of those changes depends on which, or everything lands at once and nothing sticks.

In all three uses, the framework works best as a conversation tool. Bring leaders together around the diagram, identify which layer you're working at, and check whether the layers above are clear enough to support the decisions you're about to make. If they're not, that's your starting point.

Example

A regional health service is struggling with fragmented patient pathways. Waiting times are growing, referral processes differ between sites, and a recent technology rollout has created more problems than it's solved.

Reading the situation through the architecture reveals the sequence of decisions that led here:

Vision and Strategy is broadly clear - the organisation exists to provide accessible, high-quality care across the region. But it hasn't made firm choices about which services to centralise versus distribute locally, or how to balance specialist depth against geographical access.

Target Operating Model hasn't been explicitly defined. Each site operates semi-independently, with different referral pathways, different administrative processes, and different technology configurations. There's no shared model for how care should flow from first contact through to treatment.

Organisation Design reflects historical legacy rather than current need. Structures follow professional disciplines (surgery, medicine, nursing) rather than patient pathways. Roles and responsibilities overlap between sites.

The technology platform was chosen before the process redesign - a common inversion. The system was selected to "standardise" operations, but without a shared operating model or redesigned processes, it ended up encoding each site's existing differences rather than enabling a common approach. Clinicians work around it rather than through it.

Governance is unclear at the cross-site level. Individual site leads have authority over their own operations, but nobody owns the end-to-end patient pathway that crosses site boundaries.

The architectural reading suggests the fix isn't at the technology layer - it's at least two layers up. The organisation needs to define its operating model first (how should care flow across the region?), then redesign its structures and processes to deliver that model, and only then reconfigure the technology to support the new design. Governance needs to be strengthened at the pathway level, not just the site level.

This is the value of the dependency logic. Without it, the instinct is to fix the visible problem - the technology - rather than the structural cause several layers up.

Limitations

The dependency is directional, not absolute. The top-down logic is a design principle, not a rigid sequence. In practice, there are feedback loops: technology creates new strategic possibilities, people capabilities shape what's achievable, governance constraints limit design options. The pyramid captures the primary direction of dependency, but good architects hold the whole system in view.

It doesn't tell you what to put in each layer. The architecture shows the structure and the sequence, but it doesn't prescribe content. What a good operating model looks like, how to design roles effectively, which technology to choose - for those questions, you need the frameworks that sit within each layer. The POLISM Canvas, Star Model, and Burke-Litwin Change Model each address specific layers in depth.

Culture is harder to design than the model implies. The diagram shows culture wrapping the pyramid, which correctly captures that it permeates everything. But culture is not a design variable in the same way that structure or process is. You can't simply decide what culture you want and implement it. You can influence culture through the decisions you make at every other layer - but the relationship is complex, slow, and often surprising. The architecture helps you see the connection; it doesn't make culture change easy.

It works best at scale. For small teams or early-stage organisations, the full architectural stack can feel like overkill. A team of fifteen people doesn't need a formal operating model or a governance framework - they need clear direction, good communication, and a shared understanding of who does what. The architecture becomes progressively more valuable as organisations grow, merge, or restructure - situations where the dependencies between layers become real constraints.

Getting started

Start with the question, not the model. Where are you experiencing friction, duplication, or confusion? The answer usually points to a layer in the architecture - and the fix often sits one or two layers above where the symptoms show.

Map your current architecture by asking, for each layer: have we made an explicit decision here, or are we running on inherited assumptions? Most organisations find that the upper layers (strategy, operating model) are either unclear or silently contradicted by what's been built below them. That gap between stated intent and operational reality is usually the richest place to start.

Then use the dependency logic to sequence your response. If the operating model isn't clear, fix that before redesigning structures. If structures aren't aligned, fix that before investing in new technology. Working top-down is slower at the start but dramatically faster in total, because it avoids the rework cycle of fixing lower layers that were built on unstable foundations.