According to Accenture‘s APAC practice lead for Agile, DevOps and Test Automation Mirco Hering, there is general agreement that DevOps at scale is a good thing, but the problem is getting from where organizations are to where they want to be.
Obstacles include having plenty of technology skills but little or no technology management (i.e., people and process) skills, or being driven heavily by technology vendors and ending up with a collection of tools that don’t all work well together.
Hering has found value stream mapping to be a very successful technique for implementing DevOps at scale. It allows people from all parts of the business to participate in the development of a map of the software delivery process (and, thus, gets different parts of the organization talking to each other), it provides important context for any external consultants that may be engaged, and it provides a visual representation of the real situation (not a formalization that doesn’t reflect reality).
It also provides an opportunity to explore what the participants think DevOps is really about. (Hering’s favorite definition is “building better solutions faster.”)
Get the First Bite Right
Once the map has been created and agreed, the next step is to determine what should be done first. “Find something that is meaningful but not impossible,” he recommends.
In other words, avoid biting off more than you can chew, but also avoid projects that are so specific that they won’t seem relevant to other parts of the organization. And avoid those involving technology that’s likely to be retired soon, because there might not be time for the results of the project to be appreciated.
It’s important to understand how you can show progress is being made, and organizations that understand the idea of rigorous continuous improvement are generally better at this.
There is a particular problem that arises when senior leadership changes: it is important to be able to explain what’s going on and demonstrate the benefits, such as the actual savings made.
Hering advocates the use of same rigor for applications supporting IT delivery as for business applications. For example, if software development systems or quality assurance systems go down, development and deployment come to a halt while the problem is rectified. The changes that are held up clearly have value to the organization (otherwise there’s no reason to make them), so any delay comes at a cost that can be minimized by applying the same types of backup and failover capabilities that are used to protect business systems. Other aspects of IT that can be applied to ‘doing IT’ include big data.
Use IT to Support IT
He points to the IT4IT reference architecture for managing the business of IT, saying “I think it is rarely implemented at this point, but at least someone’s thinking about it.”
Doing DevOps and Agile at scale requires de-scaling the technology, said Hering. That is, where hundreds of people might once have worked on a single piece of software that was released in a ‘big bang,’ the adoption of microservices and other approaches means small teams work on different parts of the overall project and independently deploy the results.
“That’s a huge jump,” he said. “A different capability is needed to do that.” Part of that capability involves resolving dependencies by using technology so they don’t need to be handled by people or processes.
But practitioners sometimes miss the point when they hear about organizations deploying hundreds of releases a day, and then they make the assumption that the practices and technologies required are not relevant to them because they don’t want to deploy that frequently.
Hering argues that it is really about having a deployment process that can support as many releases as you care to make, with “so little risk that it’s as natural as breathing.”
Can You Really do Continuous Delivery?
Many practitioners say they do continuous delivery, but Hering tests them by asking whether they could deploy a system at 4 a.m. the next day. If they are happy with doing that, they probably are on top of continuous delivery; if not, there’s probably something wrong, such as one or more manual steps that still haven’t been automated. Similar litmus tests can be created to cover other aspects of DevOps activity, he suggests.
Processes that are robust enough to detect any problems before the altered code reaches the customer or user empower DevOps teams to make small changes as required (whether the triggers were user requests, a realization that performance could be improved, or to implement a new business or compliance requirement, for example) without putting the business at risk.
Accenture has developed its own DevOps platform—a collection of open source based tooling—that provides a common reference point, and Hering recommends other organizations do something similar, warning that “it requires a difficult conversation about what is federated and what is centralized” because there needs to be a balance between the two extremes.
Changes to DevOps capabilities should be treated as scientific experiments, Hering suggests. The hypothesis might be that increasing unit testing coverage will decrease the number of defects, so you increase the coverage in a particular project (experiment), measure the defects (results), and draw a conclusion. But “very few organizations are that mature,” he conceded.
Training is Important
Another danger is that a lot of the information that practitioners hear (eg, at conferences) and read (e.g., in blogs) has been curated by organizations’ marketing teams, and that makes it too easy to focus on specific products or technologies rather than focussing on the issues that are really important to the organization.
So training is important to make sure everyone involved understands the concepts behind DevOps, and how to do unit testing and continuous integration. An increasing number of organizations say they want to adopt DevOps and Agile practices, but they don’t always understand the concepts and sometimes don’t really want to move out of their comfort zones.
Other pieces of general advice from Hering include asking why the organization is looking into DevOps (i.e., what are the goals and expected outcomes), making sure someone is going to drive the project, running cross-team workshops with a neutral facilitator to break down existing silos, and taking advantage of your peers’ experience in other organizations rather than trying to re-invent the wheel.
Very importantly, don’t try to move to DevOps at scale in one fell swoop because it is too much to swallow whole. Rather, take a piecemeal approach by focussing on a few aspects at a time and how they fit in with the next steps of your current project.
Hering’s book, “DevOps for the Modern Enterprise: Winning Practices to Transform Legacy IT Organizations,” was published this year by IT Revolution and is available from Amazon. He blogs about software delivery, Agile and DevOps at Not A Factory Anymore.
