Recently I’ve done a lot of listening in on conversations that the Highways Dept (I work in a UK local authority) are having with their suppliers and themselves as they try and get IT systems which are fit for purpose.

This work culminated in  me reflecting back a vision statement which more or less describes the way they want to work in the future. The key elements of this are:

  • all highways data is accessed transparently (cloud-like) in a single-access repository (ie you can access all the data in the same way regardless of where it sits)
  • location (based on the National Street Gazeteer) forms the master record for this data, creating a “digital shadow” of the road network
  • there exists a set of built-in (zero client footprint) analytical, visualisation, data entry and reporting tools
  • the data is ubiquitous, available anywhere you are (difficult in a most rural county like where I live!)
  • event handling enables data to be pushed to operators on the ground dependent on timing, nature, severity, and policy/priority rules
  • stakeholders have customised views of the data depending on role-based security and their own preferences
  • internal translation functions enable the data to traverse different formats
  • APIs exist to allow 3rd party applications to interact with the data (again, as if it was all in one place).

If you’ve ever read “Enterprise Architecture as Strategy” by Ross et al then you might recognise this description as being a classic “co-ordination” model, meaning that disparate groups of specialists (bridge engineers, resurfacing workers, traffic specialists, utilities that dig up the street, lighting engineers etc etc) all operate on the same patch of road. Each of these disciplines is highly specialised and prone to innovate in its own space, however we’ve all see the frustration of what happens when they aren’t co-ordinated properly.

My job is not to design, or even specify, a solution, but to outline the core properties of the future state of the systems that people can then work towards and attempt to unify everyone’s thinking. I’m a perpetual strawman generator – I cobble something together that everyone can shoot at.

So I have adapted the core diagram from the EAS book here (pictured – click for a larger version). Essentially, the back-end systems are integrated using some kind of ESB or hub technology.

Well, that looks pretty. It probably won’t do the job though, because we don’t know what is going on inside the hub and it doesn’t qualify as being purely event-driven unless we can add this functionality in.

So what does an event-driven architecture look like? Here’s a sample shamelessly stolen from

We can see that each of the applications on the right hand side of the first diagram are potential event sources, but the real sources are in the databases.

An event might be triggered by a customer complaint (“there’s a pothole in my road”) a police report (eg of an accident) or any number of other happenings, but they all end up in one of the databases and so can be made to trigger something. How?

Thresholds for triggers ought to be linked to policy and organisational priorities. But these change: for example, during the recent snow it was unlikely we’d be doing much in the way of hedge-cutting or routine maintenance. So the final piece of the architecture is a rules engine that allows trigger levels and organisational priorities to be set.

I don’t think any of this is rocket science. But as far as I am aware none of the leading suppliers of software to UK Highways departments have adopted an approach like this to the creation of their products. I plan to develop these ideas further in conjunction with some of my colleagues and see if we can’t get it baked in to some supplier product roadmaps. If you’re an EDA guru, and you can spot some glaring issues with this setup, please let me know in the comments 🙂