Sandbox deliverables scope

Target release

Type // to add a target release date

Epic

Type /Jira to add Jira epics and issues

Document status

DRAFT

 Existing list of objectives

  1. show infrastructure of use case

    1. building blocks

      1. available bb

      2. deployed bb

    2. kubernetes

      1. pots from kubernetes that are deployed

      2. services in the kub pots

  2. manage BBs (single and independent)

    1. show list of available bbs

      1. descriptions, links, etc.

    2. show logs of bbs

    3. deploy bb (bb has responsibility to state availability, sandbox will use their plugin interface to check)

      1. list of active instances of BB

        1. statuses

          1. deploying

          2. deployed

          3. activated

          4. test passed…

          5. error/unknown?

        2. links and info

          1. swagger UI

          2. data management

        3. uptime?

        4. resources?

      2. create new instance of BB

    4. stop/shutdown bb ?

portal for non-technical users

  • show accessible use cases and scenarios

    • show informations and descriptions of use cases

    • show dependencies to BBs and infra

      • show which instances are involved in the use case

    • button to make it live

      • check running BBs

      • use running BBs

    • (challenge with big BBs like mosip because it takes long to deploy, we may be able to use delegates)

    • (we may implement adapters ourselves, because this will be compliance strategy to make non-compliant BBs to comply) —> we will re-check this in 1-2 months

    • (mapping via xroad api after deployment is a challenge)

unclarities as of 2023-06-22

  • what’s in the cluster? —> we need API to check that, will be checked by Tsveto in next sprint

  • BB have no mandatory interfaces which make them recognizable and make them behave like plugins

    • BBs will be pushed by us to build such plugins

Existing requirements to review

#

Requirement

Validy as of Aug 1, 2023
cc @jarkkohyoty @Vasil Kolev @Meelis Zujev (Deactivated) @Nico Lueck

Feasibility as of Aug 4, 2023 until Dec 22, 2023
cc @jarkkohyoty @Vasil Kolev @Valentin Filyov @Tsvetomir Krumov

Comments on Aug 4, 2023

#

Requirement

Validy as of Aug 1, 2023
cc @jarkkohyoty @Vasil Kolev @Meelis Zujev (Deactivated) @Nico Lueck

Feasibility as of Aug 4, 2023 until Dec 22, 2023
cc @jarkkohyoty @Vasil Kolev @Valentin Filyov @Tsvetomir Krumov

Comments on Aug 4, 2023

US#1

HIGH I want to deploy the sandbox with different BB candidates so that I can experience the interchangeability of software components.

NL: Still valid, but “deploy the sandbox” shouldnt be taken word by word. It is rather “access a use case with different BB candidates”

  • Feasible on individual infrastructure

    • “Infrastructure as a code”

  • Not feasible via public portal

Community is missing alternative candidates for BBs

US#2

HIGH As an IT expert in a Ghanian ministry/contracted IT consultant I want to be able to select for each BB 1 out of 3 Govstack-Compliant applications and deploy them with a particular use-case configuration so that I can understand Govstack interoperability concept and consider using the architecture and methodology in my own digital transformation. (Owner: @Taylor Downs )

NL: Yes, same as above.

  • Feasible on individual infrastructure

    • “Infrastructure as a code”

  • Not feasible via public portal

Community is missing alternative candidates for BBs

US#3

HIGH I want to test the performance and other metrics (e.g. latency, network speed, response time, compression, carbon footprint) so that I can evaluate the potential usage of the architecture.

NL: I would lower priority of this point or delete since it is anyhow not reflecting the real performance numbers. What do you think?

  • Not feasible in current infrastructure

  • Might be feasible in other infrastructure (that’s closer to an production environment)

 

US#4

HIGH I want to read an up-to-date documentation (technology stack, licenses, architecture diagram,…) so that I can inform myself about details of use software and architecture.

NL: Valid.

  • feasible

Sandbox team is documenting sandbox deliverables, community-wide documentation must be orchestrated to be accessible via the Portal

US#5

HIGH I want to experience accessibility and UX so that I can assess the usability for my target group.

NL: Doesnt feel valid anymore. It is rather something for the Online Contruction use case to use the UI Patterns

  • feasible (but out of scope for Sandbox team)

Link and refer to UX/UI specs

US#6

MEDIUM I want to create self-hosted instance of the sandbox so that I can analyze the system in a safe environment

