Britain should learn from Japan’s shared city data

Japan’s shared-data approach offers British technology businesses a better competitive target than another isolated city dashboard. My view is that lasting value will lie in making useful data reusable across services, provided buyers retain control over access and supplier replacement. Japan’s smart-city reference architecture supplies a concrete model for that argument; it does not establish that shared platforms deliver cheaper or better services everywhere.

Key pointers

• Ask suppliers to demonstrate how another developer could reuse the data without buying their application.
• Start with a service problem and an identified data consumer before commissioning shared infrastructure.
• Require named owners for data accuracy, updates, access decisions and incident handling.
• Compare the cost of maintaining shared connections with the cost of separate integrations.
• Test supplier replacement during the pilot, while the consequences of failure remain manageable.
• Treat public confidence and service continuity as acceptance criteria alongside technical compatibility.

Japan is making data reuse a design decision

The consequential part of Japan’s approach is the separation between a service and the information supporting it. The Cabinet Office describes services resting on management arrangements and a data-linking platform called the City OS. Its national architecture is intended to make connections within and between cities easier. Japan’s smart-city framework

That is an active programme of design work. The Cabinet Office lists edition 2 on 10 August 2023, edition 3 on 31 March 2025, edition 4 on 23 May 2025 and edition 5 on 11 March 2026. Those edition numbers show successive revisions, not the number of deployments or the scale of benefits achieved. Reference architecture editions

The geospatial supplement gives the argument practical substance. It identifies fragmented information across sectors as an obstacle and proposes shared formats and interfaces through which different applications can reuse that information. Avoiding dependence on a single supplier is an explicit design objective. Geospatial platform purpose and architecture

For British companies, I would translate this into a product requirement. A supplier should be able to explain what another service can do with its outputs, who authorises that use and what survives when its contract ends.

That creates an opportunity for a smaller UK specialist. A business building a useful accessibility map or facilities service should seek an interface it can afford to use and understand. It should not have to win responsibility for an entire city’s technology estate before delivering something valuable.

How shared infrastructure would work

The Japanese geospatial design separates storage, preparation and use. Original information can come from catalogues such as CKAN or from file storage. A linkage layer collects it, converts it into standard formats and distributes it through an application programming interface, or API. Applications then use that interface to deliver services. Three-layer architecture

The practical distinction is between preparing a dataset repeatedly for separate applications and maintaining a reusable version that several applications can consume. The supplement identifies tourism guides, disaster-prevention applications and facility management among the possible uses. It also assigns responsibility for data freshness and accuracy to the data layer. Data responsibilities and application examples

Consider a hypothetical British town sharing facility locations between a visitor map and a maintenance application. The proposed benefit is that a corrected location reaches both services through the shared interface. The acceptance test should therefore include changing a record and checking both applications, not merely demonstrating that each can display a map.

I would also require each application to show when its information was last refreshed. Reusing an incorrect record more efficiently is not a service improvement.

Compare components and delivery responsibilities

A fair comparison starts by separating jobs that different technologies perform. The Japanese supplement names several open-source options, but it does not present them as interchangeable, complete city platforms.

| Component | Role described in the Japanese supplement | Question for a prospective delivery partner |

| --- | --- | --- |

| CKAN | A catalogue supplying original data to the linkage layer | Who maintains the catalogue and checks its records? |

| FIWARE | Management of dynamic context information, including sensor data and events | How will changing readings connect to the map data? |

| MapLibre GL JS | Rendering vector tiles as visual maps | Can another developer maintain the application and replace its map source? |

| deck.gl | Three-dimensional data visualisation | Does the service need this capability, and who will support it? |

The component descriptions come from the geospatial interoperability supplement. These are complementary roles, not a product ranking or a verified shortlist of UK support providers.

British buyers should compare an integrated supplier proposal with a modular proposal using the same service test. An integrated offer should identify export formats, interface rights and replacement arrangements. A modular offer should identify who takes responsibility when the fault crosses component boundaries.

Keeping an existing application is also a credible option. If it already serves residents well, the first investment could be a documented, maintained data connection. Replacing the visible service should require its own justification.

The bill belongs in operations as well as procurement

