Organisation mapping

G206 is a TOGAF Series Guide dedicated to organisation mapping as an architecture technique. It extends the content metamodel concepts of actor, role, and organisation unit into a practical mapping method that helps architecture teams understand how organisational structure shapes business outcomes.

A normal org chart shows reporting lines. G206 Organisation Mapping goes further. It structures the analysis around three core constructs that the standard org chart does not capture.

Actors. An actor is an entity (a person, team, department, external body, or automated system) that participates in a business interaction. G206 distinguishes actors from organisational units. An organisational unit is where someone sits in the management hierarchy. An actor is who participates in a business-relevant interaction. The same person may be an actor in several different contexts.

Roles. A role is a responsibility assigned to an actor in a specific context. The same actor may play different roles in different business interactions. A planning engineer is an actor. When reviewing a connection design, that engineer plays the role of technical approver. When submitting data for the LTDS, the same engineer plays the role of data contributor.

Business interactions. A business interaction is an exchange between actors that produces a business-relevant outcome. Interactions are where responsibility transfers, decisions are made, and information crosses boundaries. G206 focuses architecture attention on these interactions because they are where most organisational friction accumulates.

G206 recommends building an actor/role catalogue as a foundational artefact for organisation mapping. The catalogue lists every actor that participates in the business scope under analysis, together with the roles each actor plays.

The catalogue serves three purposes that the standard org chart cannot.

It separates identity from responsibility. The org chart says where someone sits. The actor/role catalogue says what responsibilities they carry in specific business contexts. A single team may carry responsibilities for data entry, data quality assurance, and regulatory reporting, and the catalogue makes it explicit that these are three different roles, possibly with conflicting interests.

It exposes role duplication and role gaps. When multiple actors claim the same role, ownership is contested. When no actor claims a role, ownership is absent. Both conditions are architecture-relevant because they predict transformation friction.

It supports RACI and interaction analysis. The actor/role catalogue is the input to both RACI matrices and business interaction matrices. Without a clean catalogue, those higher-level views inherit ambiguity.

Building the catalogue requires interviews with people who do the work, not just with managers who describe it. A common failure is to build the catalogue from the org chart alone, which produces a mirror of the hierarchy rather than a map of actual responsibility.

G206 introduces the business interaction matrix as a way to map which actors interact with which other actors, and what flows between them. The matrix places actors on both axes and marks each cell with the nature of the interaction: information flow, decision authority, approval dependency, handoff, or governance relationship.

The business interaction matrix reveals four types of insight that matter to architecture work.

Dependency density. Where one team depends on multiple others for evidence, approval, or handoff. High dependency density predicts bottlenecks and coordination failures.

Missing interactions. Where two actors should interact (because their capabilities depend on each other) but currently do not. Missing interactions often explain why information is lost at handoff points.

Asymmetric authority. Where one actor carries responsibility for an outcome but lacks authority over the actors who contribute to it. This pattern is common in cross-functional programmes and is a primary source of governance friction.

External interface risk. Where interactions cross the enterprise boundary to external actors (regulators, partners, customers) and where the internal ownership of that external interface is unclear or contested.

The useful content of an organisation map is the content that a standard org chart does not show. Four categories deserve particular attention in architecture work.

Dependency relationships. Where one team depends on another for evidence, approval, or a handoff that directly affects the enterprise outcome. These dependencies are invisible in the org chart because the org chart shows vertical reporting, not horizontal collaboration.

Cross-functional ownership gaps. Where a capability crosses several functions with no clear coordinating owner. This is where transformation initiatives stall most frequently. The connections journey at a DNO typically crosses planning, design, wayleaves, delivery, metering, and energisation. If no single actor owns the end-to-end outcome, each team optimises locally and the overall result suffers.

Interpretation mismatches. Where delivery teams, business teams, and governance groups interpret responsibility differently. These mismatches create friction that looks like process failure but is actually an accountability failure. One team believes it is responsible for data quality. Another believes data quality is the first team's problem only when the data is wrong. A third team publishes the data without checking either assumption.

Internal-external alignment gaps. Where internal ownership and external accountability are not aligned. A team may own a system, but the external reporting obligation sits with a different function entirely. When the regulator asks about LTDS data quality, the question may land with a regulatory affairs team that has no visibility into the data pipeline that produces the numbers.

Organisation mapping becomes powerful when it enables three specific types of question that the standard org chart cannot answer.

