top of page

Metro Mapping

Updated: Sep 19, 2020

All Maps Are Wrong, Some Are Useful


The purposes of doing Metro Mapping are:

  • Communicate the scope & scale of the programme to senior stakeholders.

  • Create a common reference model that’s understood and adopted by everyone.

  • Prepare for a discussion on business services - impact, risk etc.

  • Introduce the concept of a change-wide 'Services' model.


The benefits of doing Metro Mapping are:

  • Rapid understanding of which aspects of the business will be involved in a change

  • A mutual understanding of through visual language for the change programme

  • Productive discussions in workshops and planning sessions

  • The basis for all business change discussions; risk, progress, priority, and cost.

  • As an aid in budget approval.


The London Tube Map

“The Tube map (aka London Underground Map or the TfL Services Map) is a schematic transport map of the lines, stations and services of the London Underground, known colloquially as "the Tube", hence the map's name. The first schematic Tube map was designed by Harry Beck in 1931”. As a schematic diagram, it does not show the geographic locations but rather the relative positions of the stations, lines, the stations' connective relations, and fare zones. The basic design concepts have been widely adopted for other such maps around the world, and for maps of other sorts of transport networks and even conceptual schematics”. - Wikipedia

“The result was an instantly clear and comprehensible chart that would become an essential guide to London - and a template for transport maps the world over. Beck's revolutionary design, with certain modifications and additions, survives to the present day and is set to serve London Underground and its millions of customers for many years to come.” - TFL

The development of Beck’s Tube Map from 1931 to today, exhibits Design Thinking Principles:

  • iteration,

  • experimentation,

  • inclusivity,

  • simplification,

  • continuous development,

  • innovation.

Beck’s maps work because they are simple yet covey a lot of information. They have been adopted globally and are now the standard reference for metro maps. They are, however, inaccurate; they cannot be used to understand distance, but they do show how trains lines and stations intersect.

A Schematic for Change Design

Like so many new and novel ideas Harry Beck’s Tube Map was at first rejected by his management. Still, he persuaded them to try it out in a small pamphlet. It was an immediate success with the public. The problem Beck solved wasn’t an engineering one, it was one for the travelling consumer. And it worked to one key principle; it must be immediately easy-to-use by anyone.

It struck me that it solved a similar problem with the models we Business or IT Architects often produced. These models are for engineers, by engineers - complicated and arcane. And, because such models are hard to change, we're often out-of-date. The value of such models questioned. Are only produced to follow an architectural method or framework? Using these models with a business audience doesn't help the architect's credibility. Are they out-of-touch with reality? What needed is something business-friendlier, something like Beck’s Tube Map.

My first experiment with Beck’s style schematic was to see if I could create an IT operating model. After a bit of noodling on a Whiteboard, I produced four ‘Lines’ and around twenty stations. Six stations were ‘interchanges’ that connect two or more lines. This gave a sense of close interaction or many perspectives on a service or service cluster. Value chain sequence was also implied by placing ‘Demand’ at the top, and ‘Supply’ at the bottom.

I worked with the CIO to further refine the model before he presented it to the Executive Board. It was to be as part of a business case to expand the IT team. After the meeting, he told me that it was the first time the Board had understood the scope of the services provided by the IT function. Needless-to-say, he got his budget approved.

Example: Smart Meter Services

Following the success of the IT Operating Model Services Map, we went on to Metro-Map a power firm’s Smart Meter Services. Initially, this map was developed to communicate the scope and impact of the change programme.

(please click on the map to enlarge)

Scope of smart metering change programme
Example Metro Map - Smart Metering Services

This map clarified which aspects of the business would be affected by the deployment of Smart Meters. This illustrated the scale of the change that hadn’t been fully appreciated; some saw the programme as a field engineering challenge, others, an IT one. In fact, it was a large-scale business change that would impact around 70% of existing processes and would need significant customer interaction. Once this map was understood and adopted. It became a reference model that appeared in different stakeholder’s presentation decks.

Metro Mapping had proven its value as a change design technique that works at scale and had passed the ‘All models are wrong, some are useful’ test. These maps don’t pretend to be rigorous engineering models; they are designed to aid a business-wide, conversations, and decisions. The degree of adoption within various presenters’ slide decks was a good measure of ‘usefulness’.

If the context is not explained, then every model is 'wrong' in some way. Much like would not expect Beck’s Tube Map to be the correct model to lay new tracks, or measure distance. This is common sense. Yet, when it comes to modelling an organisation, common sense often flies out the window.

Not all maps serve the same purpose. Another type of ‘wrong’ is out-of-date models. One benefit from the simplicity of the Metro-Map it's easy to change. A typical Metro-Map takes an hour or two to update and completely re-drawn in a day. It’s easy to keep up to date.

