Transforming the digital

architecture of planning
A critique of planning software today and
the pathway to a more open, innovative and
interoperable planning software landscape

April 2020
Table of Contents
Definitions 3

Introduction 4

Our approach 4

1. Today’s planning software landscape 5

A concentrated market 5

High level architecture map of planning software today 8

Failings of planning software today 10

2. Emerging technologies 13

Common themes in emerging planning services 14

Digital transformations in other industries 17

Consequences and analysis of emerging planning technologies 19

3. A vision for a new digital planning system 21

Design principles 21

The principles in action 28

4. Things to consider next 33

Acknowledgements 35

2
Definitions
API – Application Programming Interface, a computing interface to a GDPR – General Data Protection Regulation, a regulation in European Structured data – Information organised in a way that is machine-
software component or a system, that defines how other components Union Law. readable and adheres to a predefined schema.
or systems can use it.
GIS – Geographic Information Systems {application:
{applicant:
Back-office systems – The administration system used to process a {name: Joe Bloggs,
address: 1 Main Street, Anytown,
planning application. Legacy Planning Software – refers to software currently in wide email: [email protected],
…
use across local authorities not employing the use of emerging },
property:
CIL – Community Infrastructure Levy, a planning related charge which technological advancements. {uprn: 1234,
uses: residential,
can be levied by local authorities on new developments in their area. site-area: 1,000,000,
LLPG – Local Land and Property Gazetteer, the master address …
},
Data schema – The framework for structuring a data entry. The dataset maintained by a local authority. …
},
…
schema outlines what information can be included in a structured }
data object and what data type it should be. For example, see here for Local Planning Authority – a local government body empowered by
a data schema of a person. law to exercise urban planning functions for a particular area, most
often, the local council. Unstructured data – A block of information not adhering to a specific
Development Management – the regulatory process by which a local data schema rendering it non machine-readable. For example,
planning authority controls development and the use of land. Plantech – the use of existing and emerging technologies to build 21st- paragraphs of free text inside a PDF.
century future-ready and flexible planning tools, systems and software.
Documents – Non-machine-readable (or difficult for machines to Application Form

read) documents most commonly in PDF form (not JSONs as with Red Line – polygonal line on a cadastral-like map that identifies land
Section 1

document databases). to which a planning application relates. Applicant Info:

Name: Joe Bloggs

Address: 1 Main Street, Anytown
Emerging Planning Software – refers to a range of new and Section 106 – also known as Unilateral Obligations, a tool sought by Email: [email protected]
…
innovative software tools and services that have emerged in the UK local planning authorities to mitigate the impact of a development on a
Section 2
market in the last few years that offer new ways to carry out various local community and infrastructure and secured by a legal agreement. Property Info:

planning-related tasks. UPRN: 1234

Uses: residential
Area: One million
…

3
Introduction
Ten years ago Marc Andreessen wrote “Software is eating the This white paper explores the intricacies and consequences of To ensure deep domain expertise in planning, as well as technology
world”1 – if only someone would put urban planning on the menu. this emerging future system and provides guidance for planners, and data, the Catapult’s Digital Planning and Applied Data and
In an increasingly digitised world, technology could enable central government and decision makers, local authorities, investors, Technology teams collaboratively researched and produced this
urban planners to make better value judgements on policies innovators and those looking to disrupt the status-quo. We also report. Owing to its broad scope and multidisciplinary approach, we
and development proposals. Software should provide access to outline opportunities within the emerging planning software landscape believe our view of the software landscape is comprehensive and
evidence and more information, all with the aim to inform better by presenting our vision of what a future system could look like, so draws on industry-wide best practice.
planning decisions. that government, local authorities and other stakeholders are better
equipped to shape planning software in the future. Planning practice is effectively split into plan and policy-making and
development management. This means that there are two fairly
But the software offerings of today are not yet fit for this purpose.
distinct software systems in operation for each. The systems used
Using today’s planning software presents a constant battle between
learning the software, creating workarounds for limitations in the Our approach for plan and policy-making are in less need of an urgent overhaul than
those used by development management. Similarly, development
software, formatting documents to export, and then importing back To arrive at the insights and recommendations in this paper, we
management processes, by virtue of being a regulatory activity
into the software. All of which consume huge amounts of time that undertook qualitative research across the planning industry. This
rather than a policy activity mean the software used are far more
should be devoted to the actual practice of urban planning. involved interviewing a varied selection of organisations and
complicated. For this reason this research is focused entirely on
individuals across the planning industry. We interviewed new planning
development management software.
This is what planning software should really be for. technology providers, gaining insight from findings of their earlier
work, barriers to entry and visions for the future. We also spoke to
Since 2016, Connected Places Catapult and its predecessor, Future council planning department leads involved in the decision-making
Cities Catapult, has been exploring a digital future for urban planning. and procurement process associated with buying these softwares. In
Under the moniker of Plantech, we have been looking at how existing addition, we spoke to IT administrators within local authorities about
and emerging technologies can be leveraged to build a truly 21st- the management and configuration of the planning software they look
century future-ready and flexible planning system. We have nurtured after. And we shadowed users of these softwares, to understand more
Plantech from a nascent concept with a small number of prototypes, about how the software is designed, how it is used in practice (which
into what is now a truly global community that is accelerating is often different) and pain points for users.
productivity and rapidly growing a market.

1 Marc Andreessen (2011) Why Software Is Eating The World

4
1. Today’s planning A concentrated market
The English planning software market is predominantly made up of a small number of large suppliers. This has resulted in oligopolistic

software landscape behaviour, as defined in by David M. Mandy in his book Producers, Consumers, and Partial Equilibrium. An important feature of an
oligopolistic market is the interdependence between the small number of firms, resulting in strategic pricing and product offerings2. In
planning, this has meant that legacy planning software firms offer very similar products so that customers are familiar with their offer.
In this report we will not seek to distinguish the cosmetic differences between software products; conversely, we aim to group these
services by their functional similarities, primarily looking at their role in the planning process.

2 For example, Idox proudly publicises its “exceptionally strong market position” – https://www.idoxgroup.com/investors/

5
Back-office software Idox Tascomi
Idox provides multiple back-office planning software applications and Tascomi, now an Idox company, offers a web-based planning solution
The current suppliers of planning back-office software offer end-to-
is the most common provider to local authorities, with over 90% of called Planning. Planning spans the planning process from pre-
end solutions. This means their solutions allow users – primarily
UK local authorities as customers of their product range3. The Idox applications, through to decisions and enforcements. It is web-based,
planning officers – to manage a planning application from submission
planning products in use today are Acolaid, Uniform and Tascomi, with mobile friendly and has flexible configuration. Tascomi Planning
to the authority through to when a decision is made. Most software of
Uniform being the latest added to this suite. Idox provide document integrates with their online portal service Council Direct. Despite now
this type facilitates storing, indexing, searching, generating and editing
storage, management and reporting, GIS (Idox are gold partners being an entirely integrated part of Idox, Tascomi is still perceived as
the documents for a planning application. Additionally, there are
with Esri, a GIS service provider) and a public-facing portal as well as an emerging light in the world of planning software. In discussions
some structured data associated with each application – such as the
various other additional modules, including ones for Building Control, with various authorities we encountered expectant enthusiasm
applicant name, assigned planning officer, address etc. – all of which
Environmental Health, Housing and Licensing amongst others. amongst officers towards the upcoming rollout of Tascomi within their
are also stored. We will focus on two providers, Idox and Northgate,
offices as they perceived its extra configurability as a valued remedy to
as our research showed they are the predominant providers to English
much of what ails the legacy planning software they use.
planning authorities, but it should be noted that there are other
companies offering similar services.
Northgate
Northgate, like Idox, have a whole suite of products and services. They
provide multiple end-to-end planning software such as Assure, M3 and
iLap. Assure is the latest in the suite and offers web-based, mobile-
friendly and cloud-hosted services. The Northgate suite includes an
online portal and application submission module.

Others
There are various other software that local authorities use but are
less common such as APP by Civica, APAS by Agile and MasterGov
Planning by DEF.

Figure 1: Uniform Modules

3 https://www.idoxgroup.com/public-sector/local-government/

