Page Comparison

Item

Presenter

Time

Notes

Review Action Items

Wes Brown Sainabou Jallow

5 min

Scheduling noteNote

No Product Committee meeting next week (12/28)

Terminology Update

PSRAMKUMAR

10 min

Specifically looking to define the term “Product”

GovStack Release Capabilities

Jaume DUBOIS

15 minRamkumar:

• 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.

  • Recommends that it might be useful to build on top of the work being done by the GovStack and DPGA working group on definitions - GovStack Definitions: DPI, DPG, BB (digitalpublicgoods.net).

  • 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.

• Nico: https://govstack.gitbook.io/implementation-playbook/govstack-implementation-playbook/3-terminology

• 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.

GovStack Release Update

Wes Brown

5 min

Based on feedback from the various partners, we are going to target the end of March, 2023 for our GovStack 1.0 release.

Strategy Committee Meetings Update

Martinez, Yolanda (Deactivated)

5 min

• 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.

Documentation System of Country Engagement Activities on Confluence

Shukla, Ayush

5 min

• 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.