Digital Government GaaP Series

Government as a Platform: The Wolf in Sheep’s Clothing?

This is the latest in a series of articles by Larry Larkin that looks at GaaP. Read them all.  

There’s a debate going on in the UK regarding what the Government Digital Service (GDS) is going to deliver – a true Government as a Platform (GaaP) service model that transforms the way government does business and blows up the monolithic siloed system mold or just a “platform-looking” variation of current systems based on updated technology – the latter being referred to as a “Platform for Government” or PfG.

In a very interesting article, Mark Thompson, a leading (and very vocal) proponent of GaaP in the UK, cautions that the British government may be heading down the PfG path, largely as a result of scant engagement by senior civil servants and politicians and strong lobbying by large system integrators – who have the most to lose from the implementation of a true GaaP service delivery model. In short, civil servants are sniffy about a model that many see as a wolf in sheep’s clothing. Not all see it that way.

So what’s the difference between GaaP and PfG? According to Thompson, their contrasting characteristics are shown in the table below.

The differences between GaaP and PfG (Source: Adapted from Mark Thompson’s article: “Government as a platform, or a platform for government? Which are we getting? See link in post).
The differences between GaaP and PfG (Source: Adapted from Mark Thompson’s article: “Government as a platform, or a platform for government? Which are we getting?” See link in post).

So why is it important? As Thompson puts it: “The distinction here – and government’s choice – between a blueprint for GaaP that supports participation versus one that supports mere access, is critical. The former is about democratic re-invigoration, and the latter is about – well, just technology. Participation is much more disruptive to existing modes of organising within government.”

Stay tuned.

Digital Government Digital Policy GaaP Series Government Cloud

Government as a Platform? Bah! Humbug!

In my previous article in this series focusing on Gov as a Platform, I talked about the formidable challenges that lie ahead in making Government-as-a-Platform a reality. But how about the GaaP concept itself – does it make sense?

The GaaP concept is based on the business model of companies like Google, Apple, and Microsoft that built commercial platforms, opened them to third parties and allowed them to develop all kinds of applications. The idea here was that by opening the platform to others, it would unleash the creativity of developers and result in applications and capabilities limited only by people’s imagination. This business model proved to be fantastically successful and, nearly overnight, created a new market for platform apps. What has made the platforms such a success has been that they are based on open standards, foster and facilitate an environment of collaboration among the developers, and do not require a large investment to participate. Essentially, just about anybody can develop and sell apps for iPhones, for example.

But will this platform business model work in a government environment? Andrea Di Maio, Managing Vice President responsible for government research at Gartner, wrote a very interesting piece back in 2009 on why government cannot be a platform. He sees these flaws in the concept:

  • Government operates in a more regulated environment – The data the government holds has statutory restrictions that commercial entities either do not have or are less restrictive. For example, when considering data for release, the government needs to determine if, from a regulatory aspect, the data is public data, data covered by the Freedom of Information Act, personal data, confidential data, classified data, etc. Different restrictions apply depending on the category of the data. These regulatory controls hinder the release of data.
  • The motivations of government are different from that of other platform providers – For starters, commercial platform companies are for-profit enterprises where success is measured by metrics such as revenue, profitability and growth. Government organizations do not exist to make a profit but rather to create what Di Maio calls “public value.” Success is measured by how effectively they fulfill their statutory mission and how well – and efficiently – they serve their customers/constituents. The metrics of success and rules of engagement are very different and, in the case of government, more complex.
  • Government is both a platform provider and a platform consumer – Government uses data from the private sector to fulfill many of its tasks (e.g., law enforcement), which it gets from commercial platforms (e.g., social networks). It performs both functions at the same time.
  • Government provides services in domains where there is no business case for the private sector to do so. In fact, most of what government does is generally of little interest to the public at large, things like childcare, unemployment support, public education, basic healthcare – whose most frequent users are, as Di Maio puts it, “on the ‘wrong’ side of the digital divide (least affluent, least connected, etc.).”
  • Government is many different things to the same people at the same time – It plays many roles in our lives as an authority, protector, educator, health care provider – to name a few. Given these multiple roles, their attendant overlaps, and the varied nature of the relationships, it’s not clear where the platform boundaries should lie – or could even be sensibly defined.
  • Government remains accountable for anybody else’s mashups – While, in theory, application developers would bear liability for errors/problems in their government-platform applications (vs. the platform provider – except in cases where the failure was triggered by a problem in the platform), the government will be criticized. To avoid this, will the governments get involved in testing and certifying third-party applications?