6
Application submission systems Planning Portal In 2008, the 1App service was introduced. This helped standardise
Planning Portal was established by the UK government in 2002 to data entry and reduce variation in applications. Today, the 1App
Up until 2002 planning applications were submitted directly to
provide a common online entry point to planning information and the connector allows application documents and data submitted through
the local authority, primarily by paper and delivered by post or by
digital submission of planning applications and has, since 2015, been Planning Portal to be directly integrated with back-office systems.
hand. Today, local authorities receive the bulk of each application in
partially privatised and is now a joint venture between the Ministry Over 90% of planning applications now come through Planning Portal,
electronic formats such as PDF documents (but may also include
of Housing, Communities and Local Government and TerraQuest, a which now provides support for building control and pre-app advice.
DOC, XLS and others) via a web-based gateway. These documents
private entity.
are then, in the case of authorities that are still paper-based, printed
out for use, whereas authorities working paperlessly, access the Other portal websites
Planning Portal functions as a single gateway for all local planning In 2016 Idox introduced iApply as an alternative single gateway portal
documents via computer software and document management
authorities in England. Applicants submit their plans through input for planning application submissions. iApply has, since October 2019
systems mentioned above.
fields (some validated, others not) and document submissions. This ceased to be a nationwide service and between October 2019 and April
information is sent to the relevant planning authority via a one-way 2020 was only available for submissions to a small number of local
communication, with no means of accessing Planning Portal after it authorities. By April 2020 iApply had been completely discontinued.
has been sent. This means that any amendments to the application
cannot be done in Planning Portal. To do this, validation officers will
either request a resubmission or contact the applicant directly. Issues
can arise however as payment is taken by Planning Portal, alongside
a processing fee, which is then passed onto the Local Authority –
frequently with a delay between payment processing and payment
receipt by the Local Authority. This delay means that the Planning
Authority can not start the timer on the 14-day validation period
without confirmation of payment from Planning Portal, often causing
friction and confusion between applicant and planning authority.

7
 HISTORIC ENGLAND
NATIONAL
SOURCES ENVIRONMENT AGENCY

PL
High level architecture map AN
N ING
PO
of planning software today
RT
IT
SUBM

AL SUBM
IT

Right is a schematic diagram illustrating problems of the current LOCAL LAND AND PROPERTY GAZETTEER (LLPG)
SUBM
IT

COUNCIL
software landscape for planning. These key failings are detailed in DATABASES SITE ALLOCATIONS SUBM
IT

Section 1.3 of the report. CO

NN
SUBM
IT

DA EC
TA TO
S TO R T
R MI
A key understanding of the architecture of the legacy planning AG
E SU
B

software landscape is that the source of many of its problems WE TO

R AG
E
BM
NTS
AP E
stem from having a system that inherited paper documents from BA
CK DO
CU
M

OF ER
the planning system of post-war Britain. Today the planning system SE
FIC
ES
OF IC
R EG
IST
WO
AR TW BL C H RD
C AR PU AR PR
continues to be built around paper documents that have been ED
IT
H E SE OC
ES
SIN
G TS
converted into electronic, fixed-layout flat documents that include text, SU
BM
IT
DO
WN
LO
AD
ITHE
BMDS
UA
SE
E

SP
fonts, vector graphics, raster images and other information – the most CR
EA
TE
CA
SE
common type being PDF documents. M AN
AG M M R
T
EN ING
E ME CO NITO
NT MO
PL UP EX
AN LO
AD TE EM
AIL
N ING RN S
GIS AL
BA TO
CK O LS
OF
FIC
E

IT
SUBM

IT
SUBM

EX
PER
IM
EN
TA
L

Public Interface Data Manual Process Auxiliary Office Tools Software Functions Application Data API
and Documents

8
Currently, an application is submitted through Planning Portal as a combination of data about the Once an application becomes valid (after all necessary documents have been received and correct payment
application (for instance, address, type of application and description of works) and supporting documents made) the statutory clock begins to tick. So, for example, in order to write a statutory letter notifying
like PDF plans, sections and elevations, PDF reports like a Design and Access Statement and a Heritage or neighbours to the site of the application and its details, the officer will generate a template using the back-
Transport Impact Assessment. This is received by and integrated into the planning authority’s back-office office software, but will then proceed to edit that template in Microsoft Word, or a different word-processing
planning software via a unidirectional connector (1APP) which acts as an API between Planning Portal tool. Simultaneously, the officer will be able to make the application and its associated documents live and
and the planning authority’s system. The documents and data then populate the back-office document accessible via the Planning Register, which is a public-facing web front-end offering the public access to
and data storage, which can be accessed via the front-end of the back-office software. Assessment is view and comment on live applications and view previously determined applications. In a similar way, the
carried out manually, by reviewing documents and files stored within the system (floor plans, consultation back-office software allows the officer to amend application data and supporting documents through the
responses, clarification emails with the applicant, etc.). In addition, national and local data sources may be entire lifecycle of the application by allowing them to create further templates or upload documents they
manually called upon. For example, lists of technical consultees and their contact details, address details of may have received by email (or in some cases on CD or USB drive) as negotiations over the application
neighbours from the LLPG (stored physically or elsewhere on the officers’ computer) and floodplain shape proceed, all the way through to its determination, or decision.
files from the Environment Agency (stored in GIS). Validation, case management, assessment and decision
tasks can be carried out accordingly. This largely involves a number of manual processes, with the planning While local authorities will be using GIS for their internal processes, more often than not the Web Map
officer moving between the back-office software, GIS tools and other auxiliary work tools. portal version of this displays only planning constraint information for public access. From our research
we have found that there are relatively few authorities where the portal also presents planning application
information (such as geo-referenced red line boundaries). Due to limited operability between GIS and
planning back-office software, where geo-referenced data exists it tends to need manual loading into GIS.

9
Failings of planning software today
Document not data management Tragedy of Interoperability
Planning Portal allows an applicant to submit a planning application as a series of PDF documents together A key barrier to change and innovation is a lack of interoperability in the legacy planning software market. A
with supplementary application data submitted via a web-based form on the portal. This is sent to the local hallmark feature of oligopolistic markets is the high barrier to entry for competition. Many legacy planning
authority as a series of documents and an XML file. This seemingly trivial process, which exists due to the software lack the provision to work with other software, meaning it would be easier to buy the module
direct digitisation of a paper process, has a profound knock-on effect on the entire planning process: almost from the current provider, rather than procure a new innovative competitor’s offering. Apple have been
all of the information contained within the application is received as a document containing unstructured known to employ similar strategies: in 2016 Apple removed the universal headphone jack, widely used
data, which in turn dramatically shapes the whole planning software landscape. across headphone providers. The absence of this universal port stifled competition from other headphone
producers, allowing Apple to dominate the headphone market4. Currently, legacy planning software offer
It means that the most effective and successful planning software to date have been those concerned significantly limited integration with other services. Applications – often referred to as ‘connectors’ which
with efficient manipulation of documents. Currently, the market leaders offer various permutations of facilitate ‘connections’ or integration between various packages – do exist, but when these are made
document storage, allowing the user to create, read, update, share, export and delete documents whilst available, it is often a costly and inflexible attempt to patch over a hole in the software service. The most
keeping track of the relationships between these. Each software offers only limited structured data entry, common ‘connector’ is ‘1App’ which facilitates connections between Planning Portal and the various back-
some of which is entered by users (for example, planning officers) and some read from the Planning Portal office software applications.
XML file. The result is essentially a document management system.
Fundamental to the problem of interoperability is the lack of standardised data (see Section 1.3.6) and, in
The reliance on document management in planning causes a number of pain points. Unstructured data particular, the lack of standardised, open APIs. Unlike other industries, there is a distinctly closed culture
embedded within documents prevents interoperability with other services, automation of processes, in the planning software landscape. Whilst other sectors such as banking, news, travel and health, have
reducing and detecting invalid applications, limiting the ability to screen proposals against policy and the embraced API-based services, creating an ecosystem of integrated and distributed products and services,
opportunity to link real planning information to long term monitoring. We heard from our interviews that other than 1App, which is unidirectional, we have been unable to find any API-based services amongst
these limitations have forced planners to find manual workarounds, and increased the amount of menial the legacy planning software providers, including the two biggest players. Single-provider interoperability
administrative tasks – such as copying and pasting content between programmes, some of which are even (software built by the same provider that can self-interoperate) has led to one provider offering multiple
being taught as part of their training. services, and the user finding themselves unable to procure further services externally.

4 Kastrenakes, J. (2016, September 8). The biggest winner from removing the headphone jack is Apple.

