Steve Jones

8 October 2015

An overview of Database Lifecycle Management

One of the ways in which many software development teams have tried to improve the quality of their output is by examining what has worked in other organizations and projects in the past. They look to experiment with new techniques and ideas, and implement those items that work. This practice has allowed Agile, Scrum, OOP, XP, TDD, and other ideas to spread.

Across the decades that we have been using computers, there have been quite a few development models against which developers have measured themselves, the most well known of which is the CMMI Model from Carnegie Mellon University.

Very few companies have reached the top of the CMMI model, which is fine. Lots of well run software teams have adopted many of the principals discussed in CMMI and improved their software development process along the way. Most companies also aren’t willing to pay for an assessment, so there may be some very mature teams that haven’t been officially recognized.

A few years ago, ThoughtWorks published a maturity model for organizations looking to implement Continuous Delivery (CD). The expectation was that this really applied to individual systems or applications, as few companies actually have standard practices and configurations for all their environments. The movement along the path of implementing CD also takes place across time, with some projects maturing quicker than others.

At Redgate, we’ve taken much of this previous work and built a maturity model aimed at Database Lifecycle Management (DLM), incorporating similar ideas that apply to a database development process.

We’re working on a model designed to help you measure the maturity of your database development process, with four stages that characterize your progression towards a well-engineered database software pipeline. Each stage includes the adoption of a specific type of process for managing your database development activity.

The four stages in our maturity model are:

We’ve illustrated the stages below, and shown the tools that can help you implement and reach each of them. Note that in all stages we include monitoring as an important aspect of the process because improvements are difficult to make if an organization cannot measure performance.

While these stages do lead into each other, we recognize that an organization might have some aspects of a mature database development group while lacking others. For example, many database groups might have extensive telemetry and monitoring in their applications, but have yet to implement a Continuous Integration (CI) process. You may have a release management tool where you load manually written scripts, yet lack a version control system (VCS).

These levels are a typical progression for many organizations, and a template for beginning your journey to a more stable, better engineered database development process that allows you to make database changes in a reliable, repeatable fashion.

Certainly there is still work to refine these levels and provide more details, and the work at Redgate continues. We hope to help the world build better database software and deploy it on the schedule that meets each individual organization’s needs.

Our goal is to assist you to Ship Often and Ship Safe.

This article is the first in my series about Redgate’s Database Lifecycle Management maturity model. If you’d like to find out more, dip into my other posts:

Stage 1 – The Manual Stage

Stage 2 – Automated Version Control

Stage 3 – Continuous Integration

Stage 4 – Release Management