GaaP – Government as a Platform
In Chapter 2 of Open Government Tim O’Reilly first coins the term Government as a Platform, describing how traditional IT for government should become more like Facebook, Twitter and the other Internet pioneers who have been harnessing the evolution of the Cloud to become ‘platforms’, doing so for government would enable a shared infrastructure that enables more rapid digital transformations.
As Francis Maude, Minister for the Cabinet Office, describes in this article one of the biggest cost driving challenges government faces is this duplication across departments, such as the MOJ writing off a £56m project when it discovered the same system was already being developed by the same supplier with the Cabinet Office.
GaaP addresses through building reusable building blocks, the ‘invented wheel’ that does not require reinvention again and again. A particularly powerful and practical example is the GOV.UK Verify ‘IDaaS’ – Identity as a Service, where user identity and authentication is shared across multiple applications to avoid duplicating that function for users.
iPaaS – Integration Platform as a Service
This is very powerfully combined with the role of PaaS as a form of middleware, connecting users and the multiple digital government systems they need to access, defining ‘iPaaS’ – Integration Platform as a Service.
A world-leading example is Estonia’s X-Road system, the Identity-centric middleware platform that enables world-leading Digital Government services for the nation, described in detail in this documentation.
Estonia utilizes a national identity card embedded with a microchip that requires a unique PIN to unlock for each citizen, which then ties in with the X-Road.
“X-Road is the backbone of e-Estonia. It’s the invisible yet crucial environment that allows the nation’s various e-services databases, both in the public and private sector, to link up and operate in harmony.”
With government running hundreds if not thousands of applications a ‘hard coded’ approach, where each API link is coded directly and maintained individually, can become impractical and hard to scale. As this article explains it provides a framework to eliminate data entry duplications, pre-populating government application forms like tax returns.
This then highlights the role of the PaaS (Platform as a Service) layer as ‘middleware’, a set of applications specifically integrated to act as a broker to multiple applications so that developers can ‘write once use many’.
Therefore we can define this integration platform (iPaaS) as a central feature of the GaaP design. As the X-Road name suggests this acts as a “cross roads” between applications, a common highway for exchanging data rather than applications being wired directly together, engendering more flexibility and easier maintenance for the developers.
Key highlights include:
- X-road core technology has been used in Estonia since 2002.
- Over 170 databases of their services over X-Road in Estonia.
- Over 2,000 services are used over X-Road in Estonia.
- Over 900 organisations use X-Road daily in Estonia.
- More than 50% of the inhabitants of Estonia use X-Road through the information portal eesti.ee.
- In 2013 over 287 million queries were done over X-road.
iPaaS and Microservices
This is a complimentary and accelerating architecture for an overall Cloud Native approach. For example in this Slideshare presentation Microsoft describe how the PaaS layer will evolve to become an iPaaS, ideally suited to integrating business systems via microservices.
DevOps: Transforming Procurement for the Composable Enterprise
Although GaaP is naturally a technology heavy conversation it’s actually non-technical aspects that offer the most illumination on the topic, especially for senior executives, most notably the overall organizational transformation in particular Procurement.
You might not have thought Procurement would be relevant to the software engineering scenario, but consider the broader context of IT they exist within and how much of the resource they use is bought in by the organization. When you consider the RFP (Request for Proposal) bidding process is the most common technique used for sourcing business applications for government, and that these can take months and years to conclude you can see how the two begin to relate, how one can act as a throughput bottleneck on the other.
In a Linkedin blog David Callner begins to explore how DevOps might be adopted in the public sector, noting how RFPs increasingly now feature a call for the use of Agile rather than Waterfall methods.
In particular he describes how RFPs act to collate large volumes of user requirements, a process which can take months, followed by months of supplier engagement to bid the RFP and then further months for contracts and implementation, stretching out over years beginning to end and unsurprisingly resulting in large failure rates.
In short it’s a process of trying to consume a large elephant and so instead the better approach is to break up the challenge into ‘bite size chunks’. David also describes how in some scenarios they instead work more collaboratively with agencies, to capture requirements into Agile Product Backlogs and organize these into Epic work streams, that can be worked on continuously from beginning through end.
The PaaS approach compliments and accelerates this approach by baking the procurement into the technology, empowering developers to self-serve their own requirements, and critically, employ the use of pre-developed templates and module integrations. The future of enterprise business systems is no longer buying one monolith app from a single vendor, but instead composing together modular solutions that span across internal legacy apps as well as across the XaaS spectrum.
DevOps: Teams and Roles
The reason Pivotal is such a good example of this scenario is not just that they offer a managed implementation of the PaaS, but also bring considerable expertise in the surrounding Cloud Native practices, such as DevOps, Microservices and containers et al.
A great example is this Medium article which explores the dynamics of new team models for DevOps, defining a number of specific roles and how they interoperate, such as:
- Product Owner/Product Manager
- Data scientist
GaaP on Pivotal Cloud Foundry – Cloud Native DevOps for Government
Defining a repeatable GaaP architecture with these same kinds of capabilities, is considerably easier when you explore a possible real-world implementation, making many of the somewhat esoteric design principles much more tangible.
A great example is the Cloud Foundry offering from Pivotal, where Cloud Foundry is the PaaS implemented to build the Australian digital strategy and also Cloud.gov, enabling USA public sector development teams to build Digital Government systems faster and via standardized best practices, and where Pivotal offer a managed service for others wishing to build a similar Cloud Native approach to business system development.
The article also goes on to describe a detailed PaaS architecture:
Governments can adopt wholesale this Cloud Native approach off the shelf, as it is a common, generic model for increasing the agility and throughput of any software team.
It can then be further tailored for the public sector scenario through defining a second ‘Value Line’ as shown in the diagram, from the top upwards above the apps, to represent a further layer of government-specific modules and tailorings. For example integration of federated identity services such as the IDaaS like Gov.UK Verify.
This will offer government agencies an entirely new paradigm for addressing the most fundamental of their enterprise IT challenges: Joined up, integrated working and sharing of data across multiple agencies and systems. Rather than hard-coding yet another citizen authentication process into another application, this approach instead calls upon shared, component services such as Identity Authentication.
Common Code Architecture
A very complimentary design to PaaS is an approach I describe as a ‘Common Code Architecture’. As the name suggests this means many applications sharing some individual components; in software development terms this is usually based around an approach known as component-based software, and some applications also offer specific implementations.
For example CMS applications like Drupal and WordPress offer installation configurations known as ‘multi-site’ modes, which as you would expect are intended to run multiple different web sites from one common core of modules. The benefits being that you only need to upgrade and maintain one set of software and these changes are applied to all of the web sites.
WordPress support house WPMU Dev offers this in-depth technical explanation of the feature for WordPress.
This identifies the great win/win that is possible for both end users and also Cloud Service Providers, where these tailored configurations can be available templates in their hosting catalogues, saving the public sector huge time and effort to design and build them, and offering providers solutions better tailored to the unique needs of their customer segments.