Who owns the change outcome? Not just who owns a system or process, but who is answerable for the business improvement itself. In many enterprises, this question has no clear answer, and that absence is the root cause of stalled transformation. The actor/role catalogue and RACI matrix should make this answer explicit.

Where do handoffs fail? Which interfaces consistently lose information, time, or responsibility when work crosses boundaries. The business interaction matrix identifies these points. They are where value-stream friction accumulates and where later system design must intervene.

Where is authority blurred? Which decisions require several actors who are not yet operating through a clear architecture or governance path. Blurred authority produces slow decisions, contradictory priorities, and governance arguments that absorb time without producing clarity. The interaction matrix exposes asymmetric authority patterns that the org chart normalises.

Organisation mapping is an input to business architecture, not the whole of business architecture. If the stage stops at the map, the architecture still has not explained capabilities, services, value flow, or business gaps. A common failure mode is to treat the organisation map as the deliverable rather than as one lens among several.

The organisation map should feed directly into capability ownership questions, value-stream handoff analysis, and later gap work. If it sits in isolation, it becomes a prettier version of the org chart and adds no architectural value.

The discipline is to use the map as a diagnostic tool: where does the organisation structure help the enterprise deliver its required outcomes, and where does it actively get in the way?

In the London case, organisation mapping clarifies how planning, operations, IT, data governance, cyber, architecture, and programme delivery relate, and where those relationships weaken the change effort. The actor/role catalogue and interaction matrix expose problems that the org chart normalises.

Key London actors and roles

The London connections modernisation involves at least ten significant actors, each playing specific roles.

• Connections Team. Roles: application assessment, offer generation, customer communication, progress tracking.
• Network Planning. Roles: capacity analysis, reinforcement assessment, LTDS data preparation, design review.
• Design Engineering. Roles: connection scheme design, cost estimation, technical specification.
• Delivery/Construction. Roles: physical works delivery, commissioning, as-built record capture.
• Data Governance. Roles: data quality assurance, publication accuracy oversight, metadata management.
• IT/Digital. Roles: system operation, integration management, platform support, change delivery.
• Cyber Security. Roles: OT security oversight, access control, threat monitoring.
• Regulatory Affairs. Roles: Ofgem liaison, performance reporting, licence compliance.
• Architecture Board. Roles: design review, standard compliance, cross-programme alignment.
• Programme Director. Roles: transformation outcome ownership, investment justification, board reporting.

Critical interface problems in London

The business interaction matrix reveals three critical interface problems in the London case.

1. Planning-to-design handoff. The planning team and design team use different systems with no shared evidence base. Information is transcribed manually, introducing errors and delays. The actor/role catalogue shows that both teams claim the role of "technical specification owner" but neither has clear authority over the specification that crosses the boundary.
2. Data governance to publication. The data governance function has responsibility for information quality but no authority over the systems that generate the data. When the GIS produces inaccurate asset data, data governance discovers the problem after publication, not before. The interaction matrix shows a missing interaction: data governance and GIS operations do not have a formal quality-gate interaction.
3. Programme delivery to Architecture Board. The Architecture Board reviews connections evidence on a fixed monthly schedule rather than on demand. This means that urgent architecture decisions wait for the next board meeting. The interaction matrix shows asymmetric authority: the programme director carries delivery accountability but depends on a governance body that operates on its own timetable.

London RACI structure

The RACI for the connections modernisation should address the following key activities. Each activity has a Responsible actor (who does the work), an Accountable actor (who owns the outcome), Consulted actors (who provide input), and Informed actors (who need to know the result).

• Connection application assessment. R: Connections Team. A: Programme Director. C: Network Planning, Design Engineering. I: Regulatory Affairs, Data Governance.
• Network capacity analysis. R: Network Planning. A: Programme Director. C: Design Engineering, Data Governance. I: Connections Team, IT/Digital.
• Connection scheme design. R: Design Engineering. A: Programme Director. C: Network Planning, Connections Team. I: Delivery/Construction, IT/Digital.
• LTDS data preparation and publication. R: Network Planning. A: Regulatory Affairs. C: Data Governance, IT/Digital. I: Architecture Board, Programme Director.
• Architecture compliance review. R: Architecture Board. A: Architecture Board. C: IT/Digital, Programme Director. I: All teams.
• Cyber security assessment. R: Cyber Security. A: Programme Director. C: IT/Digital, Architecture Board. I: Regulatory Affairs.

The London case also shows why organisation mapping must be revisited as the transformation progresses. The relationships that matter at the start of a programme are not always the same relationships that matter once the first transition architecture is in place.