Build a DevOps-Focused Enterprise

If DevOps is such a great idea, isn't it time to get other parts of the enterprise to adopt the concept?

It's already being done, says Antony Edwards, CTO of Testplant, a London-based test automation tools developer. "DevOps -- in particular Agile -- is fundamentally about how to productively manage a team in a highly dynamic environment, so the principles are absolutely applicable to any team," he notes.

Edwards says he has rolled out DevOps and Agile to a variety of non-technical business operations, including customer service teams, business development management staff, and even book publishers. "If you look at Agile it’s based a lot on the management principles of Japanese car manufacturers. Think the 'Toyota Way'," he says. "So if it can work in both Japanese manufacturing and Californian software development, then it’s pretty flexible."

"Different departments can learn a lot from each other," says Mark Ferlatte, who at Linden Labs in the mid-2000s created one of the first DevOps" teams. "In theory, directors or high level managers focused on larger parts of the organization that talk to each other are probably the vector most likely to succeed, unless the departments are already working together closely," says Ferlatte, who co-founded and is currently CTO of San Francisco-based software infrastructure consulting firm Truss.

Sharing values and principles

DevOps is a philosophy that's easily ported to many enterprise sectors, says Alan Zucker, an Agile, DevOps, and project management consultant based in Arlington, Va. "The values and principles of DevOps can be applied to almost any business value stream, from finance to marketing," he notes. "Nearly all organizations will benefit from close, collaborative relationships with other functions on the same value stream."

The core principles of DevOps--systems thinking, experimentation/learning, feedback --should come as second nature to most departments, notes Lucas Vogel, founder of Boynton Beach, Fla.-based Endpoint Systems, a system integrator and endpoint software developer. "Even activities like a simple SWOT (strengths, weaknesses, opportunities, threats) analysis would go a long way toward helping different areas gain a greater self-awareness of their impact on how their business performs," he says.

Antony Edwards, TestPlant

Edwards notes that DevOps, and particularly Agile, is fundamentally about how to productively manage a team in a highly dynamic environment. "The key thing DevOps/Agile does is force you to be realistic about what you can achieve and be clear on delivery dates," Edwards says. The approach drives a performance culture and close collaboration because people know up front what it expected of them and are motivated to begin sooner rather than later.

The "fail fast" mentality of Agile/DevOps is very applicable to various enterprise teams, Edwards notes. "So in marketing, rather than thinking about your social strategy for months, just run some campaigns, measure them, adjust, measure, adjust," he says.

Meanwhile, departments such as finance, HR, and marketing are all responsible for major repetitive processes that affect other business sectors, even when only incrementally improved. "All HR organizations go through annual process cycles: benefits, enrollment, goal planning, performance review, etc.," Zucker notes. Procedures and applications for executing these cycle-oriented tasks are often developed within a silo. "When the rest of the organization has to execute these processes, there are (often) issues," he says. DevOps allows every part of the enterprise with a stake in the final outcome of a process tasks to have its voice heard.

Want to understand the 9 Big Mistakes DevOps Teams Make? Check out the InformationWeek slideshow.

Zucker notes that DevOps has the potential to make the development of key business procedures, such as BYOD policies, a true team effort. "Envision iterative development where people provide feedback on the HR procedures as they are being implemented with a focus on monitoring and continuous improvement," Zucker says. "Imagine how differently HR would be perceived by the rest of the company."

Matthew Perry, director of IT Operations at St. Louis-based custom software developer WWT Asynchrony Labs, says employee onboarding is one area where a DevOps approach can have a positive impact. "I am sure many of us have seen examples where a company’s onboarding process is very ad-hoc and the communication between the teams involved is almost non-existent," he says. IT might not even be aware of a new employee until they show up on their first day. "If we apply the principles of DevOps to this situation, all teams could agree on a timeline for onboarding employees and start to implement automated workflows to accomplish tasks before an employee’s start date," Perry notes. "This would help make new employees productive on day one and leave them with a good first impression of the company."