A Capability Model, favoured by architects is an alternative. It serves a similar purpose, and has some advantages, in a different context, like for example, understanding Enterprise-wide capacity. This can decompose to hundreds of components. It has significant disadvantages in the context of agile change:

  1. It can create a time-consuming debate with business stakeholders; the term ‘capability’ can be misconstrued as ‘capable of’ - as in: “So you're saying my team isn’t capable!”

  2. It can be hard to maintain It requires an experienced architect to maintain using an architectural tool. Compared to Metro-Map that can be maintained by a Business Analyst, or anyone a proficient in using office tools.

  3. Capability and Process are muddled-up. It seems the architects are the only people who use the term ‘Capability’. Whereas, for example, business operations will think ‘Process’. I’ve found, it’s much easier to explain ‘Service’ as the consumer of ‘touch-points’ to a process. And that a process, or several processes, deliver a service. Services are more readily abstracted out of an organisational function than capabilities. Services are outside-in, capabilities inside-out.

  4. A Capability Model is static. It does not represent connectedness or influence between business components. Very few business activities fall within neat boxes. Illustrating a sense of influence or proximity is useful e.g. three different lines meet at this junction, have we got all the necessary stakeholders in the discussion)?

  5. It requires an additional level of translation when it comes to the pragmatics of implementation. If we describe all the business components touched by the transformation as “Services” the same language be all the way down to Standard Operating Procedures, SLAs, 3rd Party Contracts and technical requirements. The last point is particularly valid when various Cloud-services are being consumed and /or Microservices are being developed.

You've no doubt spotted that I've subtly shifted focus more to 'Services' (the WHAT) rather than mapping (the HOW). I owe you an explanation. Many years in Supply Chain Logistics make me see the world as a chain of connected services. And service 'Consumers' are not only Customers - they are both inside and outside the organisation. So when I created a Metro-Map all the 'Stations' are services connected by 'Lines' which are value chains, or chains of supporting services (e.g. Legal, Administration etc.).


A Bit More Service Oriented

Having been through two or three iterations of your services map, it’s time to dig a bit deeper.

Here are questions that expand a business services discussion:

  1. Who should collaborate to help define and design the services?

  2. Can we make a high-level assessment of the impact on current business processes, informal practices, and technology used? (including ‘shadow IT’)

  3. Can we start to identify the degree to which business services need; agile, robust, or resilient qualities?

  4. Can we start to identify the main interactions between the services and events that trigger a service?

  5. Can we start to describe the measurement criteria for each service?

  6. What might be the response-to-failure of a given service?

  7. Can we derive a set of global service principles, and specific one each service?

There are, of course, many other questions arising specific to your situation. The main aim is to get the business stakeholders (e.g. Service owners or Consumers) taking part in the discussion. They will raise additional questions, observations and challenges, and the map will evolve through this inclusive discussion.

It can be useful to share an overview of Business Service Specifications early in mapping workshops.

Service Orientation
Business Service Specification


Metro-Mapping is established in the Scan stage but should be at a minimum reviewed in the Reflect stage of the ACD Cycle:


Lessons Learnt

Before we leave Metro-Mapping services, I’ll sum up the lessons learnt for over fifteen years:

  1. Overly complex, analytically focused models are conversation killers.

  2. The services map becomes a reference model used across a wide range of conversations.

  3. The impact of the scale & scope of the transformation emerges early in the discussion.

  4. The early focus on services helps steer away from the ‘The answer is Cloud’ (or whatever the pet technology is). We also don’t care whether the service is internally or externally provisioned right now.

  5. Service-related concepts naturally follow-on; triggers, outcomes, outputs, SLAs, failure response and so on. This leads to concise business service specifications and measurement criteria.

  6. Naturally leads to the discussion of touchpoints & interaction between services and this helps with partitioning (chunking) the future-state operating model.

  7. Helps with a current-state analysis of the degree to which a service exists today, and how much and when it’ll need to change in the future.

  8. There’s a natural fit with ‘component-based’ IT architectures such as SOA and microservices; concepts that are often important to ‘Digital Transformations’.

  9. Business service mapping is inclusive, iterative, and evolutionary: a complete, cohesive, and shared picture emerges quickly.

Common Pitfalls

  1. Not knowing where to start: This is a ‘Throw caution to the wind’ moment. Give it your best shot, tell everyone it’s a draft and welcome their builds. If you can’t think of the right ‘line’ names, ask for suggestions. Just remember your audience and use language that’s meaningful to them.

  2. ASIS versus TOBE: Counter-intuitively, it’s best to start with a ‘To Be’ map and work backwards to the ‘As Is’. This establishes focus on the transformation goal rather than the status quo and getting bogged down in current operational issues.

  3. Service Granularity: There’s a temptation to throw everything up on the map. Again, think of the audience, keep it as simple as possible. You can always add to the map later. If it becomes necessarily complex (e.g. The Smart Meter example), that’s okay if you’ve taken the audience with you through the iterations. Also remember you don’t need to represent everything on one map. Think about your map a reference schematic that will become a slide ‘background’ on which overlays are used to represent different topics.

  4. Can’t decide which stations should be interchanges: This can be tricky to get it right-first-time. There are two basic types of interchange: 1) two or more lines meet at the single station (service), two or more lines meet but have different station (service) names. The latter is a bit harder to pin down at the beginning, it represents a close relationship between services and could indicate an opportunity to merge, or otherwise rethink the service. The former indicates all the lines that are attached to that station are either providing aspects of the service or are highly dependent on that service. Remember this is a model to help conversation & illicit feedback - it certainly will change.

  5. Context and purpose misunderstood: Don’t just flash up a tube map in a meeting without expecting to spend a few minutes on context and purpose. Take a moment to explain how your model helps to clarify the scope and context of the change. So, for example, it’s not trying to establish a strategy and isn’t an alternative to