NL: Valid. Still my assumption that this might be useful. It is what I meant with “replicable vertical prototype”

TBD

TBD @Vasil Kolev @jarkkohyoty @Oleksii Danyliuk etc.

US#7

MEDIUM I want to be able to access and change source code or any other aspect in a safe environment, so that I can showcase a customized deployment to my colleagues/superiors.

NL: Valid.

  • feasible

covered by previous ones (based on working def. how to set up own cluster etc.…)

US#8

MEDIUM I want to get a blueprint for DevSecOps environment so that I can build up my own BB-based system.

NL: Valid. Can also only be done with documentation since it says “blueprint” not “to experience or similar”

  • feasible

covered by previous ones BUT only referring to documentation level

US#9

MEDIUM I want to see the infrastructure performance requirements that is needed to assess the sustainability of the BB based approach.

NL: I think it is a fair point, but rather for the documentation or a document where we gather learnings from this project.

  • feasible

metrics of our learnings will be used to document observations

US#10

MEDIUM I want to check the administration and maintainability concept so that I can evaluate the potentially needed Maintenace efforts.

NL: Delete

TBD with @Nico Lueck @Vasil Kolev

instead of delete, we should document our observations referring to this user story

US#11

LOW I want to save my custom sandbox deployment so that I can continue working with it another time.

NL: Delete

TBD with @Nico Lueck @Vasil Kolev

instead of delete, we should document our observations referring to this user story

US#12

LOW I want to change API so that I can test integration with the test environment of my country.

NL: Possible with the Replicable Vertical Prototype with Emulators? E.g. Exchange an emulator with a software running in my environment

  • feasible

  • Possible via adapters

    • we can document OR

    • create adapter project

US#13

LOW I want to get security recommendations on how to set up such an environment so that I can build a secure testing ground for my country's systems.

NL: Optional

  • feasible

  • Related to devsecops story, should be combined/included

 Goals and requirements MVP

Touchpoint

Goal

General Requirements

User Story Reference

Touchpoint

Goal

General Requirements

User Story Reference

Sandbox Gitbook

Inform on Sandbox infrastructure

  • Documentation on Sandbox infrastructure

  • (Reference existing documentation from @Akseli Karvinen , @jarkkohyoty , @Vladislav Todorov & @Oleksii Danyliuk )

[TBC by tech]

  • US#4

Public Sandbox Demo via Sandbox Gitbook

Access public demo Sandbox

  • Access up-and-running scenarios

    • Scenarios as a playground (from civil-servant/civil view)

  • Dashboard/monitoring of infrastructure (only for information purposes)

    • Availability of services

    • Next reset of DBs

    • References to Github or resources for used technology

[TBC by tech]

  • US#4

Sandbox Gitbook

Understand service design and implementation process

  • Implementation Playbook reference

  • UX/UI specifications reference

  • Service Design along the implementation playbook - practical example of designing the building permit use case for the Govstack Sandbox along the implementation playbook

    • (Service Prioritization)

    • As is Journey

    • To Be Journey

    • Service Blueprint

    • Requirements and Specifications

    • QA

    • Important differences between sandbox Use Cases and Country implementation process

      • Other part of the implementation playbook which was not considered for generic use cases

      • UI/UX can be different based on the culture, user group/target, legislation, language, existing design system etc which should be considered by each implementation spesificly (For guiding the user UX/UI group work)

        • All the work can be accessible via public figma files (design) and through portal(research and visuals)

  • US#4

Sandbox Gitbook and DIY

Take control of and investigate on the Govstack Sandbox

  • Documentation on how to set up own Sandbox

    • Technical requirements and recommendations

    • Security recommendations

    • (Reference existing documentation from @Vladislav Todorov & @Oleksii Danyliuk )

    • Documentation on how to integrate selected BB software

    • Documentation on how to integrate other software

    • Documentation on how to run emulators and adapters

    • How to set up example use cases

      • Technical requirements

      • Deploy scenarios and necessary BBs for them

        • manage BBs (single and independent)

          • show list of available bbs

          • show logs of bbs

          • deploy bb

          • stop/shutdown bb

[TBC by tech]

  • US#1

  • US#2

  • US#6

  • US#7

  • US#8

  • US#9

  • US#12

  • US#13

 

 Working hypotheses

