Government as a Service
Part 2: Scope, Correctness Conditions
Welcome back to the second part of our first serialized design document, "Government as a Service." In this post, we will be defining the scope of our solution and the correctness conditions for that solution. If you haven't already, please read Part 1: Objective, Problem Statements first.
Scope
Design a sustainable business
We are not trying to build utopian castles made of sand, at least not yet. This newsletter is about creating solutions that are not only reasonable but also achievable. The objective of this design document, as stated earlier, is to formulate an actionable company vision that aligns with our overarching goal:
Revolutionize government software development through tailored business, product, and technology strategies, and bolster open societies with exceptional software solutions.
We will present a north star vision to guide and shape our solution, but that vision will not be achievable on day one.
We live on an island surrounded by a sea of ignorance. As our island of knowledge grows, so does the shore of our ignorance.
John Archibald Wheeler
As we navigate the vast sea of our ignorance, we set our sights on Polaris. Our voyage takes us from one island of knowledge to the next, each expedition expanding our understanding and experience. As we reach each shore, we reorient ourselves and prepare for the next journey. We acknowledge that the path may never be clear and the destination could be light-years away, but each hop is informed by what we've learned.
Ideals are like stars; you will not succeed in touching them with your hands. But like the seafaring man on the desert of waters, you choose them as your guides, and following them you will reach your destiny.
Carl Schurz
Bolster open societies
We must build a sustainable business, but if our solution does not strengthen and encourage open societies, we have not met our objective. A business that never existed or cannot survive because we refused to compromise our principles is not a pragmatic outcome. However, if our solution fails to support open societies, we've traded Scylla for Charybdis.
Politics is not the art of the possible. It consists in choosing between the disastrous and the unpalatable.
John Kenneth Galbraith
We must navigate the fine line between the idealism of our mission and the realities of building a viable enterprise.
Broad remit
In shaping our solution, we will adopt an expansive view of our solution space. Our approach will encompass the business model, engagement model, technical architecture, and any other components necessary to infuse vitality and dynamism into our offering. By embracing a wide-ranging perspective, we can ensure a comprehensive and robust solution that addresses the diverse needs of our, yet to be identified, target audience.
Out of scope
Finality
As previously stated, our goal here is exploration, ideation, and discovery. Through feedback and collaboration, we will expand our knowledge and refine these, or other, ideas until we have a feasible model that can be packaged for an appropriate audience. It's important to remember that everything within the bounds of our scope remains open for discussion and consideration.
Completion of all correctness conditions
Even within the loose confines we’ve set for ourselves the messy tide of reality is going to come in and ruin our castles made of sand. We will strive to address as many of the correctness conditions as possible with an actionable and cohesive vision; with the understanding that our solution may not be able to fully address all of them and may fall short in some areas.
Correctness conditions
I apologize for the long lists which I have tried to avoid in this newsletter but as we will need to return to this list of correctness conditions to confirm our solution satisfies them it is, sadly, appropriate.
Produce quality software
Software must meet modern standards for usability, accessibility, localization, and security in a consistent manner.
Software must be designed with user needs in mind and tested with actual users to ensure it is meeting those needs.
Software should encourage common standards and implementations.
Software must be well-documented and maintainable, with clear version control and observability.
Software must be compliant with all relevant regulations and policies.
Software must be scalable and adaptable to changing needs and requirements.
Software must be reliable and have sufficient redundancy to minimize downtime.
Software should be designed with a modular and extensible architecture to enable rapid development and deployment of new features and functionality.
User identity and authentication should be portable across systems.
Software should encourage information sharing across trusted parties and break down barriers between different services, departments, and jurisdictions.
Software should be portable across geographic regions.
Define effective product and software development practices
Product and software development must be driven by user needs and feedback, with frequent iterations and testing.
Product and software development methodology must be iterative providing quick feedback loops, regular progress, and encourage rapid iteration.
Engineers and designers must be embedded at every step of the product and development process to ensure the solution is parsimonious and correct.
Products must be developed based on broad applicability, automation and correctness rather than adherence to existing manual processes.
Standard, open source libraries and packages should be used whenever possible.
Subject matter experts must be made available and be part of development process.
Products should be able to flexibly grow to service additional customers and use cases.
Product timelines should be time-based, not scope-based.
Bespoke solutions should be avoided unless absolutely necessary.
Provide robust, standard APIs and ensure equitable data access
All data must be accessible via API in line with the SOA manifesto.
APIs must be built and documented using open standards, version-controlled, and maintained with clear release notes.
Data models must be clear and well-documented so that they can be shared with authorized stakeholders.
APIs and data must be designed with security in mind and have appropriate granular access controls and authentication mechanisms.
Equitable data access must be provided to all stakeholders with appropriately sanitized outputs based on user authorization to protect sensitive data.
Governments must have control over who can access their data.
Requesting access to data, managing access requests, and revoking access must be efficient, clear, and transparent processes.
APIs must be scalable to handle additional traffic and use cases as appropriate.
Data must be stored and made available in standardized, modern formats with consistent metadata that encourages interoperability between APIs and systems.
Data must be structured in a way that allows for easy aggregation and analysis across jurisdictions and agencies.
Governments must have control over their data storage region.
APIs must be observable and have appropriate logging.
APIs should adhere to reasonable SLAs, have monitoring in place to detect outages, and methods to communicate those outages to users.
Data should not be siloed.
Have broad product vision
Governments must think beyond their own jurisdiction or agency and develop products and services that can be widely adopted by other stakeholders.
Products must be based on a clear vision of the societal outcomes governments want to achieve.
Platforms must be flexible, connected, and broadly-applicable, allowing for easy customization and integration with other systems, including those outside of government.
Products and services must be designed with long-term sustainability in mind, with a focus on reducing maintenance costs and increasing adaptability, and must be integration with other systems.
Products should be designed to create value for governments, so they don’t view them solely as cost sinks.
Products must be designed with a focus on user experience, with a goal of reducing friction, building trust, and improving accessibility.
Products must deliver a well-defined value proposition that delivers tangible benefits to end-users and society as a whole and can be articulated and measured.
Products should be designed for accessibility and internationalization to best serve a broad customer base.
Address counterparty flaws
Solution must ameliorate flaws in counterparty behavior and minimize conflict of interests and principal-agent problems. This means us!
Solutions and agreements must be structured to align the interests of governments and vendors, prioritizing transparency in dealings with government.
Solutions should avoid lock-ins, support open-source software where appropriate, and allow for portability.
Vendors must be incentivized to deliver high-quality products and services that meet user needs and build broad, connected solutions that enable data aggregation and sharing.
Agreements and payments should be structured based on the nature of work and the degree of uncertainty.
Rent-seeking middlemen and parasitic opportunists must be identified and replaced to prevent them from siphoning resources away from governments and citizens.
Solutions should have tight, transparent feedback loops that de-risk future product phases and provide immediate value to the government customer or solution users.
Solutions should be designed with a focus on cost-effectiveness, maximizing return on investment and minimizing waste.
Okay. That was a lot. I apologize again for the lengthy list and once again not delivering what at this point, I hope, is a much-anticipated solution. Stay tuned for Part 3 where we will enthusiastically dig into our Solution, and be sure to subscribe for updates.
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.