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: a task that is expensive does not just cost the amount of money paid in resources and time. There are unintended costs and opportunity costs that are hidden and ignored.
Here are the 5 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.
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 — 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: MTTI or “Mean Time to Innocence”. 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’s left to the data team to prove they did the database deployment correctly. Proving a negative is costly and impossible, like proving extraterrestrial life doesn’t exist.
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 onto the next sprint. In effect, that requires an interrupt to the current development cycle and delays to new features.
5. Quality of life
Poor performing products, out-of-band changes, finger pointing, and interrupts impacts 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 deployments hidden costs are large and impactful. By eliminating friction in database deployments and align our database code changes with our application code changes, we can eliminate these costs and help our company win against the competition.