The DevOps movement has already done a lot of good for software delivery across a wide range of organizations. And there's plenty of room for DevOps' benefits to keep spreading as new adherents hop on the bandwagon every day.
However, despite the enthusiasm and fervor, hitting the accelerator for end-to-end DevOps is not the only answer to all the world's business cases. In fact, there are many situations for which a full DevOps transformation is not the right fit—for the business's goals, for the exigencies of the industry in which an organization operates, or for the culture or business processes in place.
Here is how to know when a full DevOps transformation might not be a good fit for your organization.
DevOps isn't all or nothing
It's important for DevOps evangelists to recognize the factors that might make a full transformation a poor fit. But this doesn't mean many of DevOps' great principles, processes, or tools can't be applied at these organizations. Instead, it's possible to cherry-pick what works for your organization.
Nebulaworks, a DevOps consultancy, frequently meets with organizations that would be better suited to move slowly toward DevOps—implementing small changes, a subset of what it means to be leveraging DevOps—or possibly not attempting to become a DevOps shop at all, said CEO Chris Ciborowski.
Alan Zucker, founding principal of Project Management Essentials, a consulting and training organization, said the decision was not binary.
"I would suggest shifting the question slightly to 'Which DevOps is right for the organization?' rather than 'DevOps, yes or no?'"
—Alan Zucker
The DevOps principles were meant to create a set of values that companies can adopt on an as-needed basis, he explained. But there are some who have gotten very religious about having to do it a specific way, he said. It's okay to use only a little bit of DevOps tools or processes and think critically about where each component makes sense, Zucker added.
These examples highlight DevOps red flags that might apply to your organization.
1. Your business doesn't need regular releases
If your organization operates with a business model that doesn't require frequently updated software to meet customer demand, that's a good sign DevOps might not be the best fit. This could apply to organizations that don't have and don't need regular releases, those that have minimal to no regular releases, and those with no release cadence in the foreseeable future, said Prasanna Singaraju, CTO and co-founder of Qentelli.
For organizations that fall under such business models, DevOps implementation "will be an IT investment with no real business value," Singaraju said.
"Being able to understand the business value, and being open to start and adapt at a pace that does not break the current business goals, is important."
—Prasanna Singaraju
For example, Project Management Essentials' Zucker related the story of a a student in one of his classes who worked at a large federal agency. He told Zucker his agency was considering going DevOps. When Zucker asked him about the agency's situation and objectives, he figured out that the organization wouldn't likely benefit from rapid and continuous deployment. "It's a fairly stable agency, with not a whole lot of big changes coming along," Zucker said.
He found, however, that when the organization did release software it had a very costly, painful process, and releases took weeks to get done. While a full transformation probably wouldn't make sense in that situation, doing release automation tooling might help, Zucker said.
2. Your business is satisfied with the current state of software
The idea of whether or not DevOps will return business value is an important one to keep in mind. It might seem antithetical to many steeped in the world of continuous delivery and improvement of software, but there are situations in the business world where traditional software delivery methods are meeting the needs of the business.
It's important to recognize these cases, because DevOps transformations are difficult, and if the value delivered at the end of the process isn't more than the hardship that the transformation will require, there's no justification.
Todd Loeppke, lead CTO architect for Sungard Availability Services, said there situations where the company should continue the software delivery method that is currently in place, since it's already meeting the needs of the business.
"If no one in an organization identifies the need to improve the quality and reduce the time-to-market for its software-enabled services, then the potential value of DevOps will not be recognized."
—Todd Loeppke
3. You operate in a highly regulated industry
DevOps can introduce additional risks in highly regulated industries such as healthcare device manufacturing. Regulation alone doesn't disqualify DevOps; in fact, sometimes the repeatability and added visibility from the automated tooling that's a hallmark of DevOps can greatly improve compliance efforts.
But there are situations where regulation can require serious adjustments to DevOps transformations.
Highly regulated industries value safety over speed, said Vishar Gashi founder and CEO at Polymath Labs. But that philosophy isn't part of DevOps, where the cost of introducing a bug is minimal because high-performing DevOps teams can roll back the change quickly without many customers noticing, Gashi explained.
"There is no such thing as rolling back a bug on a pacemaker. Regulated companies are better off following a phase-gated development process, where checks and sign-offs determine whether or not a product is ready for the market."
—Vishar Gashi
4. Your business has lots of M&A activity on the horizon
Even if the business is heavily dependent on frequent software releases, there may be cases where DevOps doesn't make sense because of business goals. This may include when the business is in the middle of a lot of merger and acquisition (M&A) activity.
With that much business change on the horizon, it simply might not be the right time for big shifts in how IT teams work.
"Businesses that are undergoing M&A activity or divestiture have end goals that do not mesh well with attempting to change the culture" or impart a philosophy of sharing, Nebulaworks' Ciborowski said.
It might be better in that case, he said, to focus solely on automation and measurement initiatives, which can both affect and help with the business objectives on the immediate horizon.
Doing that much could still be a worthwhile investment, he said, better aligned to the business and capable of direct impact.
5. Legacy processes or architectures still rule
Finally, there are going to be situations where some kind of legacy process, architecture, or delivery model still has precedence within an organization.
Anthony Blardo, manager of development operations at Skuid, said old-school methodologies still had their place.
"If your projects are massive, complex, and require being monolithic, it can be helpful to look to a spiral or waterfall delivery process to help ensure that the project is completed properly."
—Anthony Blardo
In other cases—including where DevOps could truly improve the business but it would take a long time to deal with underlying process issues—it might simply mean delaying the transformation.
It can be too daunting to move to a full DevOps model for some organizations that require individuals' control over the delivery process, said Blardo. If your director of engineering or CTO requires direct intervention and sign-off on all changes delivered, or your QA staff has limited automation, "you may be best served to look into a waterfall delivery methodology until these can be improved," he said.
Another example is when the business still primarily depends on outsourced software development.
Caroline Wong, chief security strategist for Cobalt.io, said that before DevOps can work, business realities needed to be understood.
"Business models that outsource most or all of their software development will require a massive shift to in-house development."
—Caroline Wong
Next, the organization's executives will need to identify and communicate a clear vision that describes how DevOps will benefit the organization. It's important for executives to compare the current and the future state to demonstrate how DevOps will benefit employees, customers, and other relevant stakeholders, said Wong.
Stop and assess
These are just a few example situations, but they illustrate the point that there is no one-size-fits-all approach to DevOps, and there are times when DevOps can even be detrimental to the business. The important thing is to assess the business needs and practices before jumping headlong into a transformation that will inevitably require significant growing pains and investment to carry out.
Some experts recommend a formal assessment process.
Steve Halzel, senior director of infrastructure engineering for Sungard Availability Services, said he used the DevOps Maturity Model to assess the level of difficulty or work that is needed to transform the organization. Then, after assessing against that model and completing the transformation vision and high-level objectives, he creates "tiger teams." These include different stakeholders of the organization who can roll out changes in small doses.
"I make sure each member allots 20% of their time to the tiger team and, at various checkpoints, I gauge participation levels. Lack of participation has proven to be the clearest indicator of turbulence ahead.”
—Steve Halzel
Similarly, Ciborowski of Nebulaworks said that he works with organizations to figure out a "transformation quotient." This is a quantitative score that factors in things like IT maturity levels to determine the potential of DevOps success.
Maturity matters
Organizations with low maturity, from both technical (tools and technologies) and process (organizational structures) perspectives are less likely to show success in the adoption of DevOps approaches, said Ciborowski. These less mature organizations must first set foundational skills, which includes educating team members on modern tools and adopting technologies that provide higher levels of automation, measurement, and sharing.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
