Title

Prerequisites

Have all prerequisite inputs for this RFC been met? These will be detailed in a separate document.

Example prerequisites:

  • Requirements have been detailed, including data considerations and signed off
  • Stakeholders have been identified including the product owner, business user and change sponsor (some of these might be the same person)
  • A business process (if it is existing, a current process), including a target state process has been provided
  • If a higher level design is required, this has been completed and signed off (usually for more significant changes)

If work is commencing prior to all prerequisites being met, detail the exceptions that have led to this and the expected impact i.e. rework once prereqs are complete, or being unable to finalise etc.

Reference Documents

The reference document table contains links to information relevant to the RFC, a link to the referenced document is also required. Here is an example:

Reference Document Location
EPIC01 This is a link to the RFC template

Problem Description

A detailed description of the problem.

For a new feature, this might be a use case.

For a major reworking of part of the code, it would describe the problems in that feature that are being addressed.

This section should clearly communicate why we need to solve the problem.

Background

All the historical context should go here, use this section to keep the overview as lean as possible.

Solution

Here is where you describe the change you propose to make. How do you propose to solve this problem? Address the issue at an architectural level, leaving the implementation details for code review.

Include potential code examples, or areas that need more detail than in the high level proposed change.

Service Ownership

Indicate if this solution is affecting existing services or new services. In both cases, determine which team is going to be the service owner, the service name (if it's known). Additionally, the RFC associated with that new implementation (if it's needed) will be included in the central list of services .

Here an example: Market Alerts exposed on EBO and API with dealing team managing it via BOS application

New Service Service Name Service Owner
Yes Pending to confirm PRI Team
No API WebApp API Team
No BOS TFT Team
No EBO ONL Team

Alternatives

What other ways could we do this thing? Why aren’t we using those? This should show we have thought about why the proposed solution is an appropriate one.

Caveats

Are there any shortcuts, trade-offs, or limits that need to be taken into consideration? E.g. only supports USD and EUR currencies; won’t handle ESPECIFIC_ERRORS from third party service; will only be available for a subset of users.

Operation

Short description of how and where this will be run, who will be in charge of operating it, the roles involved, if it’s intended for internal or external public access, etc.

Security Impact

Describe any potential security impact on the system. Some of the items to consider include.

Does this change touch sensitive data such as tokens, keys, or user data?

Does this change alter the API in a way that may impact security, such as a new way to access sensitive information or a new way to login?

Does this change involve cryptography or hashing?

Does this change involve using or parsing user-provided data? This could be directly at the API level or indirectly such as changes to a cache layer.

Can this change enable a resource exhaustion attack, such as allowing a single API interaction to consume significant server resources? Some examples of this include launching sub processes for each connection, or entity expansion attacks in XML.

Performance Impact

Describe any potential performance impact on the system, for example how often will new code be called, and is there a major change to the calling pattern of existing code.

Examples of things to consider here include:

A small change in a utility function or a commonly used decorator can have a large impacts on performance.

Calls which result in a database queries can have a profound impact on performance when called in critical sections of the code.

Will the change include any locking, and if so what considerations are there on holding the lock?

Developer Impact

Discuss things that will affect other developers working on Ebury code. Does this introduce a new library that must be used? Does it change how services communicate? etc.

Data Contracts

If existing data is being amended, or a new data source is being created, identify existing consumers / new consumers of the new data and make them aware of the upcoming changes, detailing whether the changes are:

  • Backwards compatible
  • Forwards compatible
  • Fully compatible
  • Not compatible

(More information available in the Event Standards blueprint)

If compatibility is not full, make consumers aware of how long the previous versions will be supported before they are fully deprecated.

The changes to the data contract need to be detailed within the RFC where known, or provided in another document. The data contract should follow the patterns detailed in Events Standards, Kafka Standards & Patterns documents.

Data Sources

  • Input data sources - identify key systems / applications / services that will be the original source of the information required for the RFC

  • Transformation requirements - high level information regarding changes that may need to be made to the source data for the RFC purposes (low level detail is likely to be provided in a separate data mapping document, but high level should be provided here to help inform the key aspects of data lineage)

  • Output data - once known, what is the target location of the data (if applicable)

Deployment

Will this need to be rolled out in stages? Are there major data transformations? Do the DevOps team need any specific instructions?

Dependencies

Link to any other work that needs to be completed before we can implement this RFC.



Based on RFC Template Version 1.1