Is It Time for Market Architecture?

If we want to design and build digital and data ecosystems that span organisations, sectors and national infrastructure, our understanding of the boundaries and span of architecture as a discipline may need to do the same.

Is it time for Market Architecture?

Architecture has always expanded when the thing we are trying to understand becomes too big for the tools we already have.

We learned to look beyond the individual application because applications depend on data, infrastructure, security, people and processes. We learned to look beyond individual projects because a perfectly delivered project can still pull the wider organisation in the wrong direction. Enterprise Architecture emerged because somebody needed to connect all of those moving parts to the purpose and direction of the business.

That was a significant step forward. It also left us with a boundary — the enterprise.

Now consider some of the things we say we want to build: a smarter and more flexible energy system, integrated transport, resilient national infrastructure, connected public services, data-sharing across entire industries, and eventually an ecosystem of digital twins capable of helping us understand the consequences of decisions before we make them.

None of those outcomes belongs to a single organisation. No chief architect controls all the participants. There is no common budget, delivery method, technology estate or chain of command. Yet every organisation involved will make decisions that create consequences for the others.

So here is my hypothesis.

If architecture exists to keep purpose, capability, information and technology aligned, then some of our most important challenges now require architecture to work at the scale of a market and a sector.

I call that Market Architecture.

By that I mean treating a market, sector or shared endeavour as an enterprise in its own right. It means understanding the organisations involved, the roles they perform, the capabilities they provide, the rules they operate under, the information they exchange, the services and infrastructure they depend upon, and how all of that needs to change together.

It sounds sensible enough. It may also sound like an unnecessary new label for things good architects should already be doing. That is a fair challenge.

We have widened the lens before

The history matters here, but only because it shows a pattern.

In the early days of business computing, specialist teams concentrated on their part of the problem. Software, data, networks and infrastructure developed their own disciplines. IBM's Business Systems Planning began connecting business strategy, processes, information and systems. John Zachman's 1987 paper gave structure to different views of the same organisation. Frameworks such as TOGAF later helped formalise the idea that business, data, applications and technology needed to be considered together.

Enterprise Architecture did not make the specialist disciplines redundant. It gave them context. A database could be technically sound and still contain the wrong information. An application could work exactly as designed and still support a broken process. An infrastructure platform could be efficient and secure while making the organisation incapable of moving at the pace its market required.

The boundary widened because local technical excellence was not enough.

I think we have reached that point again.

An organisation can build an elegant internal architecture and still be part of a market that cannot exchange information reliably. It can optimise its own customer journey while creating friction for every organisation on either side. It can build a digital twin that makes perfect sense internally, but speaks a language no other twin understands.

Perhaps Enterprise Architecture can already accommodate this. Zachman's idea was never really limited to IT, and a mature enterprise architecture can include customers, suppliers, regulators and external dependencies. But in practice, the organisational boundary still exerts a powerful pull. Funding stops there. Accountability stops there. Most roadmaps stop there. The awkward problems between organisations are marked as external dependencies and pushed towards the edge of the diagram.

Unfortunately, the edge of one organisation's diagram is often the centre of the real problem.

Example one: an energy market that must behave like a system

Take energy.

It is tempting to picture an energy system as physical infrastructure: generation, pylons, cables, substations and meters. But the market depends on far more than electricity moving through wires.

It relies on regulators, system operators, network owners, generators, suppliers, code bodies, data-service providers, government, technology partners and consumers. Each performs a different role. Each has different obligations, incentives, capabilities and investment cycles. Information flows between them under licences, codes, schemes, contracts and technical standards.

A change in one part can produce consequences somewhere apparently unrelated. A new market rule creates new data obligations. Those obligations need submission mechanisms, identity, security, service levels and operational ownership. A programme designed to improve consumer switching can alter the roles of data providers, market participants and central systems. A new flexibility service may depend on asset information that is held by several organisations, described differently and updated at different speeds.

A few years ago, while working with a UK regulator, I developed the design of a regulatory operating model and a high-level architecture for opening up the data across that market. The useful move was to stop looking at each programme or organisation separately. We mapped participants, market roles, regulatory obligations, information assets, data exchanges, digital services and common industry capabilities into the same landscape.

The diagram was not the point. The context was.

