Another Perspective on Implementing Database Continuous Delivery
Last month, Gartner released a Technical Professional Advice report titled “Implement Agile Database Development to Support Your Continuous Delivery Initiative.” The report provides advice for those struggling with a cadence mismatch between the rate at which applications are released and the rate at which necessary database changes are made. However, it simply falls short as the four recommendations create a huge overhead for development and data teams to implement without truly solving the Database Continuous Delivery problem.
Here are Gartner’s recommendations:
- “Create an initial high-level model, and then use an iterative and incremental approach to evolve the data model. Don’t attempt to create an all-encompassing set of data models.”
- “Create a data interface layer, such as an API, a service or a library, to encapsulate data access code. This layer will reduce coupling between the application code and the database schema, and increase your ability to evolve each independently.”
- “Version the database objects, the database schema and the corresponding synthetic test data. All of the scripts to create and modify the database must be maintained in your version control system.”
- “Migrate database changes using a transition period to allow other applications, including ETL and test data loader applications, to migrate at their own pace.”
These are all recommendations for bringing Agile to your database development however none of these will help resolve the problem associated with database change management and database continuous delivery. They all center around what development can do to align their application code changes with database changes. However, as Gartner’s own cited study claimed, the number one reason development teams avoid the Data Group is “Data group too slow.”. Nowhere in these recommendations is there suggested way to increase the data group’s throughput. The recommendations are full of reasons to not request as many changes. Henry Youngman would be proud.