Design Dimensions
The levers a designer actually pulls: processes, organisation, people and skills, information and data, technology, and locations and sourcing. An operating model is designed across all of them together — changing one dimension in isolation is how transformation programmes fail.
Breaking Down Each Dimension
Each dimension below sets out what it is, exactly what an architect needs to do to design it well, the inputs it depends on, the outputs it must produce, and the mistake most likely to undermine it.
1. Processes
What it is: the repeatable work — how activities are performed, standardised and connected across the value streams that depend on them.
What you need to do:
- Apply the Process Lifecycle Completeness test: identify the thing and outcome, then assess all ten lifecycle phases across Business, Information Systems and Technology. A process is not complete merely because its current-state flow has been mapped.
- Design processes from the value stream inward, so each step earns its place by contributing to the outcome, not because it has always been done.
- Standardise where variation adds no value, and deliberately allow variation where it does. Standardising everything is as much a design failure as standardising nothing.
- Build control points and segregation of duties into the process itself, rather than adding a review step afterward to catch what the process should have prevented.
- Document the process at the level of detail the people running it actually need. A process map nobody can follow on the day is decoration, not design.
Every one of the 30 phase–layer intersections must carry either a required process or an evidenced N/A — rationale required decision. Applicable processes must define an owner, outcome, inputs, outputs, controls and evidence, and predecessor/successor hand-offs.
Inputs: the value stream map, the capabilities the process supports, and existing process documentation and its divergence from practice.
Outputs: standardised, control-aware process designs that the value streams can rely on and that governance can audit against.
Watch for: designing the process on a whiteboard without the people who will run it — the gap between the designed process and the lived one is where risk concentrates.
2. Organisation
What it is: structure and accountability — how the organisation is shaped and who answers for what. Structure should follow the operating model; the operating model should not follow the structure.
What you need to do:
- Design the structure to fit the capabilities and value streams already defined, rather than starting from today's structure and adjusting it.
- Make accountability explicit at every level the design touches. An organisation design that only specifies boxes and lines, without naming what each box is accountable for, has designed a chart, not an organisation.
- Keep spans and layers deliberate. Every additional layer is a decision with a cost — in speed, in clarity of accountability, in the distance information has to travel.
- Place accountability for cross-cutting risk, including security risk, explicitly. An organisation design silent on who owns security decisions has made a decision by omission.
Inputs: the capability map, value streams, and the design principles that constrain acceptable structural choices.
Outputs: a structure with named accountabilities, tested against the capabilities and value streams it needs to support.
Watch for: redesigning structure as the whole transformation, while process, technology, data, people and sourcing are left as they were. A reorg is not an operating model redesign.
3. People & Skills
What it is: the workforce the model needs — skills, capacity, roles and the pipeline that sustains them, not just headcount.
What you need to do:
- Derive the skills and roles needed from the target capabilities and value streams, not from the shape of today's workforce.
- Assess the gap between the skills people have and the skills the target model needs, and size the reskilling, hiring and attrition this implies honestly.
- Plan capacity, not just competence. A team with the right skills and no slack to also absorb the transition will not deliver either the change or business as usual well.
- Build the talent pipeline for scarce or emerging skills, including specialist security skills, ahead of when the target model needs them, not at the point the gap becomes an incident.
Inputs: the target capabilities and value streams, current workforce skills and capacity data, and the organisation's realistic hiring and development timelines.
Outputs: a workforce plan — skills, roles, capacity and pipeline — that the target operating model can actually be staffed against.
Watch for: assuming existing staff can simply absorb new skills through a training day. Sustained capability change needs sustained investment, not a single workshop.
4. Information & Data
What it is: what the organisation must know — the information and data that processes consume and decisions depend on.
What you need to do:
- Identify the information each capability and value stream actually depends on, and where authoritative ownership of that information sits.
- Classify information by sensitivity and criticality, and attach the protection and handling requirements that follow from that classification.
- Map data flows across the dimensions being designed — process, technology, and locations and sourcing all move data, and the design needs to account for where it goes and who can see it.
- Design for data quality and stewardship deliberately, rather than assuming the technology dimension will solve it. A well-designed database schema does not fix poorly owned data.
Inputs: the capability map, value stream data dependencies, and existing data governance or classification policy.
Outputs: an information and data design — ownership, classification, flow and quality — that the technology dimension can be built to support.
Watch for: treating information and data as a subset of the technology dimension rather than a dimension in its own right. Data outlives the systems that happen to store it today.
5. Technology
What it is: the systems and platforms that automate, enable and constrain everything else in the model.
What you need to do:
- Select and design technology to fit the target processes, organisation and data design, not the reverse, where the process is redesigned around whatever the chosen platform happens to do out of the box.
- Build in secure-by-design patterns at the architecture stage, where they are cheap to include, rather than as controls layered on afterward, where they are expensive and incomplete.
- Plan the technology transition alongside the transition roadmap. A target technology platform that cannot be reached in stages from the current one is a target that will never actually be delivered.
- Keep technology decisions traceable to the design principles. Technology choices are some of the hardest to reverse, and a platform chosen against a principle becomes a constraint on every future design decision.
Inputs: the target processes, organisation, and information and data design, plus the current technology estate and its constraints.
Outputs: a technology design that supports the target processes and data model, staged into the transition roadmap.
Watch for: a technology-led redesign where the platform vendor's reference architecture quietly becomes the target operating model. The tool should serve the design, not replace it.
6. Locations & Sourcing
What it is: where work happens and who does it — footprint, buy-versus-build decisions, and the partners and suppliers the model depends on.
What you need to do:
- Decide sourcing capability by capability, not as a single blanket policy. Some capabilities are genuine sources of advantage and belong in-house; others are commodity and belong with a supplier.
- Assess supplier and location risk as part of the design, not as a procurement afterthought. Third-party risk and data residency are design constraints, not compliance paperwork bolted on at contract stage.
- Consider a Wardley Mapping view of evolution alongside the sourcing decision (see the callout below). A capability's maturity today and its likely evolution are different questions, and sourcing decisions should account for both.
- Design the transition, not just the end state. Moving a capability's location or supplier is itself a change with its own risk, cost and timeline that belongs in the transition roadmap.
Inputs: the capability assessment, cost and risk data on current suppliers and locations, and the organisation's appetite for outsourcing and geographic concentration risk.
Outputs: a sourcing and location design, capability by capability, with the supplier and residency risk it introduces made explicit.
Watch for: outsourcing a capability because it is currently low-maturity, without asking whether it is also high-importance. That combination is usually a signal to invest, not to hand to a supplier.