ActiveBlog

DevOps: Tools Vs Culture
by Phil Whelan

Phil Whelan, August 11, 2014

DevOps: Tools Vs Culture DevOps is a marriage between tools and culture. If you are just using the tools that you heard about at a recent DevOps Days and not also embracing the culture (or at least working towards it) then you're not really "doing DevOps".

Is using DevOps tools, but not really "doing DevOps" a problem? Is the cultural baggage of DevOps getting in the way of utilizing some great tools or workflows that have emerged from under the umbrella of this movement?

From Enterprise IT customers and conversations I have had, it seems that DevOps may be a little intimidating. Nobody wants to be accused of not doing DevOps right, especially if it has been mandated from high up the chain that "we need to do DevOps".

What folks have now is working. It may not be working well or efficiently, but it is working. Everyone knows their job and through hell-and-high-water they'll ship their code... eventually.

DevOps is so alien to them that it is hard to know where to start.

Do we hire a new "DevOps" team? Where do we find these people? How do we integrate them into the organization? Do we reorganize and make some Developers into DevOps Engineers? No wait... all these articles on the Internet say we should not have DevOps Engineers. That is the road to failure. It will become another silo. We have to change as an organization. It's a culture shift. I don't think my boss will sign off on this.

Ain't Broke, Don't Fix It

I love this story from Simon Sinek's book Start With Why...

*"A group of American car executives went to Japan to see a Japanese assembly line. At the end of the line, the doors were put on the hinges; the same as in America. But something was missing.

"In the US, a line worker would take a rubber mallet and tap the edges of the door to ensure that it fit perfectly. In Japan, that job didn’t seem to exist.

"Confused, the American auto executives asked at what point they made sure the door fit perfectly. Their Japanese guide looked at them and smiled sheepishly. “We make sure it fits when we design it.”*

Until the American car executives saw their competitors, their system was working for them fine. Cars would roll off the assembly line and the doors would fit "perfectly", but obviously there was something fundamentally different in the way the Japanese were creating their cars. It wasn't better CAD applications. It was something cultural. It was an invisible thread that ran through the car construction process from the drawing board, all the way to the doors being attached and even beyond that.

DevOps is a similar invisible thread that runs through the entire process of IT from the design of the software right out to the software running in production.

High Standards

There are some great talks out there by companies, such as Netflix or Etsy, who really define everything that is DevOps. They have their Continuous Integration pipelines running like a finely tuned engine - including security testing.

They often have new hires push to production on their first day. The testing hurdles in place almost always ensure that no real damage could be done by any naive new hire. Failure here is placed on the infrastructure and not on the new hire.

I usually come away from DevOps related conferences in awe of these speakers and their companies. They set the bar and they spawn many of the best new tools in this field.

But these great forward thinking companies have more than just tools and continuously delivering pipelines. They have the right culture. The culture for learning, for adapting and for seeing the bigger picture. They see how the drawing board relates to final product.

Culture First

Like the Japanese auto industry, the DevOps culture is one of high standards. A rubber mallet is simply a red flag that somewhere along the line the standards must have dropped. It should trigger an investigation into what caused the need for a rubber mallet. It should not trigger a bulk order for more rubber mallets.

Having high standards augments the workflow and results in the need for new tools. The tools around test driven development, agile processes and continuous integration have come from a cultural desire to raise the quality and consistency of delivered software.

Tools First

Culture drives the need for new tools, but new tools generally come from those pioneers at the forefront of innovation.

If you are not at the forefront of innovation then you are less likely creating the new tools, but you are likely to adopt new tools that have been proven. Most large Enterprise IT departments will be in this camp - with the emphasis on "proven".

We have seen with test driven development (TDD), Agile and now DevOps that tools can be used in isolation. TDD is the norm - everyone is either doing it or feeling guilty about not doing it. Tools like Jenkins and Atlassian's Bamboo are helping build out company's continuous integration pipelines, even if they do not see themselves as "Agile" or "DevOps".