10
Linking planning and GIS data Bundling of services
Geographic Information System (GIS) mapping has become a fundamental tool for many planners engaged Combining the lack of interoperability with the coupling of storage and services leads to a single end-
in processing planning applications and preparation of planning policy. But the relationship between GIS to-end planning software environment, which can leave the user locked-in to a single vendor. Current
mapping and planning systems is an exemplar of what could be termed a Tragedy of Interoperability in the planning software providers offer their service across the entire planning application process5. These large,
planning software landscape. Some software packages offer built-in GIS facilities such as Uniform by Idox. all-purpose packages are often limited and inflexible, and extending their capability requires expensive
Even though this internal module gives the user more functionality, it doesn’t allow for other specialist GIS upgrades and add-ons. In addition, providers offer smaller bespoke tweaks for customer specific issues
providers to integrate their services or allow the consumer to choose which GIS service they want to use. which then require the customer to hire a consultant from the provider to complete.

In most cases, data stores behind GIS-mapping applications are the source of important information, such No standardised data schema
as planning constraint information or consultation address details. As a result of the lack of interoperability,
this sort of information needs to be manually copied across from GIS databases to planning softwares. As outlined in Section 1.3.2, the lack of structured data is restricting the efficiency, transparency and use
Not only is this a time-consuming process but it is ripe for automation due to its repetitive and structured of planning software. However, for planning to move towards use of structured data successfully and to
nature and where, ideally, this sort of important data would not be tied to GIS systems it could be used and ensure principles of interoperability, standardised data structures must be developed and adopted at scale.
mapped in numerous assorted ways.
The structured data that can be transferred between the applicant and the back-office system via Planning
Portal adheres to a standardised schema that is defined by Planning Portal, but not publicly available.
Bundling of service and data storage The application is then received as a combination of structured data and documents via proprietary 1App
A key aspect of legacy planning software is the tying together of data services (software) with data storage connectors. Councils with different back-office software and different forms of the 1App connector integrate
(data centres). Coupling storage and service provision in one package has negative consequences. The the structured data with their planning software to a different extent. For example, the connector between
provider and maintainer of the coupled systems effectively lock the user in to their proprietary standards Planning Portal and Idox’s Uniform will be different to a connector between Planning Portal and Northgate’s
and structures, making it difficult and often expensive for the user to migrate to a new service. For example, Assure by virtue of the two software applications having completely different internal structures. Once
one local authority indicated that their software vendor set up an agreement whereby data is stored with ingested, it is uncertain how the planning software stores and manages the structured data. As there is little
third parties (ie. data banks) and that the procurement agreement does provide a clause by which the local or no integration with other services currently, and when there is it is costly and time consuming, it is likely
authority they may obtain the data stored should they need to. The local authority however sees this as too that each software is performing the data storage and management differently.
risky to request due to contractual complexity. As a result users are often inclined to upgrade and extend
their entire current system, instead of looking for the most suitable service and/or service providers.

5 (often with the exception of CIL and S106 services, which relate primarily to post-approval stages of work and, from our research appear to be handled most
often by Exacom, a modular standalone provider)

11
No human-centred design
Most existing planning software is configured for planning, as
opposed to designed for it. The current process is supported
with existing tools, but there are a multitude of workarounds and
manual hacks required for this to be the case. These hacks result in
inefficiencies, time delays and financial implications and costs to local
authorities. Available planning software applications do not place user-
experience and usability at their core, but instead how a user interacts Summary
with the software is often dictated by the predetermined processes
We have highlighted seven key failings that characterise and restrict the current planning software landscape.
baked into the software functionality.
These failings continue to pose major barriers to the way new technologies can be harnessed for the benefit
of planning practice. Critically, in benefiting planning practice, new and emerging technologies will contribute
There are two key user groups in the planning process: back-office
significantly to the better and faster delivery of new developments, such as critically needed new homes.
planning staff and the applicant. The current system fails both of
these user groups. The back-office staff have to wrangle and strain to
adapt their bespoke and council-specific processes to the rigid frame
of the software, leading to more work, slower decision-making and
frustrating blockers. The applicant meanwhile is met with an opaque
view of the process once the application has been submitted, only
gaining infrequent glimpses into the status of their application, and
with inefficient communication channels between them and planners.

12
2. Emerging We believe there is a significant opportunity for improved
planning software. A few emerging technologies are already
tackling some of the failures of the current system. These
There have already been moves to address some parts of the
existing system. Reducing Invalid Planning Applications (RIPA)
is a collaborative project funded by the Ministry of Housing,

technologies emerging software applications do not all displace the legacy

planning software providers directly, but form parts of a newly
Communities and Local Government’s Local Digital Fund. Hactar,
Snook and the London Borough of Hackney have collaborated on
expanded digital planning service. Therefore, the adoption of the Submit My Planning Application (SMPA) and the London Borough
new technologies must come in parallel with a change in systems of Southwark together with Open Systems Lab developed PlanX.
and processes. The London Borough of Southwark also collaborated with
Unboxed to explore the Back-office Planning System (BoPS).

Detailed below are common themes that run across these

projects, and how they are realised in these projects.

13
Common themes in emerging planning services
Structured data and common schemas
A common theme among the majority of emerging services is that they are built around structured data.
Structured data is a way of organising information in a way that is easily understandable to both human
and machine. For example, biological taxonomic classification is a data schema – it allows for each
new species to be referenced and indexed in a consistent way, using a common set of parameters (e.g.
Kingdom, Phylum, Species, etc). This allows for organisms to be compared, stored and queried much more
efficiently.

Similarly, a planning application contains lots of information – the applicant’s name, the date of receival,
the type of application, and much more. A data schema would allow this information to be organised in a
reproducible, consistent and intuitive way that would make comparing, updating, searching and analysing
applications much easier. In addition, logic trees can be constructed based on the schema to ensure that
only the relevant information is submitted in the first place, and that the information submitted is correctly
formatted, reducing the number of invalid applications. This has been demonstrated as part of the RIPA
project, which has created a set of schemas that could replace some of the planning documents submitted
with an application.

Having common, standardised data schemas is essential for the wider adoption of data-driven, rather Figure 2: Typical Breakdown of reasons for invalid applications – Wycombe District Council
than document-driven, planning services. Capturing and passing data in this way would generate a richness
of data that will unlock insights previously unimagined. Using standardised data schemas facilitates data-sharing between services by enabling a common
understanding of the contents of shared data ‘packets’. The process by which these ‘packets’ of data are
Invalid planning applications are often caused by the payment of incorrect fees and missing documents. sent must also be standardised, commonly achieved through standardised Application Programming
Figure 2 presents the typical breakdown of reasons for invalid applications from Wycombe District Council. Interfaces (APIs).
Structuring the content of an application in a standard and machine-readable way allows for live validation
and error detection for an application during the submission process, similar to the way PlanX facilitates
self-triage by identifying issues in advance of making an application.

14
 Open and standardised APIs
APIs allow software applications to communicate and share
SMPA uses the Python data structure library schematics to enforce
information with each other. APIs provide information transfer
and validate the schema, allowing the data structuring to be
between a server and a client. The client makes a request to an
decoupled from the querying and storage.The structured data that is
API endpoint, and the server provides a response. Essentially, APIs
collected, alongside supporting documents, is stored in a schema-
act as bridges for data between software applications. There are
less RethinkDB database. The back-end is then exposed through a
various standards and protocols used by APIs. For web APIs the
modern RESTful API, built around the OpenAPI specification, and is
REST framework is commonly used.
hence designed to be interoperable with any other application. The
API is only useful when the data is efficiently queryable, hence the
Open and standardised APIs are essential to facilitating
overarching need for standardised, structured data.
interoperability and the wider adoption of common data structures.
SMPA aims to guide householder applicants through the submission
The front-end of the application uses a logic tree to determine which
process, helping them include the right information, accurate and
questions are relevant based on the information submitted by the
complete documentation and to pay the correct fee, the latter of which
applicant, aiming to reduce the amount of irrelevant data in the
is particularly error-prone. To achieve this, SMPA collects structured
submission. The application details are then made available on a
data from the applicant that adheres to an open data schema. The
public user-interface. This entire service is only made possible through
schema, designed to be open, updateable and extendable, ensures
structured data, and by constructing a transparent and standardised
SMPA is sustainable in the fast changing landscape of Plantech. The
API. SMPA is designed to interface with other back-office system
Planning Portal schema was judged unsuitable for their application,
providers, and their API specification and schema design is open. This
as it was outdated and highly rigid. This was by virtue of the schema
encourages an ecosystem of services, where SMPA is just a single
having to accomodate all application types for all local authorities
part of a system of interoperable, modular applications.
using a multitude of back-office systems.
Figure 3: snapshot of part of the RIPA data scheme

