“DevOps is the collaboration of Developers and Operations to allow faster deployments.”

This is a wording we usually hear from customers, technical staff and managers. But is this really everything?

This posting will explain why DevOps does not only have a purely technical implication but also affects any other company departments.

DevOps at technical level

The DevOps movement was first mentioned somewhen back in 2007. In this time it was really a purely two department collaboration and communication procedure which had its roots in agile development.

As development was pushing out releases faster, there was a need for IT Ops to adopt to the new release cycle. This is where the DevOps movement founds it base.

DevOps and Security

Spectre, Meltdown, Heartbleed, zero-day exploits. Security is of high concern for every company with IT departments. Most security departments where usually seen as the “no-sayers”. With every new request for security related review of platforms and code, usually IT security had some complaints.

Nowadays IT Security gets involved into the planning, implementation and deployment process far more early, allowing them to share knowledge on security topics and provide guidance on security implementations.

Some people gave this new way of collaboration a new term: SecOps or DevSec or even DecSecOps.

But there are also non technical departments which must adopt to DevOps culture and principles. The most stunning ones will be HR and Finance. But was has HR and Finance to do with DevOps?

DevOps and HR

Remember the old times? Companies placed a job offering on their website, waiting for resumes to flow in, reviewing and pre-processing them and passing a few to the IT department lead for in detail review and conducting a job interview.

Now HR learned that IT is working as DevOps team. Due to a misunderstanding in wording and methods, they now start looking for DevOps engineers. But what should a DevOps engineer be capable of? Should it be more development skills or system engineering knowledge?

In general an organisation doing DevOps in IT has specific needs for specific specialised knowledge. Besides this - as the different IT sub departments now have to strongly communicate with each others a new skillset gained even more importance: soft skills like communication and willingness to adopt.

Another item we saw in the past was IT department not allowing their team members to talk about the technical setup or their work. This has changed drastically as more and more companies lack sufficient staffing, leaving positions open for a very long time.

This is where HR MUST jump in and take over responsibilities.

It is about teaching, training and talking which is of high value for HR to get more resumes so they are able to fill open positions faster.

HR must allow (and insist in fulfilment) team members to attend conferences as speakers or even run local meet-ups where people with similar mindset gather.

DevOps and Finance

As IT now acts as a department based on DevOps principles they will try to move from slow to manage, self hosted systems to some cloud concepts. Especially when using public cloud providers, the collaboration with Finance is of high importance.

Finance for example differentiates between capital expenses (CAPEX) and operational expenses (OPEX). Ask any technician regarding the differences and he will not know.

Even when IT says that public cloud costs can be more easily predicted upfront, Finance might ask for another solution. Why?

On premise own hardware is usually billed as capital expenses, whereas public cloud is operational expenses. Moving all costs from CAPEX to OPEX might not be financially the best solution from tax perspective - especially when your cloud costs grow to a high volume.

Always try to explain Finance what you want to achieve and ask for their feedback on IT plannings.

Besides this: Finance and procurement can even help you in negotiating better terms with your cloud provider. This is especially if you are high volume user.

DevOps and Management

The most difficult part is DevOps and their managers. In general there are two approaches on how to go for DevOps methods in departments:

• top-down approach
• grass-root approach

Within the top-down approach, top level management makes the decision that teams must work according to DevOps methods. Now it is the top managers responsibility to find and support staff which would like to take part in the migration and to convince staff which objects to the upcoming changes.

This is different from the grass-root based DevOps implementation, where teams decide for themselves to go on the DevOps journey. Here the teams must at least ask for clearance to run a test. The team is responsible to deliver results fast, usually by going for low hanging fruits and showing the management that the approach is worth to spend more time and money into.

But how about the mid management?

In older times the mid management was responsible to ensure top level management goals are achieved. They had to look carefully for proper KPI and sometimes needed to push pressure on teams when positive results where in danger.

Within a DevOps organisation the mid management gets a new focus. They are responsible to remove obstacles from the team, allowing the team to concentrate on their work and not do to many unplanned work.

They must start seeing themselves no longer as bosses, but as leaders. They must ensure high motivation within the team and take care on high learning process by coaching senior people to train junior staff.

Conclusion

DevOps is not purely a technical way of collaboration. It affects a company organisation as a whole. When going the DevOps approach it is highly recommended to ensure that every department has the data it needs to help building success without loosing money or resources.

Martin Alfke