Government as a Service
Part 1: Objective, Problem Statements
At last! We have enough groundwork out of the way to dive into our first design document. While we won't immediately sink our teeth into the meat of a solution, we will add layers of taut flesh, vibrant color, and rich texture to the problem, whet your appetite and stir your hunger, and leave you enticed and ready to voraciously rip apart the problem in pursuit of a delectable solution.
Objective
Formulate an actionable company vision that revolutionizes government software development through tailored business, product, and technology strategies, and bolsters open societies with exceptional software solutions.
Analyze the problems in existing government software procurement, development, deployment, maintenance, adaptability, security, and data. Define the correctness conditions of a solution. Suggest a novel company model to meet governments' needs. Outline the business, engagement, and software architecture for this new venture. Address challenges, alternatives, and concerns.
Problem statements
Before beginning this section, I'd like to emphasize that this is not intended as a critique of individuals who work in or build software for governments. I have experience building software for governments, integrating products with governments, and dealing with compliance for regulated software. The intelligent, technical people who take on the Herculean task of changing government from within are to be lauded. They often do so at the cost of foregone income and immersion into bureaucracy. Moreover, it is not the sole province of governments to struggle with developing and delivering complex projects.
It is not the sole province of governments to struggle with developing and delivering complex projects.
The problems and solutions presented aim to be globally applicable for fostering open societies, yet the examples will inevitably reflect my experience as an Angeleno, Californian, and American. Please share if you know of a country or jurisdiction that excels in addressing the outlined problems. Estonian readers, we're looking at you!
I encourage you to read this and subsequent posts with a critical eye, so that with your collaboration, the problems presented can be refined to accurately capture your experiences and insights.
Governments don't build good software for citizens
Governments don't build good software for their citizens. As a citizen, think of any interaction you’ve had with government software: paying your taxes, dealing with unemployment, childbirth or disability, moving, dealing with utilities, getting a public record, dealing with the courts, or renewing your driver’s license or passport.
Picture it in your mind. You’re looking at something that looks like it was made in the early 2000s, at the latest. The menus and pages are bloated and indecipherable. You’re logging in with a username/password and at some point providing all or part of your entire social security number and other sensitive identifying information.
Every site is completely walled off from every other site, allowing you to enjoy the endless fun of filling out numerous, duplicative forms each with their own unique idiosyncratic quirks that in many cases seem designed to provide the most frustrating user experience possible.
If this wasn’t enough, every jurisdiction, state, county, country builds their own uniquely flawed, fractured, duplicative, and isolated adaptation. In the rare case where jurisdictions do agree to common standards, they often end up inadvertently or intentionally adopting the old Microsoft mantra of “embrace, extend, and extinguish”.
All happy families are alike; each unhappy family is unhappy in its own way. Leo Tolstoy, Anna Karenina1
Governments don’t have good product and software development practices
Governments don’t have good product and software development practices. For the engineers, product, project, and design folks in the audience, think about your experiences working with governments. Recall the projects where you worked with governments or integrated with government systems.
The development was probably waterfall, or waterfall by another name, e.g. waterfall with sprints. There were hard deadlines your team had to hit based on a request for proposal (RFP) and statement of work (SOW) that was defined with little or no technical input, expertise, or details about the existing data, systems, and APIs you would be integrating with.
Sales was pressuring you to deliver on features and dates while minimizing costs from the word “go”. Money was lost in the process of winning the contract, responding to the RFP and preparing the SOW. This project had to make up for all the projects where that effort was expended and the deal was either not inked or not profitable. Sales’ bonus was tied to either the delivery date or budget.
You were working through multiple layers of consultants and project managers for different stakeholders, far removed from your end users. You were working with stakeholders who lacked technical expertise or domain knowledge in what you were trying to build. If they were technically competent, they were swamped with a million competing projects and objectives.
You were dealing with an intransigent bureaucracy that may have been actively opposed to the project you were working on or lacked interest in the project. They might have been interested in hamstringing the project by shoehorning it into existing manual processes or headcount. You either lacked access to production data necessary to do your work or had far too much access. Localization and accessibility were probably bespoke solutions if included at all. If you were maintaining an existing system, documentation, testing, observability, and infrastructure tooling probably had major gaps if they were present at all. The versions of software for programming languages, operating systems, and database you were using were ancient and frozen.
Governments don’t do a good job providing API and data access
Governments don’t do a good job providing application programming interface (API) and data access to anyone. If you're an engineer or entrepreneur trying to integrate with a government API or build a service on top of government data, you've likely run into issues.
APIs, data access, and data formats varied widely across jurisdictions. API and data documentation was nonexistent or poorly maintained. API outages were routine, and service level agreements (SLAs) were unheard of.
If the data was “public,” it was difficult to acquire and parse, stored in legacy or unstructured formats, and rife with errors. If it was “restricted,” it had the same issues as public data but was difficult or impossible to get access to, and the provider lacked the capabilities to safely grant access to anonymized or filtered data.
Even if you were a member of the government in question, in the same or different division, you faced many of these same issues. Additionally, you encountered problems with credentials valid only within a particular organization or jurisdiction, password-only authentication, and a lack of granular access controls to data.
Governments suffer from tunnel vision
Governments suffer from tunnel vision. Each jurisdiction and agency views their problems through their own narrow lens. They can’t see the forest for the trees and miss the opportunity to build flexible, connected, and broadly-applicable platforms. They are not positioned or incentivized to think beyond their own jurisdiction or develop products and services that could be widely adopted. Thus we get fifty mediocre DMV websites for fifty states.
Now some of you may be saying, I imagine, what about ARPANET or military/intelligence/security project X. Clearly, some parts of government and their partners are great at product and software development. Alas, no. Why there are standout examples of intelligent, agile product and software development many of these have been sepia-tinted or are striking specifically for how far removed they are from standard government engagements.23
Governments’ counter parties are equally flawed
And lest it be thought we were focusing too much on governments, their counter parties are equally flawed. Leaving aside the ever present threats of outright nepotism and corruption, consultants and private contractors introduce conflict of interests and principal-agent problems. These lead them to maximize their own self-interest at the expense of the government and the product while leading their customers to narrow or proprietary solutions.
The inability of governments to provide robust digital services also allows an opportunity for parasitic opportunists establish themselves as rent-seeking middlemen and fight against the development and improvement of services that are often free and government owned or operated: TurboTax (Intuit)4 who fights against free and easy electronic tax filing, VitalChek (LexisNexis Risk Solutions) who fills a gap in availability and accessibility of digital records, credit reporters (Equifax, Experian, and TransUnion) whose business model rests on the absences of available and connected government digital services, AccuWeather5 who builds a paywall on top of high quality government data and then seeks to prevent the government from providing the same data directly to citizens while providing negative value add, businesses offering expedited licenses and passports, the list goes on and on.
Even when trying to design platforms, private contractors tend to build narrow, siloed platforms that address only specific verticals and do nothing to enable data aggregation and sharing even among their own customers.
Governments have the wrong model for software
In short, governments have the wrong model for software. Governments procure software the wrong way and provide perverse incentives to vendors. Governments envision, plan, and design software solutions poorly. Governments develop, maintain, scale, and secure software badly. Governments do a poor job handling data and providing appropriate access and access controls to citizens, businesses, other organs of government, other government entities, and indeed, themselves. And for all of this they pay too much and get too little.
I apologize if this post seemed bilious. Cleanse your palate and come back next week. In our next post, we will shift our attention to defining the scope and the establishing the correctness conditions of our solution. With that groundwork in place, we will provide an overview of our proposed solution and use subsequent posts to dive more deeply into various elements of the solution.
If you have thoughts on this post or any of our other posts, please leave a comment on the post or head on over to the subscriber chat. Each post has a dedicated discussion thread there. I look forward to hearing your feedback!
This post is part of the "Government as a Service" series.
Part 1: Objective, Problem Statements you are here