Regardless of the goal, it's important to stay flexible and be willing to make modifications when applying DevOps principles to a new area. A continuous delivery model, for example, can pose challenges for some teams. "HR in a 10,000 people company can’t be updating their policies every week or no-one would know what’s going on," Edwards explains. "We’ve found that in such cases it’s good to have a 'customer proxy,' and the team releases frequently to that person," he says. The approach supports continuous delivery's biggest benefits, focusing the team on the user, making sure that what's being done will benefit the user and creating short-term incremental benefits, rather than wasting time and energy dreaming-up big projects that never materialize.

Working in an agile manner also provides the ability to steer in a different direction than was originally planned, allowing departments and even entire enterprises to respond to new circumstances and conditions rapidly and efficiently. "While it is important to understand that planning is important, focus directed toward creating detailed plans that are likely to change tends to lead the creators of these plans to think about the sunk costs involved in this type of activity, potentially increasing the likelihood of change resistance," says Erik Gfesser, a consultant-architect in the Chicago office of business technology consulting firm Centric Consulting.

Mark Ferlatte, Truss

Gfesser adds that it's also important for all DevOps initiative stakeholders and participants to accept the inevitability of change. "While change might be uncomfortable or an aspect that individuals might wish to avoid, not recognizing the reality of change will result in opportunity costs," Gfesser says. "At the same time, the decision making process around change needs to be visible by everyone involved."

Gfesser notes that clear visibility is a key reason for the rapid and widespread adoption of open source software. "(It succeeds) because of the visibility that open source software provides with regard to code and product roadmaps, as well as the participation that it welcomes from the community in terms of general feedback, bug reporting and the ability to submit changes," he explains.

Building Buy-in

Vogel notes that the DevOps concept should be an easy sell to most enterprise department managers. "You are enhancing their feedback channels and overseeing the process that ultimately delivers what they need sooner rather than later," he says. "What's not to love?"

Any organization that needs to create and manage ongoing processes can benefit from DevOps. "Organizations that support value streams or functions that cross organizational boundaries or need improvement will benefit the most," Zucker says.

Ferlatte suggests starting small, rolling out DevOps gradually and incrementally. "The other departments have their own processes and rituals that are often more refined and battle-tested than the relatively young software engineering processes we are currently deploying," he explains.

Managers must need to see that DevOps is not the flavor of the month, Zucker says. "Senior leadership is committed to the changes; they also need to see the benefit and understand the impact to their roles and their teams," he notes. The rollout should proceed from success-to-success. 'When managers see the small wins, the improvements that make their lives better, they will be persuaded."

Ferlatte agrees that most managers respond well to success. "All of these [DevOps] processes are in support of doing better," he notes. "If my team starts to perform better than yours over a quarter or two, you'll probably be motivated to figure out why."

The spark to bring DevOps to other enterprise departments doesn't have to emerge from software developers or IT. "Whoever wants to make a change in their organization and feels passionate about the benefits DevOps could bring should do it," Edwards says He notes that he has seen effective DevOps transformations led by a broad range of leaders, including chief digital officers, chief marketing officers and chief operating officers. "I see benefit in it not being the development team, as they are often seen as biased in terms of DevOps/Agile," Edwards says.

Organizational change

Alan Zucker, Agile and DevOps consultant

DevOps adoption is widely viewed as an organizational change effort. "The two biggest causes of failure of all organizational changes are a lack of executive support and a lack of organizational patience," Zucker says. "The CFO, CMO, COO or whoever is sponsoring the transformation must be committed for the long-haul."

Organizational change is never easy, though. "Most organizational change efforts fail or fall short of their goals because there is a real lack of executive support and long-term commitment and DevOps is no different," Zucker says. "People at all levels of the organization must be empowered and incentivized to do the right thing."

Edwards says that enterprises planning DevOps rollouts to other departments should focus on the approach's inherent simplicity. "I often find that people start with the assumption that DevOps is hugely complex and a DevOps transformation must take years--and so it does," he notes. "But the best transformations are when people assume that it’s simple and make it simple."