staging-devopsy.kinsta.cloud

Tag: chasm

  • THOUGHT LEADERS OR NAVEL GAZERS?

    THOUGHT LEADERS OR NAVEL GAZERS?

    I get tired of hearing what is DevOps? It just tells me that no one really has got it exactly right, but everyone longs to be the authority on the topic. Everyone writes their perceived answers ad nauseam. Reading all the different definitions is kinda like listening to infomercials. An individual puts themselves out there as an expert simply because they have an audience and the topic is in vogue.

    But before I go any further let’s put the “What is DevOps?” questions to bed once and for all. Of course the only real source to turn to is Wikipedia, as that is the definitive source and because it’s on the Internet you know it has to be true. Did I tell you I was a French model; bonjour.  Now to the definition you have been anxiously anticipating:

    DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals. DevOps is a response to the interdependence of software development and IT operations.

    There you have it; DevOps is a methodology not an industry. Now that that question has finally been answered, I hope that I never hear about it again, let’s turn back to those thought leaders. Let’s go back to time when many of today’s thought leaders were still asking what the internet is. Once again I refer to my expert source Wikipedia:

    A thought leader can refer to an individual or firm that is recognized as an authority in a specialized field and whose expertise is sought and often rewarded. The term was coined in 1994 by Joel Kurtzman, editor-in-chief of the Booz & Co magazine Strategy & Business, and used to designate interview subjects for that magazine who had business ideas which merited attention.

    Everything on the internet is about branding and the marketing of the brand. Thought leaders typically write a blog, column, book, record a podcast or webinar.  As long as the message resonates they don’t care about the delivery mechanism. So called thought leaders are simply marketing their brand whether they truly have the expertise to do so or not.  It is a simple process when you have a topic that is loosely defined in an early stage of development, as there is no objective measure of what is correct.

    Thought leaders typically are an individual or firm that profit from being recognized as such. I submit many are truly mere navel gazers, as a navel gazer is derived from the phrase “contemplating one’s navel” or “navel-gazing” if you will, typically referred to in jocular fashion, to refer to self-absorbed pursuits. Please someone explain to me the difference between thought leaders and navel gazers?

    We have so many self anointed thought leaders I am beginning to wonder is there anyone out there actually practicing DevOps or is everyone just talking about it to make a fast buck. If you are a thought leader why can’t you tell me if and when DevOps is going to cross the chasm?

    What have I learned from all this? DevOps needs an infomercial to cross the chasm, not thought leaders. Don’t even get me started on chasms.

    If you would like say something; email parker@devops.com and don’t forget to comment here.

  • Is DevOps Ready to Cross the Chasm to Mainstream?

    Is DevOps Ready to Cross the Chasm to Mainstream?

    There are just a handful of business books that I have read that have had a profound influence on me.  One was Gene Kim’s “The Phoenix Project”, another was Eliyahu Goldratt’s “The Goal”. A third one was Geoffrey Moore’s, “Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers”.  Even though written in the early 90’s, it is as relevant today as it was then.  Though our technology has changed (dare I say advanced), the adoption curve of who uses it has remained static.

    When I look at the world of DevOps today, to me it is on a classic chasm model.  The real question is will it or rather how quickly will it make the hop over the chasm into mainstream. The picture above is a great representation of the chasm. Most technologies go through the enthusiast period, moving to the visionary.  I would say that DevOps has been in this visionary period for a few years now.

    In order for any technology to jump the chasm it needs to build up enough momentum and critical mass to successfully make the jump.  Now there are some technologies that never build up enough critical mass to successfully jump over to the pragmatist’s cliff of mainstream adoption.

    Back in my StillSecure day’s NAC had a tough time making the jump. It was not until mobile technology and BYOD served as ignitions that NAC made the cross-over to mainstream.  But enough about NAC lets return to DevOps.  For DevOps the Cloud and virtualization have been ignition points.  Using software to replace hardware has allowed for rapid deployment, automation and continuous delivery models that characterize DevOps.

    With so many pundits and analysts predicting that this is the year Cloud goes mainstream (I thought it did already), DevOps will not be far behind. As disruptive as Cloud is, could it be as disruptive if not for DevOps? There is a symbiotic relationship between the two.

    But it is not just Cloud alone. DevOps has other boosters that will help it over the chasm. SDN is another big boost.  Software will eat the world according to Marc Andresseen. It may very well start with networking hardware.  But software is eating more than hardware.

    One of the hottest trends in security (and one you will see featured here in the SecOps neighborhood of blogs on staging-devopsy.kinsta.cloud) is Software Defined Security.  It may sound like marketing speak to you, but it involves putting security right into the virtual, software stack.  It is DevOps for security.  In fact DevOps and security is something you are going to hear more about from the likes of Josh Corman, Dave Mortman and Dwayne Melançon and others.  Their “Rugged DevOps” discussion is ripping through the security industry for the last year or more.

    All of the above aside the real key for DevOps to making the leap is that instead of just enthusiasts and visionaries being involved, what Moore calls “the Pragmatists” get involved.  These pragmatists are not hung up on labels or new versus old.  They just want to get the job done. If DevOps will help them get the job the done, that is good enough for them.

    The pragmatists make up a good chunk of the mainstream market.  The silent majority if you will.  To win these pragmatists over DevOps just has to show that its benefits are real, quantifiable and worthwhile. The good news is that the Pragmatist are the first group on the other side of the chasm.

    Having the Pragmatist as the first part of the mainstream is a good thing, because after that it gets harder to gain traction.  According to the Chasm model after the Pragmatists come the Conservatives.  Though not quite reactionary, this group doesn’t like change. They won’t change until they are nearly forced to by business pressures. They will resist adopting DevOps just because it is different than what they do now.  Generally technology has to be pretty mature, its benefits well established before this group will consider doing anything more than a small trial.  With DevOps representing as much a change in philosophy and culture as it does new tools, this is a really bitter pill to swallow for the Conservatives.

    I would think we are years away from DevOps making real traction into this group. Especially when there are still some folks who claim that DevOps is DOA, DevOps is much ado about nothing, that it is doomed to failure. But hey there are people who still say that the science doesn’t point to climate change and that we should teach creationism in schools.

    Call me the eternal optimist though. I do think that as Cloud and the other catalysts behind DevOps continue to expand, DevOps will be swept up even into the conservative base.

    Between Conservative and Pragmatist, a large slice of the market is spoken for. Added to the pre-chasm market and DevOps is well beyond critical mass.  Whether the last segment of the market, the skeptics ever adopt is not even relevant.  Many of these skeptics have a bone to pick. As I have grown older I am convinced that they are just wired to be skeptics.  They literally look at everything through a half empty glass.

    So there is little doubt in my mind that DevOps will not be a stillborn technological movement. It has the catalysts, the benefits and most importantly timing and circumstances are lined up to help push this from the early adopter crowd and right over the chasm into the mainstream. What’s more is I think this is already under way and will be much quicker than most people think.

    This is all a big reason why we launched staging-devopsy.kinsta.cloud.  There is a big enough critical mass now to support a site dedicated to DevOps like this.  But as we cross the chasm to mainstream, we want to ride the crest of the wave, helping to bring DevOps to pragmatist, conservative and anyone else who would benefit from it.

  • How We Can Help DevOps Cross The Chasm

    How We Can Help DevOps Cross The Chasm

    The problem that DevOps solves is universal, urgent and important.  Every IT organization is responsible for two things: deliver fast flow of projects and features, while preserving reliable, stable and secure services.  Until very recently these were thought to be mutually exclusive, we thought it was only possible to achieve one of those objectives, at the expense of the other. This caused years (or even decades) of inter-tribal conflict between Development and IT Operations; led to chronic underperformance, with features taking slower than ever to reach market, deployments taking longer, an ever-increasing number of Sev 1 outages, and IT Operations becoming buried in technical debt and unplanned work; and a variety of other symptoms.

    We now know that there is a better way. The proof is that high-performing organizations such as Amazon, Google, Twitter, Etsy and Netflix, are adopting a set of techniques that we now call DevOps, and are routinely deploying hundreds or even thousands of code deployments per day, while preserving world-class reliability, stability and security.

    During the 2012 Puppet Labs DevOps Survey of Practice ), we benchmarked over 4000 organizations. We found that the high performers were massively outperforming the low performers. Those employing DevOps practices were doing 30 times more frequent code deploys, and had deployment lead times measured in minutes or hours, versus weeks, months or quarters.

    DevOps organizations also had far better deployment outcomes: Their changes and deployments had twice the change success rates, and when the changes failed, they could restore service 12 times faster.

    This is what every IT organization needs to be able to replicate.

    DevOps Isn’t Just For The Unicorns

    “If there’s anything that all horses [enterprise IT organizations] hate, it’s hearing stories about unicorns [DevOps shops]. Which is strange, because horses and unicorns are probably the same species. Unicorns are just horses with horns.”  — Christopher Little

    We know that without something like DevOps, IT organizations will fall into the downward spiral. However, most enterprise IT organizations will come up with countless reasons why they cannot adopt DevOps, or why it is not relevant for them.

    One of the primary objections from horses is that all the unicorns (e.g., Google, Amazon, Twitter, Etsy, etc.) were born that way. In other words, from their beginning all unicorns used DevOps style work patterns.

    In reality, every unicorn at some point in their history had the same problems as horses: an inability to grow capacity fast enough to keep up with market demand, dealing with years of accumulated technical debt, lack of automated testing to sustain high rates of change, monolithic and overly tight architectures that prevented developers from being productive, and so forth.

    The unicorns have made the journey that every horse will need to make.

    The DevOps Survey of Practice showed that DevOps isn’t just for unicorns. Not all of the 4000 or so respondents were startups, and they weren’t all web operations companies either. Instead, 42% of the organizations that were implementing DevOps practices had over 500 employees. The link to those slides is here.

    DevOps is equally relevant for startups as it is for legacy enterprises. The need to decrease time to market and shrink lead times is universal. In fact, it may even be more urgent for the multi-billion-dollar enterprises – creative disruption is making the tenure of Fortune 500 companies ever more tenuous. Richard Foster, a professor at Yale University, has said that the average life of a Fortune 500 company has decreased from around 75 years to 15 years in the last half century. Of the Fortune 500 companies in 1955, 87 percent are no longer on the list.

    Increasingly, IT is the value creation and customer acquisition engine for organizations. As my friend Chris Little says, “Every company is an IT company regardless of what business they think they’re in.”

    DevOps Isn’t A Fad

    I compared the plight of DevOps to apartheid. With ridiculously worse conditions and a much more self evident problem, Nelson Mandela sat in jail for 27 years to show a minority of people in only one country that racism is wrong. Industry level change doesn’t take seven years. It takes upwards of 27. —  Stephen Fishman

    Some may worry that as more people write about or seek knowledge about DevOps, that DevOps will become a dismissible fad.

    I’d encourage anyone who wants DevOps to become a pervasive reality to look at it this way: there is a spectrum of awareness, spanning from “no one has heard of it, and dismiss it as a movement that is irrelevant to them” on one side, to “everyone has heard of it, and rolls their eyes that it’s the latest fad.”

    If I had to choose one of those scenarios, I’d choose “fad” every time. Why?  Because there is nothing worse than trying to solve a problem that no one else thinks is important. The fact that so many communities are working to solve the DevOps problems is amazing. Development, testers, agile coaches, IT operations: We all believe it’s important.

    As DevOps advocates, we must always be ready to respond when someone asks us, “I’ve heard about this DevOps thing. Is it something we should be doing?”  The response should always be, “Yes, of course, we should be doing it! Here’s what I can do to help!”

    As the DevOps community grows past what Geoffrey Moore called the “innovators” and “early adopters” (i.e., the unicorns), we must continue to tell the story so that the “early majority” and “late majority” will realize that DevOps is for them, too.  Only by doing this can we have mainstream adoption, a phenomenon that Moore called “crossing the chasm.”

    To create DevOps outcomes, we need a coalition that spans the entire value stream, from Marketing, to Product Owners and Product Managers, to Development  and Testers, IT Operations and Infosec.  Only then can we help our organizations go from low-performing IT to high-performing, which we’ve shown we can do through DevOps practices.

    Conclusion

    When IT does poorly, the business will do poorly. And when IT helps the organization win, those organizations will outperform their competitors in the marketplace. DevOps allows IT to win.