Agenda

Presenter

Duration

Discussion

Review pending action items

 Esther Ogunjimi

 10 minutes

https://www.youtube.com/watch?v=4ASKMcdCc3g

Wes - It is a critical issue if there are BBs that have no candidate products that could be used. Proposing to identify products that could be used partially. The intent for the BB specs was not to be defining a product that we are going to build.

Ramkumar - Find reusable components that satisfy a lot of Use Cases within the GS architecture and define them. We do not want to stop identifying reusable, valuable components just because there is no product in the market.

Status Updates

Leads

30 minutes

https://govstack-global.atlassian.net/jira/plans/reports/6EFAz

Consent BB

Working on incorporating the feedbacks received from v1.0

Working on the gherkin scenarios with the testing team

 USCT UC

USCT-01-Registration

Will be working on open image integration for the testing web.

Wave 3 BBs

Ramkumar - UI/UX BB are creating example patterns and the guidelines sections which will be submitted to the architecture team for initial review w/c 10 Jul 2023.

For eSignature BB, has completed 90% development of the spec, and working to organise their spec to align with the template provided. The spec will be submitting w/c 10 Jul 2023 to the architecture team for initial review.

GIS BB has completed 70% in developing the spec. Will be populating the API and functionality definition sections into the template. The spec will be submitting w/c 10 Jul 2023 to the architecture team for the initial review.

eMarketplace BB is organising the content to align to the template. Will be submitting w/c 17 Jul 2023 to the architecture team for initial review.

Wes - Ram Kumar, are you confident that all of these wave 3 building blocks that we are planning on releasing as part of the the upcoming release in September; that they will be ready for the review process by the end of July?

Ramkumar - All content for the wave 3 BBs should be ready by first week of August.

Testing

Will be adding some features to the testing app, like filtering, sorting etc. A new epic will be created for improvements to the testing app as the basic version of the app is completed.

Wave 1 & 2 Future Considerations

All BB Leads are expected to work on creating the tasks for the epic created to track this activities in each BB project.

ID BB

Received the first draft APIs for the onboarding UC

Will be working on prototyping for building an external registration client using these APIs with registration BB Lead

Sandbox

Ramkumar - When installing any BB, we should be agnostic to the platform - this should form part of the overall compliance.

Vasil - Once the concept is finalised and tested with at least one of the BB, guidance on how it's supposed to be implemented will be developed. This will give the exact procedure on how the vendor is employed in such environment which is separated for him and which is separate account with full administrative rights.

Meelis - the team has been facing challenges on how to provide common ground for the BB to play around because the BB providers are requesting for privileges that could not be granted. A proposal has been made to grant all the BB providers an isolated environment for deploying BB products in order to assess the compliancy towards sandbox as well.

Wes - It is okay for the sandbox to be specifically developed using the AWS so far we are not using any AWS specific service. The ability to be able to run on Azure or other systems is something that we want to be able to do in the future, but it also needs to be driven by a group that wants to do that or needs to do that.

Satya - We need to keep in mind the contract for the BB implementations, it was stated that we are going to develop on a cloud agnostic environment. While the hosting will be done on the sandbox environment defined by GS, the BB implementation are free to choose their own development environment and it should migrate easily to AWS.

We need to be deliberate about the infrastructure specifications. Having done an excellent work in terms of APIs related specifications and what was expected from a software perspective, but heavy resource footprint has been noticed from the first few BBs that were tried to be implemented. We should be careful not to end up with heavy resource infrastructure requirements and be deliberate by specifying how to have the bare bone dumped down versions of our DPGs that actually works. Because the current DPGs that we are having are extremely resource heavy. We have to think for a way out from a communication standpoint on how we are communicating software APIs specifications, on the hardware resourcing, cloud resourcing requirements etc

Cloud infrastructure and hosting BB should capture some of these points in their setup guidelines.

Ramkumar - To integrate DPG or a BB into the sandbox environment, there was an assumption that it can be automated running a script and it gets integrated. But it was discovered that it was not possible as the sandbox case would be different from an actual deployment case.

Alex - For IM, it is possible to automatically accept members by just tweaking the configuration. We can have IM in sandbox to accept members automatically.

