Topics

Featured in Development

As part of our core values of sharing knowledge, the InfoQ editors were keen to capture and share our book and article recommendations for 2018, so that others can benefit from this too. In this second part we are sharing the final batch of recommendations

Featured in Architecture & Design

Tanya Reilly discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters.

Featured in Culture & Methods

Mik Kersten has published a book, Project to Product, in which he describes a framework for delivering products in the age of software. Drawing on research and experience with many organisations across a wide range of industries, he presents the Flow Framework™ as a way for organisations to adapt their product delivery to the speed of the market.

Featured in DevOps

The fact that machine learning development focuses on hyperparameter tuning and data pipelines does not mean that we need to reinvent the wheel or look for a completely new way. According to Thiago de Faria, DevOps lays a strong foundation: culture change to support experimentation, continuous evaluation, sharing, abstraction layers, observability, and working in products and services.

Wall Street Journal: Enterprises Are Not Ready for DevOps, but May Not Survive Without It

Rachel Shannon-Solomon suggests that most enterprises are not ready for DevOps, while Gene Kim says that they must make themselves ready if they want to survive.

Rachel Shannon-Solomon, a venture associate at At Work-Bench, has recently written a blog post for The Wall Street Journal entitled DevOps Is Great for Startups, but for Enterprises It Won’t Work—Yet, arguing that while DevOps is appealing to startups, there are important stumbling blocks in the path of DevOps adoption within the enterprise. While acknowledging that large companies such as Google and Facebook benefit from implementing DevOps, and that “there is no lack of appetite to experiment with DevOps practices” within “Fortune 500s and specifically financial services firms”, Shannon-Solomon remarks that “there are few true change agents within enterprise IT willing to affect DevOps implementations.” She has come to this conclusion based on “conversations with startup founders, technology incumbents offering DevOps solutions, and technologists within large enterprises.”

Shannon-Solomon brings four arguments to support her position:

Siloed structures and organizational change. According to Shannon-Solomon, enterprises create siloed structures between teams because that’s how large organizations maximize value results, and one of DevOps’ main purpose is to bring those silos down. Sometimes a large company relies on another vendor for operational support, and such vendors “tend to bring their own degree of siloing.” Also, it is expensive for an enterprise to invest into “holistic solutions to facilitate DevOps” after they “invested heavily on integration for existing solutions.”

Buy vs. build. The tools needed to implement a DevOps culture are lacking. While some of the tools can be provided by vendors and others can be created within the enterprise, a process which takes a long period of time, “there is a marathon of organizational change and restructuring that must occur before such tools could ever be bought or built.”

Vendors of DevOps solutions acknowledge that when selling to the enterprise, they are trying to sell a cultural revolution. According to Shannon-Solomon, it is hard to introduce DevOps to development teams because

Vendors need to first win over individual developers with the efficiency of their solution, for example, by initially eschewing procurement and offering a sandbox environment directly to developers to test out the environment. …

Selling DevOps toolkits to the enterprise means facing the well-documented challenges of navigating procurement and a mindset currently more primed to build than buy DevOps tools.

Return on investment. Shannon-Solomon cites a senior IT professional working at an investment bank saying that his company “has not been very successful at tracking DevOps projects occurring within individual business units using homegrown tools, and any evaluation of a project’s success has been limited to anecdotal assessments and perceived results.”

Shannon-Solomon ends her post wondering “how long will it be until enterprises are forced to accept that they must accelerate their experiments with DevOps” and hoping that “more individual change agents within large organizations may emerge” in the future.

In yet another WSJ blog post entitled Enterprise DevOps Adoption Isn’t Mandatory — but Neither Is Survival, Gene Kim, a DevOps author and founder of Tripwire, an enterprise security company, argues that a “DevOps transformation is well underway, not just in startups, but in enterprises in all industry verticals and sizes”, offering as examples Nationwide Insurance and BNY Mellon Corp. in the financial services, The Gap Inc. and Macy’s Inc. in retailing, and UK.gov and the US Department of Homeland Security for governmental agencies. He believes that such large companies are embracing DevOps in spite of difficulties because “the business value … is even larger than we thought” and “those not transforming their IT organizations risk being left behind, missing out on one of the most disruptive and innovative periods in technology.”

Kim offers three reasons for DevOps adoption:

The business value of DevOps. Kim compares the value brought by DevOps with Lean’s, DevOps being the “result of implementing Lean principles to the IT value stream.” To support his view, Kim calls a survey of 4,039 IT organizations pointing to “astonishing levels of performance”:

High performers were doing 8x more frequent production deployments, being performed 8000x faster, with 2x higher success rates, and fixing issues 12x faster when something went wrong.

Survival is not mandatory (nor is adopting DevOps). Acknowledging that DevOps requires major changes within organizations, Kim goes on comparing this with changes needed to implement Lean by manufacturers in the 1980s.

For perspective, consider again the Lean revolution in the 1980s. That revolution wasn’t easy, either. It required changing incentives for plant managers, work center supervisors and even business managers. It required overcoming work center silos, massive levels of training and re-skilling, and an integrated workforce focused on flow, as opposed to units produced.

He added that those who “refused to embark on this journey [introducing Lean], and others started but did not have skill or collective will to solve this problem” are those who are “no longer relevant,” practically saying that those who are not ready to do DevOps properly will not survive or will become irrelevant.

Organizations adopting DevOps are reaping the rewards. According to another DevOps survey of over 9,200, “not only do the IT organizations using DevOps perform better, but more importantly, overall business performance is higher.”

In conclusion, while Shannon-Solomon sees few enterprises ready to embrace DevOps, Kim considers that no matter how hard it is for large companies, they do not have a choice, DevOps being a requisite for survival in the future.