DevOps or Dodos?

Avoid extinction by aligning development and operations.

By Bob Rhubart

May/June 2013

What is DevOps? The answer depends on whom you ask—and a lot of people are asking. According to Google Trends, activity around DevOps went from near zero in early 2010 to a massive blizzard in early 2013 that shows no signs of slowing. In that time, the number of articles offering explanations of what DevOps is and why it matters has also risen.

In broad strokes, DevOps represents the recognition that those on the software development side of enterprise IT and those on the operations side have to do a much better job of communicating and collaborating if the enterprise is to have any hope of achieving the kind of agility necessary to avoid the fate of Raphus cucullatus. No, that’s not some recently laid off software engineer. Raphus cucullatus is the scientific classification for the dodo, a very large, ungainly species of flightless bird that became extinct sometime in the seventeenth century. The dodo has since become a symbol for extinction, which is a highly probable outcome if your organization is no more agile than a huge clumsy bird with tiny wings.

DevOps, of course, hopes to reduce the probability of that outcome by bringing the development and operations sides together into a cohesive, agile whole. And for that reason it’s gaining the attention of architects, whose ultimate aim, after all, is to ensure that IT serves business needs—a goal that is unlikely to be met if the constituent parts of the IT organization can’t learn to play nice.

“DevOps is a vital movement whose concerns should be routinely addressed in the work of software architects,” says Oracle Fusion Middleware A-Team architect Randy Stafford. “Operators are important actors in the context of a software system, exercising critical use cases such as deploying new application versions, monitoring the health and performance of the application, and diagnosing incidents in the application’s execution. Consequently, they and their use cases should be planned for, as a matter of course, during the specification and implementation of the application. Responsible architects should already be doing this. It is professionally negligent of an application’s architect to throw it over the wall to operations without planning for operations use cases or participating in ongoing performance management of the application, using data collected by operators.”

Yet Oracle ACE Director Lucas Jellema, CTO of AMIS Services, admits to being amazed at how little attention is paid to creating the right combination of platform and application that is critical to the success of any IT system.

“Developers have a great many ways in which to cause frustrations for administrators,” says Jellema. “DevOps is one way to prevent such frustrations. By giving the middleware platform a clear position in the process that generates production artifacts—the application components as well as the platform on which they run—the chances of creating a combination that really works are much increased.”

While the case for DevOps appears strong, there is a right way and a wrong way to do it. Consider the experience of Dr. Karina Ishkhanova, a systems architect and independent consultant. She describes the DevOps implementation at one organization at which she worked as an impediment rather than an accelerator.

“Time spent in meetings and communication increased disproportionally without justifiable results,” she explains. The reason? “When serious issues arose requiring urgent communication, the parties involved contacted each other directly, bypassing DevOps professionals, procedures, and meetings.”

In the end, getting DevOps to work is all about changing behavior—a familiar challenge for architects. Architects can play an important role in the successful adoption and implementation of DevOps, according to Oracle ACE Director Ronald van Luttikhuizen, managing partner at Vennster. “Discuss the merits with stakeholders. Help redesign and adjust processes, and advise on possible supportive tools,” he says. “But remember that DevOps is primarily about people and processes, not tools.”

And in an increasingly competitive landscape, DevOps may be what keeps your organization from going the way of the dodo.

Next Steps

 GET more architect information

 DevOps and Continuous Integration
 All ArchBeat podcasts

Bob Rhubart's Blog
Bob Rhubart on Facebook
Bob Rhubart on Twitter
Bob Rhubart on LinkedIn