How to Design Government Architectures for Change

Government information systems in the Pacific are too often ‘built to last’ rather then ‘built for change’, which is the real requirement for them to be.

The traditional approach has been to build very tight vertically integrated systems. This has created unintended ripple effects that cascade across the system whenever a change is made. So what typically should have been a simple update of a business policy, process change or business rules requiring a few hours’ work often times turns into a complex, bureaucratic and code-intensive process that instead takes months of tedious effort to implement. 

Related image
You create risk of a cascade of ripple effects of unintended consequences when you have tight vertical integration between information systems

Such brittle systems built on ‘telephone book’ lists of upfront system requirements ironically make it harder for policy makers and operational staff on the front lines to be nimble and adaptable, yet the one certainty in government is the need to be flexible to meet constantly changing requirements and alterations in government policy. 

At GovCrate we understand the need to architect systems that ensure information systems maintain this flexibility. This is extremely critical in Pacific Island countries where there is high level of resource constraints faced by most island country governments for digital transformation initiatives. In that context mistakes like these kinds are very difficult to recover from as resources are already spread thin.

Over several decades of research and development we’ve developed adopted, adapted and combined several different frameworks to systems architecture and design that enables our systems to be “built for change”. The following below is an example of an architecture for an electronic registry system using:

  • wardley mapping for situational awareness of the technology landscape
  • data mart / data warehousing architecture for systems architecture
  • aggregator business model for creating system flexibility

this allows the systems we architect to have greater flexibility and provide a buffer that decouples any unintended ripple effects from changes we make to systems.

Situational analysis in 2017 of the technology landscape for e-permit system using an aggregator business model approach
Initial situational analysis in 2017 of the technology landscape for creating an electronic permit system using an aggregator business model approach

For more insights about how we think about government architecture, analysis and business models get in touch with us here.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: