Learn why business leaders need to deeply embrace DevOps, a practice designed to bring efficiency, reliability and predictability to the development of software.
Every business is, or is becoming, a software-powered business. Yet most companies lag in the adoption of modern, agile development and deployment practices, practices that augment your business continuity strategy and fuel faster product-market fit. Software and application modernization plans need to include provisions for DevOps; ignore at your peril.
DevOps is a fairly recent term that has taken deep root within the application development and deployment community. Or rather, recent in the consciousness of those on the periphery of this transformation, as Patrick Debois is credited with coining the term as far back as 2009. But DevOps is usually lumped in with “being agile” and, sadly, misunderstood.
Gaining an understanding then and realizing the potential of DevOps is my goal here. Once that is established this will lead, I think, to a better understanding of the rationale behind much of the OpenEdge 12 roadmap and strategy. The innovation and evolution, enabled by DevOps, I hope, will inspire you to think of your own business or product investments in a similar light.
To the uninitiated, an ask to define the term DevOps usually conjures up descriptions of the legendary developer operations engineer, forever watching over the health of a SaaS application like an omnipotent god ready to take corrective action whenever anomalies are encountered.
To others, it is simply the newest job title of a build/release engineer, helping get code into production. And these descriptions wouldn’t be wrong – they are simply myopic, very small facets of the overall DevOps value proposition.
The reality is that DevOps is a practice, designed to bring efficiency, reliability and predictability to the deployment of software. Yes, DevOps is about moving code from development to production. But those who embrace DevOps first realize that building and deploying Version 1.0 of the software is merely the start.
The practice of repeatedly deploying reliable software is a long-term undertaking (assuming your product is successful). And therein lies the business problem. Every time software is deployed, you’re essentially incurring a cost of production—the time it takes from code complete, through quality validation, and into the hands of sales—that is adding no value to the customer.
Yes, you may be providing your customer with a more reliable product through that process, but the customer already expected that. There is no incremental business value delivered beyond the implicitly set expectations. The longer and more inefficient that is, the more cost you incur that can’t be passed on (except in perhaps trivially competitive markets).
On the flip side, you can’t just cut corners and reduce spend here. Deploying poor-quality or broken software is a surefire way to negate years of customer loyalty and goodwill. Over time this will drive up churn, and in worst cases expose you to lawsuits, bad press and other general nastiness.
So, being efficient in the delivery of your software, while also delivering with high quality, has obvious cost and loyalty benefits. But what else is there?
You may have heard the saying, “release early and often.” The practice of getting frequent software updates in the hands of users creates a tight feedback loop. This allows you to act on feedback sooner and iterate to a delightful solution more rapidly.
And because you’re releasing more frequently, each release is smaller. This translates into less surface area to debug when things do go wrong, so you can spot errors much more quickly. Without an efficient DevOps practice, you can’t do this, hamstringing you versus the competition that can.
What do you do when one of your largest customers logs a severity-0/production-down escalation? If you have a mature DevOps practice, your team will quickly deploy an environment that exactly matches the customer’s, and immediately work on recreating and solving the problem.
When they’ve solved the problem, an update can be released quickly and repeatably. Without a DevOps practice, the team will spend days trying to mimic the environment, and they may struggle to recreate the problem because of this. The fix will be delayed, urgency and tensions will rise, tempers will flare.
One of the hardest aspects of software is figuring out just how to delight the user, to increase engagement and traction. With a mature DevOps practice and a modern application architecture, you can deploy experiments into production for a subset of your users and measure the impact.
You can deploy multiple experiments into production to different subsets and conduct multi-variant testing against them. Facebook has hundreds or thousands of experiments running concurrently at any given time.
The best software companies improve their product management practices by investing in a DevOps practice. They derive business growth from investment in DevOps.
It’s not just Facebook either, Optimizely does too. IBM recommends user experiments. Microsoft too (for a while now). Uber even automated their experiment cleanups.
Delivering the best platform on which to build mission-critical business applications requires supporting the latest innovations in software manufacturing processes. I am just touching on a few high-level benefits of DevOps, but I hope it provides a quantum of value to someone, that some reflection is derived from it, that it connects the dots between the technology and business impact.
While we may often refer to the roadmap at a feature or technology level—SonarQube support for code scanning, Gradle support for build and test automation, Docker support for containerization, and more—these are all in support of realizing the business value behind DevOps.
Investments made in DevOps are investments made in automation and efficiency, in customer engagement and customer satisfaction, and in market research and data-driven decisions. If you believe these business goals are as important as I do, then invest in DevOps.
Take a moment to learn about What’s New in Progress OpenEdge and hear what our partners are saying about how we have supported their business evolution.
See What's New in OpenEdge
Dion Picco is the Vice President of Product Management for Progress Core products. In this role, Dion combines his domain expertise with his analytical capabilities to make sure our products serve the needs of our customers and ensure that the voice of the customer is thoughtfully considered throughout product development. Dion was formerly the General Manager of our data connectivity business, where he played a pivotal role in establishing Progress as a world leader in data connectivity solutions.
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You have the right to request deletion of your Personal Information at any time.
You can also ask us not to pass your Personal Information to third parties here: Do Not Sell My Info
Copyright © 2020 Progress Software Corporation and/or its subsidiaries or affiliates.All Rights Reserved.
Progress, Telerik, Ipswitch, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.