15
User-centred design Modular by design
A key failing of legacy planning software is their unintuitive, inflexible The resulting application pulled structured data from Hackney Council A consequence of the adoption of common data structures and open
and sometimes outdated user interfaces. Amazon and Netflix did not SMPA and displayed applications at all different stages on one easy- APIs is that services can be modularised. End-to-end, the planning
need to train people to use their service - they created a superior to-use user interface. The user (case officer or planning manager) process requires many steps, actions and interactions. The process
service that actively responded to the needs of users in a dynamic is able to navigate through applications, selecting from multiple can be partitioned into discrete units, or modules, each with a single
way, with an intuitive layout. An emerging theme across all new choice dropdowns and filling out free text boxes answering specific job and well defined interfaces. This will allow local authorities to
planning technologies is the emphasis on software that is designed for questions. The application is designed around the user-experience procure the best solutions for each module of the planning process
planners. The planning process is complex, non-linear and often requires and efficiently fulfilling the requirements of the user. This is a clear without major disruption. This would also drive down costs for
specific expertise and knowledge. Currently, planners not only need to example of the design of the software responding to the needs of the upgrades and replacements and increase the quality of the service
understand planning as a process, but also how that process maps onto user, and not the user reacting to and adapting to the capabilities of accordingly. Modularisation makes updates and swap-outs genuinely
a digital system. This often involves workarounds and ‘hacks’ outside the software. The BoPS project also outlined a clear business case simpler as they are protected from the full system complexity.
of the planning software, for example using an Excel spreadsheet to for this type of product, estimating an average annual cost saving of This would be a considerable step change for the current planning
reformat consultee addresses. By closely aligning the design of the user £481,838 per council. This is achieved by reducing the time spent on process, enabling new innovators and disruptors to enter into the
experience with the way that planners engage with the planning process, processing applications by 35%7 if this service was rolled out for all digital planning landscape, and reducing single-supplier lock-in. All of
digital planning can be more efficient and less frustrating. application types. the new software applications analysed in this report (SMPA, RIPA,
PlanX, BoPS) fit within the vision of a modular planning system. These
The BoPS team developed a prototype which was designed to interface While BoPS considers the user experience from the perspective of services have been designed with interoperability at their core – BoPS
with other emerging public facing services such as PlanX and SMPA. In the planning officer both SMPA and PlanX are an example of user first can pull application data from SMPA, and has future plans to integrate
addition, it was designed to account for future planning registers and design from the perspective of the applicant. By offering a self-triage with PlanX and RIPA. The PlanX APIs allow bidirectional access with
the London Development Database (LDD)6. The BoPS team conducted process, these software have evolved the application process into a other software modules. The data structure of planning applications
extensive user research across multiple district, city and London simple, easy to use one. developed by RIPA is open and collaborative.
boroughs. The focus of the research was on how planning officers and
planning managers use software to process an application. Some of
the key findings were that planning is non-linear, information is hard
to find and there is little standardisation of many parts of the process.
The BoPS prototype is focussed around delivering a useful service for
key users based on core design principles.

6 Envisaged as a ‘live hub’ of development information managed by the Greater London Authority and
containing details of all planning consents meeting criteria agreed with the London boroughs. 7 Back-office Planning System (BoPS) Alpha phase report

16
Digital transformations in other industries
The built environment sector, and planning in particular, are not the first industries to undergo digital The banking sector has seen digital transformation through the aggregation of data and the definition of
transformation. In fact, McKinsey & Company’s Digitization Index8 would suggest that according to E.M. open standards – for example through the Open Banking initiative. This has worked well for private clients
Rogers’ Diffusion of Innovation Theory, planning is likely to sit somewhere at the tail end of the late majority9 and the business sector as a whole, but most importantly for the banks themselves. Benefits have led to
of adopters. cost savings, service optimisation and a reduction in transaction times.

Other industries such as healthcare, banking, manufacturing, transport and tourism have already undergone Our research has uncovered that the greatest challenge to digitisation within the healthcare sector was
significant transformations and are helpful in understanding best practices for the digitisation of planning standardisation. Without standardised data formats, the capabilities and utilisation of APIs is significantly
software. One unifying or repeated thread that emerges from all of these industries is the game-changing role restricted.
played by APIs in the digital transformation of each and every one of these industries. Other industries have
optimised interoperability by adhering to data standards and applying facilitating APIs. In fact, in one reference It is worth noting however that whilst APIs may appear on first inspection to be a ‘silver bullet’ for
to the way APIs have and continue to transform the health industry, it is identified that they have taken the interoperability problems, they do pose their own set of challenges and won’t cure existing problems in the
industry to a whole new level of interoperability. planning software landscape on their own. For instance, APIs will need to be created in a custom way to suit
the needs of the sector and service they are providing.
An example of how an API can promote digital transformation and innovation in the transport sector is
Transport for London(TfL)’s “Unified API”. This API provides access to TfL’s open data for use in third party What resonates most significantly with the planning sector is the proliferation of outdated or non-API enabled
software and services. This has allowed for the development of applications like CityMapper, Waze and technologies. Like planning, many within the healthcare sector are still using, and worse still, even procuring
Moovit. old technologies that are incompatible with API technology.

8 McKinsey & co. Digitization Index

9 Diffusion of Innovations, Third Edition – Everett M. Rogers, p. 21

17
Legacy planning software applications are glorified document
management systems with challenging and clumsy user interfaces.

What if we strip document management back to the basics and remove the complicated user-interface?

What if a planning authority used Google Drive to manage planning processes in the council?

Planning applications would still be submitted as digital documents – but these documents would be
saved on Google Drive.

Planning reports, notices, decisions and communications would all be produced and shared via Google
Drive, primarily Google Docs and Gmail.

For these tasks there isn’t much of a departure in terms of functionality from the software currently in use.

Google Drive allows the user to create directories – so documents received and documents produced
could definitely be kept together.
Since Google Drive is a cloud based platform, there would be no issue with roll-out and remote working. It
can also be used and accessed on multiple platforms and devices, including mobile phones, which would
Google also employs an increasingly clever search tool that allows the user to identify Google produced/
be particularly useful to planning officers on site visits.
saved documents by simply typing in keywords. So searching for things would be easy.
However, the current software allows users to link applicant data to application documents with a unique
While legacy planning software often offers a caseload management tool like a traffic light system, application ID. It also allows users to interact with geospatial data and generate automated templates for
planning officers tend to manage their cases using Excel sheets and manual lists. Google Sheets offers a letters. This could be mitigated with Google Drive Add-ons, e.g. Ultradox (automate processes in Google
direct and easy-to-access replacement. Drive) and GeoJSON Map Viewer. Additionally, each Google doc has an automatically generated unique ID.

18
Consequences and analysis of A new market for innovation in planning
The modular nature of new packages will inspire a new market for services, encourage innovation and
emerging planning technologies disruption, and promote the evolution of the planning software market and similarly reduce users from
To innovate responsibly it is important to consider both the intended and unintended consequences of your being locked in. However, the development of new tools and applications and creating a new market for
service. We therefore performed a consequence scan using the DotEveryone framework on the emerging planning software will necessitate resource investment. The decision to invest these resources is an active
digital planning innovations. This process aimed at identifying possible negative consequences of new decision to divest resources away from other parts of the economy.
technologies and outlining a mitigation plan. The framework also highlights the positive consequences and
gives an understanding of how to enhance them. Changes to revenue streams
Greater transparency and democratisation will mean better applications and more of them. Assumedly,
Increased democratisation of planning automation will be key to assisting local authorities if the volume of applications increases. So, while digital
The patterns of practice we have seen so far amongst emerging software solutions show that the transformation of planning tools used by councils may lead to an increase in the number of applications
transformation of the planning software landscape will inevitably mean that software used by planners received, it may also lead to a significant loss of income. Pre-application meetings are a significant source
will be designed, at least in part, by planners, not just configured by them. of revenue for many local authorities as they charge applicants a premium to meet with council officers,
to discuss a proposal before it is submitted. Even before the introduction of Planning Performance
With an easier to understand system, more people will be able to engage with planning. This will likely lead Agreements (PPAs) many schemes enjoyed more than just one pre-application meeting before submission.
to an increase in accurate and valid applications. As more people engage with and understand planning, we With the use of more effective ways of screening applications, including the automation of various tasks,
will also likely see a significant drop in enforcement activities as people gain a better understanding of how new digital applications will do away with the need for pre-applications, potentially ushering in a massive
and what they need to do to comply with the system. blow to revenues.

