If you see “DevOps” in our application name, that means we have to explain that term properly and we’ll do, but from a bit different angle. Lets see what DevOps is from business perspective.

Common name

First of all you should know, that DevOps have no clear definition. Yep.

Most often, DevOps is characterized by key principles: shared ownership, workflow automation, and rapid feedback.

And also, you’ve probably already heard “mantra”:

DevOps is not a role.

You can check great article on DevOpsKube website - What is Devops? What Does it really mean?

If you want summary:

DevOps is a culture or a philosophy aiming to bridge the gap between the development and operations teams to improve productivity and collaboration by automating infrastructure, code deployments, and continuous monitoring of applications.

Whats wrong with that defenition? It’s technical. And absolutely ignores business!

Pretty often engineers forgetting that “all that IT” is not about IT, it’s about business. We’re forgetting that all that wonderful stuff we’re doing, its not “because we can”, its because some business, which doing money, need it.

Business don’t care

It will confuse engineers if I would say that all that “automation”, “operations”, “development”, “monitoring” are not necessary from business perspective of view.

Business DONT CARE about it, because business is about selling tickets or making sport bets or selling financial services, etc. Its not about IT, at all.

You heard or faced such a situations when some process in a company is all manual and/or require a lot of people to do it or takes too long? You feel that process could be automated and if will save a lot of man-hours, but no one want’s or plan to automate it. And its OK.

Yep, you heard it right, its OK. Until its time to optimize costs or process slowness affects business needs, its ok. Business don’t value automation only because its automation.

What is DevOps from business perspective?

Lets try to make definition of DevOps in non-technical way as much as possible.

*DevOps *— is a service of development and adoption of tooling, which helps business to maintain software products on all stages of life-cycle in a self-service manner.

Sounds not much simpler, right? Lets explain each word here.

DevOps

After series of large personal data leaks, business realized, that they have to spent more resources on security hardening, as a result DevOps turned into DevSecOps… Last few years new areas appearing, where “Ops” should be connected with something: DataOps, FinOps etc…

So lets stop on DevOps term.

Automation is not a goal

Pretty often, when people trying to define what DevOps is, they falling into ‘enumeration explanation’: “you should do CI/CD, configuration management, use Cloud Copmuting, Ifrastructure as a Code, endless-list-here”.

As a result we have a mess in DevOps term definition… Not all projects need Cloud Computing (hello mainframes), when you’re saying “CD” you mean Continuous Delivery or Deployment (?), not all projects need infrastructure (hello Kubernetes ) and so on.

In the middle of all of that lists stays AUTOMATION. It requires special article about it, but yes folks, DevOps is not about automation, not each automation is done in DevOps way, not every DevOps activity could or worth to be automated.

DevOps is a service?!

Yes. DevOps engineers (Platform Team, DevX, SRE, etc.) are providing service, clients for that teams are entire company or software product team, which maintaining application. Or any other person who want to do Ops-related tasks, without knowledge in various “-Ops” areas.

What’s confusing me in many DevOps departments, that people thinking “they doing job”, folks NO!, you are providing SERVICE. You are serving to a business needs.

That small twist in mind blocking many good engineers from being successfull in their career. Soft skills in DevOps became more valuable in many cases than technical ones.

What does “development of tooling” mean?

Tooling its set of simple user interfaces, which helps people to make complicated things related to software life-cycle, without deep knowledge in SRE/DevOps practicies (or other technical areas). Yes, tooling is about “hiding complexity” by simple UI. “Business like pictures”, not because its stupid, but because technical details are not about business.

By other had this new tools creating new idioms for people who are not deep in technical details, but now can communicate and collaborate about it.

What does “adoption” mean?

Usually we have company-wide DevOps tools which requires adoption on an product team level, for example we have Splunk for the application logs search or AppDynamics for apps monitoring and troubleshooting, but not all applications/teams using it, such tools have to be adopted first, teams trained to use them.

What does “self-service” means?

Self-service means, that person or team using your tooling own process from end to end. DevOps team still responsible for that tool, means it should work as expected, but how that tool used they don’t care. Usage is absolute responsibility of product team, if tool works correctly, all consequences is your problem.

That twist in mind dramatically changes rules in collaboration between DevOps team and product team. Pretty often Ops teams suffering from situations when Ops have to do “all the magic” for developer and his issue will be fixed. Doesn’t matter if developer forgot to comment proxy usage or did not configured networking correctly for his server, if there is a tool which he can use to fix issue himself. “Sorry man, you own it!”

Summary

Huh, it was a long text. Short summary:

• DevOps is a service

• DevOps engineers (of all kinds) are serving to a business

• Automation is not an end in itself

• Self-service is a key for a healthy communications between Dev’s and Ops’es

What were not covered and require additional articles:

• When you have to automate something, when not

• How to determine if something done “in a DevOps way” or not

• DevOps from a solution became a problem. Why and How?

Support Us, Contact Us

If you like this post, support us, download, try and give us feedback!

Give us a star 🌟 on GitHub or join our community on Slack.