Once the market could be seen as a connected endeavour, questions that had looked like isolated technology decisions became questions about accountability, interoperability and shared capability. Who provides identity? How does a data user discover what exists? What does the information mean? Who assures it? How does an innovator gain access without every new relationship requiring another custom integration and another stack of bilateral agreements?

The same problem is now visible in current energy policy. The energy Data Sharing Infrastructure is described as a socio-technical solution combining governance, common processes and technology. The government's 2026 Energy Digitalisation Framework calls for system-wide architectural coherence, common standards and alignment across the sector.

That language matters. The sector has reached the point where more digital activity does not automatically create a more coherent digital system.

Lots of organisations can be busy building useful things and still leave the market fragmented.

In Enterprise Architecture the concept of a building block is well-defined, and in Market Architecture we'd need the same concept, only now enterprises fulfilling one or more roles within the market or sector are the building block. In the energy sector those roles are well defined, with the DNO, TSO, ESO, Generator, and so on.

Example two: separation without independence

Now take a very different problem: separating a nationally critical operator from a parent group.

On paper, the boundary looks obvious. Decide what moves to the new organisation, divide the assets and contracts, transfer the people, put new reporting lines in place and complete the transaction.

Technology makes that neat line disappear rather quickly.

What happens when the new organisation is accountable for services but the former parent still controls the infrastructure? What if security strategy, cloud platforms, identity, architectural governance and investment decisions remain elsewhere? What if the separated organisation can measure a supplier's failure but cannot replace the supplier? What if a data-centre migration already in flight commits both organisations to another generation of shared foundations?

I worked on an independent assessment of the technology separation options for a critical market operator. The visible task was to review three proposed IT delivery models. The real question was more difficult: could the operator genuinely be held accountable while lacking control over the capabilities on which its performance depended?

That meant following the problem across organisational boundaries. Business plans, programme dependencies, operating models, applications, platforms, cloud tenancy, cyber security, physical infrastructure, supplier arrangements, investment governance, service levels, costs and people all mattered.

A narrow architecture review could have said whether the proposed systems were technically plausible. A market-level view asked whether the arrangement would work for the operator, its former parent, the regulator, the wider industry and the consumers ultimately carrying the cost and risk.

Legal separation did not guarantee operational independence. A tidy organisation chart did not move decision rights. A service-level agreement did not create meaningful control if the customer could not exit the service.

This is one reason I hesitate over the name Sector Architecture. The problem was not confined neatly to the energy sector. It crossed corporate ownership, regulation, public policy, critical infrastructure, commercial suppliers and technology. “Sector” can become another box drawn around a problem that refuses to stay inside it.

Market Architecture is not a perfect term either. Public bodies, regulated monopolies and national infrastructure do not behave like a conventional commercial market. But market, used in the wider sense, directs attention towards the system of roles, exchanges, rules and dependencies through which a shared outcome is produced.

The name can remain open for debate. The gap should not.

Example three: a national digital twin made from parts

The third example is more ambitious.

I spent some time working with the Centre for Digital Built Britain and the National Digital Twin Programme, including sitting on one of its working groups. The idea was sometimes misunderstood as a single enormous model of the country. That would be an impressive technical achievement, right up to the moment it became impossible to maintain, govern or trust.

The more useful idea is an ecosystem of connected digital twins.

Organisations will continue to own and operate twins of assets, services, processes and environments. Energy, transport, water, buildings, ports, telecommunications and other domains will develop their own models and capabilities. Those twins become much more valuable when they can share the right information, safely and with enough common meaning to support a decision.

Imagine trying to model the impact of a severe storm.

The consequences do not respect sector boundaries. Flooding affects roads, rail, power, water, telecommunications, emergency services, hospitals, local authorities, businesses and homes. Each organisation may understand its own assets. The useful national view emerges from the relationships between them.

That requires more than APIs.

The participants need to agree what matters, which decisions the connected view should support, what information can be shared, who is authorised to use it, how its quality and currency are understood, and what happens when two sources disagree. Identity, semantics, security, assurance, governance and liability become part of the architecture alongside platforms and interfaces.

The National Digital Twin Programme's published principles recognise this. They call for rules, guidance, frameworks and tools that allow individual and connected federated twins to work at different scales. They also emphasise strategic ownership, governance, safe operation, trust and evolution.

