SYSTEMS THINKING APPROACH

 

A system can be defined as ‘a set of things working together as parts of an interconnecting network, a complex whole’ and smart streets should be thought of in this way. Smart streets are delivered through the interaction of components, services, and operational teams working together effectively to deliver the whole.

This approach is central to the manual and though every effort has been made in the development to break the process down into simple containable stages, the overall concept that the whole is greater than the parts must be kept in mind.

 

Why joined up services are important in smart streets

Smart street technology needs to be thought of differently from traditional roadside infrastructure (roads, bridges and even traffic signals). This is because it is:

  • linked to other systems in a “system of systems” approach. This linking may be intentional – sharing parking occupancy data with UTC – or unintentional – e.g., allowing insecure access to other systems. Hence a change in one system might impact other systems unexpectedly
  • impacting much more widely on users and stakeholders, and impacted by more of them, e.g., a Clean Air Zone payment system will be used by everyone entering a city who is non-compliant
  • dynamic – unlike much physical infrastructure, its operating and maintenance effort is large compared to installation, for example curating data to keep it up to date as the road network changes, keeping up with IT upgrades
  • customer-facing – almost every smart street service impacts the customer in a visible and direct way – parking availability, in-vehicle services, transport payment, freight and logistics information. They will notice when it does not work and complain; unlike the less direct impacts when say a traffic controller is out of tune
  • needed to cope with unusual cases far more frequently. Smart street systems need to consider IT outages, surges in demand, customers who don’t read instructions and breaks in links in the “system of system” chain above. They need to work resiliently
  • technology systems can be reconfigured to work differently, work to achieve outcomes against changing lists of priorities and quite often can be subject to upgrades, extensions and new integrations with newer systems as they appear

Smart Street Technology and services, therefore, need to be seen as part of a bigger set of processes, services and “system” – this word implies complex systems analysis and modelling but in practice means:

  • having a long-term strategy for your services as an “architecture”, but with clear steps that determine the life span of existing (or legacy) systems migration and upgrade pathways as the “system” grows. This may be not much more than listing how the policies in your Local Transport Plan might be delivered technically, and in what order
  • using published and mature standards/specifications to help elements of the system “talk” to one another, for example, UTMC, DATEX II1….
  • Avoid working in silos, consider integration into existing council services. IT departments must work with practitioners to build in interoperability and use of assets – e.g., communication networks, cloud storage, data platforms already in place, and to ensure cyber security is system-wide. This is vital where payment is concerned, but also makes a service joined up for the customer
  • requiring data to be accessible using open APIs and that you own the data, not your supplier. This is the key for example to allowing payment for parking and CAZ by multiple means, not just a single app provided by an exclusive supplier
  • thinking more widely about your system and impacts – for example, what happens to parking sensors when roads are resurfaced by another part of the Authority? Could you piggyback off an existing communications network or contract already let?

This may seem daunting – transport has been an island in terms of its systems not linking up. But other industries – and government – have joined up to deliver a better customer experience, and save costs. Examples are payment of road tax, internet retail and utility payments. Whilst these are much bigger scale, the concept of user experience and joining up the parts they touch up is key. Compare the ability to pay for anything across the planet with your mobile phone with a few touches, with the current need to download, install and set up accounts for several separate parking apps for a single town (one for Authority parking, one for the railway, one for retail …).

Recently the Bus Open Data Service has shown this approach – a one-stop-shop for open API supplied standardized real-time data, used to assist various customer use-cases. How will you be using this new asset best?

Therefore, the adoption of Smart Streets should not be thought of as operating within a silo, or a fit and forget solution.

 

Disclaimer: The Manual for Smart Streets is currently DRAFT content under development. It has not yet been released to the public and has only been shared with selected stakeholders for the purpose of review.

All content should not be used for any purpose other than to review the current state of this draft content.

*** Proposed final text for this footer***
The Manual for Smart Streets is a living document that will continue to develop through engagement. Please do contact us using the link below if you have any questions, feedback, or content to contribute.

Contact Us