Technical Design Authority

This document defines the terms of reference for the Technical Design Authority (TDA)

Scope

Requiring the approval of the VP of Engineering for Blueprints is not scalable as Ebury grows and the volume of projects and Blueprints increases.

The Technical Design Authority is a small group of experienced Engineers who have the authority to provide final approval on Engineering Blueprints on behalf of the VP of Engineering.

Responsibilities

The TDA aims to ensure Technology delivers value efficiently, quickly, often and safely.

The TDA will facilitate these goals by :

  • Defining the:

    • Technology Strategy
    • High Level Architecture
    • Infrastructure
    • Software Development and Blueprint Processes

  • Providing:

    • Reviews and feedback on Engineering Blueprints
    • Final approval of Engineering Blueprints
    • Illustrations of common patterns
    • Guides to best practices

The TDA is not responsible for solution designs or creating design Blueprints. It is focussed on providing timely feedback and approval/rejection of Blueprints on behalf of the VP of Engineering.

Software Development Process

The Ebury Software Development Process is defined in a separate document.

An Ebury Epic is a project that has strategic value and may take up to 3 months to implement.

The cost of detecting and fixing issues increases exponentially along the development pipeline

The primary purpose of Blueprints is to detect as many unforeseen and unexpected issues as early in the development process as possible - thereby reducing the exponential downstream costs.

An EPIC design must be in an approved Blueprint before work commences.

All teams should participate in the Request For Comment on Draft Blueprints.

Members of the TDA provide feedback and the final approval of Blueprints.

Blueprints

Blueprints minimise exponential downstream costs by facilitating the early detection of issues.

Blueprints should cover: * Clarification of any remaining ambiguous requirements * A Solution Design - in line with the High Level Architecture * Design considerations, such as data, security, performance, monitoring, release process, infrastructure, etc as guided by the RFC Template.

Blueprints should ideally be drafted as stand alone documents and worked on by interested parties (including the TDA) until they are mature enough to be published as Markdown for review by all teams.

Approval Process

Members of the TDA are defined in the CODEOWNERS file of the ebury-blueprints repository.

The TDA assigns a Pull Request to one of its members. This is visible in GitHub under the ‘assignees’ section of the Pull Request.

Once the Pull Request is approved by the assignee, it can be merged into the ebury-blueprints trunk.

TDA Participants

The VP of Engineering chooses participants for the TDA to act on their behalf.

The members of the TDA are defined by the CODEOWNERS file of the ebury-blueprints repository.