You Don’t Have to Take A Road Less Traveled to Modernize Database Deployment Practices
The way we design, build and deliver applications has undergone a seismic shift over the last 15 years. To meet the needs and desires of a customer base that expects immediate satisfaction, companies have to get feedback faster and deliver value more frequently. To keep pace, software companies have turned to methodologies and movements like Agile, Velocity & DevOps.
This has worked well for most components of the application stack. In the most advanced shops, a developer can now commit a change that triggers a fully automated delivery process. This process can also include several quality checks on the way to production, only stopping when a problem is detected.
Database deployment is a notable outlier in terms of process modernization. The database is not as flexible as other application components because it is a persistent store of a very valuable resource. Risk tolerance is incredibly low because the consequences of data loss and security breaches are severe. That’s why production DBs were walled off from development decades ago with DBAs to keep watch over them.
The first thing that needs to happen to bring DB change management up to the current standard is a change in mindset for all parties in the process. The deliberate and change averse posture of a lot of data teams must get aligned with the need for speed prevalent in other groups in the organization. But the other groups must also understand and recognize the importance of avoiding reckless behavior in the data stack in our pursuit of faster time to market. It’s not enough to tell someone to hurry up or to be careful. They must have context. They must have a clear understanding of the process from end-to-end and how crucial their role in that process is. Only then can attitudes truly change and true collaboration begin.
Once that’s accomplished, the age-old manual processes must be rethought. We must match the new paradigm of going fast safely. Thankfully, it’s been done before, and not just with software. A lot of the lessons learned and principles developed in the implementation of the Toyota Production System (yes, the car company) from the 1940s to the 1970s will sound strikingly familiar to adherents of Agile Development and DevOps. What resulted was a people focused production process that aligned well with the needs of all producers and consumers in that process. This lead to better market fit and less waste of all resources, material and intangible.
These are the results we’re striving for today in Enterprise IT. Does it make sense to reinvent the wheel just so you can hopefully use best practices for database deployment? Do you have the time, resources or budget to offset the cost of database deployment? If not, it might make sense to look at how those before you have prospered through times of transition. This can help you chart your own path to efficient and adaptive ops that produce value when it’s expected.
Check out our white paper: The Future of DevOps to learn more