The cost of free software is often overlooked, when adopting new innovative technologies.
The reality is that no software is free, without costs, if one needs to use it in an enterprise-grade production environment.
In this article, I’m looking into the costs of using low-priced or free technologies, especially when fast-tracking POCs into production to incorporate emerging innovative technologies.
An innovation tale
New technology, a unique opportunity
A new piece of technology is just emerging; it provides significant innovation, it is free and open-source, and it is doing precisely what the developers wished for. They are really hyped about it.
Let’s do a POC
After using the new technology in a hobby project, a developer is doing a demo with the managers.
“This piece of technology is a perfect fit for what we need, and it is free!” he says.
The demo impresses the managers; it could provide serious value to their organization. “Let’s use it; let’s do some more experimentation and build a real POC using this technology”, they say.
The POC is launched and sprint after sprint the demos further impress the management and confirms their hopes and expectations.
Let’s take it to production
The POC proves to be a significant success. The benefits of the new technology are so obvious: faster development and better results. “OK. Let’s move it to production!”, the management decides, and here it goes into the production environment.
Trouble in production
However, after delivering the POC to production, trouble arises.
There are many failures in production. It turns out that the emerging and innovative product is not very stable. However, its instability is not their primary concern; the new technology was not designed for the rigours required for an enterprise-grade environment, so, when failures occur, it is difficult to understand what happens, to find the root cause of the problem.
The operating and L1 support staff are often unable to find and fix the problem. To resolve the production interruptions, they often require escalating the issues to L2/L3 support, to developers, causing high MTTR (Mean Time to Repair), and consuming time away from development activities.
The results are not as expected. Development and their management missed accounting for something very important: is the new technology fit for the production environment?
Was that fiction?
People might proudly say that this is not happening in their environment. However, this is a common situation encountered by Workload Automation vendors in their sales journeys when their prospects or customers adopted DevOps or Big Data.
The cost of free
Let’s clarify first that sometimes, rushing an unstable solution to production is desirable. When the cost of delaying is higher than the cost of rushing, for example, when the first mover advantage is relevant. In these situations, organizations are aware of what risks they are taking; they are usually planning to deal with eventual production failures and to release fast a new improved and stabilized version.
However, when that is not the case, organizations need to be mindful when adopting new technology into production, especially as most POCs are purposely ignoring the requirements for operating in a production environment.
Missing to consider the fit of the new technology for the production environment, could lead to two main costly side-effects:
- Unexpected costs to bring the newly deployed innovation to the level of production rigors
- Unexpected cumulated costs for SLA penalties and for the repair effort to address inefficiencies, failures, and workarounds until a new solution is released in production to the level of production requirements
The cost of these two undesirable side effects could easily wash out all the benefits of using a free piece of technology, without even taking into consideration other collateral costs.
When planning and executing innovation projects, Gartner predicted in 2016 that for “every $1 enterprises invest in innovation will require an additional $7 in core execution” (Gartner, 2016). Knowing this, should be a strong motivator for management to avoid overlooking the potential costs of free software.
What does it mean? Should we avoid free open source technologies?
Not at all.
However, organizations need to find a way to absorb fast new innovative technologies without risking the stability of their production environment.
In a future article, maybe as part of the “IT Automation – standardize it!” series, I’m going to provide some suggestions on how to enable organizational agility and adaptivity, and minimize the risks of early technology adopters.
