Introduction
Bud continually adds to the Data Warehouse. This article outlines the principles and processes Bud follows. It details how Bud consults with clients before implementing significant schema modifications and the steps for requesting additional data items. The article also explains the difference between additive and breaking changes, ensuring clients are informed and prepared for any updates.
General Principles
- Bud will consult with clients using the Data Warehouse prior to developing and deploying any change that will modify the schema in any significant fashion.
- The majority of modifications are expected to be additive e.g. new data captured/calculated provided in the Data Warehouse
- It is intended that the Data Warehouse be a reliable and resilient source of data for client reporting needs, to this end where possible, we will avoid making breaking changes unless necessary.
- Bud will maintain and publish a Data Warehouse roadmap to keep clients informed of upcoming additions to the Data Warehouse.
Process for Requesting Additional Data
- Requests should be made to the Account Manager who serves as your principal contact within Bud.
- The request follows the same basic process as a normal feature request, information on which can be supplied by your Account Manager. At a high level, the request will either:
- Be accepted and scheduled for development.
- Be accepted but scheduled for a point in the future, commercial discussions can be undertaken to accelerate the development
- Be considered for future development but no commitment made
- Be rejected as not in line with Bud’s product direction
- For brevity and to avoid duplicating process from other documentation – once accepted the item will be considered in terms of impact on Bud’s client base and correspondingly categorised as either an additive or breaking change.
Additive Changes
Where a change is considered additive e.g. continues to honour the existing schema but may introduce new columns and/or tables this will follow the typical Bud development process of development, testing and once verified as meeting Bud’s acceptance and quality criteria, therefore, be scheduled for deployment.
Clients will be notified at least 24h in advance of the impending deployment, what changes are included and any impact on the service during this deployment period.
Breaking Changes
Bud will only apply breaking changes where the impact of the changes is considered to be in the best interests of all of our clients and supports a long term, maintainable data structure. An example of a breaking change would be moving a field into a different table, or removing a field entirely. At least 6 weeks notice will be given before we make a breaking change.
A breaking change will typically initiate an expansion and contraction approach. In the scenario where a column is to be renamed or a table split into two the original schema will be maintained and a new table/column added.
The same principle will apply should a column be retired or replaced with a new field (e.g. due to regulatory change).
Key Terms
Data Warehouse – this term refers to Bud’s production Data Warehouse which is available to clients (depending on commercial agreement). The Data Warehouse provides clients with an aggregated reporting orientated copy of their data within the Bud platform.
Additive Change – this term refers to a change that is additive in nature, typical examples of which are the introduction of a new column or table.
Breaking Change – this term refers to a change made to the underlying schema which will require remedial work for any clients consuming data directly. Typical examples of this are the renaming of an existing column, a change of datatype or the deletion of a table or column.
Expansion and Contraction – this term refers to an approach whereby breaking change is managed through maintaining the existing interface initially (e.g. column names), adding the updated data as a new column and then retiring the original column at a future point in time.