Truly user-focussed digital platforms are also likely to promote better methods of consultation, reducing the
number of objections to proposals as well as overall costs associated with consultations. This will in turn
lead to faster and more effective delivery of new homes, of the right types and in the right places, which is
by default the core purpose of planning activity: to promote the greater good.

19
Redundancies Subsumption and procurement Plantech as a catalyst for local
There is also the human face of digital transformation. Supermarket The way the planning software landscape is currently structured government innovation
checkouts are undoubtedly more efficient and save money, but former around a small number of big players means there is a chance that The digital transformation of the planning system could also have a
cashiers are now out of jobs. Planning admin officers are the oil that modular innovation could become subsumed into them. Whilst ripple effect on the mindset of local authorities. Councils tend to be
keep the wheels of planning departments moving and are the ones conglomerate acquisitions of smaller, emerging competitors are a slow-movers when it comes to transformation. Cash strapped, under
that would bear the brunt of automation. Planning admin officers useful strategy to prevent competition and protect market dominance, strain11, responsible for a huge number of local services and often
process and validate applications, commence public consultation they also stifle innovation10. This has already started to happen. Our bureaucratic, innovations can be difficult to prioritise, even if the long
processes and ensure planners have the support to do their jobs. In research with various local authority planners has uncovered that term rewards will be beneficial. However, the positive transformation
a new digital world, software will fill that role and the changes this many are pinning their hopes on the roll-out across their offices of a of one service could catalyse this change more generally. Connected
causes should be considered holistically, taking into account cultural new rising star – Tascomi – which is purported to offer innovative Places Catapult have seen how new packages and tools have the
and organisational consequences. solutions to their back-office needs. However, Northern Ireland based potential to open up opportunities for interoperability across other
Tascomi was purchased by Idox in 2019. Similarly, Idox’s biggest council services. Our work for the GovTech Catalyst, on housing
This is also true for planning consultants and agents who currently competitor, Northgate (part of the NEC Corporation), purchased monitoring reveals deep connectivity and potential for benefit across
play a significant role interpreting and translating planning for mass design studio Snook, part of the team behind SMPA, also in 2019. So building control, council tax and the strategic planning of council
consumption. A more accessible and understandable system means when a new disruptor comes along, often we see that the existing services like waste collection, utilities, and schools.
there will be less reliance on consultancy as digital tools enable other big players buy them out and then cease to release new, innovative
users to perform these roles. An holistic, ecosystem-centric view, that features. This further cements the oligopolistic behaviour exhibited in Finally, digital transformation of planning software will also lead to
considers these stakeholders and their accumulated knowledge as the market for planning software. the diversification and upskilling of existing staff, increasing digital
well as the new markets created should be taken when strategically literacy and broadening opportunities for talent markets with a focus
investing in the next wave of planning digitisation. This presents a real risk to innovation by bringing us right back to on software engineering and data science to contribute to local
where we are now – a small, closed circle of providers. Yet this is not services that are critical to some of our biggest challenges such as
the only barrier to new disrupters. As we set out earlier, the existing decarbonisation, and responding to the housing crisis.
planning software landscape is often simpler and easier for local
authorities to digest in procurement terms than a series of modular
components from a number of different providers. Even if new
disruptors can survive subsumption and acquisition, it is uncertain
whether they could survive local authority procurement.

10 Seru, A. (2010). Firm Boundaries Matter: Evidence from Conglomerates and R&D Activity. SSRN
Electronic Journal. doi: 10.2139/ssrn.972056 11 Local Government Funding – Moving the conversation on; LCA, 2018

20
3. A vision for Design principles
The 6 Design Principles
a new digital Learning from the best practices of other industries, the emergent features of new technologies and the failings of legacy planning
software, we have drawn up 6 key design principles for a future digital planning software architecture. These aim to overcome the

planning system problems we have identified in planning software and we believe that considering them when scoping, funding, procuring and delivering
new solutions will lead to a planning system fit for our future challenges.

21
 The transformation from a document to a data-based planning system is crucial and planning is lagging behind other industries significantly

Principle #1: in this regard. Adapting to the processing of planning applications as structured data is central to creating an ecosystem for innovation. In
itself, this transition might not seem innovative, but it enables a robust and flexible network of further digital services. This principle is the

Data, not documents

foundation for a connected, open and automated planning system. It allows for data to be manipulated, stored and shared between people
and machines more easily and more efficiently. It will inevitably open up the data to be used far more widely across the ecosystem in tasks
like plan-making and development-monitoring.

22
 Enabling structured data requires the creation and adoption of common data schemas. A data schema describes how entities are represented
in data terms. When all modules in a system adopt the same data schemas, the barriers to data sharing are significantly reduced. For
example, the digital transformation of banking and the rising number of innovative FinTech companies can be traced to the Open Banking

Principle #2:
Implementation Entity outlining industry-wide standards and data models. Although not all planning information can be captured as structured
data, the RIPA project is already demonstrating a complete schema can be developed that creates a common format for planning applications
with an emphasis on data. This is a key tenet of microservice architecture, which supports interoperability through message based
Common data communication. Standardising message formats will allow for faster and cheaper interoperability and replaceability of modules.

schemas Attempts have been made, and ongoing projects exist, to develop a single, common planning application data schema. For example, the GLA
Planning Data Standard, the Planning Portal Data Standard and the MySociety Single Register of Planning Schema. However, there is no
consensus as of yet. Building on the work of others is crucial to developing an industry wide common data schema for planning applications.
Further, the schema must be collaborative, open and updateable, i.e. version controlled and open-sourced to create sustainable, industry-
wide buy in.

23
 APIs are critical to the interoperability of services. Allowing services to communicate with each other enhances the reach and utility of a
single module,creating a system that is greater than the sum of its modules. APIs create an environment fertile for innovation, lower barriers
for entry and fostering a spirit of collaboration. Time and time again, in a multitude of industries, opening up and sharing data through APIs
has led to rapid digital transformation. But, similarly to data, APIs must be standardised to reduce complexity across different providers –
adhering to new protocols for myriad different providers could increase the complexity and block the sharing of data. This can be mitigated

Principle #3:
by subscribing to standards such as RESTful API or GDS API standards principles alongside a common data schema. In practice, this could
mean that all procurement agreements are based on the provision of APIs. Borrowing from the UNIX philosophy set out by Doug McIlroy:

Open and
“ Expect the output of every program to become the input to
standardised APIs another, as yet unknown, program.
”
This is how we build a planning system for the future, one that will no longer struggle to keep up with the present.

Alongside the technical benefits of opening up applications through APIs, by opening up new revenue streams, creating new partnerships
and reducing the cost of integration, migration and replacement there is also a strong business case for local government to do so. Although
this does come at the cost of the legacy planning software supplier who will lose the value inherent in holding the only key to the data.

24
 “ Do one thing and do it well
”
12

This is the first Unix principle. It speaks to the modularity of software components built from simple parts connected by well-defined
interfaces. Modular systems are an assembly of modules, which are defined by Kirk Knoernschild as “deployable, manageable, natively

Principle #4:
reusable, composable, stateless unit[s] of software that provide a concise interface to consumers.”13 The modular approach reduces the
complexity of large, monolithic systems from the software development perspective. Additionally, it is important to note that modules are

Modularity
not atomistic, and can be further divided into smaller submodules and subcomponents which themselves adhere to the modular philosophy.
Modular components contain issues locally, and parts can be upgraded and replaced without breaking the whole. Alongside modularity, a new
procurement model will need to evolve to cope with multiple providers. A modular planning system would be revolutionary, and would break

(unbundling) the chain of reliance on a single provider and promote more competition and innovation for planning technologies. Economist W. Brian Arthur
states that modularity “is to a technological economy what the division of labor is to a manufacturing one.”14 This encompasses the types of
benefits we are likely to see as we are able to handle more complex organisation of processes (e.g. procurement) and access greater gains.

