Tag: CA Technologies

  • CA Technologies Survey Uncovers DevSecOps Challenges

    CA Technologies Survey Uncovers DevSecOps Challenges

    When it comes to infusing security concerns into a DevOps culture, most organization still have a very long way to go. A global survey of 1,279 IT leaders conducted by the market research firm Freedom Dynamics on behalf of CA Technologies finds more than half of respondents (58 percent) cited existing culture and lack of skills as hurdles to being able to embed security testing and evaluation within software development processes. Only 24 percent strongly agreed that their organization’s culture and practices supported collaboration across development, operations and security.

    More challenging still, less than a quarter of respondents strongly agreed that senior management would sacrifice time to market to make sure there is sufficient time to assess and repair software security vulnerabilities.

    Chris Wysopal, CTO for the Veracode portfolio of security testing tools CA Technologies acquired last year, said the survey results make it clear many organizations are still wrestling with the concept of DevSecOps. Many of them may be far along the path to building a culture around DevOps, but more often than not, security teams haven’t been included in those processes, says Wysopal.

    Because security teams are not included, many organizations wind up incurring substantial costs by having to address a much broader number of security updates to applications running in production environments. Organizations that have shifted security to the left as part of more comprehensive approach to DevSecOps discover and eliminate many more security issues during the development process.

    Wysopal said the survey bears out those conclusions. The survey finds the top 34 percent of respondents who report their organizations have been able to fully integrate security into their software development life cycles view security as an enabler of new business opportunities. These organizations typically exhibited 50 percent higher profit growth and 40 percent higher revenue growth. They are also 2.6 times more likely to have security testing keep up with frequent application updates. Wysopal conceded there’s no direct correlation between better security and better overall corporate performance. But at the very least, the results indicate that organizations that invest more time in DevSecOps are not adversely impacting financial performance.

    Organizations that embrace DevSecOps not only ship higher-quality software that reduces total cost of application ownership, they also typically are in a much better position to absorb the application update impact of unexpected security events such as Spectre and Meltdown flaws being discovered in processors. Because of the need to patch these flaws, most application update processes are now being stressed across the entire IT industry.

    It remains to be seen what impact the need to quickly address these flaws will have on adoption of DevSecOps. Wysopal noted the old way of addressing security issues during a waterfall-based approach to application development simply don’t work in the age of agile development. IT security teams now need to work hand in glove with application developers. The challenge now, Wysopal said, is getting the leaders of those organizations to come to terms with the impact that change may have on the pace at which software is developed. But given the critical role software now plays in critical business processes, organizations soon will come to appreciate the need to better balance the speed of application development speed against all the potential risks involved.

    — Mike Vizard

  • CA Technologies Extends DevOps Push

    CA Technologies Extends DevOps Push

    At its CA World 2017 conference this week, CA Technologies moved to tighten the integration between the various elements of its DevOps portfolio acquired over the last year and unveiled CA Digital Experience Insights, an analytics-infused monitoring tool delivered via a software-as-a-service (SaaS) model.

    The company also announced an instance of the CA Microservices Gateway that allows the API management platform to be deployed as a Docker container. Earlier this week, CA Technologies launched a beta release of Fastrack.io, a service for monitoring Kubernetes clusters based on machine learning algorithms and embedded in an instance of the open-source Prometheus container monitoring service.

    The company is also adding CA Virtual Test Data Manager, a tool that makes it simpler to create copies of large data sets for testing purposes, and CA Service Virtualization Community Edition and CodeSV, a plug-in that enables DevOps teams to invoke service virtualization from within their integrated development environment to mimic external services without having to connect to an actual instance of those services running in a production environment.

    Additionally, CA Technologies announced it has integrated CA Veracode security testing software with CA Automic IT automation platform, and announced general availability of BlazeMeter API Test, a SaaS-based API testing tool, and CA Continuous Delivery Director SaaS, a service that integrates the DevOps toolchain.

    Aruna Ravichandran, vice president of DevOps product and solutions marketing for CA Technologies, says each of these offerings are part of a larger company effort designed to enable organizations to set up their own software factories. Now that more organizations have come to realize their ability to differentiate themselves depends on custom software, many of them want to be able to acquire all the integrated DevOps tools required to achieve that goal from a single vendor, Ravichandran says.

    CA Technologies is making a concerted effort to link the need to create a software factory as a prerequisite for driving digital business transformation at scale. To achieve that goal, she says, control over IT operations is continuing to shift to the left as developers become more accountable for the entire application experience. Offerings such as CA Digital Experience Insights make it simpler for developers to holistically manage those end user experiences by infusing predictive analytics and machine learning algorithms coupled with improved data acquisition techniques in a single service, Ravichandran says.

    CA Technologies clearly wants to become a DevOps force to be reckoned with. In the last two years it has acquired Blazemeter, Automic, Veracode and Runscope. Prior to that, the company acquired Rally Software, Nolio, Grid Tools and Layer 7 Technologies. From here it’s likely CA Technologies will continue to expand its portfolio by acquiring companies while tightening the integration between the various code bases that make up its DevOps portfolio.

    The company’s stated goal is to provide a suite of DevOps tools and services that are too compelling to ignore without forcing IT organizations to consume a product or service they don’t want by maintaining open interfaces across the portfolio. The degree to which CA Technologies can succeed in that effort remains to be seen. But there’s no getting away from the fact that the company has now assembled a formidable DevOps arsenal of products and services.

    — Mike Vizard

  • CA Technologies Positions Automic at the DevOps Core

    CA Technologies Positions Automic at the DevOps Core

    After acquiring Automic earlier this year, CA Technologies suddenly found itself with an embarrassment of IT automation riches. Now the company is moving forward by further integrating the Automic IT automation platform with the rest of the portfolio of tools and services that it says are required to construct a software factory.

    Ron Gidron, technology evangelist for Automic, says the latest version of Automic increases the number of integrations with the rest of the CA Technologies portfolio to include support for CA Test Data Management, Service Virtualization, Privileged Access Governance, Application Performance Management and Veracode application security software, among others.

    CA Technologies has made it clear it intends to make the release automation software originally developed by Automic the foundation of its overall DevOps strategy. Most of that effort is now focused on integrating the various elements of the CA Technologies portfolio. Longer term, CA Technologies will eventually move to rationalize any duplication in functionality.

    Version 12.1 of Automic also brings forward orchestration tools and self-service capabilities to enable developers to provision resources within guidelines defined by IT. Gidron says that while there will always be a need for IT operations specialists, CA Technologies is making a concerted effort to “shift left” to provide developers with more programmatic control over the IT environment. To facilitate that process, Automic and the rest of CA Technologies have been investing in creating a standard set of external-facing REST APIs, which also will be used to make it easier for products and services created by the company to consume a wide variety of external data and metrics.

    Via acquisitions and internally developed software, CA Technologies is clearly trying to unify application, infrastructure and security management with the context of a single DevOps framework. The company doesn’t plan to force organization to consume that entire stack of software. But it will try to make acquiring as much of its portfolio as financially attractive and frictionless as possible to drive what the company describes as intelligent automation across a modern software factory. Driving that need is the realization that just about every company in every industry is now dependent on some form of custom software to drive one digital process or another.

    The rate at which CA Technologies has been expanding its DevOps portfolio via acquisition is a major contributor to what appears to be a wave of consolidation starting to occur across the DevOps category. Regardless of how advanced any organization might become in terms of building a software factory, major IT vendors realize that it’s only a matter of time before IT organizations start to pressure them to bundle more DevOps-related functionality together. In fact, the line between what’s DevOps today and tomorrow versus what was considered traditional IT management appears to be getting more blurred with each passing day.

    — Mike Vizard

  • CA Technologies Acquires Runscope for API Monitoring

    CA Technologies Acquires Runscope for API Monitoring

    There’s a pressing need for a variety of monitoring tools more than ever. But given the proliferation of application programming interfaces (APIs) inside the enterprise, demand for API monitoring tools in particular is rapidly expanding. To address that requirement, CA Technologies has acquired Runscope, a provider of an API monitoring service delivered as a software-as-a-service (SaaS) application.

    Ali Siddiqui, general manager for agile operations at CA Technologies, says Runscope will complement CA Blazemeter continuous testing tools the company acquired last year and the CA API Management platform based on the technology CA Technologies gained when it acquired Layer 7 Technologies in 2013.

    While the API Economy has been a phenomenon for external-facing web and mobile applications for years now, Siddiqui notes that IT organizations have only begun to rely on APIs to ingrate internal applications in recent years. The number of private internal APIs that have been published already dwarf the number of external public APIs. Because those internal APIs have now reached a critical mass, Siddiqui says the time is now right for CA Technologies to add an API monitoring service to portfolio of DevOps tools.

    He notes that the rise of microservices inside enterprise IT organizations also will exacerbate existing API monitoring and management challenges. Each microservice generates its own API, which needs to be maintained and monitored. Before too long IT organizations will find themselves trying to unravel the interdependencies of thousands of microservices that all expose an API that can be developed in any number of programming languages.

    These days it’s not uncommon to see dedicated management teams focusing on specific APIs. Rather than treating the API as an afterthought, many IT organizations have come to realize it’s the quality and robustness of the API that ultimately determines the quality of the application experience. In fact, most service level agreements (SLAs) going forward will require access to data being generated by APIs to make sure the terms of any agreement are being met. As such, it’s starting to make sense in some organizations to organize DevOps teams around critical APIs, rather than specific elements of application logic that, in the age of the containers, will soon be more frequently updated.

    There’s no shortage of API monitoring tools these days, and Siggiqui says CA Technologies is committed to making sure the Runscope service remains open in terms of integration with other API management and testing tools. However, eventually there will be incentives provided to organizations that choose to standardize on multiple DevOps tools from CA Technologies.

    Despite the proliferation of monitoring tools, the percentage of application workloads that are instrumented remains relatively small. The reason for this is that the cost of monitoring every enterprise application has often proven prohibitive. The issue that enterprise IT organizations will have to confront as dependencies between microservices increase will be figuring out how to implement instrumentation across all those services in a way that doesn’t wind up breaking the budget.

    — Mike Vizard

  • VMware Cloud on AWS Will Bring DevOps Issues to a Head

    VMware Cloud on AWS Will Bring DevOps Issues to a Head

    Now that instances of VMware are starting to become available on Amazon Web Services (AWS), a DevOps ecosystem is starting to emerge around the management of applications workloads moving into and out of AWS.

    Among the more than 4,500 applications that VMware claims already support VMware Cloud on AWS are those from Blue Medora, CA Technologies, Chef, Cloudbees, Dynatrace, Jfrog, Puppet, SaltStack and the Ansible arm of Red Hat.

    VMware CEO Pat Gelsinger told attendees at the recent VMworld 2017 conference that VMware and AWS are just now scratching the surface of what they plan to accomplish together. AWS CEO Andy Jassy added that, unlike other alliances, which consisted mainly of marketing, engineers at both companies are working closely together to deliver VMware globally across all AWS availability zones. At present, VMware Cloud on AWS is available in the AWS availability zone hosted in Portland, Oregon. The service soon will be extended to the east coast of the United States, followed by rest of the world over the course of 2018.

    The availability of VMware Cloud on AWS should force several DevOps issues within enterprise IT organizations that have deployed the VMware stack of software mainly on-premises. Many of those organizations have also been employing public clouds such as AWS. But because those environments are based on different hypervisors, it was never easy to migrate workloads between the two platforms. There are plenty of options for running VMware software in the cloud, but because AWS is the largest provider of public cloud services, there are many customers who want to seamlessly move workloads between their on-premises IT environments and AWS via a common stack of VMware software.

    In many organizations the desire to shift applications workloads into AWS will bring many DevOps issues to a head, as VMware and AWS use has occurred in independently of each other. There could be many workloads running on each platform, but for all intents and purposes, IT organizations have managed both platforms in isolation. Now that VMware is becoming available on AWS, all the challenges associated with moving workloads between a public and private cloud come to the fore.

    Most of those DevOps issues will be focused first on moving some classes of workloads running on VMware into AWS. Application workloads that don’t need to run constantly will be among the primary candidates followed by a slew of data protection applications that will enable IT organizations to back up and archive massive amounts of data inexpensively. Next up will be applications that need to be distributed globally to increase availability.

    At the same time, a lot of VMware shops will be moving application development into the cloud. But just because an application is developed in the cloud doesn’t mean it will stay there. Many IT organizations have already discovered that when it comes to long-running applications, the total cost of deploying them on-premises is less than deploying them on a public cloud. The DevOps tasks ahead, of course, will start with figuring out which VMware-based applications make the best candidates from a financial and availability perspective to be deployed on AWS.

    — Mike Vizard

  • Moving from ‘Tester’ to ‘Quality Enabler’

    Moving from ‘Tester’ to ‘Quality Enabler’

    Speed versus quality. Can you really have one while the other exists?

    When Agile came on to the scene, it pushed to get development teams to create code as quickly as possible. Then DevOps came on as a practice that helped these Dev teams and the Ops side of the house to interact and collaborate more on best practices, tools to use and pinpointing issues in operations.

    But the testing practices and QA teams have had challenges keeping up with all this code that is getting thrown their way at an avalanche pace. That is probably why nearly two-thirds of self-proclaimed DevOps practitioners report that their biggest bottleneck occurred in the QA/Test phase. In fact, this cited bottleneck was more than 2 times greater than the No. 2 proclaimed bottleneck, planning (29 percent).

    It’s been said that “the consumer appetite to engage via digital channels is matched only by intolerance for any defects that might have an impact on their user experience and business outcomes.” If organizations are going to speed their delivery pipeline, they need to remember that the success of continuous delivery hinges on the effective employment of continuous testing.

    Part of the problem remains with manual testing practices. You can’t manually test millions of lines of code, then try to figure out the customer experience during integration testing with other internal or third-party systems and API, with hundreds of microservices or varying mobile devices.  The complexities of today’s composite apps make it impossible.

    And traditional, legacy testing tools don’t help, either. Gone are the days of waiting for the UI to be complete before QA teams begin their testing. And gone are the days of developers throwing code over the wall to the testing team and washing their hands of it.

    A few other facts:

    1. Ninety-one percent of QA professionals agree that the role of testing must change to meet the demands of today’s agile development needs.
    2. Only 1 in 3 organizations involve QA in planning requirements.
    3. Fewer than 1 in 5 organizations write new tests each time new code is checked in.

    The idea of continuous testing helps to solve that. Continuous testing is the practice of testing across every activity in the software development life cycle (SDLC) to uncover and fix unexpected behaviors as soon as they are injected. That can’t happen in the above environments.

    A new ebook from CA Technologies and devopsy.kinsta.cloud notes that to continuously deliver software, organizations need to make sure tests, procedures and processes around quality are designed to fit in line with the flow of development, integration and deployment. While continuous testing is dependent upon strategic automation, it is not synonymous with automated testing—a continuous testing process encompasses other important QA activities that impact overall product quality.

    As such, continuous testing depends on four major pillars:

    1. Code Quality – Did developers create the application code correctly?
    2. Pipeline Automation – Can the application code work across environments without manual intervention?
    3. Application Quality – Did developers create the correct features?
    4. Customer Experience – Are users perceiving value in the application delivered?

    These four pillars are discussed in more detail in this continuous testing ebook. You’ll learn the evolutionary journey you can take to shift testing practices left, and really make testing and quality everyone’s responsibility. You’ll even read how GM Financial was able to transform its load practices by implementing some of these practices. See how you can start using these pillars in your QA efforts.

    Now is the time to elevate QA’s new role from that of tester to quality enabler.

    — Scott Edwards

  • Lack of Continuous Testing Mastery Slows DevOps Progress

    Lack of Continuous Testing Mastery Slows DevOps Progress

    Progress in achieving the maximum benefits to be gained from investing DevOps processes appears to be held in check by a failure to master the art of continuous testing. A new survey of 923 IT and testing professionals published this week by CA Technologies suggests that only 20 percent of the respondents could be classified as “leaders” when it comes to implementing continuous testing.

    A full 93 percent of respondents identified testing automation as important, but only 1 in 5 respondents said they achieved a high level (80 percent or more) of test automation coverage. Seventy-five percent said continuous testing is important as well. Unfortunately, most of the respondents continue to rely on manual processes. In fact, respondents attributed continuous testing challenges to the lack of automation in almost every aspect of the testing process, including generation of test cases through test execution to critical activities such as fast, safe and efficient test data management.

    Scott Edwards, senior director of product marketing for CA Technologies, says failure to automate continuous testing will only lead to an increased DevOps divide. Organizations that have automated DevOps processes not only release more code faster, the report find they enjoy advantages such as:

    • 2.3 times more likely to have succeeded in left-shifting testing activity to developers;
    • 2.6 times more likely to reduce defects by more than 50 percent;
    • 2.4 times more confident in quality of output;
    • 1.9 times more confident in speed of delivery; and
    • 3.9 times more likely to be working in an organization exhibiting rapid revenue growth.

    Edwards says those results indicate that organizations that are further down the DevOps process will enjoy a substantial competitive advantage at a time when organizations of all sizes are realizing how dependent they are on software to differentiate themselves. Organizations may be operating in a variety of vertical industries, but increasingly they are becoming software companies that happen to specialize in a specific area, says Edwards.

    Making that shift requires IT organizations to move away from thinking about developing applications as an art to building what amounts to a software factory, he says. The factory approach not only eliminates silos in the DevOps process, it also should ideally allow developers to continuously test their own applications. Of course, the biggest issue with testing may very well be the simple fact that most developers build applications today using notebooks and workstations that don’t accurately reflect the complexity of the data center environments those applications will ultimately be deployed in. However, thanks to the rise of technologies such as service virtualization and cloud-based development environments, it has become easier to more closely mimic production environments.

    The degree to which an absence of continuous testing impedes both the rate at which applications are deployed in a production environment will naturally vary by organization. But the one thing that is almost certain is that organizations that have mastered continuous testing are much more likely to deliver a quality application experience than those that don’t.

    — Mike Vizard

  • DevOps Matchmaking: APM + CI = A Perfect Marriage

    DevOps Matchmaking: APM + CI = A Perfect Marriage

    As anyone who has ever been set up on blind dates by friends can attest, finding the right match in today’s world is a tricky feat.

    There’s a lot of evidence suggesting that the frantic pace of life makes such matchmaking more difficult than ever. That said, when the right set of complimentary traits exist and there’s a willingness to find common ground, things can work out.

    Spike Jonzian-notions of artificial intelligence aside, certain technological partnerships are increasingly being perceived as “a perfect marriage” within the context of DevOps automation.

    Register today for the upcoming webcast: “Using APM to Turbocharge Continuous Integration”

    These technological matrimonies closely support the underlying tenets of DevOps methodology—collaboration, experimentation and increased velocity. In fact, it’s easy to wonder why no one ever conjoined them before. But we were using traditional waterfall development and operations and so couldn’t conceive of such a thing. On the other hand, emerging availability of tooling supporting new integrated workflows represents a significant catalyst.

    Finding the Perfect Fit

    One such DevOps confederation getting a lot of attention is the matchmaking of continuous integration (CI) and application performance management (APM) technologies. Tying together these once-disparate systems makes a lot of sense, despite the fact that few tools would seemingly appeal to more (traditionally) polarized constituencies.

    Continuous integration has been a staple of the development community for many years. It emerged as teams evolved the practice of long build times into more frequent check-ins to deliver code and look for potential errors more quickly. Today, with the rise of CI tools such as the Cloudbees Jenkins platform, some development teams are touting tens of thousands of builds per day.

    On the other end of the spectrum, squarely on the turf of IT operations, APM has been evolving rapidly over the past few years as organizations have sought to improve use experience and applications reliability via dedicated monitoring. Enabling this ability to identify and address emerging issues has resulted in APM becoming the fastest-growing segment in the IT ops management market, according to Gartner.

    DevOps matchmaking factors in when you bring these tools together to create an automated workflow that spans their respective use cases. A cross-functional team can leverage APM-level monitoring and KPIs within the domain of CI and testing to identify potential performance obstacles introduced in new code. Doing so then rather than waiting to respond later in the applications life cycle benefits everyone.

    Reaping the Benefits

    For example, say an e-commerce applications developer has implemented a new inventory search functionality—something considered a key differentiator by business management. The developer knows this feature could rely heavily on some back-end database system and wants to ensure it’s tested properly, even as the code is being introduced.

    Integrating APM and CI allows the entire team to monitor the process and test various conditions related to the update, tracking multiple builds and looking out for related performance issues. Such integration also allows for centralized tracking of other key attributes such as build number, status and build date, to further ease management.

    Most importantly, by tying these two critical aspects of the applications delivery life cycle together, the collaboration and feedback loops required to truly embrace DevOps methodology become ever more valuable as these core Dev and Ops functions become intrinsically linked.

    If this type of DevOps advancement gets your heart pumping, you’re not alone. Later this month, we’ll host a webcast here on devopsy.kinsta.cloud featuring experts from CA Technologies and Cloudbees. They’ll be discussing the benefits of matchmaking with APM + CI integration. They’ll also detail real-world benefits organizations leveraging integration of our respective technologies (CA APM and Cloudbees Jenkins) enjoy.

    We obviously feel that this is a DevOps tooling marriage that will mature, change and stand the test of time. We’d love to garner your questions and feedback on the topic.

    Which is all good, because thankfully there’s no such thing as Tinder for DevOps … yet.

  • CA Technologies Delivers First Integrated and Open Continuous Delivery Ecosystem, Enabling Organizations to Deliver Applications Faster and More Efficiently

    CA Automates Complete Application Lifecycle for Improved Deployment Times and Testing Efficiency

    New York, June 15, 2016 – CA Technologies (NASDAQ: CA) today announced the availability of CA Release Automation Continuous Delivery Edition, and several new integrations across CA’s DevOps portfolio and third party solutions creating the first integrated, fully automated and open continuous delivery ecosystem. Organizations can now connect and automate the entire app pipeline progression from development, to test, to production, to accelerate deployment times of applications by as much as 20 times* and improve testing efficiency by up to 25 percent**.

    “To thrive in the application economy, digital transformation must be driven by continuous delivery—the ability to rapidly and reliably release applications that meet the demands of external and internal customers alike,” said Jeff Scheaffer, general manager, Continuous Delivery, CA Technologies. “CA is the only DevOps solution provider that currently bridges development, testing, release management and operations in an open, seamless tool chain that helps organizations achieve entirely new levels of application delivery speed and quality.”

    Develop Swiftly, Test Agilely and Release Reliably 

    As organizations progress on their digital transformation journey, the volume, velocity and complexity of applications continues to grow. “Businesses no longer have the luxury of time. Rising customer expectations, competitive threats, and increased consumer choice have turned rapid delivery and iteration of software applications into a competitive differentiator. Optimizing the delivery value chain has become the new means to better business outcomes,” according to Forrester Research.***

    For application owners tasked with rapidly delivering innovative and inspiring applications, but struggling with constraints and dependencies across the software development lifecycle, CA helps eliminate these challenges by providing continuous delivery capabilities that enable organizations to improve release planning and orchestration, use agile testing to test less and cover more, provision data on demand and deploy simulated environments – all with zero touch workflow.

    This is accomplished through:

    “With CA’s continuous delivery solutions we’re standardizing our application products, achieving consistency between server environment platforms and are able to easily integrate CA Release Automation with other continuous integration applications such as Jenkins,” said Matt McComas, AVP Critical Applications, GM Financial. “As a result, we are quickly identifying and resolving inconsistencies in our application environments and have been able to cut deployment times down to two and a half minutes for a 98% reduction in deployment time.”

    Furthermore, to help organizations leverage existing investments, CA’s continuous delivery solutions integrate easily with market tools such as HP Application Lifecycle Management (ALM), Atlassian’s JIRA Software, Jenkins, Docker, Perfecto, Chef and Puppet for an open and fully integrated continuous delivery solution stack.

    “By using different CA tools as part of the software development lifecycle, testing is no longer a gatekeeper, but rather an operational quality door opener that helps simplify the development of new releases,” said, Arnold Hoogerwerf, IT strategy advisor at KPN, a leading telecommunications company in the Netherlands. “The tools we use from CA’s set of continuous delivery solutions have allowed us to reduce our investment and increase our agility in testing and helped us discover defects earlier so we can continually improve the quality of our applications in a shorter timeframe.”

    Release automation goes hand-in-hand with DevOps practices and Cloud technologies to ensure that organizations can deliver apps that provide the very best customer experiences and drive competitive advantage in today’s app-driven, cloud-connected, mobile-everything world. The open and flexible architecture of CA’s continuous delivery solutions can help organizations deploy applications to modern Cloud platforms such as Amazon Web Services, Microsoft Azure and Skytap as a standard part of their app delivery practices.

    To learn more, join InformationWeek, CA Technologies and a team of industry experts on Wednesday, June 15 from 11 a.m. ET to 1 p.m. ET for the live virtual event, Automation, Speed and Quality: The Keys to Your Continuous Delivery Journey. To register for the event or watch the replay visit,http://cainc.to/Wfn25T.

    Resources

    • The Total Economic Impact™ Of CA Release Automation, Forrester Research, December 2015

    **The Total Economic Impact™ Of The CA Technologies Test Data Manager Solution, Forrester Research, December 2015

    ***TechRadar™: Continuous Software Delivery, Q2 2015, Forrester Research, May 1, 2015

    About CA Technologies

    CA Technologies (NASDAQ:CA) creates software that fuels transformation for companies and enables them to seize the opportunities of the application economy. Software is at the heart of every business in every industry. From planning, to development, to management and security, CA is working with companies worldwide to change the way we live, transact, and communicate – across mobile, private and public cloud, distributed and mainframe environments. Learn more at www.ca.com. 

     

    Press Contact 

    Michelle Laidlaw

    Public Relations

    (631) 342-4701

    michelle.laidlaw@ca.com

  • Does DevOps drive agility, or does agility result in DevOps?

    Does DevOps drive agility, or does agility result in DevOps?

    DevOps is a hot topic. Hell, I’m writing this on a site dedicated specifically to DevOps and you’re reading it, so it seems safe to assume we agree on the general premise that DevOps is an important trend for both business and IT. I question however, giving all of the credit for cost cutting, or for more agile and effective organizations to DevOps.

    A recent survey commissioned by CA Technologies titled DevOps: The Worst-Kept Secret to Winning in the Application Economy makes the claim that 88 percent of IT professionals surveyed have already implemented DevOps or plan to within the next five years. It also notes that companies that have already adopted DevOps have experienced 14 to 21 percent improvement in quality and performance of applications and/or faster time-to-market. Clearly DevOps is virtually ubiquitous, and companies that embrace DevOps are all but guaranteed to be more effective and efficient.

    Well, no. Not really. I’m a huge fan of DevOps, and I think there is a very good chance that organizations that adopt DevOps are likely to experience tangible, measurable benefits. However, one does not necessarily lead directly to the other and, in fact, it may be the other way around. Perhaps organizations that are doing the right things to yield improvements that result in more efficient and effective operations are also the organizations that are likely to embrace DevOps. I call this “Does DevOps drive agility, or does agility result in DevOps?”

    For starters, we still can’t even narrow down a concise explanation or definition of DevOps we can all agree on. So when we say that an organization’s success is the result of DevOps, what do we mean? Is it because the company broke down barriers between teams and enabled workers to collaborate together more efficiently? Is it because the company moved its infrastructure to the cloud and automated deployment of virtual servers and applications? Or is it because the company embraced specific tools or platforms like Chef, or Docker?

    There is an argument to be made that much of what comprises the strategic side of DevOps is just a natural, cyclical occurrence in business. There’s always some new management philosophy or business model du jour with a catchy buzzword, and right now it’s DevOps. Part of the reason that DevOps remains such an ethereal concept is that most of the organizations employing DevOps don’t realize they’re using DevOps, and they don’t call it that. Those organizations are just responding to the realities of competing today in the best way they can. That effort seems to lead invariably to embracing philosophies and strategies that have been collectively dubbed part of the DevOps culture.

    The organizations that started it all didn’t sit down and say “OK. We should start by adopting DevOps tools and strategies.” Companies like Netflix didn’t “embrace” DevOps—they created it from scratch, organically, and developed the tools and strategies that form the foundation of the DevOps movement. Everything that follows is an attempt to mimic the success of those organizations.

    If it’s a question of which came first, the chicken or the egg, it seems clear to me that DevOps is the outcome of a culture shift more than the engine or catalyst of the culture shift. To be fair, DevOps has matured, and is evolving into a culture all its own, and the tools and philosophies that make up DevOps are more clearly defined as time goes on. A company looking at it today can explore successful tools like Chef and Docker, and study examples of other organizations that have achieved success through DevOps principles.

    We still need to be careful, though, when breaking down statistics like those in the CA survey. Companies that are more agile, and deliver better quality products more quickly may also have adopted DevOps tools and strategies, but it doesn’t necessarily imply a direct cause and effect between the two. Perhaps as DevOps matures and the definition of the strategies and tools that comprise it becomes more consistent it will be easier to state clearly whether or not an organization has “adopted DevOps” and apply metrics that directly measure the effects of DevOps unique from the metrics the company would achieve anyway with or without DevOps.