Plutora Blog - Deployment Management, Release Management, Test Environment Management
What is Enterprise DevOps?Reading time 9 minutes
By now, most of us are familiar with what DevOps is — it’s a culture that brings people, processes, and product together to deliver quality software faster, with the end goal being to deliver more value to customers.
Scaling DevOps in large, highly-regulated enterprises presents unique challenges. Generally, these challenges involve things like monolithic systems, legacy software, manual workflows, and other issues related to large organizations that are, due to their size and age, inherently more cumbersome and slower to adapt.
In this post, I discuss how DevOps fits into the enterprise and what release managers can do to adapt and extend DevOps to meet the challenges present in larger businesses.
What is DevOps?
To understand what DevOps is, you have to understand the fundamental disconnect between development and operations. Development teams create and change software while operations teams are tasked with ensuring the stability of systems they maintain. The accepted metaphor was put forward by Andrew Shafer in 2009, and it posits that there is a “Wall of Confusion” between Development and Operations.
Businesses have two competing motivations: delivery and stability. The business needs to be able to deliver software changes frequently while also maintaining 100% availability for the end-user. Traditional approaches to IT emphasize a strict separation of concerns between Dev and Ops, forcing the business to choose either delivery or stability. You can either deliver software changes constantly and sacrifice stability, or you can emphasize stability and make it next to impossible for software to change.
Some define DevOps as a set of tools and technologies, but DevOps (like its cousin Agile) is more commonly characterized as a set of common approaches and shared values:
- More Frequent Releases – DevOps teams strive to do away with infrequent, ceremonial releases and move toward a model more closely aligned with Agile software development. In some organizations, this means continuous releases.
- Emphasis on Automation – DevOps teams use end-to-end automation for everything. A DevOps project might enable development teams to perform self-service deploys using tools like Chef or Puppet.
- Shared responsibility – DevOps teams don’t view releases and deployments as someone else’s responsibility. When software is released both development and operations should be collaborating across Shafer’s Wall of Confusion.
DevOps (like Agile) defies easy explanation, but those who practice it can recognize it. While I don’t think it makes sense to define DevOps as a set of tools, there are several that are associated with the movement, such as Chef and Puppet. Similar to Agile, it’s also easy for organizations to adopt components of the approach a-la-carte.
Challenges in an Enterprise
First, let’s define what we mean by Enterprise. We’re not using this as a catch-all phrase to talk about all businesses; when we say “enterprise” we mean it. These are companies like international banks moving billions a day or massive retailers tracking inventory in the hundreds of billions.
In these environments, a good metaphor to describe the difference between Development and Operations is a satellite. Development groups are busy manufacturing satellites in a hangar while operations is responsible for maintaining these systems in orbit.
In these enterprises the following concerns are a given:
- Change Control – There is a change control process for a release and it needs to be completed for every change, no matter how small.
- Approval Gates – The DevOps promise of self-service deployments driven by development on-demand may be impossible. There is a release team.
- Massive Environments – If your software deals with billions of transactions or customers, it is very likely that your environments are similarly massive and likely not amenable to rapid automation with tools like Chef and Puppet.
- Orchestration with Multiple Groups – Large organizations tend to have releases across multiple departments at the same time.
Scaling DevOps to the Enterprise: Enterprise DevOps
DevOps as commonly practiced has some blind spots in the previous list.
- DevOps and Change Management – Someone practicing continuous deployment may view a tool like BMC Remedy as a waste of time, but to an application support team or a network operations center, this information is critical.
- DevOps and Approval Gates – Application teams should be able to automate and control deploys without lengthy delays and process, but at a large organization developing high-risk software, governance gates are there for a good reason.
- DevOps and Non-automated Environments – Developers can be given the reigns to spin up and spin down cloud infrastructure, but the organization is often resource constrained for infrastructure and it can take days to prepare and qualify a new environment.
- DevOps and Orchestration – DevOps emphasizes single-team efficiency from a developer’s perspective, but it doesn’t account for some of the cross-team orchestration challenges that happen with the largest software releases.
From the perspective of IT, a DevOps project gives off all the signs of increased risk and maintenance. In the next section, we define what it takes to bridge the gap between DevOps and IT.
Enterprise DevOps Strategy
Yes, DevOps is about automation and technology, but it’s mostly about communication. It’s about making communication between development and operations non-adversarial and less formal. Enterprise DevOps is a bit different. You can think of Enterprise DevOps as “DevOps when your IT department is still focused on ITSM and ITIL.” Enterprise DevOps shifts some of the infrastructure automation requirements out of the Dev side of DevOps and into the Ops side of DevOps.
Center of Gravity Shifts from Development Release Management
With efficient Enterprise DevOps, your development teams are still delivering early and often, they may still be using Puppet and Chef to automate deployments, but they are taking an extra effort to address the information requirements of the IT group and they will continue to be entirely disconnected from the production deployment process. Whereas the center of gravity in a smaller DevOps approach is squarely on the side of developers, in Enterprise DevOps the responsibility for coordination is with the release managers.
In an Enterprise DevOps approach, your application teams should be standardizing on a common set of automation tools and approaches. It is impossible to scale DevOps to the level of a large enterprise if every team and application group feels enabled to craft a unique interpretation of DevOps. Within each group, it should be difficult to tell the difference between DevOps and Enterprise DevOps. For a developer, the experience should be the same as code being delivered to a shared reference system for testing on a continuous basis.
Enterprise DevOps Respects Change Management
Enterprise DevOps is a form of rapid software delivery that still needs to respect the formalities present in a large organization’s IT department. If operations use BMC Remedy or ServiceNow to model a release as a change request, your release process needs to comply with that policy. While many view DevOps as getting rid of unnecessary process, Enterprise DevOps preserves that formal interface between development and operations and isolates both sides from heavy process-oriented interactions.
Enterprise DevOps Reduces Risk Associated with Environments
When you practice Enterprise DevOps, you train your operations group to use DevOps tools to automate and standup common environments for teams to use interchangeably. For example, if you have 40 groups in your company all developing applications on Apache Tomcat, an Enterprise DevOps approach to this would be to have the central IT group create a set of Puppet or Chef scripts to be used as a baseline for other groups.
In an Enterprise DevOps approach, your operations teams supply a common set of virtual machine (VM) images or environments that development groups can automate. In a smaller DevOps approach, your development teams would be writing tools to automate deployment to production. In an Enterprise DevOps approach, your applications teams will stop at testing and staging environments, and operations will still be responsible for translating the automation work done in staging to a production environment.
Enterprise DevOps Enables Orchestration
When all teams have standards on the same flavor of DevOps and release managers understand that software deployment and releases are standardized, they can more accurately predict timelines. In a large organization, this is critical for on-time delivery.
Plutora Enables Enterprise DevOps
When we created Plutora we did so with the idea that bridging the information gap between different groups involved in a release reduces the friction and risk associated with releases. If you’ve been involved in a big release, you’ll appreciate that releases are all about conflict – conflicting release timelines, a conflict between development and operations, and conflicting tools used to model releases. If you can understand and anticipate these conflicts you can manage them and releases can be more predictable.
The DevOps approach is about breaking down the boundary between Development and Operations and aligning both groups to meet the same objectives. If the Operations group still has to perform some of the procedural tasks associated with a heavy process like ITSM, you can still have a development team that targets a DevOps-style deployment that retrofits this new process for the interface that the IT department expects.
Plutora can do just that. It provides an interface to development teams focused on DevOps technologies and isolates them from having to deal with ITSM. You can configure Plutora to feed information from JIRA and other tools directly into tools like BMC Remedy. Plutora is the tool that will give project managers the tools they need to apply the right kind of pressure on operations groups to adapt to development teams using Agile and DevOps-style automation.
With Plutora, we’re trying to address the real challenge of deploying software – the communication gap between operations and development. Think of Plutora as the tool that tears down Shafer’s Wall of Confusion and replaces it with a tool that can give you great visibility while reducing risk.