12 [McIlroy78] The Bell System Technical Journal. Bell Laboratories. M. D. McIlroy, E. N. Pinson, and B. A. Tague. “Unix Time-Sharing System Forward”. 1978. 57 (6,part2). p.1902.
13 http://www.kirkk.com/modularity/2009/12/chapter-2-module-defined/
14 Arthur, W. Brian. The Nature of Technology: What It Is and How It Evolves. Free Press, 2009.

25
 Although not obviously structural to a modernised planning system, encoding privacy, security and fairness into planning software is
important to maintain a healthy ecosystem of services that is trustworthy and responsible. As data breaches have received more press
scrutiny, distrust of data driven services has grown, and data-governance and information-sharing has become much more prominent

Principle #5: in public digital discourse. Adhering to GDPR’s ‘Privacy by Design’ philosophy and maintaining a high level of security when building and
implementing software solutions will create a more trustworthy and robust system.

Privacy, security A consequence of unbundling data storage and service provision is that there is more opportunity to access data for building applications
on top of the existing services. This must be facilitated in a way that allows equal access for all, which can be achieved by following the

and fairness rest of the principles outlined here – namely open APIs to ensure interoperability and modularity to allow for connected, distributed service
provision. An extension of the FAIR (Findable Accessible Interoperable Reusable) principles15 could be used as a framework for ensuring high
quality data stewardship and management to create an ecosystem for knowledge sharing and innovation.

15 The FAIR Guiding Principles for scientific data management and stewardship

26
 Current planning software has a range of functionality depending on the provider. That’s because as things stand, the front-end and
functional design of these software applications always centres around one question: what should a software application on top of a
document management system be able to do in order to process an application? This answer results in software that can take an application
from submission to decision, but which doesn’t necessarily achieve that by prioritising the needs of the people that need to use the software
or their experience of doing so.

The questions everyone involved in developing these software applications should be asking include: what users exist in the planning
system, and what do they actually need at which stage of the process? How are they currently working, and how could the software make

Principle #6: their work more intuitive, fluent and less laborious? The answer to these questions results in software designed with the user’s experience at
the heart of it. This will create planning software that is easier to use16, and which will speed up the processing of planning applications and

Ease of use improve the quality of work for planners.

Similarly, our research reveals that the typical configuration for legacy planning software consists of a local client on the planners’ machines
and the document management on a local server. This makes it difficult for planners to access planning application information remotely,
restricting remote working and working in the field. This also limits the use of mobile devices. Additionally, local client configuration adds
further complexity for IT departments when rolling out software and updates and providing software assistance.

Web-based planning tools would facilitate ease of use as they will likely reduce IT problems with software and promote remote working.

16 Norman, D. The Design Of Everyday Things. Basic Books, 1988

27
 PA CKK
Y BAAC
EDDB
FFEE AW
N+D
CAK DR
CAK ITH
TFR-TAR W
L-
PL EX
PE SE
SLEF
AN RIM
NIN EN
TA
L
GA
PP
LIC Y
AT E WA
IO T
N GA

SUPPLEMENTARY
APPLICATION
DATA
AM
EN IT
D BM
FLOOD ZONES SU

The principles in action

CONSERVATION AREAS CONSTRAINT
TE
DATABASES C
CO HNIC PA PA ACCK
K
NS AL S YM Y DBBA
ULT INT EN POLICY CIL DFFE
EED
AT TR
A TC N+ AW
IO HE DATABASES AK DR
NS NS CK N CAKC TH
CO TIO R-TAR WI
IDA FL-TF
AV
AL PL EX
PE
L
SES
E

AN RIM

Our Vision
M
HE
SC
PO
NIN EN
TA
L
LIC
YW ING
GA
RIT OR PP
CO ING NIT LIC Y
WA
NS MO
TR
AT
TE
PO AIN
LIC S1
IO
Based on our design principles, we have envisaged a future example of digital planning software
TS
N GA
Y AN 06
D PO CONSTRAINT
LIC
PL Y DATABASES
AN
NIN
architecture. This architecture mitigates the G C failures ofICthe
ON L
Y current system and builds on theATIO progress
N
AP
P ING
ST PO LID LIC
OR
ND VA AT
NIT
of emerging innovations highlighted in this report. RA
IN TS Our vision is predicated on modularity, openness and
A IO
TECHNICAL
N MO TE
C
CO HNIC
NS AL PA
ULT TS YM CIL
AIN

structured data. Actions are clustered into modules according to their similarity. Each module has bi-
AT EN
EXPERTS IO TR TC
NS NS HE N
CO CK TIO
L IDA
VA
MA

directional communication via RESTful APIs. We believe a new digital planning system following this
HE
SC
PO
LIC
URBAN DESIGN OFFICER YW ING
RIT OR
TECHNICAL CO ING
MO
NIT

architecture would reduce unnecessary administration, improve the experience for both planners and the
NS
TR
HIGHWAYS ENGLAND EXPERTS PO
LIC
Y
AIN
TS
AN
S1
06
D PO
LIC
PL
public, and create a space for new Plantech innovations.
Y
AN
NIN N
GC Y IO AP
IC AT ING
ON OL L I D P LIC
OR
ST DP VA AT
R AIN AN IO NIT
TS N MO
The entry point for an application is a public-facing submission portal which we are calling the ‘Planning
PL
AN

Gateway’. There could be many services, both national or local, that allow the public to submit, track, amend
NIN
G RE NS
GIS TIO
ICA

PL
TE
R TIF

SE
NO

Aapplication
G

and withdraw their application. We believe this is the most crucial part of the procedure, as it
NIN

NN A
AN

B
PL

I G AT A
currently decides on the format and content of the information used in the entire N digital
D planning process.
CO
NS
ULT
AT
ION
RE
SP
ON

Without this step executed well, all of the following stepsEMare T limited and suffer. At the submission portal,
EX S
PE
RIM ES L
EN
IA PL
EN NT AN
TA
L ERIE NIN
XP
AG
E GR NS
EG TIO

the applicant submits their application predominantly in

NG
a structured data format. This could be achieved
IST
ER ICA
E TIF
NO
IC G

U BL AN
NIN
P PL

by asking a series of relevant questions or it could simply be an interactive form – flexibility is left to the CO
NS
ULT

providers discretion but should be driven by an iterative assessment of user-needs and testing. PL
AT

E
IO NR

AN S
ES
PO

BA
EX NS
PE ES
T
NIN
RIM L
TIA
EN
A
EN
TA IEN
M
G DAT
L R
BUILDING CONTROL PE
E
AG
EX
GAZETEER NG
CE
The outcome is that the planning application would then exist mainly as a structured data object. PLANNING CONSTRAINTS
AND POLICY
PU
BL
I

Supplementary data is pulled from other data sources at this point, such as OS basemaps, to help the
E LOCAL PLAN
TIC
N NO
REPORTING
CI SIO
DE
PLAN MONITORING

applicant provide all the necessary information. Any necessary fees, such as application charges, can AS
TIO
ICA ION
NA
N D

SE
SS TIF LAT

also be paid at this point. API’s will allow for transaction information (ie. notification of payment) to be
O
N S U
ME N
RE NT CO
PO S
RT ION
W RIT N DIT
ING
G CO

distributed to the Local Authority’s in-house accounting tools and monies will be deposited into relevant
NIN
AN
PL PL
AN
NIN
GC BUILDING CONTROL
OM

accounts via direct communication between the payment function and online banking tools.CISBi-directional
MI
S TT N GAZETEER
ION
EE IO
IAT
OT
EG PLANNING CONSTRAINTS
E N

GD
AND POLICY

communication channels between the gateway and the planning database must exist Ato NN allow the gateway
I N
NO
TIC
E LOCAL PLAN

PL
N REPORTING
SIO

to display tracking information and feedback on the application’s progress.

CI
DE
PLAN MONITORING
N D
NA
TIO
AS ICA ION
SE
SS TIF AT
ME NO SUL
RE NT N
PO CO
RT O NS
W ITI
RIT O ND
ING
GC
NIN
AN
PL PL
AN
NIN
GC
OM
MI
TT N S
ON
EE IO
IAT
EG
OT
ISI
N
EC
GD
EX
PE
RIM
EN
TA

IN
L

