Blueprint Lifecycle
EPICS
The primary purpose of RFCs in Blueprints is to provide a macro level assessment of an idea by any and all members of the Technology Department, thus giving the idea the best possible chance of success, while minimising costs.
Each EPIC must have Approved Blueprints describing the solutions before the EPIC is started.
Blueprint Lifecycle
A Blueprint is a design written as a Markdown file based on the Markdown Blueprint template
- Draft: a Blueprint has been drafted and evolved by a small team of interested parties. This small team must include one or several Solutions Architects.
- Request for Comment: The completed draft Blueprint is added as a branch of the Ebury Blueprints
Repository (
ebury-blueprints). A Pull Request is created for the branch and relevant people are invited to review and comment. Feedback is incorporated into revisions of the Markdown file by the author. - Approval: an assigned member of the Technical Design Authority (TDA) reviews and approves Blueprint. Further additional approvers may be required as defind in the section below. The Blueprint cannot be merged/published until a member of the TDA approves the Pull Request.
Approval
The Technical Design Authority (TDA) will assign a member responsible for the final approval of a Pull Request using the GitHub 'Assignee' section.
Members of the TDA are CODEOWNERS of the ebury-blueprints. The approval of the assigned member is required in order to merge the branch into the trunk and have the Blueprint published.
The assigned member of the TDA reviews the Blueprint and ensures the relevant additional approvals are in place:
Additional Approvers
| Section | Description | Approvers | |
|---|---|---|---|
| Architecture | New or updated Blueprint | +1 | SVP of Engineering |
| Components | New or updated Blueprint for a component that has architectural significance (1) | +1 | Another member of the TDA |
| A Blueprint for new component | +1 | A Solution Architect or Technical Lead (3) not associated with the proposing team | |
| New or updated Blueprint for an existing component | +1 | The Code Owner | |
| Any Blueprint requiring a 3-point estimate | +1 | Engineering Director of the proposing team | |
| Data | Any Blueprint with changes to data schemas produced (2) | +N | Solution Architect or Technical Lead (3) responsible for the consumers of the changed schemas |
| Any Blueprint adding new consumers to existing data sources (2) | +1 | The Solution Architect or Technical Lead (3) responsible for the producer of the data | |
| Any Blueprint describing a change impacting on Analytics | +1 | SRE / Analytics Team Lead | |
| Practices | New or updated Blueprint | +1 | Another member of the TDA |
| Policies | New or updated Blueprint | +1 | SVP of Engineering |
| All | Minor improvements that do not change the meaning or intent of the original. | 0 | None |
- The addition of new architectural components, new integration methods, new technologies, etc.
- A Blueprint that has content in the ‘Data Consumer Impact’ section of the RFC.
- A Technical Lead must be a Staff or Principal Engineer.
Once the Pull Request has been approved by the assigned member of the TDA, the Blueprint can be merged into trunk.
Socialising the Blueprint
For new or significantly changed Blueprints, please consider who would need to know about the changes; don't assume people will just read it on their own.
For significant changes, the solution architect for the relevant domain is responsible for organising informational sessions.
These sessions should be recorded and the video link added to the Blueprint.
Removing a Blueprint
Archiving a Blueprint requires the same approvals as updating the Blueprint.
A Blueprint is 'removed' by:
-
Changing the title to 'Archived: rfc title'
-
Moving it into the docs/archive folder in the repository
-
Adding a link in the Archive section
Blueprints in the Archive section are no longer active, but are accessible for reference.