2023-03-15 - Product Committee

Date

Mar 15, 2023

Participants

@Wes Brown
@Sainabou Jallow
@Sarah Farooqi
@Paweł Gesek
@Margus Mägi
@Valeria Tafoya
@Taylor Downs
@Esther Ogunjimi
@Shukla, Ayush
@Nico Lueck
@Uwe Wahser
@Meelis Zujev (Deactivated)
@PSRAMKUMAR

Meeting Recording

Recording URL:

Discussion topics

Item	Presenter	Time	Notes
Review Action Items		5 min	Ramkumar: live master directory link is ready. Ayush will update the link once the remaining documents still on google drive have been moved to Confluence. Suggested that @Rachel Lawson (Unlicensed) could support to upload the master directory onto Confluence.
Daylight Savings	@Wes Brown	5 min	Should we move the time for this meeting one hour earlier or will this time be ok going forward? We will leave the meeting at the current time
IM in Use Case Steps	@Margus Mägi	10 min	Whatever we develop, we must think beyond ministerial or function silos and abandon the digitalization of paper processes (getting registered, filling out forms, etc.). We need to prepare our products, consumers, and beneficiaries for the time when every service is prefilled, happens behinde the scene, and is events (triggers) based proactive service. Many countries are not there yet, but we must prepare them. Whatever the country is, it should be founded on the ideals of the rule of law. Everything we create (whether a use-case or a solution) should take place in this context. We must address the topic of legal certainty in our use-cases. IM is the only solution around (together with X-road) that enables the whole of gov digital architecture design while preserving the division of powers (an important rule for a democratic society), and still being highly scalable. IM is a distributed architecture-based cyber resilient by design network that has/is a trust framework for services provision (register of registers; the process of becoming a network member; a regulatory framework that supports once-only principle etc..) IM has no single point of faliure. The system logs each transaction in 3 locations (transaction log, respective peer logs). Such logging enables necessary data lineage for digital forensics that stands in court when disputed. This leads to legal certainty of data in digital registers, which is an underlying necessity for digital society development (if the court cannot rely on digital register data in its decision-making and still need to bring paper proof, then people will not trust digital services) True that there are prerequisites in that must be in place. For example, a single source of truth requirement must be in law to successfully implement a once-only principle in a cross gov case. Yes, we produce solutions, not regulations, but we need to enable and push for it as designers and engineers. Otherwise, we are just another OSS/MOSIP reseller - below the bar. In our use cases, we need to go beyond regular thinking and explain this to our beneficiaries even if this will not be implemented immediately. IM true value comes from cross-ministerial use-case delivery, but in a user-centric approach for services, all services are cross-domain. We hold a seminar with the CEO of NIIS.org the mantainer of x-road, titled “From connectivity between databases towards an ecosystem of ecosystems – lessons learned through the development of X-Road” Also there are takeaways of the seminar by @Ain Aaviksoo (Deactivated) for your convenience down below . X-orad is open-source software and ecosystem solution that provides unified and secure data exchange between organisations. It facilitates reliably techno-organisational federation of trust. Distributed collaborative information exchange network is not only a technological, but also a political matter. What technology can deliver is to ease the building of trust and creating an ecosystem of collaborative partners with shared common interest. X-road achieves this via common trust principles, architecture and easy-to-follow technical solution. It is, however, important that the ecosystem has a leader (eg a digital agency of the country), which is taking the lead role of deploying and maintaining, facilitating the ecosystem, and very importantly - supports the onboarding of new members to the ecosystem. This role is both technical as well as organisational, such as enforcing the technical requirements. Such ecosystems will benefit its members once there is critical mass of services facilitated via common trust layer. This is why there needs to be a longer vision for eGovernment. If you only think of the first few agencies and services, the benefits of such ecosystem are not obvious. But when you need to have 10 to 15 different government services even for a larger city, you have 14 integrations less and only one security practices used by different agencies instead of 10. A government CIO may easily have 3000 information systems in government portfolio and with point to point integrations requires to monitor and maintain the security policy enforcement of tens of thousands interactions. An ecosystem approach will become a huge cost saviour very quickly. Starting the ecosystem is the most difficult moment. It requires the CIO's vision for such an ecosystem and policy/political level support to overcome the initial inertia by the individual system owners and their vendors to replace what's built previously with the new unknown solution that was not invented here. So, a good start would be to envisage 50 services in three years that could be scaled to thousand services in five years. Comparing alternative approaches to enable this exponential growth might reveal the advantages of X-road quite quickly. Once the critical mass of services have been deployed within the ecosystem, it is much easier for everyone to understand its huge benefits at the system and whole government level. The ecosystem is also more important than the technology it uses at any given point in time. You can and must change the technology and even the technical protocol, but maintain the concept, which is most valuable. And vice versa - no technology alone can substitute for the trust embedded in collaborative ecosystem culture. Plus, X-road model has proven some core conceptual techno-organisational principles to stand the test of time over 20 years. The legal side of eGovernment is also very important. To ease and complicate the implementation of efficient eGovernment the regulations should enforce the policy hat reducing administrative overhead is a goal in its own right: data usage between agencies, oversight of technological risks and future financial burden etc. Very notable feature of X-road is that it facilitates the same benefits of transparent and effective information collaboration with private sector entities as it does between government agencies. This dramatically increases the flexibility of creating public services in collaboration with private sector, while maintaining the same principles of trust. X-road is 20% of software and 80% of its "consequences", meaning that it gives the flexibility to set up very different configurations for one's ecosystem, but get an assurance of its robust security and effective collaboration capabilities that are resilient over time. From techno-legal point of view X-road provides the non repudiation of messages so that you actually get log files with evidence value that can be utilized even in court cases. By today it is also important to know that the global ecosystem of engineers knowledgeable and experienced with X-road principles and technical deployment is broad: 21 ecosystems, 132 countries, 2600 individual members supporting services for 250 million citizens already and counting. Quote of the day: “Don’t just digitize the stupidity of the paper format” The use case should include details about how data can be gathered from other systems (registries, etc) and the method to do that should be through the IM (more for legal/compliance reasons than technical?) Feedback Ramkumar: agrees with this process. Q - what are additional values that IM should provide before being a secure communication channel? Auditing aspect. Margus: whenever the login is happening in one location, it is not enough. In regulatory level, there should be a logic for any information there is a single source of truth. Regulatory sense the population registry is the single source of truth. This supports the audit trail. If the maturity of the country is not there, this data should be provided via the information mediation. Taylor: Envisioned a number of use cases that may not go across multiple ministries. Q - if a use case only focuses on one particular ministry and using the IT data system, is IM still necessary to cross check with other ministries? Should we encourage IM use even for "black box" comms inside a member/application? Margus: Even if a function is only pertinent to one domain -i.e. notary process, the case still is the source of information should always be checked via the single source of truth through the IM. Meelis: IM is not only a technical setup but more or less also a digital governance model/ platform that can support additional security /organizational layer. Steve: we need to figure out if anything needs to be done in the use case and architeture diagrams - to point out where information mediator is needed Wes: might be best to flag/highlight in which step where IM is most likely to be needed. Nico: Is this something for the use cases or should we rather develop something like GovCases? So cases wich resemble infrastructure, regulatory and organisational context of exmaple Government contexts.
Online Building Permit Use Case	@Sainabou Jallow	15 min	Draft Use Case presented on March 8th: https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/product-use-case/urb-1-online-building-plan-approval-system Updated version (as of March 15) still under review on Gitbook https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/~/changes/33/product-use-case/urb-1-online-building-plan-approval-system/~/comments/u11OEywOqghKRSGse3Cs?node=1f992b47cbaa4f51a4dcb0209055f7fb Overview Interactive feedback session facilitated via Miro board: Online building plan approval use case Feedback Ramkumar - Could add the e-marketplace to step 1 Previous Feedback Step 1: Outreach Communication Add data collection and reporting as a workflow. Step 2: Registration Margus: More clarification needed if this step is mimicking the process of registration building block steps - a generic process that is applicable in any kind of registration process? Margus: In the whole of government approach, to register a user should not happen because in an ideal case, everybody should have a singular digital identity - either from the certificate authority or the population registry. There should be in place a single system. In this instance, issuing a username and password to establish certain services or start using certain services should not be a step. However aware that the current reality is different. Include messaging and information mediator as a BB. Step 3: Application Address decision support needs. Step 4: Data Verification and Validation Ramkumar: The description assumes permission has already been granted to access and share applicants data (legal person/legally registered person/entities). This can cause privacy issues especially for businesses. This step should clarify and ensure permission has been granted from applicants. If it's a legal entity, there'll be an authorized person who has to officially give permission to share the relevant records of the organization. This step seems out of order - makes more sense to follow the unconditional cash transfer steps order. Could be moved to step 3. Margus: Information mediator should be added as an additional BB - responsible for data exchange needs and verification processes. Step 5: Review Ramkumar: Name of step could be changed to Eligibility Check to align with the terminology used in other use cases. Step 7: Ongoing Case Management Sarah: There should be a different treatment for complaints which requires a different process that is outlined here. Addressing complaints should have a separate step as it also differs to monitoring and evaluation. Margus: from the registration perspective, change requests and disputes can be addressed in the same process via a task management system to address disputes or amendment requests. We should address problem diagnosis. Additional steps to incorporate Meelis: This use case seems to provide only a half service. If the aim is safety and sustainability at state and municipality level, then it should include a process (similar to application) - which validates the quality and accuracy of the building plan post construction. If the aim is to pilot a small part of a full digital service then it is OK, but is should be implicated at least. Sarah: Based on how the product use case is currently defined (single generic process), the current steps are enough. But if we're thinking about it from a service angle/end to end service delivery, then we could add this step. Need to officially decide how we are defining use cases as Govstack and then keeping that consistency throughout. Ramkumar: A separate step should be added on method of issuing the permit. Maybe requires generating a new ID, communicating with different parties - informing relevant individuals/stakeholders of the issuance. Messaging BB should be added. Issuing of the permit could be called enrollment. This process is similar to the step in the unconditional cash transfer use case. Sarah: Add a cancelation step outlining process of when an applicant who started the application process wishes to cancel the permit request. General use case format feedback Sarah: Likes the visualization depicted on the Miroboard. We should consider displaying visuals in the use cases on Gitbook. A visualization for each use case step. It could be embedded within the use case pages itself. Ramkumar: We should figure out how to incorporate capabilities. If we can standardize a generic registration process/template. Offer registration as a generic capability. Then for the next use case, before working on the detailed outline from scratch, we can first check how its different from the standardized use case steps, and what additional requirements are needed. If the process is similar and generic then instead of creating a whole new use case document, these subject domain matters can be included as example implementations for i.e. registration, payment etc. Creating a standard template for these capabilities and adding example implementations per subject matter.
GitBook Generated Markdown	@Taylor Downs	10 min	Slack
Accelerated Use Case Process		5 min	Status Update Review EPR Use Case (PRD-112: ENV-1 (EPR): Stage 9.3 - Create Use Case document with logical stepsProposed ) Goal is to incorporate feedback received today from Yolanda. Setup Online Construction Permit Tasks (PRD-115: Create Epics and Tasks for Online Construction Permit Use CaseAccepted ) Compile Online Construction Permit Documents (Epic Required) Identify/Invite Country Representatives (PRD-117: Identify Country Representatives for Use Case FeedbackDone )

Action items

@Shukla, Ayush to create a live master directory document (on Confluence) 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. PRD-120: Migrate Master Directory Document to ConfluenceAccepted Ramkumar requested this item be checked as complete.

@Martinez, Yolanda (Deactivated) to create proposal for where to host country content so that it can be linked in the Use Case on gitbook (Will present next week)

@Martinez, Yolanda (Deactivated) find out if/how to make Use Case source documents publicly available (readonly is fine)

@Jaume DUBOIS to translate GovStack slides into French - requested this item deadline be moved to March/April

@Rachel Lawson (Unlicensed) Train tech teams on where to document things once Google Drive goes awayPRD-51: Document Training for BB TeamsDone

@Steve Conrad @Valeria Tafoya finalize BB specs format by March 3rd. Almost done

Decisions

Agreement and alignment on sandbox purpose - Sandbox is intended for Reference Systems that are a staging-level prototype of a service, not anything approaching a production-level system
For accelerated work, UC do not have to have Example Implementation to proceed (though these will be worked on as a higher priority)