Clarity is needed on how GovStack as a whole defines what is considered a product and what is not.
Currently both technical and non-technical teams are interchangeably defining the following three distinct terms with the word product: 1. building blocks, 2. applications, and 3. solutions.
Ramkumar recommends that we all agree to not use the 3 terms above as aliases for the word product, but instead refer to them respectively as building blocks, applications and solutions in order to curb confusion.
The reality is they feed into each other. The building blocks are feeding into the applications, and applications are feeding into a solution that we finally propose to the government.
Proposed solution: we should follow the three layers clearly presented in all GovStack presentations:
1. Building blocks which is the foundational layer, by definition should be seen as components. It should not be seen as an entire product or an entire solution.
2. Application - a product that solves one specific aspect of a solution i.e. payroll system.
3. Solution as something that we can conveniently use in the context of what we offer to governments as a whole in a specific sector: it might be an entire insurance management system, or it could be an entire health care management or system like postpartum mother child care system.
Then if we are creating a solution and handing it over, it becomes a product.
In parallel, there is also a need to clarify on the difference between digital public goods (DPGs) and digital public infrastructure (DPIs).
It should be clear that DPI focuses on infrastructure not solutions, so cloud architectures, deployment frameworks etc.
We should all agree that a DPG can be defined as being any of the following - an application or the building block or a solution, that is offered as a digital public good.
Next steps: have a workshop where we break down one real use case based on the concept above - defining exactly the solution level requirements, the product level requirements and the building block level requirements.
Feedback
Moritz: agrees with Ramkumar that having agreed definitions is critical. As per DPGA GovSpecs and respective software products are defined as building blocks so it is important to have a coherent language here on for example, the definitions of Building Block Specs and Building Block Software Solution.
All the terminology definitions should be placed in a glossary document and then shared with the Governance Committee for approval to publish it and ensure it is publicly available on different resources online - GovStack’s website, gitbook, etc.
Meelis: Let’s first anlyze where everything starts: minimal service (functionality) independently performs a particular job (input and output)= it can be called building brick. Multiple functionalities logically brought together create Building block = component. The reality today is that many candidates in this scope are products that consist of multiple components. Product = content with several components / BB which is orchestrated through certain rules and principles.
Today Product is defined as the Govstack community which operates through openness and certain principles.
Yolanda: it is important to keep in mind that this is a co-design process so as we move forward with the first country engagement, we should be open to updating the definitions. Let’s remember that the main objective of the GovStack initiative, is to support countries in scaling the digitization of government services.
Initial workshops scheduled to take place in January to start iterating the user journey documentation requirements and process for system integrators (SIs) to develop the sandbox functional prototypes.
The set of uses cases the country engagement team will focus on are now clear - i.e., the EPR, e-cabinet, and online building plan use cases.
Yolanda and team will provide updates on the outcomes of these initial workshops for feedback from all.
A lot of work has been put in place by the team to set up a systemic structure to manage country engagement documents which can be found on the GovStack JIRA public space. The parent page is called country engagement, includes links to general resources - country implementation playbook and user journey template.
All documents are live with a child page created for each country implementation - information can be found on the country’s basic stats, GovStack implementation journey, roadmap, relevant presentations, use case documentations, and the GovStack team members involved.
A template for meeting notes is also included to support in tracking the progress for each use case, or each country implementation. Notes will be systemically added based on the template.
Access control policies have been put in place for certain documents due to the specific government’s privacy regulations.
If anyone has issues accessing certain documents, they can reach out to Yolanda or Ayush for access.
Yolanda: This documentation system is based on the whole of governement approach and country engagement playbook.
Coordination, co-creation and incorporating feedback were all key priorities in the development of this systemic documentation system and the use case and user journey structure. A lot of work went into this with the objective to have in place a system that ensures service design and delivery of digital services from end to end.
Feedback
Ramkumar: Important to discuss further, the steps required to break down the selected use cases into logical process blueprint templates.
This could be outlined in a single document which starts from country engagement, to product feature definitions, then to all the building block maps, and ends up in some API.
✅ Action items
Rachel Lawson (Unlicensed) Train tech teams on where to document things once Google Drive goes away
PRD-51
-
Getting issue details...STATUS
Wes Brown to break apart use case steps into individual document pages
Jaume DUBOIS to translate GovStack slides into French
Shukla, Ayush to create a live master directory document with links to all relevant GovStack folders/files across the technical and non-technical workstreams. PSRAMKUMAR to then circulate this master directory link to all team members.
PSRAMKUMAR to share notes on the terminology process presented during the Product Committee meeting.