The most important thing for DevOps Engineers in this kind of situations, is to get (a) Management Commitment and (b) Required Budgets. Read on for some more details on both ...
Get Management Commitment
Once that is in place, things become easy for such DevOps engineers. Especially whenever resistance (from all sorts of parties) comes into the game. Trust me, there will be such resistance, which challenges such as:
- Why do we have to change? I want to keep doing what I did for X years already!
- I do not want to loose the (technical) power I have, and complete all sorts of workflow procedures, to get a silly fix in production that should take me like 5 minutes instead of 5 hours (or days ...).
- ... (I could add another dozen bullets here ...).
Whenever those challenges come up, all a DevOps engineer should have to say is like:
I'm sorry, I'm just doing my job ... based on instructions from upper management.
Get Required Budgets
An effective way to get Required Budgets, is to create/submit an appropriate business case which explains the tangible and intangible benefits of various DevOps practises by applying them to some real world cases that apply to the company itself.
Below are some real world cases I experienced myself, as an SCM consultant hired by some companies where these things had happened. I know, SCM is only part of DevOps, but it's the area where I have some expertise ...
1. Benefits of automation
Due to some strike from only 2 (!!!) computer operators (who did not type the console commands anymore that they where expected to type), trains had to be halted somewhere half the way between 2 factories (since the system at the factory where the train was heading to was down, crucial data about handling the train was not available).
By implementing an SCM system, many operator commands were automated.
2. Reduce software license costs
Some software vendor had decided to increase some yearly fees for the (outdated) SCM software, which management didn't agree to. Therefor they created a special project to get it replaced by some alternative SCM software.
The budget of the project was equal to the yearly fee they didn't want to keep paying. That included flying in engineers from other continents (like me) to make the project succeed.
3. Reduce operating costs
Some major insurance company was using some FTP software to transfer software fixes to about 13.000 midrange computers (AS/400s) throughout the country, and this whenever "a" fix became available. The cost of 1 such transfer was about 4 USD (13.000 x 4 = 52.000 USD for a single transfer ...). The software consisted of 120.000 components, developed/maintained by about 150 developers. Do the math about the probability that 1 developer made 1 (tiny) mistake in any of these 120.000 components, which made it to production, and required an urgent fix, which would cost another 52.000 USD (just for the transfer!).
By implementing an adequate SCM system (with managed test environments, approvals, etc), this company achieved a major cost reduction. Think about it, if the SCM system could prevent the need for only 20 transfers of urgent fixes, it resulted in a cost reduction of 52.000 x 20 = 1.040.000 USD (quite a budget to implement an SCM system, they only needed a fraction of that amount to get the job done).
4. Reduce costs of unavailability
If the above cases are not convincing enough, then think of the system(s) of a major credit card company being unavailable around the world. I've been told that 1 second of unavailability costs them 1.000.000 USD.
That's probably also the reason why, for a very long time, such companies have sophisticated DevOps tools in place, for many decades already. Because each second they are not in business costs them a fortune.