Nearly every business today relies on faster, innovative technology to succeed in the marketplace. How about the coffee you drink, or the movie you’re watching, or the phone on which you’re watching it? Name every business or walk of life. You can argue that technology serves to make it better. If DevOps helps deliver the best services and experiences to you, then should companies making the coffee, movies, and phones also make their own DevOps solutions?
I completely empathize with the challenges the developers and DevOps teams face in transforming a team or company from traditional development and delivery to an agile lifecycle. I experienced this firsthand at Trend. I led a business unit that acquired a SaaS company for online backup and storage; this young company updated and deployed code several times a day. It was painful to integrate their processes into ours. I wish ElasticBox had been an option then. I cringe when I consider the time and costs of lost productivity, wasted development time, and delays in getting to market.
Faster deployment nirvana
Every day, I speak to several technology companies. Speed is at the top of their mind. They all experience the pain of not deploying and delivering applications to the cloud fast enough. Most have some number of cloud applications, some customer-facing and many internal on both private and public clouds. To give you an idea of how widespread this pain is, see the 2014 451 Research report. The 451 Research team reported that more than 60% of businesses wanted to deploy more frequently.
But moving from agile development to agile delivery across an application lifecycle comes at a cost. Companies calculate the cost implicitly and explicitly. I’ve heard feedback from prospects who explicitly say: “I love your product, but I can build the same thing with my developers in xx country.” They usually have many smart development resources and tend to be born-in-the-cloud companies. Others tell me, “This is not our core competency. We don’t want to maintain a cloud application manager. We want yours.”
Build versus buy DevOps
At what cost do companies decide to build versus buy a cloud application manager from ElasticBox or one of our competitors?
- First, you have to answer this question: What is your company’s core competency? Do you really want to divert resources to build your own cloud application manager versus invest in your core offering?
- Second question: What is the urgency and need? If you have time on your side, taking a year to build your own solution may make sense. If you need a solution tomorrow, then what is the cost, in terms of market impact, competitiveness, customer satisfaction, of delaying a year.
Once you answer that, you calculate the total cost of owning (TCO) the complete lifecycle of build versus buy. These values must encompass all the phases of building and ownership: acquisition, operation, change management, training, ongoing maintenance and internal support. Time and time again, enterprises only look at the initial build or acquisition cost and fail to fully calculate the ongoing implicit costs.
Recently, I met with a VP of Engineering who had built a barebones deployment solution a few years ago. Now she bemoans the fact that the costs of maintaining a less-than-perfect solution is too much. Her TCO calculation included the developers, ongoing maintenance, workflow delays, meetings, support tickets, delayed product launches. Her decision to now buy is a no-brainer.
I’m not arguing that it’s always better to buy than build. But consider the factors — core competency, time-to-market delays, and TCO. We want enterprises to keep building great software that complements their core value proposition. When it comes to agile delivery, consider an experienced partner who handles the same problem for dozens of enterprises. Simplicity, flexibility and speed — those are the barometers of agile delivery success. So developers feel productive, applications deploy faster, and your customers relish the delicious cup of coffee as they watch Netflix on their iPhone.