A NN
PL
Modules Planning Database Functions Data Sources API
28
Before being submitted to the planning authority, the application is validated against an application schema The interface will be built for planning case officers by reducing the administrative tasks and improving the
and against planning constraints and planning policy. The validation module queries a planning constraints useability for the functionality they need.
and policy module that analyses the application contents against policy and constraint data sources, and
sends back necessary information. For example, the application might need a heritage impact assessment When assessing an application, a planning officer will query the planning constraints and policy data
if it is located in a conservation area. This application will be compared against a common data schema sources with the application data and receive detailed information regarding the application’s compliance.
and tested to see if it contains the correct information in the correct format. If the application fails the initial For example, an application for a tall building will contain rich data relating to its maximum height, shadow
validation check, the applicant will be notified and told to amend their application. If the application passes, paths, effects on wind patterns, access of natural daylight and sunlight into habitable spaces and impact on
it continues its journey onwards to the planning database. skylines and view corridors. All this information could be screened against the relevant data sources within
the local authority’s planning and constraints module.The constraints and policy module also links planning
A validated application would be stored in the planning database. The planning database could exist locally, officers with the necessary experts – for instance, a local authority’s urban design officer can provide
nationally or be federated (that is, set up as a single centralised unit within which each state or division feedback on the proposal. This differs from the way this is carried out today, because in this future system,
keeps some internal autonomy), but it is essential that it can be accessed through standardised RESTful the expert would have access to a back-office gateway to view and interact with all relevant application
APIs, and can be accessed by various groups with varying levels of access. The database will store all data, as well as policy, and be able to submit their response directly rather than via email or word-processed
planning application data, including those in cases where supporting information will need to be provided in documents.
non-data-rich formats. The database will be updated by planning officers, through the decision process and
the pipeline (applications pending a decision). Another key aspect of the decision-making process is engaging with the wider public. This means
the decision module must communicate with the public engagement module. Public engagement
Once the application is stored, planning officers will be able to read and update the application through the encompasses a searchable public planning register that allows members of the public to view up to date
assessment function in the decision module. The decision module will be the main interface for ‘back-office information on planning applications. It also includes consultation and notification, inviting public opinion
planning’ and it’s core function is to assess the application and make a decision. This requires a series of and comments, and notifying relevant parties of any development plans. This is a clear springboard for
actions that fall under this module, namely: new, innovative technologies. For example, using publically accessible application data to visualise new
developments in experiential ways with augmented and virtual reality technologies. Through communication
● case workload management
between the two modules, the decision module could collect feedback from public engagement.
● assessment against policy and constraints
● statutory consultation Finally, planning data is available in perpetuity. Data can be used by the monitoring module to assess the
● notification performance of the scheme during construction and after completion. Similarly, the data can be used for
the monitoring of the development in a locality as part of the plan making and policy writing processes.
● negotiation
● report writing
● sending a decision notice, and
● setting out of planning conditions.

29
 Figure 4: This diagram demonstrates how the new software architecture would 1. Submission 6. Collation of Comments
facilitate the development management process.
An applicant submits an application via the Gateway. They can The Public Engagement module facilitates ways for people beyond the
use various tools to amend or withdraw the application and pay planning system to engage with the scheme and lodge their responses.
associated application fees. The Gateway module is intricately tied to
the Validation module allowing a proposal to be triaged through the 7. Decision-making
POLICY
DATABASES AM
EN
D BM
IT
system once all necessary information is provided. The Constraints and Policy module and the Public Engagement
Module both provide relevant information necessary for an officer to
SU

4
PL
PA
Y

EX SE
SLEF
-TA
L-TFR
C
R AKC
+DF
AKN
FEE
EDDB
BAAC

4
CKK

WIT
HD
RA
W 2. Validation reach a determination on an application.
PE
AN RIM

The Validation module consists of a number of tools that allow the

NIN EN

1
TA
L
GA
PP

8. Planning Decision
LIC Y
AT WA
TE
application to be triaged through the gateway so long as all necessary
IO N GA

tasks have been completed and the appropriate data supplied. The The Planning Decision module brings all the necessary information
CONSTRAINT
TE
submitted data are validated against a common schema with the together to create a decision. An officer can assess the scheme,
DATABASES C

negotiate changes and amendments with the applicant (via the

CO HNIC

Schema Validation feature, ensuring the submitted application is

NS AL PA
TS YM
ULT
AIN EN CIL

10
AT R TC
IO NS ST HE
N CK N
CO AT
IO
LID

7
VA

Gateway), prepare a planning decision report, set out Planning

MA

structured in the correct way.

HE
SC
PO
LIC
YW ING
RIT OR
CO
NS
ING NIT
TR MO

Conditions and navigate the Planning Committee all via the module.
PO AIN
LIC TS S1
Y AN 06
D PO
LIC

The payment is validated to make sure it has been initiated, received

PL Y
AN

2
NIN

Once a decision has been reached and is ratified, a decision notice can
IO N
GC Y AP
ON LIC AT P ING
O LID LIC
OR
ST DP
and is of the right value.
R VA AT
NIT
AIN AN IO N MO
TS
be produced and the decision disseminated.
The Constraints and Policy feature verifies what necessary
TECHNICAL
9. Updated Data
supplementary planning information will be required for triage – for
EXPERTS

instance a Heritage Impact Assessment for a scheme located in a A finalised and determined scheme will live in the database alongside
7 3
other determined schemes and schemes in the pipeline. Data is
PL 5 Conservation Area.
accessible via the Planning Register, a component of the Public
AN
NIN
GR NS
EG IO
IST AT

PL
E IC
R TIF

SE
NO

AN
G

3. Enters the Database

NIN

A
Engagement module.
AN

AB
PL

CO
NS
ULT
AT
IO
6 NIN
G DAT
9 Once through the Gateway, the application lives in the planning database.
NR
ES
EX PO
PE NS
NT
RIM ES L
IA

10. Post-application Tools

NT
EN
TA RIE E
L
EXP
E
G EM
GA
EN
L IC
UB
4. Live Application
P

Where an application has been approved the Application Monitoring

+ The Self-track module allows the applicant (at any time) to track the module can facilitate the processing of S106 and CIL agreements and
1
BUILDING CONTROL

1 progress of the application as it moves through the system. Once the payments. It can also facilitate monitoring of application forecasts. For
GAZETEER

PLANNING CONSTRAINTS
AND POLICY

example, if an application was expected to lead to 100 new car journeys

E LOCAL PLAN

application is successfully through the gateway, it becomes “LIVE” and

TIC
NO
ON REPORTING
ISI
D EC
PLAN MONITORING
D

8 a week and significant increases in the number of bats on the site, this
AN

the statutory clock begins to tick.

N
TIO
AS ICA ION
SE
SS TIF AT
ME NO SUL
RE NT O N
PO C S
RT ON
ITI

module would facilitate ways to check if these actually did happen.

W RIT ND
ING
G CO
NIN
AN
PL PL
AN

5. Statutory Consultation and Engagement

NIN
GC
OM
MIT
TE N S
ION
E TIO
TIA
CIS
GO
NE

11+ Extensions to other services and purposes

E
GD
NIN
PL
AN
The Public Engagement module loads application data directly onto
the Planning Register, and provides ways for the planning officer to Application data can be used for other relevant and/or associated
notify statutory consultees – including offering a number of interactive services such as Building Control and the Council Gazetteer.
and experiential tools for those interested, to engage with the proposal.
EX
PE
RIM
EN
TA
L
The live planning database will also assist with monitoring and reporting
Modules Planning Database Functions Data Sources API
for policy and plan-making purposes, and assist with policy writing.

30
Figure 5: This diagram presents the modules that could be used directly for a planning application. Figure 6: This diagram presents the modules that could be used directly for the decision-making process when considering an application.

AFFORDABLE HOUSING POLICY AFFORDABLE HOUSING POLICY

POLICY POLICY
DATABASES AM
EN
DATABASES AM
EN
SUSTAINABLE TRANSPORT POLICY D IT SUSTAINABLE TRANSPORT POLICY D IT
BM BM
SU SU

PA CKK PA CKK
Y BAAC Y BAAC
EDDB EDDB
FFEE W FFEE W
AKN+D RA AKN+D RA
CAK
C HD CAK
C HD
-TAR WIT -TAR WIT
L-TFR FR
EFL-T
PL EX
PE SE
SLEF
PL EX
PE SESL
AN RIM AN RIM
NIN EN
TA
L NIN EN
TA
L
GA GA
PP PP
LIC AY LIC Y
AT EW AT WA
IO T IO TE
N GA N GA

FLOOD ZONES FLOOD ZONES

CONSERVATION AREAS CONSTRAINT CONSERVATION AREAS CONSTRAINT

