There’s a reason we so often use the word “journey” when we talk about DevOps – it is a critical aspect to a practical approach to DevOps. While we focus a lot on culture in the DevOps community, as I have previously said, culture is an output, not an input; it is the destination, not the journey. By contrast, the set of ‘best-practice’ application delivery methods that improve communication, collaboration, and integration between development and operations are the ongoing journey that drives this transformation for continual growth and improvement, and helps us reach the destination.
Which leads to the question for this next article in the Enterprise DevOps Q&A:
Q. What is the Ultimate Endpoint of Enterprise DevOps?
My initial reaction when asked this was to wonder whether the DevOps journey even has a defined endpoint. While many might say ‘culture change’ is the destination, many others would say there is no ultimate endpoint.
However, for enterprises especially, with their rigorous set of annual, quarterly, and even monthly goals and metrics (and associated performance reviews, bonuses, stack ranking, etc.), it is difficult to absorb such boundless activity. Larger organizations often need, if not one specific endpoint, at least multiple SMART waypoints along the journey.
If we follow through on the journey analogy, using CAMS (Culture, Automation, Measurement, and Sharing) as a rough roadmap, we may start trying to change the culture by removing structural barriers to collaboration, or attempt to shape new sharing behaviors. For large enterprises with goal-oriented metrics, automation is happening further down the road – which makes it a worthwhile next waypoint for organizations that have started their journey but are asking “What’s next?”
Waypoint 1: Release Automation
Release automation is a key technology that integrates dev, test and ops at that precarious gap between them – code release. Release automation solutions work by modeling components (e.g., images, packages, source code, configurations, etc.) of the development, test, pre-prod and production environments for each stage in the application release life cycle, and then fully automating the deployment and promotion of changes across those environments.
This is important in DevOps because in enterprises where release automation does not occur, dev and ops (and/or test, QA, staging, acceptance, etc.) staff have to perform these release steps manually. This not only limits their productivity and pushes out application delivery dates, but is also highly error prone.
Here’s an example from a recent case study by Enterprise Management Associates (disclaimer: I worked for EMA a long time ago and think they are excellent people and very strong analysts). During the Christmas season, a consumer electronics company’s website failed to perform as large numbers of customers logged on to configure and provision their new home entertainment systems. The company deployed a cross-functional “WebOps” group to investigate the problem, which was occurring within their software deployment processes. In short, a lack of standardization made it possible for code, configuration or process errors introduced during deployment to create flawed execution environments.
The company responded by implementing a release automation solution that can execute a given workflow and configurations automatically, so each environment mirrors the last and errors are reduced or eliminated. As a result, the company has moved from a manual deployment method, where IT staff had to execute multiple scripts in sequence by hand, to an automated one in which IT can “deploy with a high state of reliability in 15 minutes with few adverse after-effects.” This allowed the company to standardize its deployment processes, improve the consistency and reliability of its website and ultimately meet the needs of its customers and vendor partners.
Waypoint 2: Continuous Delivery
Automating these handoffs is a great waypoint for enterprises to measure their journey. It is also a great starting point to the concept of continuous delivery – end-to-end application delivery that combines an ecosystem of people, processes and technologies into an automated, iterative, ‘assembly line’. In such a scenario, release operations build on release automation to integrate and orchestrate promotion across environments, enabling predictable, monitored and measurable continuous delivery from development to production.
At a high level, development involves four phases: planning, building, testing and releasing an application. When an organization achieves continuous delivery, every technology and people process that can be automated between these phases is, so for example, development data from a release automation tool could be fed into a portfolio management solution, which would help automate approvals and future planning phases. In addition, if you used shared services in composite architectures, each team didn’t build the same thing over and over. You built it once and all shared it.
Then, as iterations occur and the portfolio management tool amasses more and more data, IT leaders will see first-hand how different methods led to better results (e.g., when this technology was used, the project was delivered X% faster). And of course, this kind of real-time data can be used to make better, more nimble business decisions that enable companies to differentiate and be more reactive in the marketplace. This is often exactly the type of intermediate measurement that larger enterprises need to justify the changes they are making; to justify the journey, with real business metrics.
DevOps: A Continuous Journey of Continuous Improvement
Returning to the question I posed at the beginning of this blog, I can tell you that neither release automation nor continuous delivery are the endpoint of DevOps – but they are certainly significant milestones to shoot for on the journey. So if they’re not the answer, what is?
To be perfectly honest, I’m not sure DevOps has a concrete endpoint. As the cliché goes, it’s more about the journey than the destination. As I have written in previous blogs, DevOps is all about delivering high-quality applications faster and at lower cost. As long as you’re continuously improving in that direction, the endpoint really doesn’t matter.
