Why we don't need Devops

I am a strong believer in the fact that we don’t need Devops. We’ll at least I believe we shouldn’t need Devops. And I’ll tell you why.
Devops is a set of methods and procedures that is geared towards integrating the Operations specialist into the development team. This is done to the ends of developing an integrated software product consisting of the end-users application and related infrastructure components like middleware and operating systems.
Let’s take a closer look.

We are clearly talking about infrastructure components. But what is infrastructure?
Wikipedia tells us the following:
“ Infrastructure is the basic physical and organizational structures needed for the operation of a society or enterprise, or the services and facilities necessary for an economy to function. The term typically refers to the technical structures that support a society, such as roads, water supply, sewers, power grids, telecommunications, and so forth. “
So we can safely establish that infrastructure is a facilitating entity, right? Something we all share and use.
The most commonly thought of when we talk about infrastructure is a traffic system and roads in particular.
Roads are everywhere. They are generally considered important for the economic and social structure in a country. Roads serve a very straightforward purpose, to facilitate transport of people and goods across a nation.
A road also has constraints.  The vehicles used to mitigate these roads are bound by constraints. Most of these constraints are measured in dimensional boundaries like length and width but there are others less obvious like indicator lights or visibility.
These constraints are in place to create certain uniformity. This uniformity is very important, because it guarantees that anyone can use the infrastructure after taking notice of the common rules (getting a drivers license).
A manufacturer of, let’s say, cars knows upfront what the constraints and limitations are for the transport infrastructure of the country or area he intended to build a car for. No designer will design a car that won’t fit the road by making it 5 meters wide. In the transport business it’s that simple. You build your product to fit the infrastructure and you can do that because you know upfront what the constraints and limitations are.
Now let’s take a look at ICT-Infrastructure.
A company’s ICT-Infrastructure is sort of the same as a Transportation infrastructure. It facilitates applications and takes care of the data transportation throughout the company.
Just like any Infrastructure it has it’s constraints, like the techniques that can be used or the security measures that have to be taken into account.
This is where the comparison stops and trouble begins.
For some reason software development for years has been delivering applications that demand alterations to the ICT infrastructure. And operations has been forced to make those alterations, leading to massively incoherent collections of it devices marked as “ infrastructure”.  As a result maintenance cost of ICT has skyrocketed. And even more important the implementation speed of new applications has plummeted.
Who’s to blame for that??
I know for a fact that the general consensus that among operations personnel is that application developers are to blame
I know this for a fact because I’ve worked as an operations engineer for several years.
But it’s not true.
After having worked with software developers for quite a while I now strongly believe that no developer in his right mind will develop an application if he knows upfront that it is not going to work on the company’s infrastructure. Just like no car manufacturer is going to produce a car that’s not allowed on any or all parts of a countries infrastructure.
So if developers aren’t to blame, who is? Well there is only one possible guilty party left: Operations itself. And the reason is simple: For not telling the developers upfront what the constraints of the infrastructure are.
A typical operations department is an ad hoc organisation that responds instead of a proactive one that communicates. Making itself into a victim of the situation rather than a partner to development. They are used to changing the road not the vehicle.
So if we communicated a bit more, we wouldn’t be in this mess, and we would most certainly not need something like devops. But most organisations are and so we need devops.
Next to the fact that devops is a very practical method that focuses on delivering functional software on working infrastructure, it’s a method that enables hands-on practical communication between operations and software development.
For operations it’s a way to partially get back into the driver-seat. On the other hand Software development will probably get their software in production a lot faster.
And who knows what kind of innovations may derive from it ?