Agenda

Presenter

Duration

Discussion

• Review pending action items

 @Esther Ogunjimi

 10 minutes

TECH-278: All BB Leads to confirm if data model has been defined for respective BBs.In Progress

TECH-288: Review BB data core model in GithubIn Progress

TECH-642: Define compliance concept timeline Done

Concept of adaptor

@Steve Conrad

Adaptor Concept

Is this model correct/sufficient?

What technology/tooling do we use? Are there multiple options?

We need to focus some time on the adaptors and how do we bring existing DPGs into compliance with the specs that we're developing.

The adapters are used to provide URL and payload mapping between an existing API and Gov Stack API definitions.

In contrast, the workflow building block is used to manage more complex transactions, or where you need to know the control rollback or commit flow of a transaction. If one transaction requires calling multiple building blocks, that's where you would use something like the workflow building block. Then finally the information mediator is used to transfer information securely between building blocks when going over the wire across the internet.

what's the tooling or technology that we would use to implement an adaptor?

A simple scenario; if you have one building block calling another one, the first building block makes a call that goes through its adaptor, which maps the URL and payload into the GovStack format. The adaptor then sends it over the wire to the first adaptor and the second adapter maps that GS format URL and payload into the second DPG format. The second DPG format processes the information and then, the process happens again in reverse.

Each building blocks is linked to an adapter that does the mapping from its native format to GS format and then GS back to native.

A couple of considerations to note; we are not looking at the idea of service discovery and how one service knows where another service is located. It is really important that adaptors are easy to reuse and reconfigure so that we are not rewriting from scratch for every different use case or sector.

Could we allow but not mandate an adaptor on the 'calling' application or BB?

Taylor - DPG requesting data from another BB should be out of scope. In Gov Stack, we are obsessed with services and rest API; rest API does not make requests and we should never be in the business of helping application make a request to another service. Adaptor is entirely around receiving a request and adapting it.

Steve - We have not talked to much yet about the UXUI building block or what is app consuming the services. Is that part of GS or not?

Wes - Adaptors consume/convert to the defined BB APIs without having to use other standards. If the BB API aligns to a standard then that standard would be used by default but it's driven by the BB API. Some software may (eventually) directly support BB APIs as well, in which case an adaptor would not be required. That's not likely in the short-term.

The term "adaptor" doesn't really map to the sending. It's more of an application-specific translation service. In either case, there is some custom dev required; seems much easier to just update the software to talk to the other BB.

Pawel - Will this be an interceptor and intercepts the request? Or will this be module or GovStack SDK that anyone can use to build GS clients applications? Building adaptor on the sending side might be challenging because DPGs can be written in different languages, frameworks, and might want to retrieve GS data in different ways. It might be easier on the receiver side

Ramkumar - Adoptors could be borrowed, and in case where there are non, we can build ab adaptor.

Taylor - in the specs folder, non of the BBs have a medical record standard for patient data as part of their open API specification. Adaptor helps the DPGs meet the open API specs in this 12 repos. We need to be thinking around medical record standards

Status update

BB Leads

@Valeria Tafoya @Meelis Zujev (Deactivated) @Dominika Bieńkowska (Deactivated) @Steve Conrad

Scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?

• Specification 1.0 publication TECH-206: Specifications Release v1.0In Review

• TECH-615: Building Block Alignment to Template for 1.0 PublicationDone

Wes - The work that we're doing here is not trying to go through and change the content or change the intent of the content. We are just trying to make sure everything is getting aligned to the template that we agreed that we would use. That will mean we might need to make some changes in the short term that we need to revisit in the future. The goal is for consistency across each one of the building blocks so that they all read the same and that we have a cohesive set of specifications that seem to flow well together.

No changes should be made in 0.9.

• Wave 3 BBs

• USCT use case definition TECH-225: Implement INST-1 - Unconditional Social Cash Transfer Use CaseIn Progress

  • Moved to outreach communication step 

  • Arnold - where is the functional ID generated from? because that is the ID mapper.

• Testing

  • Still working on Payment BB

• Sandbox Team

  • Going through demo testing.

• Architecture Team

Building Blocks versioning

@Damian Borowiecki (Deactivated)

Proposed technical solution to the versioning of BBs [ARCHIVE] Test Suite Versioning

Damian - It’s been decided to rely on the functionality that is already provided by GitHub and other version control systems.

Ramkumar - Who will control the version numbering and auditing it? The test suit will evolve over time because we do not know all the tests presently.

Wes - Assuming there is also going to be a non versioned one as well. If we will have specific point in time versions, which we need to be able to show compliance or compatibility for software to specific versions of building blocks, we also need to have the development version, master main etc, but something other than a specific version that is being worked on that is yet to be released.

Damian - Besides those releases, the latest test suite will be executed, which would be made in branch in our case.

Taylor - This is supporting releases rather than deciding how building block spec owners do their versioning

Staya - The concept of living documentation should be looked into. Cucumber on its one defines the model of how code and gherkin files are minted and synced.

Pickles is an open source which helps to generate living documentation as cucumber needs - so we do not need to keep creating new gherkin files repeatedly as APIs changes. https://www.picklesdoc.com/

Document describing approach: [ARCHIVE] Test Suite Versioning

BB spec target reader- Persona

@Ingmar Vali

I have received feedback to make BB specification well readable for architects by removing the example screenshots.
"Screenshot are not appropriate for this section. You should just list capabilities, which can be understood by a Solution Architect, who already familiarised herself with sections 2 and 3. "
That raises a question- has it been decided who is our target reader of the specifications?

Taylor - the users that were discussed in the past are:

• DPG owners - who will look at the specifications to know what they need to become compliant

• Integrators/Architects - who will look at the specifications to decide how they want to propose an implementation to ministries following the GovStack way.

• The group that are receiving responses to RFPs based the recommended GovStack Specification- buyers or governments

Ingmar - It is complicated to narrow on just three groups. But if we want to focus on everybody, some screenshots will be nice for the IT Leads or government officials for decision making. It is important to write documentation that the decision makers must read.

Ramkumar - the decision makers do not have to get deep into the BBs specs. The reference UCs, wireframes and high level demos in the Sandbox are there for them to see while they can delegate their technical team to review the specs.

Wes - The current 1.0 publication is more technical and it is intended to focus on the technical audience. The decision makers can have sandbox as one potential entry point but there should be others, and documents to help guide them as well. This gap will be filled in subsequent releases.

Images/screenshots can augment feature descriptions and, to a limited amount, requirements. They should not be used as part of the definition itself.