Architecture Team Page

Members

Accountable Person (only one person)

@Kristo Vaher

Responsible Person(s) (“team members doing the work”)

@PSRAMKUMAR @Steve Conrad @Wes Brown @Aare Laponin @Aleksander Reitsakas @Taylor Downs

Informed (“keep in the loop”)

@Nico Lueck Technical Committee

Product Committee

Team Properties

Status

ACTIVE

Start Date

 

Mar 17, 2023

End Date

(Anticipated date of last deliverable)

Ongoing

Belongs to Committee (only one)

TECH COMMITTEE

Mission

The GovStack Architecture team’s mission is to provide technical recommendations and guidance to the Technical Committee, Building Block Working Groups, Testing, and Sandbox teams. The architecture team will review questions from these groups and provide decisions, recommended processes, and examples for other GovStack technical teams to leverage.

Deliverables and Maintained Assets

Name of the Asset

Link to the Asset (if already existing)

Date or Frequency of expected delivery/update

Name of the Asset

Link to the Asset (if already existing)

Date or Frequency of expected delivery/update

Non-Functional Requirements Document

 https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements

Updated with each GovStack release

Security Requirements Document

 https://govstack.gitbook.io/specification/security-requirements

Updated with each GovStack release

Further Activities

  1. Weekly Architecture team meetings - topics to be determined

  2. Development of Guidance documents for BB working groups, Testing Team and Sandbox team. These will be stored in Confluence (ie. Adaptor Concept and Authentication and Cross-BB Authorization) and referenced in the Non-Functional and Security requirements Documents.

Other Information

Meetings

Meeting Day/Time: Fridays, 2pm - 3pm UTC

Meeting Link: Join the meeting

Mandate

The architecture team will be responsible for providing guidance and making decisions about key technology questions related to GovStack. The specific areas that the architecture team is responsible for are:

  • In cooperation with the Building Block working groups, provide design decisions and best practices for issues that cross multiple building blocks

  • Resolve questions from BB groups that cannot be resolved internally. The architecture team will be the group that can make a binding decision for Building Block teams to follow

  • Provide research and guidance on specific topics that are raised by the Building Block working groups or Product committee. The architecture team may bring in additional non-voting members to support on specific topics

  • Ensure that the sandbox, testing, and reference implementations that are being developed by the GovStack teams are aligned with GovStack designs and specifications

  • Act as reviewer for technical specifications and documents prior to a GovStack release

  • Provide guidance and support for existing products to onboard to GovStack

  • Ownership of documents and specifications that are cross-cutting, such as the non-functional requirements document, security requirements and UI/UX guidelines

Decision Making and Voting Members

The architecture team is a sub-committee of the GovStack Technical committee. It is comprised of voting members, and additional non-voting members may be brought in to the architecture team to provide support and guidance on specific issues.

On issues where a decision is required, the architecture team will seek to develop a unified consensus. However, decisions may be made by a simple majority vote of the members of the architecture team.

The voting members of the architecture team are:

  • Dr. Ramkumar PS

  • Steve Conrad

  • Wes Brown

  • Aare Laponin

  • Nico Lueck

Current Work

Over the next 6 months, the architecture team will be focusd on the following tasks, in addition to any requests that come from other GovStack Groups:

  • Review and rework the GovStack non-functional and security requirements

  • Review specifications from BB working groups

  • Review Use Case example implementations

  • Work with Compliance team to define an initial process for compliance and onboarding products (ie. Ukraine work) - (Software Compliance Concept ). Is there a non-technical/non-API-driven approach we can use.

  • Provide recommendations on specificity and standards for GovStack

  • Identify a process and examples for onboarding existing products and creating adaptors: 6 Onboarding Products | GovStack Specification

  • Coordinating BB specification and testing work with the sandbox team and implementation

  • Respond to specific questions coming from BB working groups that cannot be resolved in Technical Committee (primarily focused on architecture)

  • Identifying and prioritizing Building Blocks to be developed and what is a BB

  • Review GERA document from Open Group and integrate any guidance that is relevant

  • Develop/own FAQ and terminology documents