While these are all very valid points, I personally do not believe that GaaP: (1) is an all-or-nothing proposition and (2) these are unsurmountable problems. GaaP will evolve and its direction will be driven by needs – so if there’s not a need in a certain area – or there are major regulatory obstacles – then it’s not likely anyone will expend the effort and money to create applications. It will be a natural evolution process.

What do you think – can the government be a platform?

Read Larry’s full series of posts on GaaP.  

Digital Government GaaP Series Open Data

GaaP: Paths and Cliffs

This is Part 3 of a series of articles by Larry Larkin

Previous articles in the series described the myriad of benefits – financial, operational and social – that GaaP can bring. But how do we get there? The path, alas, is not a road to follow but, rather, a cliff to scale. The challenges associated with moving from our current siloed, monolithic application environment – pervasive across the Federal/Central governments – to an open-data platform ecosystem are mind-numbingly formidable.

The technology path, relatively speaking, is the easiest one because: (1) the technology is available, (2) the cost efficiencies are more apparent and measurable, and (3) ever decreasing budgets are acting as forcing functions. We’re still far away, particularly in the United States, from the “one big Government cloud” – but we’re making progress. The US Federal Government’s “Cloud First”mandate, which requires agencies to consider cloud-based solutions when seeking to implement new systems is a good example.

The showstoppers are issues like:

  • Leadership – What incentives do agencies/ministries have to collaborate to design and build a common architecture that delivers shared services? Even if the cost savings of a common approach are there, who is going to orchestrate and drive its development – who has the authority to make it all happen?
  • Control of the data – Today, the data owners, i.e., the government organizations, have control of the data. Will they be willing to relinquish some of that control and share this data? What data should be shared and what shouldn’t? Who decides? What role do citizens have in deciding which data about them can be shared and which cannot? What about privacy and security – and liability?
  • Open data standards – Who sets the standards on how data is shared and defines the interfaces? To date – by default – it has been the private sector, companies like Facebook, Amazon, Google and Apple, that has been setting the standards.

These are complex issues that cut across government, industry and citizens. They tend to be manageable at the state and local government levels given their smaller scale. However, at the national government level, particularly in the United States, given its size and complexity, these issues are almost intractable.

For such an effort to succeed at the national level, a central organization with cognizance over all governmental departments and some measure of authority – the orchestra conductor, if you will – is a requisite first step. Happily, these organizations already exist: Government Digital Service (GDS) in the UK, and US Digital Service (USDS), together with 18F in the United States. GDS, by virtue of its ability to fund projects, has made tangible progress in constructing GaaP building blocks, platforms like GOV.UK for publishing and GOV.UK Verify for identity verification.

USDS and 18F, by necessity, have been focusing their limited resources in fixing critical systems at risk of failure and, in the process, inculcating industry best practices across US government agencies. Given their remarkable workload – and their success – I suspect it will be a while before they can focus on “global” GaaP issues.

So, the good news, is that several critical chess pieces of GaaP are in place. Given the magnitude of the cultural change (within government agencies) and massive resources the implementation of GaaP will require, the process will have to be evolutionary and will take time. But the movement is there…

Read Larry’s full series of posts on GaaP.  

Digital Government Digital Policy GaaP Series Open Data

The Promise of “Government as a Platform”

In my last post on the subject I talked about the IT nuts and bolts of Government as a Platform (GaaP) and the significant operational cost efficiencies that it could realize. The real value – and power – of GaaP, however, is as an enabler of what I call, for lack of a better phrase, “government-enabled applications.” By that I mean applications developed by end users, be they individuals, organizations or companies that combine “Government Platform” capabilities with other web services to deliver applications that are only limited by one’s imagination. Or as Tim O’Reilly aptly put it:

