It may surprise you, but DevOps has been around for nearly two decades. Driven by the development community’s desire for more capabilities and controls when deploying applications, DevOps gained momentum in 2011 in the enterprise with a positive outlook from Gartner and in 2015 when the Scaled Agile Framework (SAFe) incorporated DevOps. Unprecedented growth in AWS during this period also compelled CIOs to learn more about how startups were innovating and operating efficiently on the cloud.
Back then I was a dev-centric CIO working in a regulated Fortune 100 enterprise with strict controls on its data center infrastructure and deployment practices. I was excited at the prospect of automating deployments — and smoothing tensions between development and IT operations teams. But DevOps struck me as too dev-centric at the time, and my first articles questioned who owned DevOps and how DevOps was a major shift in practices.
DevOps has evolved significantly since then — to the point where there isn’t a one-size-fits-all approach to success. Removed from day-to-day DevOps operations, many CIOs lack a complete perspective on what practices to prioritize and can be misled by how startups, vendors, or professional service organizations implement DevOps in overly simplified environments compared to what’s required in complex, regulated enterprises.
Multicloud architectures, applications portfolios that span from mainframes to the cloud, board pressure to accelerate AI and digital outcomes — today’s CIOs face a range of challenges that can impact their DevOps strategies. Below are six common mistakes CIOs still make when implementing DevOps, along with recommendations for rethinking your approach.
Taking an IT project mentality over a cultural transformation one
DevOps requires culture alignment between dev and ops to improve customer experiences, drive business agility, and improve operational resiliency. But by taking a tools-first approach to implementation, many CIOs overlook the importance of culture change.
“CIOs may mistakenly approach DevOps as a narrow IT implementation without prioritizing the necessary cultural shift towards collaboration, automation, and continuous improvement across the entire organization,” says Naresh Duddu, AVP and global head of Infosys’s modernization practice. “They may also overlook the importance of aligning DevOps practices with end-to-end value delivery, customer insights, security considerations, infrastructure scalability, and the ability to scale DevOps at an enterprise level beyond isolated teams or projects.”
This can also be the case when it comes to compliance, operations, and governance as well.
“To successfully implement DevOps, CIOs need to focus on fostering a culture that emphasizes workflow, integrating DevOps practices with existing ITIL or other governance frameworks to ensure compliance alongside agility,” says Gabby Menachem, VP of product, ITOM at ServiceNow.
Rick Boyce, CTO at AND Digital, underscores how a typical IT project mentality toward DevOps can undercut the CIO’s ability to deliver on business objectives.
“When DevOps is treated as just another IT process or a single team’s responsibility, organizations see slower product cycles and a lack of alignment between development and business objectives,” he says. “By fostering a culture of collaboration and shared responsibility, companies can accelerate their time to market, improve product quality, and enhance their adaptability to changing market conditions.”
Recommendation: Ask leaders for their understanding of key practices such as agile, DevOps, and product management, and differences in core principles, methodologies, and tools will surface. CIOs can align the culture by drawing out people’s opinions and forging the organization’s vision for balancing innovation and operation resiliency, which is at the core of a DevOps culture.
Targeting continuous delivery without adequate ops
Some DevOps teams that develop advanced CI/CD pipelines jump quickly into continuous deployment, pushing code changes into production frequently on fast deployment schedules. But continuous deployment isn’t always appropriate for your business, stakeholders don’t always understand the costs of implementing robust continuous testing, and end-users don’t always tolerate frequent app deployments during peak usage.
CIOs must also consider whether DevOps teams have the requisite security, observability, AIops, and other disciplines to ensure robust deployments meet expected service level objectives.
“Not all DevOps teams have the same discipline and culture required to automate integration and delivery as one unit properly,” says Vikram Murali, VP of application modernization and IT automation at IBM. “CIOs need to make sure that their behavior, toolchains, and standardizations are setting up their teams for successful DevOps practices. Too often, we see teams compromising quality for speed and taking shortcuts to deploy code into production because of CI/CD.”
Jim Stratton, CTO of Workday, explains succinctly why his organization follows a weekly deployment schedule: “To continue evolving our platform without breaking things, we need to test everything.”
CrowdStrike recently made the news about a failed deployment impacting 8.5 million Microsoft Windows computers, causing nearly 10,000 flight cancellations worldwide, and creating a significant financial impact. The crisis should be a warning to all CIOs who empower DevOps teams to accelerate continuous delivery without sufficient testing, rollback, monitoring, and other operational best practices.
According to the State of DevOps Report 2023, only 18% of organizations achieved elite performance by deploying on demand, having a 5% change failure rate, and recovering from any failed deployment in under an hour. High performers (31%) deploy between once per day and once per week, report 10% change failure rates, and recover from a failed deployment in under a day. Keep those real-world benchmarks in mind.
Recommendation: CIOs should adopt a risk-informed approach, understanding business, customer, and employee impacts before setting application-specific continuous deployment strategies. Applications sanctioned for frequent, continuous deployments should have robust continuous testing, enhanced observability, and a canary release strategy to minimize risks.
Shortchanging end-user and developer experiences
Many DevOps practices focus on automation, such as CI/CD and infrastructure as code. CIOs may mistakenly underinvest in practices that improve user experiences, increase alignment with business stakeholders, and promote a positive developer experience.
One example is how DevOps teams use feature flags, which can drive agile experimentation by enabling product managers to test features and user experience variants. Feature flags can also help DevOps teams reduce the fear of failure by controlling features based on performance impacts and automating communications to stakeholders around deployments.
But too many DevOps teams use feature flags just to control user access to new features, says Claire Vo, chief product officer at LaunchDarkly. “They are versatile tools within DevOps that enable safer deployments, facilitate A/B testing, and enhance operational resilience,” she says.
DevOps roles and responsibilities — especially when “shifting left” infrastructure automation, testing, and security functions to developers — can also be a problem. In some cases, placing too many responsibilities on developers’ shoulders reduces their productivity and requires them to develop unrealistic levels of expertise.
“CIOs and CTOs must avoid the pitfalls of ‘shift left,’” says Rob Whiteley, CEO of Coder. “While DevOps and DevSecOps can drive tremendous automation and time savings, they often come at a tax to the developer. Shifting operations earlier in the software development lifecycle increases cognitive load and decreases developer productivity.”
Recommendation: CIOs should ask questions and facilitate discussions on how DevOps practices impact people, including customers, end-users, employees, and developers. CIOs should also weigh in on roles and responsibilities and oversee defining a governance model to avoid overloading individuals or ending up with responsibility gaps.
Empowering teams to select tools without standards
Empowering teams to select their platforms, tools, and technologies can help drive better outcomes — but this practice comes with caveats.
“Allowing teams to choose tools doesn’t mean each team is given free rein to select any tool they want. Introducing technologies without any constraints can increase technical debt and fragility,” states Google Cloud’s DORA research program on empowering teams to choose tools.
One approach to developing DevOps standards is establishing platform engineering disciplines for creating reusable, configurable, self-service components. According to the 2024 State of DevOps Report: The Evolution of Platform Engineering, 78% of respondents work in organizations with platform engineering groups in place for at least three years. The top benefits of platform engineering for developers include increased productivity, better quality software, reduced lead time for deployment, and more stable applications.
Platform engineering is one approach for creating standards and reinforcing key principles. These help teams avoid focusing too much on the technology, losing sight of business objectives or introducing “DevOps debt” by building capabilities that will be difficult to support.
“While automation is a critical component of DevOps, it’s not a panacea,” says Lukas Gentele, co-founder and CEO of Loft, adding that it can lead to more significant issues down the road. “Automation can quickly show improvements in deployment speed and frequency, but if the underlying architecture isn’t designed to support scalable, multi-tenant environments, it can lead to operational headaches and increased costs.”
Recommendation: CIOs must strike a balance with their DevOps teams between self-organization practices, experimentation with new technologies, establishing platforms, and creating standards. Beyond platform engineering, CIOs should consider the roles of enterprise architects and delivery leaders in their organizations and how they collaborate when questions arise on DevOps platforms and methodologies.
Expecting teams will define appropriate risk strategies
While teams can learn DevSecOps principles and CIOs can select IT risk management frameworks, many organizations are understaffed to review how teams prioritize proactive risk mitigation and implement robust security measures when shifting left.
“Many CIOs believe that securing their organization’s applications involves merely managing an aggregated list of detected vulnerabilities,” says Moti Gindi, chief product officer at Apiiro.
Detecting vulnerabilities and prioritizing remediations in the agile development team’s backlog is reactive and only addresses known vulnerabilities and potential software supply chain issues.
Bill Murphy, director of security and compliance at LeanTaaS, says DevOps teams may not focus enough on data security. “Data security breaches have consequences that extend far beyond notifying affected parties. They severely tarnish an organization’s reputation, leading to lost business opportunities through diminished customer renewals and a decline in new customer acquisition.”
A new area of concern is how development teams use AI code generation and copilots. “AI complements the work of developers and engineers, freeing up time for innovation, system design, and architecture,” says Andrea Malagodi, CIO of Sonar. “I anticipate CIOs will focus teams on strong designs, good architecture patterns, rigorous code testing, and critical analysis of code to ensure it meets quality and security standards.”
Recommendation: CIOs should require product managers and delivery leaders to define their roadmaps showing priorities in new capabilities, technical debt, and risk mitigation. Even as automation, continuous testing, and increased observability practices enable DevOps teams to increase deployment frequency, organizations should define a release management strategy and establish periodic reviews of how each team prioritizes and addresses risks.
Failing to define the CIO’s DevOps role
One last area where CIOs go wrong is when they jump into DevOps only after major issues like system outages, failed deployments, angry stakeholders, or security breaches.
“For CIOs, the discussion around DevOps often seems deep in the weeds, so they delegate it to someone two or three levels below in development,” says David Brooks, SVP of evangelism at Copado. “DevOps is about delivering value to the business faster and more reliably and is at the heart of digital transformation efforts.”
Because DevOps has been maturing for over 15 years, CIOs should expect their teammates to have different visions and implementation approaches. CIOs leading digital transformation should get proactively involved in defining the DevOps culture, specifying how they will collaborate with teams regularly, and promoting practices aligned with business needs.
Read More from This Article: 6 enterprise DevOps mistakes to avoid
Source: News