Pramod Sadalage

30 November 2022

Enabling digital transformation – and data modernization – with DevOps

I don’t need to highlight the impact of the last few years on the world and its businesses. Companies that once completely dismissed the idea of remote working now embrace online offices, with many now operating fully remotely. Externally, the marketplace is shifting too, and opportunities for creating and realizing value can be found in new, less familiar places.

The pandemic amplified the digital landscape; as a result, there is no fear and resistance to transformation anymore: everyone wants to transform themselves. And this trend of digital transformation hasn’t reached its peak either; it will simply continue to grow. Innovative competitors are still entering the market at pace, forcing businesses to question how they can transform to compete successfully.

Adopting the digital transformation mentality

Modern digital businesses know that digital transformation isn’t an outcome; it’s a mindset. So, what characteristics set these companies apart from their competitors? I would argue there are seven:

1. A focus on customer value – These businesses focus internally on which department did something better than the other; ultimately, the customer is where you should be focusing your value.
2. A test and learn culture – It’s okay to want to try something new and equally okay to fail and learn.
3. Responsive to market shifts – They are nimble and can respond to changes in the market.
4. Technology at the core – Modern digital businesses place technology central to their strategy, with an appropriate voice in the boardroom.
5. Structures and governance – Companies ensure that a proper framework is in place to enable the speed of decision-making.
6. Strategic use of information assets – They use data as the base for critical decisions and rely upon it for innovation.
7. Outcome-aligned organization structures – Companies ensure that everyone within the business is aligned to the same outcomes.

Traditional organizations are playing catch-up by making siloed technology investments in upgrading to microservices and continuous delivery, but it’s just not enough. New digital-first organizations that embody the mentality outlined above are entering industries and experiencing exponential growth cycles. These newcomers are faster, leaner, and more fearless and have adopted platform thinking from their inception.

They also tend to adopt DevOps (shown in the book Accelerate: The Science of Lean Software and DevOps) to reduce delivery lead times and increase the frequency of deployments while minimizing change failure rates and lowering the mean time to recover when errors occur.

To benefit from a DevOps culture, as the name suggests, there needs to be a collaboration between Development and Operations – teams that are typically measured by and prioritize different things. Developers are measured by how much change and how many new features they can deliver. Operations teams are measured on the system’s stability, and how many downtimes, failures, or bugs are reported.

This mismatch of expectations often results in developers wanting to push out releases as much as they can and operations teams pushing back because, who knows, if you deploy a new feature, something may break, and that will take their SLAs down.

So, this misalignment of the incentives creates a rift between dev and ops. The DevOps movement is an answer to that – it focuses on enabling collaboration, introducing automation, and aligning everybody’s outcome to the value delivered to customers.

The software development cycle is streamlined, with automated processes to remove human error and increase reliability, testing is shifted left in the pipeline to catch errors earlier, and teams release small changes more often to release value to users sooner.

Avoiding the pitfalls

Even when DevOps is introduced, there are a few misconceptions of DevOps being ‘done’ or ‘completed’.

The first is quite common – DevOps is a culture; therefore, simply changing a team’s name doesn’t give you the culture you seek. They might have a different name, but they are not working towards the common goal. For example, the infrastructure team wants to do infrastructure but may not be aligned with the rest of the outcome. So, you want to ensure the culture shifts its alignment to business outcomes.

The second is around technology – adopting DevOps is a culture change, not solely the purchase of tech. Simply signing up to a cloud provider does not mean you ‘have DevOps’. Instead, you need to ensure the technology is enabling business value change.

The third is around constraints. You might have implemented many changes, like introducing version control and starting Continuous Integration, but you still have numerous constraints on the system.

These might need approval any time you spin up more infrastructure or wait a couple of days after submitting a ticket to request a database. There may be a lengthy manual regression cycle following QA approval because you don’t have things automated. You might still have manual infrastructure delivery instead of automatically provisioning it.

These are only some examples of the constraints; they may be numerous within your organization. So, if you want to adopt a DevOps culture, I would enumerate these constraints and focus on how you can reduce the amount of time and effort that people are spending on them.

Of course, there might be some restrictions that you want to remain, especially if you are in a regulated environment. That constraint will have an input and an output, for example, the creation and publication of a document for the regulators, so it is worth seeing whether it can be automated.

Adding data modernization

DevOps doesn’t apply only to infrastructure; it can apply to databases, networks, security, and many more aspects because it’s the culture that is important. For example, the same culture of collaboration must be fostered among DBAs and application developers.

When I was a DBA roughly 25 years ago, there was this notion that we would develop code, and when it was time to deploy to QA, someone from the DBA team would then figure out the database changes that should be deployed. The same would then get applied to UAT and production. It was siloed and seen as separate from the software development process.

The new approach I have been using for almost 20 years now is the concept of a migration-based approach. So, every time someone wants to make a change, the DBA pairs with the developers and says, ‘Okay, this is the feature that we want to do, and this is the current database state’. A migration script is then created to effect that change. Here’s a simple take on what it means according to me:

The benefit of working this way is auditability. Each check-in of code, or push, to a version control system like Git shows the time, the person’s name, and what they were working on. As the change moves to Continuous Integration, it triggers a build to test the code and then gets pushed through other environments like QA, UAT, and production.

The migration script also carries that metadata and allows you to audit who checked in the change when it was checked in, why it was checked in, what can be done if something goes wrong, and who we need to contact. The idea here is not to blame people but instead to get to the bottom of who knows, as fast as possible so that errors can be fixed and fixed quickly before they become a problem.

By version controlling everything, the incremental delivery of database changes becomes part of the typical Continuous Integration / Continuous Delivery cycle you already have set up for your application code. So, when the code has been through all the different testing environments and is ready for release, it can be published as a package alongside the package for the application changes. You can use many database change control tools to achieve this modern approach to database development.

This approach frees up DBAs to pair with developers right at the beginning of the development process and can think, ‘How do I approach solving this problem?’ or ‘Do I split this table?’ or ‘Do I add an index?’, or ‘Is this better served using a stored procedure?’.

These are the kind of design decisions where DBAs can offer valuable input, thus shifting left the whole notion of where value can be added and minimizing errors further down the development pipeline.

Summary

To summarize, I want to talk about four things that are important for your digital transformation efforts:

1. Allow to fail, fast. If something fails, don’t go into a blame culture. Instead, think, ‘What did we learn?’ or ‘How could we have failed earlier than this?’. This lowers costs and maximizes learning.
2. Don’t just buy DevOps. Implement the culture of DevOps; it’s not a thing you buy. It would be best if you focused on cultural change and collaboration, ensuring that the teams are empowered to do certain things.
3. Think organization wide. Your leadership should understand why you are implementing digital transformation; your whole organization should understand and be aligned on the business outcomes because it can affect different areas. For example, it can sometimes involve HR policy change, like aligning compensation to business value and outcome.
4. Global optimization. There needs to be a focus on how long it takes to get from concept to cash. So, look at the end-to-end picture rather than optimizing for local teams and local personal optimization.

This post is an extract of a webinar Pramod Sadalage presented on digital transformation and data modernization. If you’d like to find out more about the topic discussed, like the 24 capabilities that should be considered when measuring software delivery performance and the value of shifting left, watch the webinar on-demand.

Thought Leadership

Article hub

Read more from Redgate leaders - on digital transformation, the role of the database and more.

Find out more