Sometimes you just need to stop and contemplate Larry Ellison’s comment about the computer industry in general and cloud computing specifically.
“The computer industry is the only industry that is more fashion-driven than women’s fashion. Maybe I’m an idiot, but I have no idea what anyone is talking about. What is it? It’s complete gibberish. It’s insane. When is this idiocy going to stop? ―Larry Ellison
Cloud computing and DevOps are certainly taking the world by storm with promises of transforming the way that business will access and use technology. Cloud computing represents the consolidation of compute resources inside the data center and the use of all applications and infrastructure outside the data center. DevOps is transforming the processes around delivery of applications and data to its user base by instituting more automation and collaboration between the parties responsible for building and deploying.
When combined, businesses can successfully implement a design, build, test, stage, deploy and operate process that has the ability to use various infrastructure and application platforms. In turn, businesses can use this process to more easily implement disaster recovery, high availability and greater scalability in the most economically appropriate manner.
Make no bones about it, I am a believer and an evangelist of this approach. That said, I’m also a pragmatist and believe that the hype needs to be tempered. For example, there has been significant hype around the new Docker technology. Docker is an open source project backed by a commercial company of the same name. Docker enables applications to be containerized so that they can be packaged and reused across platforms. If you read the reviews, Docker is the greatest contribution to virtualization since the emulator and going to revolutionize the aforementioned process I defined above. After getting hands on with the technology, which Docker admits is still not ready for production enterprise deployments, what I found was a very good technology for homogenizing Linux distributions. However, it doesn’t operate on Solaris, Windows or AIX. Yet, the Docker fanbois are out in force diminishing the value of automation tools, such as Chef, which can operate across a heterogeneous environment, such as the ones you would find in any Fortune 2000 business.
My point is that the speed and velocity with which cloud computing and DevOps is penetrating IT creates a vacuum that is filled with inaccurate and questionable information. Business velocity is a metric that is used to measure the ability of a business to absorb the many changes that seem to follow adoption of cloud, DevOps or both. Business velocity is comprised of three key elements:
- The desire of the business for IT to change
- The range of time required to fully embrace and deliver based on a change
- Competitive pressures due to industry events and competitors
While it may be advantageous to implement the build-to-operate process, it may not be pragmatic in the current business cycle. For example, retailers cannot absorb significant changes like this three months prior to the Christmas shopping season. Banks cannot absorb changes of this ilk three months before year end close. Hence, in these situations the range of time is limited to achieve training and implementation to achieve this goal. So, it could take upwards of two business cycles to facilitate getting the right resources in place and then implement the proposed changes. Hence, their business velocity is constrained by these factors.
That said, many retailers are in a struggle to compete against online retailers and specifically the giant, Amazon. Two years is two years too long to implement changes that will allow them better inventory control, better customer experience and the agility to drive a brick and mortar retail chain in a manner that competes with an online only presence. For these businesses, competitive pressures override the constrained business velocity and force the business to absorb these changes much more quickly.
While this is seemingly common sense, there are many businesses that fail to stop and take account of their business velocity before engaging in projects that use cloud and DevOps. The results are often less than stellar because they may get interrupted by competing priorities, lack of appropriate time and/or resources or simply the hurdle created by the parts of the business that are risk averse and don’t see value in this change. The latter happens a lot more than people realize in large organizations. Individuals often put their own concerns for their roles and stature above the needs of the business.
A little pragmatism goes a long way. Sure, everyone wants to be part of the cloud and DevOps train because as Larry stated, “…we’re more fashion-driven than women’s fashion.” It is imperative upon management to take honest accounting of your business’ velocity as a means of tempering how and when you will embrace these technologies in your own organization.