Over a million developers have joined DZone.

I Wouldn't Start from Here: Understand Your DevOps Starting Point

DZone's Guide to

I Wouldn't Start from Here: Understand Your DevOps Starting Point

As the second entry in a series of blog posts, this article provides a roadmap for those beginning to implement DevOps at enterprise scale.

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

There is an old joke in the UK about a couple of city dwellers driving through the countryside and becoming lost. After several minutes driving around, they see a local farmer. Drawing next to him, they wind down the car window.

"Excuse me, could you tell us the best way to get to the nearest town?"

The farmer looks at them, nods, pauses, and says: "Well if I wanted to go to town I wouldn't start from here."

If you are introducing DevOps across a large enterprise you will probably have a lot of empathy for the farmer's view. Given an inherited technology estate, along with embedded process and practices, it is sometimes difficult to know where to start. You are also likely to inherit at least some vociferous individuals advising why current practices have to remain as they are.

We shall start by stating that it is a given that DevOps adoption revolves around creating a culture that provides support for autonomy and removing centralized command control behaviors. It is not delivering a raft of tools. That said, there is plenty of excellent content that details the concepts and behaviors required. We are not going to attempt to replicate that. Rather, in this post, we shall concentrate on providing thoughts and experiences on potential approaches to identifying an automation foundation to enable DevOps in a large established organization.

Create a standard taxonomy of capability

In large organizations, one of the key challenges is to ensure that a standard taxonomy is used. This assists in optimizing knowledge sharing and understanding the available solutions and experience in the enterprise. The Enterprise Architecture function should own the Enterprise Information Management (EIM) solution and it makes sense for this to detail the standard capabilities you are looking to deliver.

Defining these capabilities is critical. Technologists as a rule are better at defining solutions than requirements. By focusing on capabilities rather than solutions (or tool names) you drive a higher quality of debate. It is also easier to identify gaps. In a cross technology organization it can highlight surprising areas of strength. For example, the mainframe platform tends to have strong automated deployment capabilities which are often missed when continuous integration and automated testing is discussed.

Define your current technology stack

The next step after defining your capability matrix is to detail the current solution(s) in each capability space. If you are fortunate, you will have an EIM solution that is comprehensive, current, and already has all this information. It is more likely that your records will be — at best — partial.

In the first instance, focus on placing the current technologies in the correct categories rather than defining which solutions are valid and which are not strategic. If you can achieve a first pass quickly, this can start to drive discussions and decisions.

Stakeholder communication is also critical. While not normally a fan of duplication, you need to detail the solutions available to your engineers. Most EIM solutions are great as repositories but are not intended as communication media. We recommend an approach that enables your community to understand the options available to them within the organization. Create a page where this information is readily available. Content that you should consider linking from this page includes:

  • Capabilities
  • Solutions available for the capabilities
  • Precis of each solution
  • How to obtain access to the available solutions
  • Links to any training material
  • Links to vendor page
  • Links to social media content (stack overflow, internal blogs, and forums etc.)

A good example of an easy to understand presentation of capabilities and tools is the Xebia Labs periodic table of DevOps tools.

Figure 1: The DevOps Periodic Table of Elements

Finally, we should consider the gray market in technology. People across the organization are likely to be using solutions to problems which are not officially recognized or documented in the EIM. There may be solutions already in the organization that will add great value at larger scale. Conversely, potential solutions may have already been tried and issues identified. A culture that encourages communication and sharing of experience and information will enable you to deliver more quickly and avoid replication of effort. Enabling others to feel they can safely share information without repercussions is key. There is obviously a balancing act between encouraging innovation and avoiding an uncontrolled proliferation of technology. In a later post, we shall talk about a potential approach to governance designed to mitigate some of these challenges.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

devops ,devops implementation ,enterprise devops

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}