Tag: research

  • Global Survey Finds Testing as the Most Valuable AI Investment Across the Software Development Lifecycle

    Global Survey Finds Testing as the Most Valuable AI Investment Across the Software Development Lifecycle

    Tricentis report reveals AI-augmented DevOps tools will save teams over an estimated 40 hours per month—equivalent to an entire workweek

    AUSTIN, TEXAS – August 6th, 2024 – Tricentis, a global leader in continuous testing and quality engineering, today released the findings of its most recent AI report, “AI-augmented DevOps: Trends Shaping the Future.” This year’s research aims to understand to what extent the anticipated benefits of AI in DevOps have been realized today, and how a lack of trust, skills, or other challenges could affect its adoption.

    When asked to evaluate the most impactful areas for AI investments across the delivery cycle – such as planning, coding, deploying and releasing – DevOps practitioners ranked testing as the most valuable (60%). This result was foreshadowed in the Tricentis’ 2022 study, which found that testing is where organizations expected the greatest value from AI-augmented DevOps, with nearly 70% of respondents having rated the potential of AI-augmented testing as extremely or very valuable.

    The research finds that DevOps teams are realizing the benefits of AI, with mature DevOps teams who have adopted AI significantly more likely (30%) to rate their teams as either extremely or very effective. The biggest challenges DevOps teams are using AI to address are developer team efficiency (60%), reducing the skills gap (54%), cost reduction (47%), and software quality (42%). In fact, almost one third (32%) of respondents estimate AI-augmented DevOps tools will save teams over 40 hours per month—equivalent to an entire workweek.

    The 2024 results show that teams use AI to augment a wide range of testing tasks, including test planning/deciding what to test (47.5%), test case generation (44%), and analyzing test results (32%). Additionally, nearly half (42%) of respondents expect AI to perform a risk analysis of code changes, helping QA teams focus on code areas with the greatest risk of errors to quality.

    The report surveys 500+ DevOps practitioners, managers, and executives from small, mid-size, and enterprise organizations across the globe and in several industries, including financial services, healthcare, and manufacturing.

    Other 2024 findings reveal:

    • Regulation is expected to help build trust, but others worry it will stifle innovation and outcomes. Nearly two thirds (63%) of those surveyed view increased regulation as a way to build confidence in AI across their organization, while a smaller—but not insignificant—number of DevOps practitioners (16%) feel increased regulation will hinder or stifle the potential impact of AI in organizations.
    • Humans remain vital to ensure software quality, but there’s a shortfall in AI skills. Data shows that humans are still very much “in the loop,” with over two thirds (71%) of respondents checking outputs at least half of the time, and almost one in five (19%) claiming to check AI outputs all of the time. However, a lack of AI skills (28%) is seen as the greatest hurdle to AI adoption in DevOps.
    • Generative AI (Gen AI) and AI copilots are key drivers of AI adoption: GenAI (45%) is now the most widely adopted type of AI used by DevOps practitioners. In particular, AI copilots are also on the rise, with use cases in planning, code development, and software testing.

    “AI is an exciting technology and growing at a pace unlike anything we’ve seen in our industry,” said Mav Turner, Chief Product and Strategy Officer, Tricentis. “As AI technology is further developed, however, training software development and quality engineering teams with the necessary skills to effectively work with AI will be absolutely critical.”

    “DevOps teams looking to get started with AI should look no further than their testing processes. AI in testing helps to detect, auto-heal and predict defects during development, as well as identify which tests need to be run based on high risk. When coupled with low-code/no-code technology, this means that, regardless of a team’s technical expertise, AI can significantly contribute to overall software quality. As DevOps teams continue to mature, testing will be pivotal to realizing their investment in AI-augmented DevOps tools and practices.”

    To view the full findings of the report, download the complete “AI-augmented DevOps: Trends Shaping the Future” report here and register for the upcoming webinar on Thursday, August 29th here.

    Additional resources:

    Survey Methodology

    The findings are based on a global study conducted by Techstrong Research on AI augmentation in DevOps environments. The survey was fielded from April 19 to June 30, 2024, and yielded responses from 500+ DevOps practitioners, managers, and executives in the Americas, Europe and the Middle East, and the Asia-Pacific from small, mid-size, and enterprise organizations.

    About Tricentis

    Tricentis is a global leader in continuous testing and quality engineering. The Tricentis AI-based, continuous testing portfolio of products provide a new and fundamentally different way to perform software testing. An approach that’s totally automated, fully codeless, and intelligently driven by AI. It addresses both agile development and complex enterprise apps, enabling enterprises to accelerate their digital transformation by dramatically increasing software release speed, reducing costs, and improving software quality. Widely credited for reinventing software testing for DevOps, cloud, and enterprise applications, Tricentis has been recognized as a leader by all major industry analysts, including Forrester, Gartner, and IDC. Tricentis has more than 3,000 customers, including the largest brands in the world, such as McKesson, Allianz, Telstra, Dolby, and Vodafone. To learn more, visit https://www.tricentis.com.

  • AppDynamics Survey Reveals High IT Stress

    AppDynamics Survey Reveals High IT Stress

    A global survey published today by AppDynamics, a unit of Cisco, suggests the last year took a substantial toll on IT teams at a time when many organizations either launched or accelerated digital business transformation initiatives.

    The survey, of 1,050 IT professionals in organizations with revenue of more than $500 million, finds organizations, on average, implemented digital business transformation initiatives three times faster in 2020 than they did in 2019 in response to the economic downturn brought on by the COVID-19 pandemic. That increased level of activity, however, appears to have come at a significant cost. The survey found 89% of respondents felt they are under immense pressure at work, with 84% admitting to having difficulty switching off after work.

    The survey also found stress levels are, not surprisingly, rising as well, with 81% of respondents experiencing increased frustration and 63% conflicting more with colleagues.

    The root cause of these issues cited most often include new sets of priorities and challenges (80%), technology sprawl and a patchwork of legacy and cloud technologies (78%), acceleration to cloud computing (77%) and multiple, disconnected monitoring solutions (74%).

    A full 85% also identified cutting through noise generated by increasing volumes of data to identify root causes of performance issues will represent a significant challenge in the year ahead. A total of 92% also noted the ability to link technology performance to business outcomes will be what’s really important to delivering on innovation goals over the next year.

    Three-quarters (75%) of respondents said they are already struggling to manage overwhelming “data noise.” Nearly three-quarters (73%) also noted they fear the inability to link IT performance with business performance will be detrimental to their business in 2021. Three-quarters (75%) of respondents also noted their organization needs to connect full-stack observability to business outcomes within 12 months in order to remain competitive. Two-thirds of respondents (66%), however, said right now they do not have the resources and support they need.

    AppDynamics regional CTO Gregg Ostrowski said the survey makes it clear that existing approaches to merely monitoring IT platforms are not going to be sufficient, at a time when observability across the full stack of IT platforms being employed is now absolutely essential. Rather than convening war rooms where IT teams responsible for different platforms compare reports in the hopes of identifying the root cause of an issue, Ostrowski said modern observability platforms provide a holistic view of IT environments that IT teams need to proactively resolve issues before they impact the business.

    That level of visibility will also play a crucial role in reducing the stress levels of IT teams that, in many cases, are now in danger of suffering from burnout, Ostrowski added. Of course, the more fatigued an IT team is, the more likely it is mistakes will be made.

    It’s not clear to what degree IT teams are embracing observability as a core IT management concept. The AppDynamics survey noted that 71% of respondents are wary of misleading claims from vendors who are re-labelling monitoring tools as observability platforms. Regardless of how observability is achieved, the general consensus remains: whatever observability means within the context of IT, most organizations lack it.

  • CloudBees Advances Expanding DevOps Agenda

    CloudBees Advances Expanding DevOps Agenda

    CloudBees today at its online DevOps World 2020 conference announced it is embedding additional DevSecOps capabilities that span the application development and deployment process within the continuous integration/continuous delivery (CI/CD) platform based on the open source Jenkins projects.

    In addition, CloudBees announced it will make generally available by the end of this year two additional modules for its Software Delivery Management (SDM) platform. Launched last year, the SDM platform provides a centralized mechanism for all stakeholders in the enterprise to track application development projects.

    The first module available today unifies the management of feature flags across an entire application development project. The second creates a system of record for tracking progress by importing and normalizing all the data made available by the tools that make up a DevOps platform.

    The DevSecOps offerings, meanwhile, provide IT teams with a hardened instance of the CloudBees CI offering, along with hardened audit-ready pipelines to ensure only immutable, approved components and environments are used without any drift or tampering. CloudBees is also adding support for role-based access controls based on fine-grained permissions as well as tighter integration with the feature-flagging capabilities of the CI/CD platform. If issues arise in a production environment, specific features can be pulled back with full traceability provided automatically.

    Finally, CloudBees has integrated its CI/CD platform with security automation applications from Anchore, Alcide.io, FOSSA, CyberArk, Checkmarx, Contrast Security, Shiftleft.io, Snyk, RunSafe Security, Sonatype, WhiteSource Software, Synopsys and Zimperium.

    CloudBees CEO Sacha Labourey said in the wake of the COVID-19 pandemic, it’s clear organizations are accelerating the development and deployment of more sensitive applications that drive digital business transformation initiatives. In fact, according to the results of a survey of 347 IT professionals conducted by Accelerated Strategies Group (ASG) on behalf of CloudBees published today, digital transformation objectives have somewhat or significantly increased in priority for nearly two-thirds (63%) of respondents.

    Slightly more than half said their organizations have also placed higher priorities on increasing their DevOps initiatives (52%). Many are also now practicing daily standup meetings (56%), using cross-functional teams (46%) and automating tasks (43%).

    Overall, 59% said their software teams have become somewhat or significantly more productive, with 43% reporting it is now easier to complete work tasks in a timely fashion. Nearly two-thirds (61%) said they are also finding it easier to work across time zones and, in some cases, even different continents (39%).

    Labourey said that as digital business initiatives continue to gain steam, more organizations will be applying DevOps principles to the business itself. SDM platforms will play a critical role in enabling that transition by providing a common framework through which IT and business professionals will be able to collaborate more closely, said Labourey. The goal should not be to turn software development into a factory, but rather to prioritize projects and initiatives in a way that benefits the business.

    Ideally, SDM also provides a framework through which IT teams can manage up at a time when many business leaders lack visibility into often complex DevOps processes that tend to have lots of dependencies, noted Labourey.

    In the meantime, the divide between all the application owners, IT teams and security professionals that make up an IT community within an organization continues to narrow. The challenge now will be determining what to do next, once all those constituencies are finally seeing the same thing at the same time.

  • DevSecOps Requires Teamwork for Success

    DevSecOps Requires Teamwork for Success

    While the manifestos surrounding the current development pipelines may differ, there is one concept that remains constant: teamwork. All the various frameworks populating the development landscape bring together teams of people to build and deliver applications. This is especially true of DevOps, which focuses on a technical culture with defined roles on a quest for responsiveness. 

    Yet, many organizations seem to be failing miserably when it comes to bringing cybersecurity into IT operations, especially where DevOps is concerned. New research from Tanium, a purveyor of endpoint management and security platform solutions, illustrates that all is not well where cyber and IT operations intersect.

    Tanium commissioned Forrester Consulting to survey more than 400 IT leaders at large enterprises to uncover the challenges, consequences and gaps they face when managing and securing their endpoints. That research revealed that two-thirds (67%) of businesses say that driving collaboration between security and IT ops teams is a major challenge.

    That lack of collaboration has a cascading effect, impacting the overall security hygiene of the enterprise and exposing systems to even common threats. Simply put, teamwork requires much more than just building camaraderie between security, operations and development folks; success requires that various team members come together to support the culture of DevOps. 

    Strained relations between those players can lead to security failures, an assumption evidenced by Tanium’s research. The survey results indicated that security and IT ops teams with strained relationships more often struggle with basic IT hygiene, taking nearly two weeks longer to patch IT vulnerabilities than teams with healthy relationships.

    It is those types of issues that can weaken the confidence of  IT decision-makers to make the correct decisions. The report claims that they have a misplaced sense of confidence, with 80% certain they can act on the results of vulnerability scans but only 49% feel confident they have full visibility into all the hardware/software assets on their environment. 

    According to Tanium, that misplaced confidence is attributable to the increased investment in IT security and operational tools. However, just increasing security budgets does not always deliver on improved capabilities. As the survey results indicate, throwing money at the cybersecurity problem often creates a false sense of security regarding how well businesses can protect their IT environment from threats and disruption.

    Many of those threats seem to fall through the cracks, a problem often blamed on the lack of end-to-end visibility of endpoints and their health. Solving that particular issue requires that IT security professionals interact more effectively with their IT operations and development counterparts (again, teamwork). Further exacerbating the problem is that many applications and services still operate in silos, which inhibits the visibility and control needed to properly protect the environment.  

    “According to our research, most teams are confident in their ability to take timely action on the results of their vulnerability scans. However, further investigation shows teams are admittedly suffering from visibility gaps of all hardware and software assets in their environment, which undermine these efforts to take action. With around 50% of IT leaders showing confidence in asset and vulnerability visibility, you’re essentially leaving your security to a coin flip,” said Chris Hallenbeck, Americas Chief Information Security Officer at Tanium. 

    Ultimately, Tanium recommends adopting a unified endpoint security solution to address the gaps in protection, while also encouraging security and IT ops teams to work more closely together. However, it is likely it will take more than just that to fully integrate security into the DevOps pipeline. Cybersecurity pros will need to get involved in the development pipeline to ensure that security becomes a foundational element of the application development and delivery process. 

    — Frank Ohlhorst

  • Culture, Not Changing Much in DevOps

    Culture, Not Changing Much in DevOps

    One of the things that has bemused me from day one of the DevOps movement is how culture is viewed with an odd dichotomy. It is simultaneously DevOps’ greatest strength and its greatest weakness.

    Of course, there is a simple and reasonable explanation for this phenomenon. DevOps wants to change culture. Cultures that are resistant to change are typified as “bad” and those that are not are typified as “good.” It is never that simple, but that’s how the portrayal goes.

    After a decade, you would think we’d have massive IT culture change supporting DevOps initiatives at one level or another (somewhere on a scale from pilot project to corporate standard) pretty much everywhere.

    But data seems to indicate that this is not the case. Disclaimer here: I fall more on the “automation” side of the “What is DevOps, really?” question. I don’t think that matters here, since I’m pointing at data from the DORA “State of DevOps Research Report,” which is 1,900 of you all speaking, not me.

    Image Credit: DORA State of DevOps Report

    Most of the coverage on this report is by people who have bet their entire career on DevOps—a solid bet, but one that can lead to stilted coverage, which takes all the positives and hoists them high. And there is a lot of positive to be found. But I’ve noticed a trend of not looking at the data with a critical eye. The bit that I’d like to focus on today is what DORA labels “Firmographics”—a breakdown of respondents by title.

    Only 27 percent of those who responded were on a DevOps team. Presumably because Google is a sponsor of DORA, it included Site Reliability Engineering with DevOps teams, and that’s a fair inclusion, since SREs by definition are doing DevOps.

    Consider that data point representing “culture change” in a world where the respondents are, by self-identification, doing DevOps. Some will argue this is the wrong way to look at it, but one of the issues that culture people bring up constantly is breaking down silos and organizing around product or product portfolio instead of development and operations. But it seems more as though organizations are knocking holes in silos and communicating through them—which means we should pay more attention to that style of DevOps and quit harping on organizational change. Again, this fits well with my world view, which has always been “That specialist in a shared bit of hardware is not moving to a DevOps team.” The EMC specialist (for example) adds value to the entire org because of their domain-specific knowledge, not because of their deep understanding of the entire DevOps toolset. Once you’ve carved out exceptions for storage, networking and platform specialists, moving everyone to a DevOps team is pretty moot.

    I won’t conjecture why only 27 percent are moved into dedicated teams, nor why that number did not go up from 2017. I have a predilection toward “because it’s not necessary,” but likely there will be two camps when this discussion gains steam because more reports show a low rate of change—Group A will be, “Because those people are resisting change,” while Group B will be, “Because those people don’t feel they need change.” Guess what? That will be the same group of people, and that angle of discussion will be irrelevant. The important bit will be, “Are you completing everything you need to get done, and what is your structure?” That’s where the meat of the discussion will need to occur. Because by deduction, 73 percent of people participating in the DORA survey are doing DevOps while not being on a dedicated (eg: reorged) team.

    And that’s perfectly okay, as long as they’re achieving the goals, that’s what matters. The how is useful when deciding to move in a certain direction, but delivering is the thing IT should—and generally is these days—be gauged on.

    — Don Macvittie

  • How Service Mesh Addresses 3 Key Microservices Challenges

    How Service Mesh Addresses 3 Key Microservices Challenges

    I was recently reading the “Global Microservices Trends” report by Dimensional Research and found myself thinking, “A service mesh could help with that.” Let’s look at three key challenges listed in the report.

    A couple key points in the report make it clear microservices are seeing widespread adoption. It’s also clear that along with the myriad benefits they bring, there are also tough challenges that come as part of the package. From the report:

    • 91 percent of enterprises are using microservices or have plans to.
    • 99 percent of users report challenges with using microservices.

    Major Microservices Challenges

    The report identifies a range of challenges companies are facing.

    Companies are seeing a mix of technology and organizational challenges. We’ll focus on the technological challenges a service mesh solves, but it’s worth noting that one thing a service mesh does is bring uniformity so it’s possible to for all teams to have the same view, reducing the need for certain skills.

    Each Additional Microservice Increases the Operational Challenges

    Not with a service mesh! A service mesh provides monitoring, scalability and high availability through APIs instead of using discrete appliances. This flexible framework removes the operational complexity associated with modern applications. Infrastructure services were traditionally implemented as discrete appliances, which meant going to the actual appliance to get the service. Each appliance is unique, which makes monitoring, scaling and providing high availability difficult. A service mesh delivers these services inside the compute cluster itself through APIs and doesn’t require any additional appliances. Implementing a service mesh means adding new microservices without adding complexity.

    It is More Difficult to Identify the Root Cause of Performance Issues

    The service mesh toolbox gives you a couple of things that help solve this problem:

    Distributed Tracing: Tracing provides service dependency analysis for different microservices and tracking for requests as they are traced through multiple microservices. It’s also a powerful way to identify performance bottlenecks and zoom into a particular request to identify which microservice contributed to the latency of a request or which service created an error.

    Metrics Collection: With service mesh you also get the ability to collect consistent metrics across your mesh. Metrics are key to understanding what has happened in your applications, and when they were healthy compared to when they were not. A service mesh can gather telemetry data from across the mesh and produce consistent metrics for every hop. This makes it easier to quickly solve problems and build more resilient applications.

     

    Differing Development Languages and Frameworks

    Another major challenge that report respondents noted facing was the challenge of maintaining a distributed architecture in a polyglot world. When making the move from monolith to microservices, many companies struggle with the reality that, to make things work, they have to use different languages and tools. Large enterprises can be especially affected by this, as they have many large, distributed teams. Service mesh provides uniformity by providing programming language agnosticism, which addresses inconsistencies in a polyglot world where different teams, each with its own microservice, are likely to be using different programming languages and frameworks. A mesh also provides a uniform, applicationwide point for introducing visibility and control into the application runtime, moving service communication out of the realm of implied infrastructure, to where it can be easily seen, monitored, managed and controlled.

    Microservices are cool, but service mesh makes them ice cold. If you’re on the microservices journey and are finding it difficult to manage the infrastructure challenges, a service mesh may be the right answer. Let me know if you have any questions on how to get the most out of service mesh, I’m happy to talk and you can find me @zjory.

    — Zach Jory