In the movie Groundhog Day, Bill Murray plays the roll of Phil Connors, a regular Joe who wakes up each day to find out that he is reliving February 2nd all over again—and he’s the only one aware of the time loop. To take advantage of this phenomenon, knowing that there will be no long-term consequences to his actions, Connors seduces women, steals money, drives recklessly and even ends up in jail. The next morning, all is back to normal, and he starts his antics again.
Connors also repeatedly attempts, and subsequently fails, to get closer to Rita, a love interest of his. The combination of the same day’s repetition and Connors’ futile attempts set up the classic definition of insanity—doing the exact same things over and over but expecting different outcomes.
In today’s hyper-competitive markets, enterprise software development teams who suffer a lack of innovation find themselves stuck in their own Groundhog Days. In order to stay competitive and relevant, companies need to innovate faster and change to adapt to market demand quicker than ever before. Enterprises today compete on differentiated products and services and do so by adopting more efficient processes. Those that fail to innovate, change, or modernize and optimize existing applications will learn more than an economic lesson—they risk the demise of the entire business.
Rapid innovation is at the underpinning of the enterprise competitive advantage. Whether a change in process to your business applications, developing new products and services or consolidation/modernization of existing systems—the pace of innovation and quality of software released is the differentiating factor to enterprise success.
So, why is innovating so darn difficult? Here’s a hint; it’s all about development environments.
Technology is delivered through a software lifecycle that is often measured by cycle time, defined as the amount of time it takes for a feature to move from concept to customer value. In a perfect world, features move smoothly from concept to value. But, the reality is that with accelerated release cycles, quality suffers. An acceptable level of quality is always important prior to releasing an application to production, but low quality is often tolerated in an effort to decrease cycle time in order to get application releases out on time and within budget. Most enterprises that are trying to innovate faster are trying to adopt iterative development, agile, scrum, continuous integration, continuous delivery & devops in an effort to ensure quality while significantly decreasing cycle time.
Here lies the fundamental issue that plagues most organizations.
The anchor drag on cycle time is almost always idle time or any delay in the above mentioned processes. Removing idle time should be the focus of all application development executives, as the reduction of idle time is always within their control and enables them to reduce cycle time and accelerate innovation to drive the competitive advantage to the business. But, like Phil Connors, most enterprises do the same things over again and again, expecting different outcomes. The only change they may make is putting more people on projects, spending more on expensive on-premise infrastructure, and implementing idealistic processes—all in an effort to squeeze a few more days from release cycles.
Many enterprises fail to see that the single largest cause of idle time in software projects is shared environments. Typically on-premise environments for dev/test need to be scheduled, may not be available when needed and provide no value to keep around when not in use. While shared software project resources can include people, in high-priority projects, environments are generally what causes the greatest amount of contention.
All software projects require environments that typically include development environments, test environments, user acceptance environments and production. Each environment consists of four layers:
1. Infrastructure & OS
2. Software libraries to support the application
3. Application binaries
4. Application configuration files
Due to the sensitivity of the application to changes in any of the four tiers, consistency across all environments is critical to identifying defects sooner. When environments are not identical, idle time is introduced and cycle time is increased. Sharing environments for any software project will create idle time and disrupt the SDLC. As a result, innovation, velocity, and quality suffer..
Enterprises that leverage SaaS-based environments not only can eliminate idle time, and the developer time wasted managing and maintaining environments—they dramatically impact the time to delivery, and overall release quality. Enabling development teams the ability to self-provision, replicate, share and collaborate on environments as needed greatly removes the inefficiencies and interdependencies caused by environment contention.
One of Phil Conner’s most memorable lines from Groundhog Day is when he asks his buddies, “What would you do if you were stuck in one place and every day was exactly the same, and nothing you did mattered?” For enterprises that find themselves in a similar predicament, the answer is easy—start using SaaS-based environments for dev/test. Take advantage of the elasticity, scalability and on-demand access of SaaS-based environments. Enterprise grade solutions exist that address security concerns, provide self-service to development teams and complete visibility and control for IT over resource utilization. Believing that on-premise infrastructure is going to help you innovate develop, test, and release quality applications faster is pure insanity.