“If there’s one thing we learn from the technology industry, it’s that every big winner has been a platform company: someone whose success has enabled others, who’ve built on their work and multiplied its impact. Microsoft put ‘a PC on every desk and in every home,’ the internet connected those PCs, Google enabled a generation of ad-supported startups, Apple turned the phone market upside down by letting developers loose to invent applications no phone company would ever have thought of. In each case, the platform provider raised the bar, and created opportunities for others to exploit.”

This is what GaaP is really about – government agencies not only providing web applications specific to their mission but also services on which citizens and organizations can build applications of their own for the benefit of other citizens and the community.

What kind of applications you might ask? A good – and commonly used – example is (now a part of created by Adrian Holovaty in 2005. combined (“mashup” for the technically inclined) crime data published by the Chicago Police Department with Google Maps. The result was a map showing the physical locations of where crimes were being committed. There is a page and RSS feed for each city block. The user can browse the crime data in a variety of ways: by street or address, by ZIP code, by location type (house, building…), by type of crime, by date and by keyword. In a matter of a few clicks, a person can get a picture of crime activity in their neighborhood and potential areas to watch – useful stuff.

Other examples: Real-time public transit schedules and updates; official information about buildings and construction projects and visualizations that show how a city is changing over time and real-time road traffic information. (OSM) – which provides free, editable maps – is a good example of how GaaP type of applications can evolve and blossom. OSM grew out of a crowd-sourcing effort led by Steve Coast to create free maps of the UK, where map data is expensive and not freely available. Using Ordnance Survey (UK’s mapping agency) out-of-copyright maps from the 40’s to aid navigation, OSM volunteers set out to map the UK in 2004 using handheld GPS trackers. Today, OSM now offers a map of the entire world and has over 1,000,000 contributors worldwide.

These examples represent the first-generation of GaaP applications – akin to the Pong video game of the early eighties. Much needs to happen to enable GaaP to achieve its full potential. This will be the topic of the next article in the series.

Read Larry’s full series of posts on GaaP.  

Digital Government GaaP Series Government Cloud

So What Exactly is “Government as a Platform?”

These days, “Government as a Platform” has become a very popular topic in the eGovernment community. It has been touted by some as the foundation that will enable citizen eParticipation on a scale that will finally realize the promise of eDemocracy. What I’ve also found is that there is widespread confusion as to what GaaP really means – which is probably caused by the myriad of definitions or, shall I say, interpretations, of what GaaP is.

Tim O’Reilly introduced the concept of GaaP in 2009. In its simplest form, GaaP is “…an open platform that enables anyone with a good idea to build innovative services that connect government to citizens, give citizens visibility into the actions of government and even allow citizens to participate directly in policy-making.”

Figure 1. The GaaP concept from an IT nuts and bolts perspective.
Figure 1. The GaaP concept from an IT nuts and bolts perspective.

At the IT architecture level, the basic idea here is that instead of each agency/department providing services through siloed enterprise applications, there is a common, government-wide IT platform through which all these services are delivered. Within this cloud-based platform, common functions such as communications, identity and access management, and web services are implemented as shared utilities (“shared capabilities” in GaaP parlance) – instead of replicating them in each silo.


The benefits are not only a simpler architecture but lower risk and costs. Functions unique to an agency/department would still be provided by that organization. Figure 1 depicts a simplistic example. A more detailed – and very humorous example – is provided in a video by change management consultant Mark Foden.

One of the first – and most successful – implementations of a digital government platform is Britain’s National Health Service’s NHS Jobs e-recruitment service.

Prior to 2003, recruiting for NHS jobs was done on a regional basis by 600+ providers, each of which ran their own recruiting program and facilities. TUK’s Department of Health and its consultants worked with all NHS providers to standardize on a single recruitment platform which, when implemented, opened job opportunities to workers nationwide. By eliminating duplication and inefficiencies due to redundancy, the platform-based e-recruiting system has saved over US$1.6B/£1B in its first nine years of operation.

Cost efficiencies are just the tip of the iceberg (or perhaps the icing on the cake) with regards to the benefits GaaP brings. In Part 2 of the series, we will examine how GaaP can transform government the way Web 2.0 transformed the Internet.

Read Larry’s full series of posts on GaaP.  

(You may also want to read this post by David Moody).