Is it raising the quality of the software they are creating? Yes! This means that the culture in one organization is driving the creation tools that are being used in other organizations. These other organizations are then getting the benefits as if they did have the culture.

New culture will no doubt lead to new tools, but can we say the same for new tools leading to new culture?

Thinking Tools Is Culture

"We do TDD, therefore we are Agile."

"Is DevOps part of our culture? Well, we use Jenkins."

"We're all about Lean Methodologies - we created an MVP!"

I think it is a fairly obvious statement that using tools associated with a specific culture does not mean that that culture has been adopted.

DevOps: Tools Vs Culture It is hard to understand a culture you are not a part of; therefore, it is easy to falsely assume that you are a part of it. If it walks like a duck and quacks like a duck, it must be a duck, right? Well, some ducks take off their costume at the end of the day and go home to their families.

What defines culture?

I think possibly a set of ideals. I will refer again to Start With Why. Simon Sinek stresses that you must always start with why. What are the core motivations for everything you do?

Why are you using Jenkins? To ensure that all the tests pass. Why? To ensure that nobody commits build-breaking code. Why? We want our builds to always to be good. Why? Why is this is important?

Culture Is A Compass

Tools are important, but these are just stepping stones. Culture helps you focus on the direction you want to go, and lets you see which stepping stones are missing and which new stepping stones you need to create. It helps you see when you need to change direction.

Just using somebody else's stepping stones will send you in the right direction, but will not help you see the gaps. It means you are always following, so you better hope your competitor does not also have the culture.

Enterprise Adoption

Enterprise IT understands tools. It understands software. There is a problem and there is a solution. There is budget and there is cost to new software. They have a workflow and the new software either fits into that workflow or it does not. When it does not fit, the chances of adoption go down, but the software may have such a compelling story that it is worth the change.

Culture is much harder for large organizations to change.

Conclusion

Enterprise IT no doubt wants to reap the benefits from the tools that DevOps provides, but do they do they also want all of the baggage that DevOps brings?

DevOps related tools are created with a DevOps culture in mind. Some would say if you're using DevOps tools, but not making cultural change, then you are doing DevOps, but you are doing it wrong. Nobody wants to be that company that is doing DevOps wrong.

Tools alone can take you a long way in the right direction, but it is closer to following breadcrumbs than actually having a compass.

Title image courtesy of Boston Public Library on Flickr under Creative Commons License.

Related Posts

DevOps: Hero Culture

DevOps: Hero Culture Firefighters are the ones who are often up at 3am frantically trying to keep systems online.

Sometimes they are too busy putting out fires to step back and look for preventative measures. Fire fighting is a noble job, a job for the brave, it saves companies from outage, from loss in revenue, from loss due to bad publicity. Yes, it is a job for heroes. And this is where the problem lies.

Read More...

DevOps: Self-Service

DevOps Self-Service Have you ever strolled down the aisles of a grocery store, found the items you wanted, checked the prices, put them in your basket, then headed off to the checkout? Of course you have. This is what is known as "self-service". This is also a term that is becoming familiar to software developers. Providing self-service should be included in the mandate of modern IT Operations teams.

Read More...

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

Phil Whelan has been a software developer at ActiveState since early 2012 and has been involved in many layers of the Stackato product, from the JavaScript-based web console right through to the Cloud Controller API. Phil has been the lead developer on kato, the command-line tool for administering Stackato. Phil's current role is a Technology Evangelist focused on Stackato. You will see Phil regularly on ActiveState's Blog. Prior to coming to ActiveState, Phil worked in London for BBC, helping build the iPlayer, and Cloudera in San Francisco, support Hadoop and HBase. He also spent time in Japan, where he worked for Livedoor.com and met his wife. Phil enjoys working with big data and has built several large-scale data processing applications including real-time search engines, log indexing and a global IP reputation network. You can find Phil on Twitter at @philwhln, where you can ask him any questions about Stackato. Alternatively, email at philw at activestate.com