About two years ago we began to think through the architecture for a better digital services to our citizens, focusing initially on meeting “universal” needs – things that pretty much every resident or business in Bristol might have, that could be accessed and as far as possible delivered using digital technology.
We sketched out a blueprint for these digital services to customers, focusing on the capabilities that would be required, and then unpacking them into the business and application functions that would make these capabilities real. This phase of our work was unashamedly non-agile – but for those of you shaking your heads about our failure to commit to emergent architecture based on user needs, just because “Big Requirements Up Front” and “Big Design Up Front” are bad ideas doesn’t meant that a big picture enterprise architecture vision has no value. We aren’t in the position of a lean digital startup, with a blank sheet and free rein to innovate. All large organisations with history have an existing architecture and the infrastructure that embodies it, and this needs to be taken into account and used wherever possible. (Take a look at Scott Ambler’s posts about the architecture aspects of Disciplined Agile Delivery for more on this.)
In addition, we have a number of strategic goals as a council, quite separately from the individual user needs that might be discovered when we look at a single service. These include building an open standards based citizen account that can interoperate with the Verify scheme built by GDS, and enable citizens to use Personal Data Stores if they wish to; a platform that can support a unified experience across multiple services, some developed from the ground up by the council and digital agencies, some bought as pre-built services from third party providers; the ability to define, create and manage integrations with systems we run ourselves and services that other parts of government and third parties provide.
So in late 2013 we had a reasonably clear idea of the capabilities we ended and the technologies that would contribute to them. We called this collection of technologies our “digital platform” – the structure that we could build on to deliver services. It was composed of a number of elements, mostly implemented using products we had selected and procured in the previous few years:
- A portal framework, providing consistent UX, responsive design, APIs and a structure for managing multiple transactional services – Liferay Portal
- Identity Management – ForgeRock’s OpenAM
The digital platform interoperated with a number of products that provide core infrastructure services to the council:
- Integration with backoffice systems – Tibco’s ActiveMatrix ESB products
- Business Rules & Process Management – Tibco’s ActiveMatrix BPM suite
- Document services – Alfresco One
- Customer record – Salesforce.com
So this gave us a toolkit to use, as appropriate, to construct digital services that meet user needs. Since April 2014 we’ve been working with these tools, and learning to work in an agile/iterative way – a story I will tell in my next post.