TE TE
DATABASES C
CO HNIC PA
DATABASES C
CO HNIC PA
NS AL S YM NS AL TS YM
ULT INT EN CIL ULT
AIN EN CIL
AT
IO T RA TC AT
IO TR TC
NS NS HE N NS NS HE N
CO CK TIO CO CK TIO
L IDA L IDA
VA VA
MA MA
HE HE
SC SC
PO PO
LIC LIC
YW
RING YW ING
RIT
ITO
RIT OR
CO
NS
ING N CO
NS
ING NIT
TR MO TR MO
PO AIN PO AIN
LIC TS S1 LIC TS S1
Y AN 06 Y AN 06
D PO D PO
LIC LIC
PL Y PL Y
AN AN
NIN N NIN N
GC Y IO AP GC Y TIO AP
ON LIC AT P ING ON LIC IDA P ING
PO LID LIC
OR O L LIC
OR
ST D VA AT ST DP VA AT
R AIN AN IO NIT R AIN AN IO NIT
TS N MO TS N MO

URBAN DESIGN OFFICER URBAN DESIGN OFFICER

TECHNICAL TECHNICAL
HIGHWAYS ENGLAND EXPERTS HIGHWAYS ENGLAND EXPERTS

PL PL
AN AN
NIN NIN
GR NS GR NS
EG TIO EG TIO
IST IST
ICA ICA

PL PL
ER ER
TIF TIF
NIN
G NO

AN S E NIN
G NO

AN SE
BA A
AN AN

AB
PL PL

NIN A NIN
G DAT G DAT
CO CO
NS NS
ULT ULT
AT AT
IO NR IO NR
ES ES
EX PO EX PO
PE NS PE NS
RIM ES L
T RIM ES L
NT
TIA
EN
IA
NT
ME
EN EN
TA IEN TA RIE
L R
M L
GE GE
PE PE
EX EX
GA GA
EN EN
B LIC B LIC
PU PU

BUILDING CONTROL BUILDING CONTROL

GAZETEER GAZETEER

PLANNING CONSTRAINTS PLANNING CONSTRAINTS

AND POLICY AND POLICY

LOCAL PLAN LOCAL PLAN

T ICE T ICE
NO NO
I ON REPORTING I ON REPORTING
CIS CIS
DE DE
PLAN MONITORING PLAN MONITORING
ND ND
NA NA
TIO TIO
AS ICA ION AS ICA ION
SE
SS TIF AT SE
SS TIF AT
ME NO SUL ME NO SUL
RE NT N RE NT N
PO CO S PO CO
RT ION RT O NS
W IT W ITI
RIT O ND RIT ND
ING
GC
ING
G CO
NIN NIN
AN AN
PL PL PL PL
AN AN
NIN NIN
GC GC
OM OM
MI MI
TT N S TT N S
ION ON
EE EE
TIO TIO
ISI
TIA TIA
CIS
GO GO
NE NE C
G DE G DE
N NIN N NIN
P LA P LA

EX
PE
EX
PE
31
RIM RIM
EN EN
TA TA
L L

Modules Planning Database Functions Data Sources API Modules Planning Database Functions Data Sources API
Figure 7: This diagram presents the modules that could be used directly after a planning application has received approval.

AFFORDABLE HOUSING POLICY

POLICY
DATABASES AM
EN
SUSTAINABLE TRANSPORT POLICY D IT
BM
SU

PA CKK
Y BAAC
EDDB
FFEE W
AKN+D RA
CAK
C HD
FR-TAR WIT
EFL-T
PL EX
PE SESL
AN RIM
NIN EN
TA
L
GA
PP
LIC Y
AT WA
IO TE
N GA

FLOOD ZONES

CONSERVATION AREAS CONSTRAINT

TE
DATABASES C
CO HNIC PA
NS AL TS YM
ULT
AIN EN CIL
AT TR TC
IO HE
NS NS CK N
CO TIO
L IDA
VA
MA
HE
SC
PO
LIC
YW ING
RIT OR
CO
NS
ING NIT
TR MO
PO AIN
LIC TS S1
Y AN 06
D PO
LIC
PL Y
AN
NIN N
GC Y TIO AP
ON O LIC IDA P LIC ING
ST DP VA
L
AT ITOR
R AIN AN IO N
TS N MO

URBAN DESIGN OFFICER

TECHNICAL
HIGHWAYS ENGLAND EXPERTS

PL
AN
NIN
GR NS
EG TIO
IST
ICA

PL
ER
TIF

SE
NO

AN
G
NIN

A
AN

AB
PL

NIN
CO
NS
ULT
AT G DAT
IO NR
ES
EX PO
PE NS
NT
RIM ES L
IA
NT
ME
EN
TA
L RIE
GE
PE
EX
GA
EN
B LIC
PU

BUILDING CONTROL

GAZETEER

PLANNING CONSTRAINTS
AND POLICY

LOCAL PLAN
T ICE
NO
I ON REPORTING
CIS
DE
PLAN MONITORING
ND
NA
TIO
AS ICA ION
SE
SS TIF AT
ME NO SUL
RE NT N
PO CO
RT O NS
W ITI
RIT ND
ING
G CO
NIN
AN
PL PL
AN
NIN
GC
OM
MI
TT N S
ON
EE
TIO
ISI
TIA
GO
NE C
G DE
N NIN
P LA

EX
PE
32
RIM
EN
TA
L

Modules Planning Database Functions Data Sources API

4. Things to This report is not intended as a prescriptive set of steps to cure
the planning industry of its monolithic software affliction. Nor
does this serve as a prediction for the future of the planning
Our vision is based on extensive research and insights, iteration,
collaboration, discussion and consideration. Whilst the focus of
our recommendations has been on the technology and software,

consider next software landscape.

However, our research has shown that there are significant

these are derived from an understanding of the people and
processes any new technology would be built for. We present it
as one of many possible pathways to a future all-digital planning
challenges with the status quo. The vision for a new planning software landscape.
system we’ve set out, and following the principles and ideas
within this report will deliver a system that is more transparent,
efficient and fit-for-purpose, and which will encourage innovation,
competition and evolve over time.

33
The first step to deliver transformational change will be to start with identifying and delivering ways to Most critical however is that key players in the planning software landscape need to start to think about
move away from the current reliance on documents. This is the source of the problem with the system, and how to deliver a truly 21st century planning system. We look to the key shapers and funders of the planning
without resolving this issue it will be near impossible to deliver real software change. This will require the landscape, central government, local authorities, the plantech community, and legacy planning software
development of standard schemas and governance models for how planning data are stored and collected. providers, to work towards delivering a planning system that responds to the failings we have outlined in
this paper. We hope that by drawing on these principles in scoping, funding and delivering new tools, we will
Secondly, we must put the user at the forefront of our design. Software must be designed to serve the move towards a planning system delivered by a sustainable and vibrant market that can help us deliver the
needs and goals of the user and be intuitive and easy to use. So, those responsible for procurement need homes and services people need.
to value user-research and service design and should prioritise products and services that have been
developed accordingly. We need to further rethink procurement processes so that we invest in ways to How these transformations will be funded will still need to be resolved. Much of the emergent software
learn about what users actually need before investing in a product. outlined above benefited from Research and Development funding from central government, but more will
be needed to scale and run them. Local authorities cannot afford to develop and run their own instances
of each new solution, and economies of scale will be needed. There will need to be new institutions and
innovative business models to be able to continue to deliver and scale these innovations, as well as
continued support from the government to fund further Research and Development, and possibly even
service delivery.

34
Acknowledgements
This paper is the product of cross collaboration and co-operation between the Digital Planning and Data
Science teams at Connected Places Catapult. Alongside us, we benefited from the hard work and support
from the Catapult’s Project Management unit for their careful management of the project and the Creative
Design team for their hard work producing this report and the illustrations contained within.

In addition to the hard work of the Catapult teams, we could not have delivered this report without the
assistance and co-operation of our insightful and knowledgeable partners.

We are particularly appreciative and thankful to assistance from the Planning Department at the London
Borough of Waltham Forest for their willingness to allow us to shadow their staff.

We also acknowledge the honesty and openness of staff at the Greater London Authority, London Borough
of Southwark, London Borough of Lambeth and Coventry City Council in sharing their insights and
experiences.

The teams at Unboxed, Open Systems Lab and Hactar were critical in providing valuable information and
advice and further insights that assisted in ensuring the robustness of our findings.

35