Here is the challenge. Each organisation can make a rational local decision and the national ecosystem can still fail.

One twin uses a different definition. Another updates too slowly. A third cannot share data under its current legal basis. A critical dependency is missing because it sits outside the funded programme. The interfaces may all function, yet the combined answer cannot be trusted.

If we intend to dream at national scale, then somebody has to think at national scale. Not to design every component, but to make sure independently designed components have a reasonable chance of working together.

Surely this becomes an enormous architecture exercise?

This is the objection that should make any experienced architect nervous.

Try to map every organisation, role, capability, obligation, service, dataset, standard, system and dependency in a national market and you will create the world's most expensive outdated diagram.

Markets move. Policy changes. Technology changes. Organisations merge, separate and fail. New participants arrive. The first version of the architecture will contain gaps and wrong assumptions. By the time a central committee has approved the perfect target state, the target will have moved.

The answer cannot be more architecture theatre.

Market Architecture would need to behave as a living capability. Start with a shared outcome that matters. Identify the participants and capabilities essential to it. Map the exchanges and dependencies most likely to prevent it. Agree the minimum rules and standards needed for the first useful step. Build something, learn from it and update the architecture.

That is not an excuse for everyone to do whatever they like. Emergent architecture still needs direction. A garden grows and changes, but someone still chooses where to plant, what to protect and which growth is choking everything around it.

The authority of Market Architecture would come from usefulness and participation. Regulators, operators, government and industry would need to maintain it together. Delivery programmes would both consume and improve it. Disagreements would be visible rather than buried inside different programme assumptions.

Nobody needs a central architect approving every interface. Everybody needs enough shared context to understand the consequences of their own decisions.

So what should Market Architecture actually do?

If the idea is useful, it needs to change what we do.

I think Market Architecture should establish a maintained view of five things.

1. The shared outcomes. What must the market be capable of doing, for whom, and how will we know it works?
2. The participants and roles. Which organisations contribute to those outcomes, where does accountability sit, and which capabilities must exist somewhere in the system?
3. The critical exchanges. What services, decisions, data and physical flows move between participants, and where do trust, timing, meaning or control break down?
4. The common foundations. Which standards, identity arrangements, semantics, security controls, registers, discovery services and data-sharing infrastructure allow the market to work without recreating every connection from scratch?
5. The path of change. Which initiatives are already altering the landscape, where do they overlap, what assumptions conflict, and how can useful progress happen without waiting for a perfect end state?

I would begin with one outcome, not a sector-wide modelling programme.

Choose something important that no single organisation can deliver. Bring the necessary participants into the room. Build the smallest useful shared view. Follow the dependencies far enough to expose the real constraints. Agree what has to be common and where local choice should remain. Then connect funded delivery to that view and keep changing it as the work teaches us more.

The artefacts could include capability maps, participant and role models, regulatory and policy views, information-exchange maps, shared service architectures, standards roadmaps, transition states and decision records. Useful tools, certainly. None of them is the point on its own.

The purpose is coordinated action across boundaries.

Is it time?

I think it is.

Perhaps Market Architecture will prove to be the wrong name. Perhaps it will settle as a form of Enterprise Architecture, Sector Architecture, Ecosystem Architecture or Economic Architecture. I am less interested in winning the naming argument than in making the missing work visible.

Enterprise Architecture taught us to connect strategy, capability, information and technology across an organisation. The challenges now in front of us ask for the same discipline across organisations that retain their own authority, funding and priorities.

That is harder. It is also where many of the failures now hide.

The next time you look at an architecture, pay attention to the boundary.

What sits just outside it?

A regulator? A supplier? A market operator? A shared platform? A dataset owned elsewhere? A policy decision made years before the project began? Another sector whose infrastructure your outcome quietly depends upon?

Keep following those relationships and you may discover that the enterprise you have carefully architected is only one component in the system that actually matters.

If nobody is maintaining a view of that wider system, local excellence will not save it.

We want connected energy, integrated infrastructure and national digital twins. We talk about coordination, interoperability and whole-system thinking. Those ambitions deserve an architecture drawn at the same scale.

If your organisation is trying to solve a problem that crosses organisational, regulatory or sector boundaries, Watchmen can help make the wider system visible. That is usually where the right problem has been hiding.