The DevOps Conversion in Business on the Data Journey

Personal changes and mental shifts aren’t the only changes that need to happen in order to convert to an IT DevOps Model. There are serious business adjustments that need to be made as part of this process. Admittedly, this process starts out overwhelming (the change curve is real), but you will get there, I promise. And you’ll never look back once established. The following five obstacles are most common you’ll encounter on your journey to a full DevOps implementation.

1. Denial

As demonstrated in my previous post about DevOps, you need to undergo an epiphany, realizing that things need to change. Allow others to go through this process as well; it will take time because change is fundamentally hard. You will encounter strange obstacles such as fear, pride, laziness, and even depression. Remember, people have worked their entire careers supporting the Waterfall Method and you’re asking them to give up something that pays the bills and defines their career.

2. Automation Ridiculousness

Get your teams used to the idea that the first two questions they should always ask themselves when presented with a new task is “Can this be automated?” and “Should this be automated?”. Most DBAs thrive on manual work, so this may be a big change for them. Invest in developing your automation processes but guard against the isolation of the experience wherever possible. Try not to isolate the DevOps experience to a new team, instead start with an existing team. As time goes on make a soft requirement to only allow the creation of an automated process when it is attached to a deliverable (customer request). Your Product Owners can help with this. It keeps eyes on the prize and avoids wasted efforts as well as measurable results.

3. DevOps Isolation:

A New DevOps Team

A select group of people (we will call them the enlightened ones) will go off and create DevOps in their own make-shift team, effectively increasing the isolation from both Ops & Dev departments. Don’t worry, this is natural. The trick is to not let it go too far, avoiding an even larger isolation problem. Guide the team in choosing a real project with a real deliverable and integrate with an existing team as quickly as possible. There may be a need to develop an automation framework, but don’t let this take too long before integrating with a real team.

Does Operations Provide Value?

This is the most dangerous obstacle. Developers realize they are empowered and create some neat automated processes. They create a pipeline that builds every component from the infrastructure all the way through to the software deploy. Everything is scripted, and it works. This is where we may need to fight off a bit of ego. Make no mistake: Sr. DBAs, network engineers, and application engineers are worth their weight in gold when the fires come. They are critical to include on the DevOps team.

Reinvent

Changing titles is a place to start, but that’s just the beginning. Your operations people should be called DevOps engineers. This is where the culture can really change. As an example, teaming the ops team with dev team in a new agile process is a great way to get their feet wet. Offer training to your admins on scripting and best development practices. They will feel empowered when they can speak the same language as the devs. Tell your devs they need to rely on the operational expertise of the admins. Have the team focus on what each person does best. Encourage cross-team training to understand the entire pipeline, and your overall system stability will sing.

4.Departmental Transformation

At this point we have grown up quite a bit. We have some wins under our belt. Upper management is actively noticing less bugs and quicker release times, and the overall stability of IT is better than it’s ever been. Build on this progress by re-questioning everything you’ve done so far. This is a good opportunity to destroy your ego once again. It will be easier this time, I promise. Bring in a couple of new Sr DevOps engineers and allow them to question everything. What is working? What isn’t? What are the time wasters? How can we take this to the next level? Is all of IT included in our process? How can we get everyone involved?

5.Natural Consequence: A High Performing Organization

This is the fun part. You can now deploy, often with minimal risk, across multiple stacks. Bug changes can be fixed in a matter of hours, rather than months. Teams are focusing on what they enjoy, and operational knowledge is freely shared with developers and vice versa. Executives embrace the stability of the IT department, and your team and processes are being recognized at company townhall meetings. Your department now laughs at the thought of going back to the previous structure.

Have Faith in the Process

Seeking advice and education along the way is imperative to long term success. The key to success is faith in the process and allowing it to work itself out over time. The natural consequences of the DevOps journey are worth the effort. Keep in mind that DevOps is not the same for any two organizations. Each culture will adapt to create their own unique process. As long as your team follows the fundamental principles, the end result will be increased efficiency, overall personal and team satisfaction, happier customers, and company-wide wealth creation. DevOps is truly the greatest management tool to ever hit information technology.

The most rewarding conversations are found in discussing failures and successes.  For it is only out of failure that we truly grow. Contact Fortified Data to help you and your organization reach your DevOps goals.

Connect with Fortified Data on Facebook.