5 Hidden Database Deployment Costs

Today, database deployments that change schema and logic are often performed via a manual, lengthy, and costly process. It is important to remember that a task that is expensive does not just cost the amount of money paid in resources and time. There are unintended economic and opportunity costs that are hidden and ignored.

Here are the five hidden costs associated with today’s approach to deploying database changes.

1. Time-to-Market Delays

When production applications releases are delayed due to manual database deployments, it impacts time to market. Customers do not receive new features, enhancements, and bug fixes quickly. This time-to-market delay can result in a decrease in revenue, savings, or even job security. In today’s market, where the competition is only a swipe away on a mobile device, companies cannot afford to have database deployments be the culprit that delays the delivery of new application features to market.

2. Remediation

With manual database deployment processes, there are often mistakes; and that leads to the need to remediate. Had the manual deployment process been completed correctly with no errors, you would have saved time spent diagnosing failed deployments and resolving them. Instead of delivering new features, your teams are fixing unforced errors — and that is especially costly. It’s like having your organization run with leg weights on when it comes to database deployments.

3. Finger-Pointing and Blame-Shifting

Covering for one’s mistakes is time-consuming and takes away from far more valuable activities. However, being placed in a situation to defend the correctness of database deployments when something goes wrong during the application release is even worse. We know the term “mean time to resolution,” or MTTR. There is another metric I like to use: “mean time to innocence” (MTTI). That is the amount of time it takes to prove that you are not the cause of the problem and that others should look elsewhere for resolution. This often happens with database deployments during a failed environment push. Teams will point to the database change as the most likely source of the failure, and it is left to the data team to prove that they did the database deployment correctly. Proving a negative is costly and impossible, like proving extraterrestrial life doesn’t exist.

4. Interruptions

Due to the siloed nature of application developers and database administrators, feedback on database changes is not provided to the development team until the database administrators review the change. That review happens late in the release cycle. Thus, the feedback loop is too long. By the time the database administrators provide the feedback and request for change, the development team has moved to the next sprint. In effect, that requires an interruption to the current development cycle and causes delays to new features.

5. Quality of Life

Poorly performing products, out-of-band changes, finger pointing, and interruptions impact the entire team’s quality of life. In turn, that can lead to staff turnover, in-fighting, and inwardly focused technical teams. These problems distract the organization from creating and delivering great products that benefit the company.

As we’ve seen, database deployment hidden costs are large and impactful. By eliminating friction in database deployments and aligning our database code changes with our application code changes, we can eliminate these costs and help our company win against the competition.