Should every business function have an Ops extension?

I n the new world of digital business, we are all connected. Email, social media and more formalized enterprise collaboration platforms all work to fuse our respective job roles and line of business functions into one harmonious torrent of effectiveness. Except, it’s not quite like that and we still find ourselves dragged into endless strategy meetings where the most productive element is often a factor of who sits nearest the window for fresh air.

The technology function has long sought to counter the essential disconnects in every business that still exist, despite social platforms… and in spite of strategy meetings.

As a result, the software application developer (Dev) function formed a working methodology to connect more closely with the operations (Ops) administrators that keep our IT up and running once the software has been created and deployed. Hence, the portmanteau combination term DevOps arose.

But if DevOps is a methodology, a workplace culture and a mindset for mutual work challenges that stems back to the operations backbone, then shouldn’t every department have an -Ops extension? Shouldn’t all line of business functions run with an appreciation for the engine room? Is this the way forward — or its EverythingOps a convoluted proposition that ultimately will trip us up?

What does operations do, really?

To clarify what the operations department actually does. These are the DataBase Administrators (DBAs), the systems administrators (sysadmins) and other auxiliary technical engineers that will implement security protection controls plus additional technology layers including data analytics and so on.

In the world of EverythingOps (let’s call it EvyOps and coin the term here) we find a crowded marketplace, that is – every department and specialism wants to slap its DNA into operations in order to help disseminate its higher mission.

Machine Learning (ML) specialists are already calling for MLOps to propagate the spread of Artificial Intelligence functions into every user’s app. Technologists working on ‘chatbot’ technologies want to see ChatOps happen so that chat tools appear as a part of every app on every desktop and device. CloudOps champions the use of an increasingly abstracted and virtualized IT functions that run on cloud services — and so on and so on.

Productizing automated processes

What all these Ops extensions have in common is a desire to build a method for ‘productizing’ one core function of a business. Once a function is productized it can be encapsulated and automated into a process-driven framework that the enterprise itself can run on. Well, that’s the theory on paper at least. In reality, business is often a lot less easily compartmentalized, but digital transformation is getting us there.

“The deeper truth here perhaps lies in the fact that DevOps should always have been about the whole business because in reality DevOps doesn’t start with Dev and doesn’t end with Ops,” said Andi Mann, chief technology advocate at data analytics company Splunk, Inc.

Mann points to the reality of the situation saying that it’s not just a world of Dev and Ops in IT i.e. it also functions including program management, quality assurance, user acceptance testing and more. Equally, outside of IT, Mann says that there are critical business teams like training, marketing, documentation, sales, pricing, accounting, customer service and more. All these functions either drive demand for new software capabilities, take those new capabilities to market, or both.

Just not cricket, or DevOps-ish

“With so many stakeholders in software application delivery, ‘DevOps’ is really a huge misnomer. It is largely unfortunate that the name stuck because now many people don’t look for collaboration and alignment very far beyond Dev and Ops. If all you do is streamline Dev and Ops, you are just moving the bottleneck and creating pain for other teams – which, in itself is not very DevOps-ish, really,” said Splunk’s Mann.

Head of marketing at UK and Europe headquartered Montreal Associates is Faye Lewis. Agreeing that ‘just’ Dev and Ops was always too narrow a vision to build even digital businesses foundations on, Lewis is an advocate of SalOps (sales and operations) and an Ops injection for finance in the shape of FinOps.

“Sales, however, is still very much a role where people are reactive rather than driven by long-term strategy – that’s why we’ve not seen the rise of SalOps in a real way. In sales departments, you have an emphasis on building long-term relationships with clients, but because these clients have problems to be solved on a day-to-day basis, the strategies needed to be successful in sales are very much day-to-day as opposed to long-term,” said Lewis.

Lewis argues that the problem often comes down to mindset. Sales, in particular, is a place where people who may have been doing the same job for ten years, without the real impact of technological change disrupting the way they work. She asserts that convincing essentially non-digital workers that change is innately better than the status quo is the challenge.

If this is all too many -Ops for you to stomach, take some solace in the suggestion that the future is a place where we enjoy NoOps. According to TechTarget, NoOps (no operations) is the concept that an IT environment can become so automated and abstracted from the underlying infrastructure that there is no need for a dedicated team to manage software in-house.

The future is a place with a more tightly embedded Ops operational function in everything we do and touch. How we engineer that process might just be what all this digital transformation is actually all about.