@Jonas Bergmeier Aug 10, 2023

  1. It is more valuable to technical consultant if they can access a well structured documentation with the possibility to up-and-run “a Govstack” in their own cloud to investigate upon it, opposed to get somewhat very limited access to a publicly running Govstack infrastructure.

  2. Government decision makers want to see proof that the concept of Govstack works in practice with use cases they can relate to.

  3. Government decision makers are generally more curious about economic factors than technical details, from a certain point onwards technical experts are involved to investigate on details.

  4. It should be convenient and fast to get in touch with experts for government decision makers and technical experts as well.

 Non-functional requirements

Requirement

Notes

Requirement

Notes

Mobile first design and full responsive

 

Maintainability and accessibility of service

 

Integration of services in existing marketing infrastructure

 

Accessible via sandbox.govstack.global

 

 Out of Scope

Out of scope requirement or feature

Reasoning

Notes

Out of scope requirement or feature

Reasoning

Notes

Separate use case environments for user groups or users

  • most options to provide this would massively increase infrastructure costs

  • options that might not increase infrastructure costs massively cause a disproportionate high effort with high complexity

  • relatively low expected users / day based upon govstack.global metrics as of Aug 9, 2023

  • system can reset to default DB state regularly

 

Individually built portal frontend

  • low sustainability

    • not easily maintainable

    • very high effort to built

    • question of continous maintenance after Sandbox project ends in current form

  • doesn’t help to fulfil the identified requirements compared to using Gitbook

 

Notes Aug 8, 2023

Portal scenarios meeting

MVP decisions

  1. publicly accessible USCT and Djibouti Use case will run permanently and openly accessible

  2. they will be reset every X hours to a defined default state

  3. portal should give possibility to request support for DIY environment (DEV SUPPORT/SERVICE)

not defined yet: how and where will the deliverables be exposed?

  • depending on the questions:

    • what's the name of it?

    • is the product of the portal self-built, within wordpress or something else, such as gitbook?

  • this will be decided when wireframes are reviewed and scope for mvp is clarified

Action Items

Gitbook subscription expansion vs. other tooling → final check with stakeholders @Oleksii Danyliuk
Gitbook team sync / intro Aug 18, 2023 @Oleksii Danyliuk

 

 Open Questions

(As of Aug 2, 2023)

Question

Answer Aug 9, 2023

Notes and questions (to answer the question)

Date Answered

Question

Answer Aug 9, 2023

Notes and questions (to answer the question)

Date Answered

How do we provide isolation between the clients?

The first version of public use case (USCT) wouldn’t include multi tenancy, or client separation logic. System is going to refresh predefined data on schedule base or on demand.
Currently, the system would not have a client isolation.

  • isolation not extremely important, because this is open information of open source project

  • if we have isolated sandboxes, this is isolated environment anyway

Are we able to provide separate kubernetes clusters?

In general yes.

 

 

Can they be forked for separate customers?

Deliverables can be forked:

  • paec by

 

 

Can namespaces be used to separate “customers”?

@jarkkohyoty

 

 

Can we use separate xRoads to separate env.?

@jarkkohyoty

 

 

How long do we expect users to use the sandbox?

 

 

 

How do we deploy the different parts of a scenario?

 

 

 

How to provide access to sandbox?

 

We already have achievement with cognition/magiclink. Maybe we should continue.

 

Registration? - Auth etc.

 

  • Barrier of entry should be as low as possible

  • zero installation would be what we want

  •  

 

What explicit scenarios are there regarding the technical collaboration between a government and Govstack and how can a portal support this?

 

cc @Nico Lueck @Farina Owusu

 

Can the portal be cloud agnostic?

looks like this is not achievable currently

 

Aug 1, 2023

How can deployment of products be automated?

 

  • we need automation scripts from vendors

 

Git repositories

GitHub - GovStackWorkingGroup/sandbox-app-portal-backend
GitHub - GovStackWorkingGroup/sandbox-app-portal-frontend

 

 

Is 'portal' a fitting name?

 

Could be decided after concept phase

 

Scenarios for technical implementation

@Oleksii Danyliuk @Vasil Kolev@jarkkohyoty

Name

Scenario A

Scenario B

Scenario C

Name

Scenario A

Scenario B

Scenario C

Description

  • based on architecture WG, we can provide multi-tenant application for the portal with different accounts under this tenant, i.e.

    • government a → tenant

      • user a → user

      • user b → user

      • user c → user

    • government b → tenant

      • user a → user

      • user b → user

      • user c → user

  • make use of API to expose information in portal

  • multi-tenant through different namespaces