The reference architecture argues that standard formats can reduce repeated development work and recommends simple hosting for map tiles. Those are architectural recommendations, not a published GBP price or a measured saving for a British deployment. Cost-related design guidance

I would ask for quotations that separate the following work.

| Cost component | What the quotation should make explicit |

| --- | --- |

| Data preparation | Which records need cleaning, matching or location correction |

| Connections | Which existing systems need adapters and who maintains them |

| Operation | Hosting, monitoring, updates, backups and incident support |

| Data stewardship | Staff time for checking accuracy and approving access |

| Application changes | Testing and adapting each consuming service |

| Exit | Export, documentation, replacement testing and handover assistance |

The financial test is whether reuse removes enough repeated work to justify those shared responsibilities. Count the cost of adding the next service and changing an existing data source. Include customer staff time, even when the supplier’s quotation excludes it.

For a small business bidding into this market, that suggests a defensible service offering in maintaining connections or checking data quality. The buyer should pay for a defined outcome, such as a feed meeting agreed freshness checks, with an escalation route when it fails.

The strongest objection is that sharing creates another dependency

A shared platform can become an expensive dependency before it has enough useful consumers. It can also concentrate decisions about access in an operator whose priorities differ from those of residents or application suppliers. These are reasons to limit the platform’s initial scope and test its accountability.

The University of Tokyo’s Smart City Data Governance Guidelines, developed through a university-industry project, warn that technology-led data collection can provoke public opposition when it moves ahead of citizens’ expectations. Their emphasis is on services, rights and suitable rules for handling data.

That objection weakens any proposal to collect information simply because it might become valuable later. It does not invalidate sharing information for a defined service with an accountable owner.

My preferred starting point is a limited dataset with identified consumers, agreed access rules and a documented correction process. The pilot should also test what each service does when the shared feed becomes unavailable. A public-facing application should have a deliberate response to stale data, whether that means displaying a warning, using an agreed fallback or suspending the affected function.

The proposal should stop if nobody can name the next useful consumer or fund the maintenance. Japan’s own glossary supports a connected model of City OS rather than the idea that every city needs a single indispensable computer platform. City OS definition

Editorial analysis

Britain’s technology suppliers should compete on how easily their work can be reused and replaced. A company that documents its interfaces, maintains reliable data and makes handover practical gives buyers reasons to retain it beyond the difficulty of leaving.

For the next city-service procurement, ask a second developer to build something small against the proposed interface during the pilot. Record the assistance required, the missing documentation and the restrictions encountered. That exercise would provide stronger evidence of interoperability than a supplier’s promise.

Japan offers a sufficiently concrete architecture to make that test worth adopting. The commercial opportunity is conditional on useful services, reliable operation and permission to reuse the data. The volume of information collected is a poor substitute for any of those things.

FAQ

What does City OS mean?

Japan uses City OS as a metaphor for infrastructure connecting data and services. Its official glossary describes a network node linking cities’ information and services, rather than a computer operating system that a city requires to function. Official glossary

Has Japan proved that shared platforms save money?

The supplied architecture describes lower application-development costs as an intended advantage of standard formats and reusable interfaces. It does not provide a comparable cost study establishing savings for a British buyer. A UK business case should therefore test integration and maintenance costs against a defined alternative. Architecture objectives

Does shared data mean unrestricted public access?

That should not be the assumption when designing a service. My recommendation is to define who can use each dataset, for which purpose and under whose authority before connecting consumers. The governance guidelines support setting rules for suitable data use and balancing service benefits with people’s rights. Data governance guidelines

Where should a smaller British supplier start?

Choose a narrow service problem and establish which maintained data it needs. The Japanese architecture separates data preparation from applications and explicitly accommodates services consuming a shared API. A small supplier could test that approach through a focused application or integration contract, with responsibilities and support costs agreed upfront. Application-layer model

Sources

• Cabinet Office, Japan — Smart-city programme and reference architecture register, including edition 5 dated 11 March 2026
• Cabinet Office, Japan — Geospatial Data Interoperability Platform, second edition, 23 May 2025
• Cabinet Office, Japan — Society 5.0
• Japanese government Smart City Guidebook — Separate volume 3, glossary
• University of Tokyo, Institute for Future Initiatives — Smart City Data Governance Guidelines, policy recommendation, March 2023