Vasil - the seeding interface is suppose to be dynamic, provided by the BB and able to confirm at deploy time. This is a key requirement for dynamic configuration in the sandbox.

Capabilities (Contd)

Steve Conrad

25 minutes

https://docs.google.com/presentation/d/11zg0PQQKbpWFxwAc_oK12iM83ax8hUpBqlJHwB-kLGk/edit?usp=sharing Key question: Are capabilities technical and tied to use case steps? Or are they more general business processes?

Is there a need for both of these concepts?

Wes - Capabilities is not a layer but a component that we use to organise our work and to help define commonalities across the different UCs and how they are implemented in BBs. The layer on slide 6 labelled as capabilities should be UCs, and the UCs are used to define what the BBs are supposed to do. Capabilities should sit next to USs and BBs, which will represent how we can organise our work internally. The value add that capabilities can provide is to flesh out that idea of work flows

Steve - Capabilities should probably be more concisely defined - capabilities as related to use case steps.

Jaume - Will continue to support capabilities as that’s the top layer of an infrastructure. What is the capability? Is it a workflow? Is it not work flow. We need to build an infrastructure in GS and not UC as UC will be built by the people that will use the GS. The top layer should be a simple functional one and not a technical one.

If we build in silo when we build a UC and it mean we are not thinking infrastructure, we are thinking along the path of solutions and building in silo.

What is Infinite? Infinite is a quantity of services we can build on the different sectors but the quantity of capabilities is finite. We need use case to illustrate what we build.

Wes - The use cases are intended to be that functional definition and that is the area that we do expect people to try to align to.

The way that we scope the infrastructure that we're building is via use cases, because the infrastructure is almost infinite in terms of the overall functionalities that could be built into any of the BBs. We need something to help us restrict the total scope of what we're working on.

The use cases do need to funnel into overall the cross sector capabilities or work flows and the way we getting around them is through the example implementation in each steps.

We need to have something to help constrain the work that's going on in the building blocks. But the the intent of a UC is not to be defining infrastructure level functionality. They are supposed to be defining the concrete things that could be done with BBs and to ensure the BBs are designed in a way they can actually do that. The secondary goal is to help implementations go to roll out GovStack solutions, to look at the use cases that we've defined and use that as a starting point for the specific use cases that they're going to need for their implementations.

Steve - The use cases help us discover the functionalities that need to be exposed by building blocks and what capabilities need to be delivered.

Vasil - We should first define capabilities and then define how we implement it. Currently the building block concept is isolating the workflow implementations from the real vendor implementations by providing specification.

The same should happen with capabilities by providing specification for those capabilities and provide the proper components which are realising those capabilities which are implementing those capabilities.

Alek - What is the interface for the capabilities? What is the protocol? How will the capability be used?

Jaume - It may use different building blocks, or involve various building blocks, and it may involve the specific workflow for it. The capability can use through rest APIs.

Wes - However it's important to note that a Capability (pretty much no matter how you define it) will be general and likely just a template for how to accomplish a given task using Building Blocks.

(Similar to how the reference use cases could be used as the basis for implementation-specific use cases).

Apache v2 license

Steve Conrad

5 minutes

Apache v2 license was called out in the BB template, but it has not been applied evenly. Do we want to patch or just add to the next release?

Wes - Voting for a patch to 1.0 (1.0.1) to include the license.

Where to do “new work” in GitBook

• Request to tag the names of all the contributors for Payment - should this be done across board?

Rachel Lawson (Unlicensed)

10 minutes

Reminder of process for creating changes in gitbook: https://govstack-global.atlassian.net/l/cp/1cw7pwtw

All new work takes place in the development space.

Wes - Technical Committee should be coming to a consensus on and making a decision about how to organise your work when it is not going to be included in the next release.

Authorisation mechanism

Jaume DUBOIS

10 minutes

The goal is to have clear needs defined. What to do we have currently?

Do we have full inventory of:

• Types of accessors checked (human, back-end systems, apps or browser, robots, hardware, ..)

• Granularity of access control (Building block, module, API, single API service, single API service for specific tenant or data)

Is the overall management of all the accesses realistic from operational and user standpoint?

AOB

Steve and Esther on holiday next week