alphaspirit - Fotolia
Too often I've seen companies adopt DevOps without engaging with the data group. These efforts will fail to deliver DevOps benefits. If the data group isn't in the loop, DevOps ventures like continuous delivery and infrastructure as code just won't work.
But time and time again, we see DevOps teams completely ignore data professionals. From tool evaluation to process improvement, those calling for DevOps adoption routinely ignore data professionals. Ironic then, a movement built around inclusiveness ignoring a key component to a company's success.
Here are the four most main reasons DevOps teams ignore database pros.
1. It's easy to ignore them.
Most companies deploy database changes to their dev and test databases. There was a time when the data group owned that responsibility. But with the adoption of Agile, companies have ceded that responsibility. Thus, devs and testers have no need to interact with the data group, cutting it out of data architectural decisions. The data group must simply accept the changes as requested by the development team.
2. Data is hard.
It's very difficult for the development team to deal with the concept of state. One of the 12 factors for applications is stateless applications. So, introduce the idea of handling state for the persistence layer, and it's often dismissed. After all, isn't it an operations problem?
3. Data professionals have different goals than other team members.
The application development group's incentive is to change things. The operations group's incentive is to maintain stability. Change is the enemy of stability. We want DevOps benefits. We have adopted DevOps to mitigate this conflict and find a way for both teams reach their goals. The data group has slightly different goals. They too seek stability, but the integrity and security of the data are also paramount. As a result, we have a difference in values that leads to conflict.
4. Data professionals say "No" too often.
Finally, data professionals do have the well-deserved reputation as Dr. No. In the past, database administrators have been guilty of using data as a billy club to get their way, and have taken all responsibility for production database changes. Because of their long history of mandating, they're the final arbiters of production database deployments and are frequently dissatisfied with development-created schema and logic changes. They've too often caused the rest of the company to voice their frustration with a terse, "Fine. Do it yourself then."
We can fix this and earn true DevOps benefits
These challenges are not insurmountable. We can resolve these issues by addressing the root cause. We have cross-functional teams in development now. We need to embrace distributed data management and move some of our data professionals into these development groups.
Of course, we still need the data professionals that understand the challenges of storage, performance, high availability for databases and benefits of DevOps. But, a large percentage of data professionals need to look at their peers in systems administration and mirror their career paths by adopting infrastructure as code.
By taking on this new approach of teaming and distribution of responsibilities, we can move faster to the end goal: faster software releases.
The answer, as always, is automation
Learn more about how data and DevOps can come together. Consultant Howard Deiner breaks down techniques to help keep your code, tool sets and databases all on the same page.