JAXenter: Your talk is structured around incremental and radical shifts of technology and science. Can you give us a little background on what that looks like in the field of computer science?

Mike: The way I see it is like this: software as a field started with Turing.  We had computation before that, but general programmability was the key to launching our industry. The field matured relatively quickly, but soon the growing hardware abilities outstripped our ability to deal with complexity, and in 1968 a “software crisis” was declared.  The outcome of this crisis was to introduce engineering methods and decomposition to manage the growing complexity of our creations. From this period, we discovered data hiding, structured programming, Structured Systems Analysis and Design, up-front planning etc.  This is the era I consider to be the paradigm of Software Engineering, where we mimicked the approaches of other engineering disciplines to manage our challenges. And this paradigm served us fantastically well. The development of our field was impressive, and the progress made from 1968 to 1998 should be considered a resounding success. However, things started to get complicated.  Many high value and high profile software projects were failing, even when they followed best engineering practices. And other projects, not following the engineering approach (think: gnu, linux, …) were having tremendous success.  These anomalies built up until the paradigm was ultimately questioned once more. This led many in the industry to consider an interesting “What if”: What if, instead of software being akin to building bridges, it is more like working on the production floor of a car factory?  What if, planning wasn’t the missing ingredient in our puzzle, but optimizing the flow of a value stream?  From these simple questions, the agile movement was born.

JAXenter: Does DevOps qualify as a disruptive paradigm shift?

Mike: Yes, but not in the way most would suspect.  I believe that Agile was the new theory the ignited the new paradigm, but it had two missing ingredients: data + tools.  A theory without data and tools cannot become a paradigm, so the period between 2001-2011 was pivotal in spawning the new paradigm.  Those data and tools are what I would reasonably categorize as DevOps, the driving force for realizing the the agile promise. As an example, the first principle of the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  A great idea, but everyone wondered how do we do it? Well, it turned out we needed automated tests, continuous integration, automated deployment, cloud provisioning, rollbacks, breaking down of silos, and a lot of additional tools and ideas that we didn’t have in 2001.  These DevOps tools were the key to the success of this current era of software.

JAXenter: Why should companies shift to a DevOps mindset if things are working well for them right now?

Mike: Well, I wouldn’t recommend the change if that was really the case.  But in all honesty, most companies have competition, and if their competitors can deliver on customer needs 440x faster than them, then eventually they will be disrupted. Most organizations are already well aware of this and taking it seriously, for example we are seeing more and more “Chief Digital Officer” roles and Digital Transformation projects in traditional industries like banking, government, and industry. I think the State of DevOps Report, from DORA, provides a trove of excellent, data-backed research on the business case for DevOps and the amazing opportunities that can be had.  This is where I normally point newcomers to the “Why” of DevOps.

JAXenter: What does a successful DevOps adoption look like? An unsuccessful one?

Mike: As Tolstoy posited, “Happy families are all alike; every unhappy family is unhappy in its own way.”  The same is true for technology organizations.  There are many ways to satisfy business needs with technology, and successful organizations are able to deliver on business needs in an responsive manner that build quality in to the result.  They work together as one team, are dedicated to building competence, and always looking for ways to improve.  Great teams deliver great outcomes. As for unsuccessful DevOps adoptions…there are many ways to fail unfortunately. It takes a lot of commitment, leadership, technical chops, and just an overall will to change that many organizations find difficult. The promise of DevOps cannot be attained by buying a product or having a company re-org – even if they may be part of the puzzle. There is no quick fix to solve poorly performing technology organizations.  As the saying goes, there are no silver bullets, but you can get far with lots and lots of lead ones…

JAXenter: What’s the most important lesson you’ve learned from implementing a DevOps process?

Mike: You need to get more than buy-in from the executive level, you need to get commitment and leadership.  The necessary culture and organizational changes need to be communicated and modeled in a cohesive strategy.  Without this, individual teams and departments can locally optimize, but politics, stasis, and fear can block the true potential success from being achieved. 

JAXenter: What will attendees be able to take away from your keynote speech?

Mike: I hope they will see our moment in the history of our field as a strategic inflection point, where moving into the new paradigm is not only desirable, but necessary for continued success.

Thank you very much!