Chris Conway
Chief Architect, Quantiv
Last month’s blog about Birmingham City Council’s financial woes inspired me to delve deeper into the issue of IT in local government – and, in fact, IT solutions more widely.
My last article looked at the huge cost overrun associated with the council’s enterprise resource planning (ERP) project, and how such a large overrun might have been avoided.
And this got me thinking that perhaps there’s a parallel between the way different local government organisations are structured and how different IT solutions are organised.
The 5 stages of IT solution maturity
Through the years, IT solutions have moved through different stages that could be characterised as:
- ‘Do anything’ (or ‘do what you can’)
- ‘Do the thing’ (with a bit of knowledge of what’s possible)
- ‘Do everything’ (with a bit of, or a lot of, confidence – or even arrogance)
- ‘Do another thing’ (the ‘dotcom goldrush’)
- ‘Do the right thing’ (the enlightenment)
Birmingham – which is one of the largest local authorities in Europe – initially opted for a software supplier using the third approach: buy a big system and fit into it.
It would be easy to say the council made that choice because politicians love big things, as they make for good headlines. And, economically too, there’s some evidence that concentrating activity in specific locations can produce a virtuous circle of growth.
So, in that context, perhaps a large council’s approach of concentrating on a single, large ERP system is understandable – that ‘centralisation’ mirrors the council’s structure.
Avoiding bottlenecks and overheating
But engineers are a more cautious breed than politicians and economists. In engineering, that virtuous circle could be seen differently: as positive feedback. Engineers tend to treat positive feedback with a great deal more caution, and so designs often include features to ensure they don’t lead to bottlenecks and overheating, i.e.
- As a system approaches capacity (that ‘howling’ of a public address system being a classic symptom), mechanisms limit growth.
- And rather than a smaller number of ever-bigger systems (option 3), IT solutions are often now made up of a larger number of more moderately-sized systems.
The federated approach: multiple specialist systems
Engineers tend to lean towards solutions based more on the fifth option. So, rather than concentrate processing in a single, very large system, activities are spread across multiple specialist systems.
But this way of thinking doesn’t just apply to IT solutions.
The Dutch have a strong history of engineering excellence, and there’s a current example of this in Amsterdam. Here, developments are concentrated outside the inner city in the Zuidas area to the south. These developments include the A10 South tunnel, and the Amsterdam Zuid station.
This approach involves some serious short-term challenges. But developing in this location means activities can be spread across multiple points, rather than concentrated in a single, already-busy central area. Plus, it offers more flexibility, more overall capacity, and better use of resources.
Modern IT solution designs have similar characteristics. While it might still be possible to use a single system to cover all requirements, solutions are now more likely to combine features from multiple specialist systems (option 5).
Understanding the processes
But this method isn’t simply a matter of buying a series of good systems and expecting (or hoping) they’ll work together. It’s not even enough to dictate that the systems come with well-defined application programming interfaces (APIs), which can then be used as part of a micro-services architecture.
Instead, a federated approach first requires a thorough understanding of the organisation’s processes and activities; in particular the transformations in the organisation’s state brought about by their completion.
These organisation-focused definitions then form the basis for decisions on how processing should be partitioned, and so in turn show:
- The responsibilities of each system
- The data that needs to be shared between systems
As the previous blog mentioned, these definitions can then be used to compare different candidate systems, both against each other and, more importantly, against operational processes.
It’s worth noting there’s nothing in this description that implies the specialist systems must be different systems. A single system could still provide that specialist functionality, but with this analysis the requirements for functional and data separations are clear.
Support with federated IT solutions
At Quantiv, we’ve long been advocates of federated solution architectures. And we’ve specifically designed our NumberWorks method to support the analyses needed to aid this approach. We’ve achieved this by building a targeted model of operational processes and data.
And if multiple systems are used, our NumberCloud service can then be used to allow these systems to share data in a cohesive way. This ensures information is available where needed but without introducing unnecessary coupling between systems.
But as well as IT, perhaps such an approach should also be taken to local government structures, i.e. federating rather than centralising like Birmingham. And, in turn, those structures might indeed then form a virtuous circle by making sure those government organisations’ IT solutions are subject to correct review.
To find out more, talk to the Quantiv team on 0161 927 4000 or email: info@quantiv.com
