Tag: definition of devops

  • Trick Question: What is DevOps?

    Trick Question: What is DevOps?

    DevOps suffers from the lack of a clearly defined definition. A Google search displays results that state that DevOps is empathy, culture or a movement. There are also derivations of DevOps, such as ChatOps and HugOps.

    A lot of speakers mention DEVOPS but no-one seemed to have a widely agreed definition of what DEVOPS actually means.

    — Stephen Booth (@stephenbooth_uk) November 19, 2015

    Proposed Definition of DevOps: “Getting more done with fewer meetings.”

    — DevOps Research (@devopsresearch) October 12, 2015

    The real head-scratchers are the number of job postings for DevOps engineers and the number of certifications for DevOps popping up all over the web. The job title “software engineer” is contentious within the technology community, so the job title “DevOps engineer” is just begging to take pointless debates to a new level.

    How, then, do you create a curriculum and certification course that has any significant value on an unclear subject?

    For a methodology that has an emphasis on people, empathy and communications, it falls woefully short of heeding its own advice and values. On any given day, you can see the meaning debated on blog posts and tweets.

    My Understanding of DevOps and Why it Exists

    DevOps is an extension of the agile methodology that is hyperfocused on bringing customers extraordinary value without compromising creativity (development) or stability (operations). DevOps is from the two merged worlds of development and operations—operations in this context include all aspects of IT such as system administration, maintenance, etc.

    Creation and stability are naturally at odds with each other. The ripple effect is a good way to explain how these two concepts have friction. Stability wants to keep the pond from becoming turbulent and causing harm. Creation leads to change, which can act as a random rock thrown into the water and sending ripples throughout the whole pond, leading to undesired side effects that cause harm to the whole ecosystem.

    DevOps seeks to leverage the momentum of controlled ripples to bring about effective change without causing enough turbulence to impact the whole pond negatively.

    The natural friction between these two needs often drives a wedge between development and operations. Operations worry that a product update may include broken functionality that customers have come to depend on, and developers worry that sorely needed new features may not make it to customers because of an operation’s resistance to change.

    Instead of taking polarizing positions, DevOps is focused on blending those two positions into a force that effectively provides value to the customer without compromising the creativity and stability that a product or service needs to compete in an ever-evolving world.

    Why is a Clear, Singular Meaning Needed?

    The understanding of a meaning is an important part of sending a message.

    If an unclear word is used to send a message, the word risks becoming noise and the message risks becoming uninterpreted or misinterpreted.

    Without a clear, singular meaning, you risk losing the message that you want people to hear. In technology, I see messages get drowned in noise all the time.

    In communications theory, noise is anything that interferes with understanding. Noise is more than just the sounds of static, loud music or machinery. Creating noise can be simple as using obscure words to explain a topic or providing an unclear definition that muddles the comprehension of a given subject.

    DevOps suffers from too much noise that increases people’s uncertainty of the word. After reading a few posts on DevOps, each one with its declaration of the essence of DevOps, people can get confused by what the word means. DevOps is empathy! DevOps is culture! DevOps is a movement!

    Because of noise, DevOps seems to stand for multiple ideas plus agile operations without setting any prioritization or definitive context. Okay, so which is it? Is it one of those or is it all of them? Which idea is the most important? Furthermore, these ideas can cause friction, as not everyone shares the same view on these topics. DevOps is supposed to reduce friction between naturally opposing groups within a business, not create more of it.

    Remove the Barriers

    Another aspect of noise is using words that are a barrier to understanding a given definition.

    DevOps is the practice of operations and development engineers participating together in the entire service life cycle, from design through the development process to production support.

    — the agile admin

    People from a non-technical background or outside the world of agile and development may have a difficult time understanding a definition like that. When I read something like this, all is hear in my head is same sound the teacher in Peanuts makes: “Blah, blah blah, blah.”

    If you want people to remember something, make it easy to understand and memorable.

    Appeal to All Personality Styles

    In marketing, you’re taught to write to appeal to four personality styles: driver, analytical, expressive and amiable. Getting people to work together in the workplace also requires appealing to these four personality types.

    There is a need for a single definition of DevOps that appeals to the four personality styles—or, at the very least, refrains from being a barrier to entry. If a person needs to persuade someone who has a driver personality, but the definition includes language that invokes an automatic “no,” that puts people who want to use DevOps at a disadvantage.

    Give people every advantage you can for them to adopt DevOps.

    It’s Time for a Definition for DevOps

    At a time when the DevOps role is becoming increasingly important for businesses, it is crucial that a globally recognized definition be created to reduce uncertainty. It’s hypocritical to introduce a word that touches upon the importance of communication and then expect people to take it seriously when the definition constantly changes.

    It’s time that we have a singular definition for DevOps so people can use it for the hiring process or certifications without the risk of the message being lost or co-opted into something it is not.

    About the Author/Michael Herndon

    UntitledMichael is the head of DevOps at Solovis, creator of badmishka.co, and all around mischievous nerdy guy. He is writing on behalf of Packt Publishing.

  • Evolution Not Revolution – DevOps in the Wild

    Evolution Not Revolution – DevOps in the Wild

    Ever heard these questions:

    • What is DevOps?
    • How do I hire a DevOps Engineer?
    • Should we have a Director of DevOps?
    • Am I doing DevOps?
    • Why is DevOps failing in my organization?

    More and more frequently, I run into engineers, managers and business leaders describing failures in their organization due to “DevOps.”

    Oddly, digging a little deeper, I find that most of these cases are simply failure by substitution. The Operations team was failing, so they rebranded it DevOps. Alas, buzzword compliance was unable to change the trajectory of the team and the buzzword was blamed.

    DevOps today is–still–an ill-defined set of practices closely associated with automation and operations. If you accept this as fact, then DevOps can neither fail or succeed. If we want to measure the success of the DevOps movement in an organization, then we need a definition that leads to accountability.

    A Definition for DevOps

    The DevOps movement, unlike Agile, lacks a manifesto. To fill that gap, I assert that DevOps is a philosophy and that its base definition is:

    DevOps is the way in which a technology organization embeds itself in a business to the benefit of that business.

    The business in question need not be a technology company such at Docker or IBM. Indeed, all companies today are technology companies whether they like it or not. (1)

    In this and future articles I will write about philosophy, models and implementation. In short, a philosophy is what I reason from to create models of behavior. Models inform the actions taken in an implementation. Implementation without philosophy leads to failure. Jingoistic adherence to philosophy without accounting for new technology leads to failure. Balance must be acheived.

    As an example of this sort of failure, take a lesson from project management. Many shops adopt Jira because it can do anything. Since the tool can do anything, that means their workflow is capable of anything! Problem solved, QED. We all know tools are not process. When we look at our own track records of instituting change. too often the change stemmed from tool choice, not critical thinking about what was to be accomplished.

    Tools should reflect the philosophy they are implemented to support. Without that philosophy tools will fail. The more complex the problem or tool, the more spectacular the failure. In this example, Jira did not fail, leadership failed. Specifically the thought leaders entrusted with workflow management.

    Are you Doing IT DevOps Style

    DevOps is about evolution. If you are doing IT DevOps style, then you are asking questions like:

    • What should we change next?
    • How do we create a sandbox to measure the impact of the change?
    • How do we create demand for the change once vetted?
    • Who do we need to be patient zero?
    • What cultural paradigms are we shifting and how do we ease this for teams?

    While automate-all-the-things is often associated with the term DevOps, automation without cultural shift will result in broader failure, rather than success. Like any technology problem, at its core DevOps models account for their impact on people because businesses are composed primarily of people.

    Future Articles

    Over the course of the next few months. I will relate my experiences at several companies. Articles will describe:

    • What we changed.
    • Why we changed what we did.
    • What cultural issues we faced.
    • What technologies we used and why.

    I hope you will join me to learn how the practice of DevOps as a philosophy can lead to millions of dollars on the bottom line, happy bosses, fluffy bunnies and rainbows. If your lucky, you might even become a unicorn, though my own horn has yet to sprout.

    The first case study will describe a failing company with three months capital. An amazing team. Some amazing mistakes and, ultimately, some amazing success. Technology decisions driven by the needs of a sales team. Automation driven by a business model. A successful acquisition.

    References

    (1) The Phoenix Project – Gene Kim, Kevin Behr, George Spafford
    (2) Good to Great – Jim Collins

     

    About the Author/Boyd E Hemphill

    boyd-hempilBoyd E Hemphill is Director of Evangelism at StackEngine (link). , an enterprise grade, Docker operations management software company. DevOps raconteur and organizer of community events in Austin, find him on Twitter or LinkedIn.