Our CEO, Tatiana Krupenya recently interviewed David Grummer, CPO of RedGate, an entrepreneur and product leader with more than 25 years experience in various technological sectors. Today we want to share with you the text version of this interesting conversation.
What do you mean when you refer to a database being a bottleneck of productivity?
There are three key factors to this. The first is data persistence and database perplexity. The second is team processes, and the third is test data. If I unpack them a little bit, databases can’t obviously be overwritten if we want to preserve data integrity.
The first factor is that we have to care about and be alive to the risk of data loss. This is more challenging in larger organizations, which often work with large complex databases – typically across multiple database platforms – and will often have some technical debt. For example, we find lots of organizations have databases that contain invalid objects, which unfortunately means that the database can’t easily be recreated from version control scripts. This, in turn, means that the database can’t easily be integrated into agile processes, which creates an interest charge that’s playable on the technical debt.
The second one is about team processes and the friction that the database can throw into the mix – particularly at scale. There is often a knowledge or understanding gap between different teams around their goals, challenges, and constraints during the software delivery life cycle. App Dev teams are often focused on releasing agile changes to meet business needs, while data teams are more focused on protecting the database and the data they’re responsible for. There can therefore be a lack of training skills and mutual understanding across the areas that can lead to misalignment, and a lack of visibility between these groups can reinforce that gap.
Lastly, there is the quality and management of test data. If Dev Teams don’t have quick and easy access to high-test quality data, it slows the workflow and raises the risk of issues at deployment time. In addition, data sensitivity is a factor, which is why it has to be compliant and easily and quickly accessible. What’s more is that the task of setting up your own database test is both challenging and time-consuming, which is why shift testing is the way to resolve it.
This all sounds very familiar. What do you gain if this is removed?
Our customers tend to highlight three core areas. The first is around the time it takes to get the product onto the market, which supports the organization’s competitive position by getting it more quickly onto the market and accelerating its delivery. Higher satisfaction is the second one. This comes from both the customers and the teams, which stems from faster delivery and more reliable releases. From a customer’s perspective, this is great because they’re getting more value, and they’re getting it sooner. It is also very motivating and fulfilling for the teams working on those products when they can see the impact they’re making on the customers and the business.
And the third trend is really around efficiency, savings, and revenue gains. Bringing up teams from a lot of manual work means there’s much more opportunity to add value innovation and greater operational efficiency.
Do you think there is a cultural aspect that needs to be considered?
Absolutely. It takes a combination of people, processes, and technology to successfully make any transformational change. Personally, I would put people at the top of that list because it’s the most important of the three. Culture is massively important. I already talked a bit about the tension in many organizations between the Dev and Ops teams. Cultural changes are a key part of successfully adopting DevOps. Bringing some alignment through shared objectives that are focused on aligning everyone’s outcome to delivering value to the customer is massively important. Processes and technology can, of course, enable a variety of benefits, such as introducing more automation, reducing human error, increasing reliability, etc. But DevOps won’t work if organizations don’t get the benefits without the right culture. So yes, culture is absolutely critical.
I can’t agree more. Database professionals face many challenges when working across databases. What is behind the growth in this database variation?
The story of the database market is a story of proliferation. We’ve gone from a world of big monolithic databases to today’s huge database diversity. There are now almost 400 database types which is why the growing variation in what’s being used is down to an increase in choice with people selecting the best database for the job. Most people are therefore working across multiple databases, and developers are doing that because most enterprises are doing that. The vast majority of surveys show that almost four out of five enterprises are working with a range of databases in their stack – and the numbers are growing. This shows that there is a huge level of growth which brings a little bit more complexity.
That is indeed true. However, tech is obviously a constantly evolving backdrop. Is that the only thing that is changing?
No, not at all. Besides the growth in the range of databases that are in use, it is also compounded by the changes in the mix of where those databases are hosted, the mix of operating systems that the developers and teams are using, and changes in the tooling. In today’s world, there’s just a far wider range of choices of tools available to support through the SDLC. There’s a change in pretty much every level of the stack these days.
What’s the impact of this?
First and foremost, it brings increasing complexity and increasing velocity of change. This creates opportunities as well as presents some challenges for organizations and individuals – whether it’s productivity barriers, training issues, potential issues around audit and compliance, greater risk of failing, or security issues. All of this is a key driver for automation and trying to find ways to increase simplicity for knowledge workers to help people navigate that complexity and do it efficiently, and reduce the risk of manual errors. This is crying out for tools that can help people tackle those challenges and support their organization to work in a way that they want and that fits their culture and processes. If people process technology, we need all three to work together in order to succeed with DevOps and digital transformations.
That’s an interesting point about tools. What should people be thinking about when considering the tools that can help?
It’s hugely important to consider the end-to-end story. How complete are the tools you are looking at? How well do they fit together? Does the tool train you’re building support your people working efficiently and effectively? To get full value from DevOps, it is hugely important to think about the database. It’s really important to take an end-to-end perspective and think about tooling across not just the continuous database delivery but also test data management. Redgate supports customers to take that join-up approach with end-to-end solutions, enabling them to deliver business value faster through accelerating software delivery, supporting team collaboration, and improving quality and security.
It appears we share a lot of common values with you. The reality we live in is that database professionals can sometimes face issues with senior management who do not take the database seriously. What advice would you give them so that their CEOs or CIOs take note of their concerns?
That’s a great question, and you are right because it’s a constant problem. I think the biggest part of the recipe is talking about the main points and the agenda, which is really about its impact on the business’ performance. There are some real, significant, quantifiable benefits that can come from it – whether it’s from protecting revenue from downtime, reducing the cost from failed changes, or reducing the amount of time that is spent on manual tasks. Those factors alone can generate more than $5 million a year of cost savings for a typical enterprise.
Beyond that, there are other arguments that are a bit more variable from one industry to another around the impact on your competitive position from accelerating time to market, and the value of that can vary quite a lot between organizations. There’s also the reduction in risk from supporting compliance and protecting sensitive data through your SDLC. For me, there’s a compelling ROI, and there are some quite compelling messages in there that really are on point for sea-level stakeholders to respond to.
