devopsy.kinsta.cloud

Tag: CA

  • Open Mainframe Project Launches Zowe to Advance DevOps

    Open Mainframe Project Launches Zowe to Advance DevOps

    The Open Mainframe Project has launched Zowe, an effort to make mainframes running z/OS both more accessible and programmable using REST application programming interfaces (APIs).

    Announced at the Open Source Summit, the Zowe project is being led by IBM, CA Technologies and Rocket Software.

    Matt Hogstrom, chief architect for z/OS Systems at IBM, said the goal of the Zowe project is to attract a new generation of IT administrators to the mainframe platforms and make it simpler to include mainframes within the larger scope of an integrated set of DevOps process spanning multiple platforms.

    In addition, IBM, CA Technologies and Rocket Software collectively are trying to create an ecosystem around the mainframe that resembles more of the types of interactions that occur between companies that participate in the Linux community, Hogstrom said. The Open Mainframe Project operates under the auspices of the Linux Foundation.

    Now that IBM mainframes are more than 50 years old, IBM and its allies are increasingly relying on open source tools to make sure mainframes stay relevant for another 50 years, he said.

    To achieve that goal, Zowe provides access to an extensible z/OS framework that provides new APIs and z/OS REST services. The Open Mainframe Project, as part of Zowe, has also created a unifying workspace based on a desktop app container accessed via a browser and a scriptable command line interface (CLI) that makes it easier to integrate z/OS into cloud and distributed environments using a set of low-code tools.

    Greg Lotko, General Manager for Mainframe at CA Technologies, said the contributions to the Zowe Project made by CA Technologies are based on CA Brightside, a set of DevOps tools developed specifically for mainframe environments.

    The biggest challenge the mainframe community now faces is a dwindling pool of talent. Most college graduates today have limited exposure to mainframes at a time when many of the IT professionals who do have mainframe skills are retiring. In the absence of skills to manage mainframes, IT organizations wind up making decisions regarding where to put workloads based on the availability of expertise available to run those platforms. IBM, CA Technologies and Rocket Software all have a vested interest in leveraging DevOps tools and processes to eliminate the silo that currently exists between mainframes and other platforms by making it easier to call services residing on a mainframe using REST APIs, while at the same time making it easier to manage mainframes within the context of a common set of DevOps processes spanning multiple platforms.

    Mainframes, of course, are still comparatively expensive platforms to acquire. IBM has sharply reduced the cost of mainframes over the years. But the primary economic value proposition of mainframes is that the total cost of operating a mainframe is less than a distributing computing environment running a comparable set of workloads. Mainframes are highly automated, so IT organizations that can afford the cost of entry tend to still favor mainframes for complex transaction processing and analytics applications. The challenge—and opportunity—for mainframe shops now is in turning those applications into a set of reusable services that can be readily invoked from anywhere in the enterprise.

    — Mike Vizard

  • CA Technologies Looks to Shift Automation Left

    CA Technologies Looks to Shift Automation Left

    CA Technologies, at its recent CA Automation Summit, advanced its case for leveraging automation to create a software development factory via an update to the CA Automic One automation platform that adds automation-as-code functionality.

    Gwyn Clay, vice president of product management for the Automation Business Unit at CA Technologies, said the latest release of CA Automic One make is simpler to “left shift” automation artifacts by making it possible for developers to embed those artifacts within application code versus having to wait for a DevOps teams to run them out of band.

    The latest version of CA Automic One also now includes version control and lifecycle management for automation artifacts that enables automation objects such as jobs, workflows and scripts to be promoted from development to production as part of an integrated DevOps process, said Clay.

    CA Technologies also revealed it is embedding intelligence into workflows enabled by CA Automic One, which enables dynamic runtime estimations that can predict potential issues within certain paths in the workflow execution.

    Other new capabilities added to the automation platform include support for PostgreSQL databases, as well as new integrations with CA Workload Automation, CA Continuous Delivery Director and CA Jarvis analytics software delivered as a cloud service.

    CA Technologies has been on a multi-year campaign to embed automation across the entire DevOps processes. With this latest release, that campaign effort is being extended to developers themselves. Clay said the rise of digital business transformation—much of which is being driven by cloud-native applications built with technologies such as Docker containers, Kubernetes orchestration software and serverless computing frameworks—is finally forcing the automation issue in the enterprise. Not only are applications being built faster than ever, but the complexity of those applications has increased exponentially. And yet, the size of the overall IT staff has remained stagnant. Without some form of automation being embedded within the applications itself modern software development practices becomes difficult to sustain, she said.

    Clay noted that most organizations are not yet at the point where they are deconstructing monolithic applications into a set of microservices. But it’s already clear most new applications will be built on a microservices architecture. CA Automic One represents an opportunity to apply automation across both legacy monolithic applications in addition to embedding artifacts directly within new applications, she noted.

    It’s not clear the impact the ability to embed automation artifacts will have on how enterprise IT is managed going forward. IT operations teams still will need to be able to set policies and constraints concerning the level of automation a developer might be able to invoke. Most developers don’t have much regard for the need to share limited infrastructure resources with other applications. But as the ability to infuse automaton into almost every application becomes pervasive, the locus of power within enterprise IT organizations will continue to shift to the left. The challenge now is determining the best way to strike a balance between all the competing factions looking to control who gets to automate what exactly when.

    — Mike Vizard

  • DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    DevOps Chat: The Kitty Hawk Venture & Continuous Testing w/ Aruna Ravichandran

    A great new book on DevOps is coming out called “The Kitty Hawk Venture.” In the vein of “The Phoenix Project,” it is a novel about one fictional company’s journey specifically with continuous testing. Based on a real-life airline company, the book is great case study and learning experience around continuous testing and its importance to the entire CI/CD and DevOps experience.

    The book is written by Jeff Schaeffer, general manager of the Continuous Testing business unit at CA Technologies; Alex Martin, CTO of Continuous Testing at CA Technologies (and former CTO of Rally Software); and Aruna Ravichandran, vice president of  Gobal Marketing at CA Technologies and author of “DevOps for Digital Leaders.” Beyond the book, there is a companion ebook on continuous testing, as well as other related content.

    In this DevOps Chat, we speak with Aruna, who is a frequent guest on our chats, about the book, continuous testing and the overall DevOps market. It is an excellent chat and, as usual, Aruna’s passion for what she does and DevOps shines through.

    For those not familiar with our DevOps Chats, the streaming audio of our conversation is immediately below, followed by the transcript of our conversation.

    Audio

    Transcript

    Alan Shimel: Hey everyone, it’s Alan Shimel. devopsy.kinsta.cloud. You’re listening to another DevOps chat. This is gonna be a really great chat. I have one of my dear friends in the DevOps industry joining us. Aruna Ravichandran Ravichandran, VP of Marketing DevOps at CA technologies. But more than that, now a multi-time author as well as a code engineer and a bunch of other things. She’s had an amazing, amazing life and career. Aruna Ravichandran, welcome.

    Aruna Ravichandran: Thank you, Alan. I am very excited to be here with you today talking about my latest book.

    Shimel: Yup. So it’s a new one coming out, hopefully in July I guess is the current timeline. And it’s called, “The Kitty Hawk Venture.”

    Ravichandran: That is exactly right. So you know, I think we chatted about a year ago when I wrote my first DevOps book. It was called, “DevOps for Digital Leaders.” And what we decided to do based upon the substance of the book is to basically to take a leaf from the Phoenix Project and write this book in terms of a real life story about one of our customers. I can’t name who the customer is. And the book is actually called, “The Kitty Hawk Venture.”

    And it’s a novel about continuous testing in the world of DevOps in order to help customers as they’re going through their digital transformation journey. So it’s not written as a continuous testing handbook.

    But it’s basically a real life example which happened with one of our customers and tells the story of the journey they actually went through in terms of how they actually transformed their testing discipline, lines of automation down to continuous testing and how they actually addressed some of the bigger challenges they actually had internally across the board.

    Shimel: Got it. So Aruna Ravichandran, I promised you and I promise our audience, no spoilers on this. So I don’t want to go too much into the actual story of the book, let’s keep it at a high level and say that it is about continuous testing and it is based on a real life customer experience. Maybe an amalgamation of customers.

    But you know, Aruna Ravichandran, you mentioned your first book, “DevOps for Digital Leaders.” So this is then your second book on DevOps.

    Ravichandran: Yes, it is. But this time I’ve actually focused on one of the emerging disciplines within DevOps. the first book was primarily focused around DevOps as a discipline, some of the challenges customers actually face.

    Where do they actually start. Because you know, there is no hard and fast rule in terms of DevOps. you can start with continuous integration. You could start with continuous operations. Or you could start with continuous testing.

    The book was primarily focused around end to end DevOps and gives some amount of coaching to the end reader on where to start, what’s the maturity model, what are some of the metrics, how do you measure the substance of DevOps.

    It also talks about several different customer examples on the journey they actually went through. But and speaking from that, we saw that a whole bunch of our readers are interested in learning more about an emerging discipline around continuous testing. So this book is primarily focused on continuous testing as a discipline and why it’s a very important area within the world of DevOps.

    Shimel: Yup. Now, Aruna , though, you hear it in your voice when you’re speaking to our audience here – it comes through loud and clear. this whole area of DevOps – continuous testing specifically with the book. It’s something that you are passionate about. I get it, you’re a VP in the DevOps group. You should feel an affinity. But this seems to go beyond your title and your job. It’s truly something you have a passion for.

    The book is almost 200 pages from the early view I saw. You don’t write 200 pages, you know, blah, blah, blah. You’ve gotta have sort of a burning passion. What is the passion that’s driving you?

    Ravichandran: So the passion that drives me is my customers. As I talk to my customers in the DevOps space, I am very passionate about solving customer problems. And as I talk to my customers, especially customers who want to make an impact, who are on their digital transformation journey, what I learned was testing is a discipline which has existed for several different decades across the board, the very first time when this actual code was actually implemented.

    But what you – what I actually found is that people have testing practices. But it’s mostly around islands of automation. Very, very few customers actually are doing end to end testing, which I call continuous testing.

    And even though you have islands of automation, what I actually find is that testing still continues to be manual. I did a poll of a whole bunch of enterprise customers across the board, and I was shocked to find that testing still appears to be 70% manual across the board.

    And given all of the – this is my personal reason for why I am very passionate about continuous testing, because I think that DevOps has gained a tremendous amount of precedent, but if you don’t embed continuous testing as a discipline across the software development life cycle, you really cannot go through DevOps.

    So continuous delivery has a lot of what do you say affiliation with the market. More and more people are getting educated on how to basically go through the CICD pipeline so that it can go from code to production in minutes. But what they realize is that if you don’t have the testing discipline embedded across the SCLC, going through the pipeline doesn’t buy you anything.

    And so that’s why this is a very important topic which I am very passionate about.

    Shimel: I mean, Aruna Ravichandran, on some level it’s almost – and I think I’ve heard you say this, continuous testing is almost the missing link. Right? In the continuous delivery, in the software development life cycle delivery chain. Right?

    For a lot of – you know what I mean? Companies, they focus on configuration management, on CICD, even on security. But that continuous testing is – it’s right there. It’s a lynchpin. The other thing I wanted to just quickly mention about it is continuous testing isn’t just a pre-delivery —

    Shimel: It’s truly continuous.

    Ravichandran: You nailed it. I would 100 percent agree with you on everything you stated. It is the missing link within DevOps. continuous testing is a practice of testing across every activity in the software development life cycle with the hope that you can uncover and fix unexpected behavior as soon as it’s ingested.

    So it’s about embedding testing as a fundamental and ongoing aspect of every activity through the application life cycle, going all the way from requirements down into production, while facilitating the pre-exact mechanisms what happens in the world of DevOps to where you can actually fix the problem throughout the life cycle.

    Shimel: Let me return to “The Kitty Hawk (Venture),” here again if I can for a moment. You mentioned earlier you took a page out of Gene Kim’s Phoenix Project book in that this isn’t similar to other books you’ve written and that I’ve even reviewed. That are your typical sort of business textbooks, right? You follow an outline and a table of contents and it goes. “Kitty Hawk” is more like you say – a novel, I think is the right word for it.

    How does that make it different for the reader? Or the listener if it’s an audiobook? For someone reading the book.

    Ravichandran: Yup. So for example – this book “[The] Kitty Hawk Venture” is actually based on the main character in the book is Leigh Freemark and she’s a senior director for quality assurance at a company called Runway Air. So the vertical we actually chose was an airline company.

    The way this book is actually written is it talks about the journey of what they actually went through from a transformation journey. So they experienced a major glitch in terms of quality and which caused a substantial amount of negative reputation for Runway Air.

    So this book actually walks through Leigh’s journey, the journey of her own personal mission of making quality first as a big part of her agenda.

    And the way this book is written – we have so many technical books which basically come into the market on DevOps and on testing, so on and so forth. So we wanted to basically – we took a leaf from “The Phoenix Project,” and we also took another leaf from “The DevOps Handbook,” which is the second book which was recently announced by Gene Kim.

    So this is basically written as a novel which tells you the journey which Leigh Freemark went through with Runway Air, but at the end of each chapter we give guidance in technical terms, of what was the actual continuous testing journey Leigh actually went through.

    Right? So that’s why I said, it’s written as a novel but at the end of each chapter we also have like a handbook around the continuous testing discipline on what changes people actually need to make in order to fully embrace continuous testing as a discipline in the book.

    Shimel: And even beyond that, Aruna Ravichandran, from what I understand and correct me if I’m wrong, you guys are planning on coming out with sort of an eBook companion to “Kitty Hawk” on “The Definitive Guide for Continuous Testing.” Is that correct?

    Ravichandran: That is exactly right and so we just actually published it and it will be out very soon. It’s called “The Definitive Guide to Continuous Testing.” And here, we walk our users through 11 different disciplines on continuous testing.

    Ongoing all the way on small teams [sound drops] _____ to how basically they can go through the transformation journey on continuous testing. And at a very high level, I walk you through eleven disciplines and you will see that completely in the novel because that was the journey which Leigh Freeman actually went through in the book, is the first discipline how do you basically and it will – the – you know, all of your testers.

    It could be a developer who is actually doing unit testing or it could be someone who is doing API testing or it could be load testing. Or it could be reproduction testing. All testing in production, you need to be able to have your environment set up. How do you quickly virtualize your environment becomes a very important part of the mix.

    How do you basically break on your environment, how do you actually create your environments very, very quickly is one of the first disciplines. The second discipline talks about testing management right? So regardless of what testing you’re doing having the right data at the right time is very critical. So how quickly can you generate your data?

    And given the world of GDPR right now, you know, which basically went into a test in May, people have to be even more critical about generating test data. You want to make sure that your GDP are compliant. And so having the test data at the right time is critical but also being compliant with a whole bunch of mandates out there is even more critical. The third discipline talks about test automation. How do you basically fully orchestrate the application pipeline.

    So that if the scripts actually fail, you can orchestrate how you can actually achieve continuous testing. The fourth one is around pipeline orchestration. This is the backbone. Everything is tied to it. everything must be integrated with your entire automation stream. You need to understand how it works, how to interpret the results and how do you make quick decisions in order to find out which part of testing is actually a bottleneck?

    And this is what we actually call pipeline authorization. The fifth one focuses on the various different competences, right? If you are testing, the world is going more towards an API economy. So how do you actually bring API testing discipline so that you reduce the reliance on UI testing? Especially for business logic testing.

    The sixth one is around performance and load testing. Right? So you can’t think about performance and load testing toward the end of the testing life cycle. You need to think about shifting left performance and load testing so that you can enable development teams to actually think about this much more earlier on.

    The seventh one is the around the new emerging practice around security testing. So this is where everybody talks about DevSecOps, it’s all about shift left security. How do you enable developers to actually embed static code analysis as a part of their unit testing?

    How do you basically get them to think about security testing by making it easy for them? By having it integrated as a part of their ID environments, whether it’s intelliga or it’s xless or visual studios, so on and so forth. So security testing is the seventh one.

    The eighth one is accidents of test driven development and behavior-driven development. So you take the accidents criteria for each user and create that to ensure that those were actually met. Right? So this keeps testing focused within sprints and ensures developers develop what the business actually expect.

    The ninth one is around automated test generation. And this is the activity of manually designing and writing manual tests of automated tests which is the biggest bottleneck.

    They are the computing magazine data surveyed very recently and they asked, which is the biggest bottleneck across your software development life cycle? 63% of the practitioners actually said that testing was a bottleneck. And why was testing a bottleneck? Because it takes time.

    Think about it, you have actually created 200 test cases for your regression suite for a vertical feature you are going to launch. Let’s assume you’ve caught a major defect and you fix the vertical defect, it means that you have to go back and recreate all of your regression text suites.

    And if there was an automated way that you could take your requirements and as things changed in production you can recreate your test suite, that will be a tremendous amount of savings for anybody to actually not have to create the test cases manually which then eliminates the bottleneck which we actually have.

    The tenth one is around requirement engineering. You must include all of SDLC stakeholders into your continuous testing journey. This means finding a better way to communicate and collaborate right from the requirements phase. The earlier one includes requirements engineering into continuous testing initiatives, the smoother that continuous testing journey will be. Because team members will be working with the same understanding right from the beginning.

    And the last but not least – the eleventh discipline talks about feedback loops. This is the heart and soul of DevOps, it still continues to be the heart and soul of continuous testing. These are critical to ensure that you can have successful continuous testing.

    Shimel: Excellent. You know, Aruna Ravichandran, sitting here looking – I want you to talk about quality, I don’t know if we have time. Maybe we’ll do it on another show. But the 11 disciplines, you did a great job laying them out here. I’m just wondering if someone listening says to themselves, oh my goodness, where do I begin? This is daunting. There is eleven of them. What is your advice to someone just starting out, listening in here – do I do eleven at all at the same time? What do I start with? What – do I take the path of least resistance? How do I get started with this?

    Ravichandran: So I break it up into six different areas, so this is a question you get asked for DevOps and you get asked the same question around continuous testing. So if I have to give guidance on techniques on how to actually adopt – it’s also a cultural transformation too.

    So the first one is, you know, you need to figure out a way to improve the relationship between the tester and each developer. So keeping the team small and creating inter-team collaboration makes it very easy to actually report and actually share the results between the tester and developer.

    So that would be one important tactic which needs to be adopted from a cultural transformation perspective. Number two, is like I said, people actually have automation within testing, which is what we call test automation. But they really haven’t automated the whole thing. So I would say continue to make automation a priority.

    So figure out where people are spending a lot of their time – it could be around building a regression test suite, because they tend to be manual. So how do you automate? So keeping that automation mindset is important. Figuring out where you’re spending cycles of your time in terms of doing manual tasks is important. So making automation a priority is important.

    Map out within your SDLC and identify your automation opportunity. Number three is make it small – right? Like get small. Break it down into smaller increments so that it’s easier to test after every aspect of the SDLC. So break down increments after coding. Break it after design. This makes it easier to automate the test and it also makes it much more easy to deploy and integrate as a part of continuous delivery.

    The fourth one is you want to keep track of everything. Use metrics. Start-up criteria. Right? So your defect density rate is high, figure out how can you reduce the defect density rate. Continuous testing is all about immediately identifying if things are working or not. How do you basically rinse and repeat if it’s working, or how do you actually pivot and change if it’s actually not working.

    The fifth one is getting the right continuous testing tools. Tools play a big role. So we talked about also transformation, we talked about processes and practices, and also having the right tools is important. Figure out the tools that help you develop tests and analyze continuously.

    Pick the best of breed tools that work together in a way that incorporates very easily into your continuous delivery environment. Choose tools which have community based support, that have open source plans that everyone shares the challenges and solutions and have interesting and lead to interesting use cases.

    And last but not least, the number sixth one, is develop a system to display your results. So do deep dives into the results, because that shows you that if you have your code not working, where the gaps are. define your KPI and your acceptance criteria and make them quantifiable. Create dashboards to track those KPIs, including a baseline so that you can actually track with the sequence changes. So these are some of the disciplines I always share with my customers as well as my clients.

    Shimel: Excellent. And now with everyone listening on here. Aruna Ravichandran we’re almost out of time, one more question if you have a second.

    Ravichandran: Absolutely. I do.

    Shimel: So I don’t know if we’re letting the cat out of the bag. If you can’t talk about it, politely say so. But you’re about to roll out something we hear called continuous testing academy? Launching this summer?

    Ravichandran: Yup.

    Shimel: So what’s that about?

    Ravichandran: So the key thing – going back to the question you asked, this continuous testing is like an emerging discipline. People want to know what do I need to do, how do I need to start? How do I get there. And so last year I launched the – I saw that there was a tremendous amount of need in the market around JMeter.

    And so I launched JMeter academy in order to basically to provide input to the community so they could actually train themselves on JMeter. But this year, knowing that continuous testing is gaining tremendous amount of momentum, I’m going to launch a continuous testing academy.

    This is going to have a basic module, it will also have an advanced module. And people will actually have the opportunity to go through the entire module and get themselves certified. We’re also going to launch a certification and you will have the opportunity to become continuous testing certified by DevOps institute. So this is our way to give back to the community in order to basically get people understanding on how they need to evolve their continuous testing practice in order to make a bigger impact in the DevOps world.

    Shimel: Excellent, again, Aruna Ravichandran – great job. You are just, I mean, literally, what a dynamo. All over the place. Doing so many different projects. All with DevOps and continuous testing as a theme there. Congratulations and hats off to you. One of my heroes. Anyway, we’re about out of time. Thank you so much, Aruna Ravichandran, for giving us a preview. Once Kitty Hawk is available to the public, I’d love to have you back on and perhaps we can chat more about it, sound good?

    Ravichandran: Yep. That sounds awesome. As always, Alan, it was excellent talking to you. I love your energy, I love your passion. And looking forward to partnering with you more as we basically enable our customers and prospects to continue on marching further along in the world of DevOps.

    Shimel: Well stay tuned for some announcements, we’re working on it. Aruna Ravichandran, I will be in touch. Aruna Ravichandran Ravichandran, a VP product marketing, marketing DevOps, CA technology, multiple times author, and really DevOps enthusiast. Thank you for being our guest on DevOps chats today. We’ll speak to you soon. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • Welcome to the CA Live Chat Series home page!

    As the popularity of DevOps grew, so did a common refrain: Continuous integration and continuous delivery create an environment to continuously introduce vulnerabilities into software. The idea was that the rapid speed of DevOps was in opposition to the concept of secure development. However, as time went on, it became apparent that a system that fosters collaboration and promotes automation creates continuous opportunities for integrating security testing into the development process.

    During this session Maria Laughlin, Vice President of engineering at CA Veracode, and Chris Eng, Vice President of research at CA Veracode, will provide their perspectives on how to build security into a company’s culture so that it permeates the development process. They will discuss the need for empathy and understanding between teams and offer practical advice on making security a part of the DevOps environment such that it becomes another element of quality.

     

    Welcome to the CA Live Chat Series home page!

    CA and devopsy.kinsta.cloud are proud to announce CA Live Chat, a series of webcast-like events which allow experts to host discussions on meaningful DevOps topics, from insights and outlooks to product demos. These events are typically highly interactive and thrive on attendee give-and-take. This fresh, new concept introduces a vibrant, well-trafficked YouTube Live channel of video-chats promoting DevOps and Continuous Delivery topics for the purpose of thought leadership. Please click on any of the on-demand sessions below and “stay tuned” for our exciting upcoming CA Live Chats!

    Assess and Guide Your DevOps Journey Leveraging Industry-leading DevOps Research – Live Chat
    The DevOps Research & Assessment Group (DORA) is a group of the most preeminent researchers, scientists and experts in the DevOps community—and is the force behind the annual State of DevOps Report. CA has partnered with DORA to offer a unique assessment service for organizations in any stage of DevOps maturity. By leveraging DORA’s expertise and existing research—such as over 23,000 data points from over 2,000 companies worldwide—the assessment service can help you understand both the strengths and areas for improvement in your own DevOps programs.


    Better Training for Better Security
    In this session, Pete Chestna of Veracode talks to David Wayland from a Fortune 500 Financial Company about the recent CA Veracode/devopsy.kinsta.cloud DevSecOps survey. This lively discussion reveals what they have seen in the industry and their real world experience in implementing successful training programs. Your takeaways from this webinar will be solid recommendations for creating your own secure training initiative that leads to better engagement and better results.

    Implement a Best Practices Approach to Container Monitoring
    Listen to this conversation with Kieran Taylor, CA Technologies and Alan Shimel, devopsy.kinsta.cloud to understand:
    • What new monitoring, analytics and alerting techniques are best suited for containers.
    • Why an open data model is key to understanding and tracking microservice dependencies.
    • How to establish monitoring across the entire application lifecycle to increase development speed and quality.

     

    Is GDPR Getting Ready to Give Your Company the Left Hook?

    The General Data Protection Regulation (GDPR) introduces new and broad changes for data privacy for any company that retains EU customer data. Because so many companies are global, this regulation will most likely involve your company. GDPR gives EU citizens far more control on how you use their personal data. They can limit your use, be forgotten, and even seek damages if their data is misused or breached.

    Join CA Technologies’ Jeff Hughes, Sr. Principal Product Marketing Manager and devopsy.kinsta.cloud founder, Alan Shimel, as they discuss this upcoming legislation and how companies should go the distance by preparing for the May 2018 deadline! Jeff will provide concrete steps that you can take now to start or continue preparing for this new regulation. You’ll walk away with a knock-out action plan to start moving your testing and compliance teams in the right direction.

     

    Modern Application Monitoring is the DevOps X-Factor – Discover why!

    Just as we’re starting to get our heads around application containerization and orchestration and along comes serverless computing, service mesh architecture and hype-free Internet of Things use cases. Now DevOps practitioners need to elevate monitoring capabilities beyond relatively simple guarantees of technology uptime and application performance into the more challenging area of ensuring an optimum customer experience. An experience that fuses physical and digital, isn’t time bounded, and incorporates a complex series of customer journey touchpoints.

    Join a conversation with Pete Waterhouse, Senior Director of Product and Solutions Marketing at CA Technologies and devopsy.kinsta.cloud founder, Alan Shimel to understand:

    • What’s on the near-term biz-tech horizon (including containers, serverless, IoT) and how this will radically impact your monitoring strategies
    • How traditional practices in continuous delivery, testing and monitoring must evolve to support new digital models and the Internet of Things
    • The increased importance and benefit of application performance analytics across the DevOps toolchain

    Application Monitoring DevOps X-Factor

     

     

    Data Privacy – Why your company needs to pay attention to what’s behind the compliance curtain!

    Data Privacy has once again vaulted to the forefront with Facebook and other large companies grappling with data breaches and the use (or misuse) of personal data. We are charting new frontiers in data privacy and legislation alone will not mitigate the data challenges that lay ahead. Brand loyalty and brand trust can take years to build, but can be lost in an instant with one data privacy misstep. There are a number of regulatory challenges facing enterprises globally that need to be considered as well including The US Patriot Act and the upcoming GDPR requirements. Join us  learn from Alan Shimel of devopsy.kinsta.cloud and DevOps testing and compliance expert Jeff Hughes of CA Technologies on:

    • What is Data Privacy?
    • What are the penalties for non-compliance?
    • How can companies comply with data privacy laws?
    • What else can a company do beyond adhering to compliance regulations to protect data privacy?

    Enjoy a lively discussion with useful ideas that will help your teams exceed compliance regulations and preserve trust with your customers.

     

    Links to additional resources:

    Container Monitoring and Management eBook
    This eBook from The New Stack lays out the monitoring challenges confronting todays DevOps engineers, describing approaches to metric collection and visualization, the classes of modern monitoring, and importantly – how what methods work to tame complexity and ensure these dynamic application environments deliver on their promise.
    https://www.ca.com/content/dam/ca/us/files/ebook/container-monitoring-ebook.pdf

    The New Stack Makers Podcast: Future-Proof Docker with Modern Monitoring
    In this podcast, we discuss the complexities of monitoring microservice architectures and applications deployed to Docker. Sushil Kumar, SVP of Product Management at CA Technologies, describes the importance of employing an open, flexible monitoring data model for Docker.
    http://transform.ca.com/rs/117-QWV-692/images/CAtechnologies_Podcast.pdf

    The Total Economic Impact™ of Application Performance Management from CA Technologies
    A commissioned study conducted by Forrester Consulting on behalf of CA Technologies that examines the potential return on investment (ROI) that enterprises may realize by deploying CA Application Performance Management (APM).
    https://www.ca.com/content/dam/ca/us/files/industry-analyst-report/the-total-economic-impact-of-apm.pdf

    Try CA APM Today!
    Monitor application performance in minutes. No credit card required. It’s easy and free for 30 days.
    https://www.ca.com/us/trials/ca-application-performance-management.html?mrm=620656

    Contact – Becky Arenson
    Rebecca.arenson@ca.com

  • DevOps Chat: Huw Price, Smart Automation Is Key

    DevOps Chat: Huw Price, Smart Automation Is Key

    Before the new year, I had a chance to sit down and chat with Huw Price, Vice President, Application Delivery, CA Technologies. Given Huw’s title what do you think we spoke about? You guessed it, automation. Actually there is more to it than that. Automation for automation’s sake alone is not necessarily a good thing. As Huw points out, smart automation is key.

    Huw and I will be participating in a full webinar on the topic of Smart Automation and how to build it on January 24th. You can register for this free webinar here.

    As usual with our DevOps Chats, below is a streaming audio player with our interview and below that is a transcript of our conversation. Enjoy!

    Alan Shimel:                Hi, everyone, it’s Alan Shimel, Editor in Chief at devopsy.kinsta.cloud here for another DevOps chat. Today’s guest on DevOps Chat is Huw Price of CA Technologies. Huw, welcome to DevOps Chat.

    Huw Price:                  Hi, Alan, nice to be here.

    Alan Shimel:                Nice to have you here, Huw. Huw, if you wouldn’t mind, if you could give our audience a little bit – I said you worked at CA, but what’s your title and what are you responsible for over at CA?

    Huw Price:                  Yeah, I’m a VP at CA. I was the managing director of Grid Tools, which venture you may have heard of, where we specialized in all things test data, and laterally we moved into all things test case optimization and into test automation. My role at CA – I’m kind of an evangelist QA specialist practitioner, and it’s actually fitting quite well with the DevOps land of trying to improve quality whilst improving speed at the same time, which is a bit of a magic trick. But it can be done and it needs some new thinking.

    I would say that over the years, it used to be cost was the top driver for businesses, but now due to the pressure of business, it’s all about competition and it’s all about getting stuff to market quickly, and you can’t have poor quality code going out to customers because they’ll just move to someone else. And I think that’s really what’s kind of driving a lot of our thinking at CA at the moment.

    Alan Shimel:                Absolutely, and it is somewhat counterintuitive when they tell you you could go faster but have higher quality. And I’ll even throw one more improbably into it – and be more secure by doing that.

    Huw Price:                  Yeah, that’s an interesting area. I think actually what I’m finding now is that I’m a big fan of doing everything in parallel, the days of sequentially waiting for one team to hand stuff off to the other, and what we’re finding is things like performance testing and security testing are kind of job one, and you need to build those in almost as functional requirements as you’re designing your software really. That sort of hopping from one piece of functionality or requirement to another seems to have vanished. It’s all hands to the pump I think at the moment is what I’m finding out there.

    Alan Shimel:                It is a bit of a Chinese fire drill, as they say. But out of chaos comes order, and that’s kind of the good news. Working with you and your team we’re actually doing a webinar after the New Year, in January, and it’s titled “How To Build the Right Automation.” And you and I were talking a little bit offline, of course, and the idea that you just automate for automation’s sake, maybe that was a couple years ago, but now we’re trying to be smarter about designing what’s to be automated and how we do it. Can you share with our audience a little bit of maybe your insight into that?

    Huw Price:                  Yeah, I think so. Automation’s got a bit of a bad press, and to be honest, I think rightly so, it’s considered very fragile. You only need a small change, a pop-up appearing on a screen, some kind of slight delay in a network and some of the automation breaks. And then everyone looks for the results and you spend days and days actually finding out that the program is fine or the functionality is fine, but it was actually the automation script that was wrong. That’s the first problem.

    And the other one is the time it takes to build the automation in that it’s not uncommon for automation to be built three months after a sprint is finished, which of course means you’re automating something that doesn’t exist any more, which is not very continuous. And the value of what you’re actually doing is pretty poor. I think that is kind of the backdrop of where people have been.

    They’ve moved towards test-driven development, behavior-driven development etcetera, but they still have the problem that actually maintaining the automation scripts, even if they’re key word or Gherkin, it’s still an issue. Because, you know, requirements don’t exist any more, just change requests exist, and a change request means you’ve got to go back through all of your existing automation and say, “Do I have to change all these automation scripts, which ones do I change, which ones are duplicates, which ones make no sense?” And that is a massive amount of work.

    I’ll just give one example. There was a bank in Canada, and basically for every single requirement change, they would go through every automation script by hand to see if it needed to be changed. So one change request took one tester all day to see if it impacted any existing automation scripts. So that’s just one change request. So how many testers do you have, how many automation guys do you need, how many change requests can you fit through that very narrow pipe. I think that’s where people, even with some of the new techniques – and I’ve got to say that the automation frameworks are becoming better. They’re becoming more structured; they’re becoming more malleable key word based. But they still don’t really address the problem of if I make a change to a requirement how quickly can I update my automation framework.

    Alan Shimel:                Excellent.  Huw, I want to talk to you a little bit about the go to market with your group. You’re obviously probably dealing with mostly large enterprises, how does a large enterprise realize they have this problem? Is the problem one where, “Geez, we need help automating,” and they haven’t even cut across the threshold of “we need to be smarter about automation” because they’re still at just the “we need automation.” Or is it organizations who have already, let’s say, dabbled with automation and are now realizing, “Wait a second, this is just a giant cluster waste of time.”

    Huw Price:                  Yeah.

    Alan Shimel:                “And we need help being smarter about automation.”

    Huw Price:                  I think the answer is yes to all of them. Even within the same organization – and I can think of one we’re dealing with at the moment – you get such a sort of disparate set of skill sets, capabilities, maturity models, and quite often we’ll go into a large company and introduce teams to each other and say, “Do you realize you have a really nice sort of key word driven framework sitting over here with a very clear object library, which you’ve got all this work and you’re going off and building yet another selenium framework, maybe you guys should talk to each other.” I just find that we do a lot of sort of introducing companies to other people in the same company.

    Alan Shimel:                Sort of like matchmaking, huh? Matchmaking all that stuff. Interesting.

    Huw Price:                  I’d like to add on that, certainly what I do and members of my team and other people in the business are doing, we are genuinely hunting for best practice here. This is not about us selling software any more, the market is moving so quickly and this ability to be a sort of lightening rod of best practice amongst other companies, genuinely it’s quite fun and we’re enjoying it, and we do share around what we’re finding out in the market in terms of what’s good, what people are struggling with, and hopefully we’re bringing not just software to the market, it’s more some best practice thinking as well, and I think that’s quite interesting.

    I’ve got to say that chatting with you when we met in Vegas, I learned a couple of things from you. And I find that when I talk to pretty much everyone. And I’m trying to feed that back, whether that’s by webinars or with the direction of how we build the software. We’re trying to just keep pushing the boundaries, keep communicating, keep thinking. It’s kind of fun. We’re really enjoying it at the moment.

    Alan Shimel:                Absolutely. I always tell people these are interesting times to be in the IT world, there’s just so much change happening – and change I think in a good way. New tools and trends and ways of doing things, it is fun, it really is fun.

    Huw Price:                  I’m going to take a slight tangent here. I was listening to an agile coach talking and I agreed with 80 percent of what he said, and disagreed with 20 percent. But then I challenged him and said, “Can you tell quickly whether an agile team is good or bad?” And he said, “If they’re having fun, that’s generally good.” And I know everyone is into hero culture at the moment, charging around trying to get the release out the door at the last minute. That’s what we’re trying to focus on is move away from the hero culture and actually getting that fun back into – you know – solving challenging problems and automating as much as possible and joining stuff up and getting feedback loops going and all that kind of fun things. So it is, as you say, very interesting times.

    Alan Shimel:                Sure. Steve, let me ask you a – and I’m not being facetious but a real question – can we have too much automation?

    Huw Price:                  Actually, that’s interesting. I did a presentation at Star West and I talked about risk based testing. It’s actually kind of touched on an interesting subject here. The reality is, if you have a very stable system and you’ve got a bunch of very experienced programmers, you know, you run it through a code quality engine and it’s very solid and stable, and they also understand all of the data that flows in and out of it – the reality is that actually you might need a very minimal amount of automation to test that.

    If you’ve got something which is highly, highly active – I’ll mention an Indian company, they’ve got one API which brings in 150,000 new customers a day. That API, I mean, that is staggering. 150,000. This is to do with the 4G rollout across India. That API, you know, I would be automating the hell out of that. I would have so many automation scripts around that. I would have docker images spun up in every different direction, I would have visualization wrapped around it, I would have negative testing up the wazoo, so that if you make a change – performance testing, blaze meet up, whatever it takes, to make sure that that baby, when you make the slightest change, you don’t mess with it — because if it’s down for ten minutes, that’s 5,000 customers. So I think people maybe should start thinking a little more sort of holistically and higher up in terms of the different levels of risk associated with it. I think that’s one thing.

    So I think that’s one thing, and then the other one is the speed at which you can automate. The reality is that what we do, we will generate – we’re very much into building a model of what the system should do. You could potentially build all your automation scripts before you’ve actually built the application. I was doing some work with Eggplant the other day and we actually generated a whole bunch of Eggplant scripts based off a Microsoft PowerPoint of what the system should do. So in other words, before the developers started, we’ve actually created the automation framework.

    Now, if that takes 15 minutes, great. If it took 3 days, then it’s a little bit of a tradeoff. So I think this balancing things up based on risk, and also the technology that you have to hand, is probably the two criteria you should start thinking about.

    Alan Shimel:                Agreed, agreed. Steve, as I had told you offline, the time here goes incredibly quick and we’re coming up on our 15-minute outside limit. I just wanted to bring you back home to the webinar in wrapping up. I believe our webinar is scheduled for in the latter half of January, and it is called “How To Build the Right Automation.” For people who are listening right now, give me two or three points why they really should make it their business to attend the webinar.

    Huw Price:                  I think firstly they’ve got to understand what they’re automating. If you look at most automation scripts, you’re probably only covering about five percent of the functionality. We would look to automatically generate 85 to 90 percent of the functionality of the system in either the same time or less time, so I think that’s firstly. To really understand coverage, I think that’s important.

    The other one then is to think about that actually automation is not just about the scripts themselves, it’s about getting the right test data and the right – I’m going to use the phrase visualization, whether that’s service visualization or message visualization or sort of network visualization or visualization environments. So trying to create an environment such that your automation is actually testing the bit that you really want to test. If you think of an end to end test, to get to something like a share trade close where you might have 200 functional logic gates I need to test, is actually really difficult, because you’ve got to have all of the right bits around your automation to make sure that you’re testing the right stuff.

    So better automation in terms of the design and also the assets around the automation to make sure that you’re actually testing the correct stuff. I think that’s probably what I’m going to focus on during the webinar.

    Alan Shimel:                Got it, got it. Well, obviously on devopsy.kinsta.cloud we’ll be publishing links to the registration page for people who want to join us on that webinar. It sounds like it could be – it sounds like it could be a great one if folks are interested.

    Huw Price:                  And it’s lots of demos. I’ll do a couple of slides, but I prefer to do demos.

    Alan Shimel:                Oh, that’s greatest.

    Alan Shimel:                Yeah, most techies love to see stuff.

    Huw Price:                  Actually, we’ll drive right in here.

    Alan Shimel:                They’ll give you a slide, but anything beyond that they’re just like, “Show me stuff, show me stuff.”

    Huw Price:                  All right, so let’s stay tuned to devopsy.kinsta.cloud. I would imagine we’ll probably have the landing page up within the next week or two as we head into the holidays.

    Alan Shimel:                Well, Huw price, I’m going to ask you one last question – not a curveball or anything, but I usually ask a lot of our guests this – for our audience listening, one book that you would highly, highly recommend they read.

    Huw Price:                  Actually there’s a book called Model Based Testing. What we’re discovering is that people are now moving pretty much – they’re realizing that without a model it’s very difficult to proceed. And there’s a book called, it’s actually an adjunct book to the Model Based Testing Course. We’re massing this out to our customers now to kind of reset their thinking. Everything we do in life is a model, everyone’s making decision gates, logic gates, risk based profiles, and this is going down really well. People are really taking the time to read it. What I’ll do is during the webinar I’ll put up the pages so people can go and get it. I can’t remember the exact title. It’s called Model Based Testing – The Course Guide, or something like that. But I highly recommend that.

    Alan Shimel:                Excellent. Huw Price, thank you so much for being our guest on this episode of DevOps Chats.

    Huw Price:                  Oh, it’s a pleasure.

    Alan Shimel:                Thank you, it was our pleasure and we look forward to the upcoming webinar, “How to Build the Right Automation,” including demos, and we’ll have more information on that. And we hope to have you back on DevOps Chat soon, Huw.

    Huw Price:                  Great, all the best. Thanks so much.

    Alan Shimel:                All right. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks very much, everyone, and we’ll see you on the next DevOps Chats.

    — Alan Shimel

  • DevOps Chat: Jeff Schaeffer, CA Technologies, on Everything Continuous

    DevOps Chat: Jeff Schaeffer, CA Technologies, on Everything Continuous

    I recently had a chance to sit down with Jeff Schaeffer, senior vice president and general manager of Continuous Delivery and DevOps Business Unit at CA Technologies. I have interviewed Jeff before, most recently at Jenkins World, where we did a video on our DevOpsTV YouTube channel. Jeff is a great interview who always gives good insight into what CA’s and his views of the dynamics shaping the DevOps market are.

    Jeff and I had a chance to talk about the launch of the new CD neighborhood sponsored by CA Technologies. Specifically, we discussed how CD—and, for that matter, the whole idea of continuous IT—is reshaping the way organizations do business. It is a great conversation that I hope you will enjoy.

    Below is a streaming audio of our DevOps Chat and below that is the transcript of our conversation.

    Alan Shimel: Hi, everyone. This is Alan Shimel, editor in chief, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s DevOps Chat guest is Jeff Schaeffer, who is responsible for CA Technologies’ continuous delivery CD business.

    Jeff, welcome to DevOps Chat.

    Schaeffer: Thank you, Alan. Glad to be here today.

    Shimel: Good to have you here. Jeff, of course, I think the last time you and I spoke was at—it was at the Jenkins World event, and we had a chance to actually sit down on video and talk a little bit about, you know, where do you see the market, where you see the DevOps market going, what CA’s involvements are and where you guys are kind of placing your bets and moving your pieces around as this market continues to evolve.

    And we were, of course, talking offline before we started today’s podcast about kind of how you view the different waves, if you will, of maturation of companies’ life cycles with software and so forth, and you mentioned third wave, fourth wave.

    I’d love, if you don’t mind, if we could share a little bit of that context with our audience in terms of your view of the historical ebb and flow here of history, if you will, of where we are. So would you mind sharing that?

    Schaeffer: Thanks, Alan. So, Alan, as we were discussing, our—the thesis and the drivers for continuous delivery actually start kind of in the history of technology, and it’s probably never been a more exciting time for any of us to actually be involved in application development and technology in general as it’s transforming all the markets.

    And the history is useful to the extent that it helps us understand the future as well, and when we think about it, you know, we’re really in the midst of the third wave, in which businesses have disruptively adopted technology in the business.

    The first wave was back in the 1960s and it was really about the mainframes and the digitization of the paper processes in the company. I mean, it was a process disruption.

    The second wave was in the ‘90s, and it was really about ERP and CRM systems where we were automating the supply chains of companies, and again, it was a process disruption.

    Today we’re in the third wave, around the application economy, and in the context of digital transformation and the app company, you know, companies today, they promote their brands, their products, their services through their web and their mobile applications, and it’s become the primary methodology by which they engage their end users. And it is actually underpinning and enabling business model disruption, which is very different than the prior two waves of disruption.

    So when we look at it, it’s an entirely new business model. We’re all familiar with the majority of those in terms of, for example, Uber disrupting transportation and Netflix disrupting media, et cetera.

    And one of the challenges about the third wave is that—following the third wave, actually, I think is the fourth wave, and the fourth wave is gonna be around systems of insight and engagement, by which companies are able to take all of the multitude of data that they’re generating in terms of every interaction with their end consumers—you know, with suppliers and providers—and be able to analyze those data sets’ multivariate analysis and derive deep insights, and to be able to then, in turn, customize their offerings. Companies would be able to use that data to make more of the right decisions more often, to drive efficiencies, et cetera.

    And so naturally, the fourth wave—and it’s coming, but before we can actually fully benefit from the fourth wave, we actually still need to master the third wave. And in the context of the third wave, the app economy, it’s really about, how do you get these applications, these web or mobile applications into the hands of end consumers more quickly and, you know, great quality and at lower cost and factor of production.

    And so that’s really the area where companies today are focused. And, to do that, what most companies are doing is, they’re adopting agile methodologies, right? They have to increase their competitiveness and their ability to deliver this custom software. So they look to get development up to velocity, so they’re adopting agile methodologies, and then they quickly realized that the rest of the value streams are not at velocity—so testing, release, operations—which then leads them to adopt DevOps, which is where we’re gonna have a great conversation today.

    And, with DevOps, they start to adopt the culture and the practices, and then realize they need a new enabling tool chain, and so if you think about any technological disruption and being a function of organization and people being a function of process and being a function of tools and technology, they now adopted a new tool chain, which is the continuous delivery tool chain.

    And that’s an area where we at CA are focused about how do we provide the coaching around the organizational transformation and the practices in the process transformation and then, you know, from a product perspective, we’re building the next generation tool chains, building block fashions, and bringing those to market to support companies’ transformation and competitiveness in the application economy.

    Shimel: Perfect. And you know what, Jeff, that actually dovetails into, of course, just today, we announced on devopsy.kinsta.cloud that we’ve added a new CD—or continuous delivery—Neighborhood, which CA has graciously sponsored. And we’re really looking to build this into a—I don’t want to use the word portal, it’s so 1999—but a destination where people can come and get some great content and some great education around this whole CD tool chain and the CD economy, if you will, that is growing up.

    But, you know, Jeff, going back to what you were talking about, we can’t get to the fourth wave until, I think, the third wave is a little bit more solidified and a little bit more mature, a little bit more settled. In my mind, what we’re seeing is, a lot of these convergent circles starting to overlap, right? You mentioned agile, we mentioned CD, we mentioned things like API, right, which is another big area for CA.

    Schaeffer: Yes.

    Shimel: And, you know, they’re not totally independent of each other, nor are they totally dependent on each other, but you know, they kind of form the ultimate Venn diagram where the overlap is just marvelous, right? I mean, it’s just a wondrous time to be in business if you’re using—you know, you’re leveraging all of these things.

    You know, and you’ve been around, Jeff, as I have—what do you see with that?

    Schaeffer: Yeah, so Alan—exciting things, exciting things. So, a couple of quick comments, one on the Continuous Delivery Neighborhood—really excited for that. Alan, I can tell you that in that context, whenever I meet with peers across the industry, one of the things that comes out very broadly today is, there’s a big gap between conceptualization of things like agile, DevOps, and continuous delivery, and translating those into real world practice.

    Shimel: Mm-hmm.

    Schaeffer: And the opportunity to provide that education, to provide a journey to share examples of how people have adopted these and succeeded is gonna become absolutely instrumental in terms of unlocking the full potential of these methodologies and these concepts and deriving the business benefit.

    So we’re really excited with what devopsy.kinsta.cloud is doing with respect to the educational exercise, and also devopsy.kinsta.cloud and that sponsorship of the DevOps Express Consortium, which is another multi-vendor body that’s focused on this translation of concept of real world practice, and of course, here at CA, we’re happy to be a founding member of DevOps Express as well as a sponsoring member here for devopsy.kinsta.cloud and the CD Neighborhood.

    The second thing is, when we look at the change in the continuous delivery tool chains, what we’re finding is, as companies adopt agile, they start looking to have—okay, what is the prescription of the next generation software factor, software life cycle, and as they look at continuous integration to continuous test, continuous release and deployment and continuous operations, you know, how do you string these building blocks together?

    And the only way to reduce the cycle times is making both a process change but also the tooling change. And the tooling is very different today versus, say, some of the legacy providers of application development and testing tools. It’s all pragmatic, API driven, so that it’s fully automatable. There’s a lot more—as you were describing the intersection and the Venn diagrams, it’s really a function of the feedback loops. So how do I take data, for example, from operations and use that to make a smarter example in continuous testing?

    Let me share an example of what we mean by that. So, if you have a mobile application, you know, mobile application is much more difficult to manage in production than, say, a web app. First, people simply don’t update their smartphones that often, and so you end up with a long tail of versions in production environments.

    Shimel: Mm-hmm.

    Schaeffer: They’re running on different operating systems—iOS or Android and different versions of the operating systems. They’re running on different hardware platforms like an iPhone 4 or an iPhone 7, Galaxy 7. They’re running across different carriers, and there’s over 700 different carriers worldwide. And it becomes a factoral problem, and it’s unlikely that any given testing team has the ability to model that many combinations—because it’s a factoral problem—to model that many combinations in their test matrix.

    But, if you have operating data, and you know that 80 percent of the user base is on these five to seven combinations, then you can provide that data back to the QA team and proactively test those combinations and take your risk in the tail of where people have more infrequently completed combos. But, by the same token, if you can detect failures in operations, you can provide that same data back to dev, and they can focus their investigative research as they work on the current product engineering.

    So when we think about the Venn diagrams and how all of that works together in the future, it’s—not only are the format factors of the tools changing, but the feedback loops become absolutely essential in order to fully automate and to systematically improve the software life cycle process. And so, a really exciting time.

    And we’ll often hear that today, this idea of shift left and shift right, but it’s really a—you know, those things embody, that vocabulary embodies a number of concepts. One is, you know, how do I push activities earlier and earlier into the development process under shift left, so how do I incorporate, say, for example, performance testing early, and then how do I tie performance testing into operational testing, and how do I provide that feedback loop all the way back?

    So just exciting times, lots of transformational changes, and people are definitely looking for prescription and methods as how to reconfigure their software life cycles and incorporate that into their current software development methodologies, and that’s what, I think, DevOpsExpress.com will be so good at is helping provide that center of knowledge and best practices for the betterment of the industry.

    Shimel: Absolutely. Jeff, believe it or not, we’re almost up at time, but I wanted to—and I don’t mean to embarrass you, but I want you not to be shy here. CA has done a masterful job of amassing, developing—both holistically, acquisitions, et cetera—a play in this new third wave, fourth wave economy, if you will.

    Schaeffer: Absolutely.

    Shimel: Give our audience—again, don’t be shy. Why do you think CA is best situated to really leverage what’s happening out there right now?

    Schaeffer: Wow, great question, Alan. So, two, maybe three key points on that. So number one, Clayton Christensen, who is a professor at the Harvard Business School, he’s written extensively on the concept of disruption and then disruptive innovation in the market. And one of the key things that you learn about, or learn from Clayton, is that the incumbents never survive the disruption. And it’s not because they’re—you know, it’s just because of their decision making and how they’re driven by their paradigm.

    And CA, uniquely, is in a position as a company to invest in this next generation of continuous delivery capabilities. And so we’ve been putting together this next gen tool chain through a combination of organic product development as well as acquisition, and so we’re uniquely in that position in the market in terms of being a vendor of sufficient size to provide that consolidated next generation tool chain and to ensure it works together. Per kinda the research of the market and industries over time, you know, we’re in a unique position relative to the traditional incumbents and I’m excited.

    You know, we’ve pulled together the Rally Software, which brings kind of market leading agile management capabilities into the portfolio and we start with the planning process and agile management. We realize that, in the application economy driving the automation, that oftentimes in the app economy, the API is the application, but that’s also the primary means by which we exchange data and are able to integrate or automate all of the functions as well as create the next generation architectures, which are all kind of composite applications built on microservices which work through APIs.

    So we’re connected by the APIs, and so we’ve invested in their seven and brought in a really robust API management capability, and then we are laser focused in the continuous delivery space. So, how do we take and orchestrate release with release automation software and release automation continuous delivery addition, which is basically harvesting the data and providing the analytics so that we can systematically improve and continuously improve the software development life cycle.

    And then, beyond that, we have a number of kind of the next generation continuous testing tools. So, everything in terms of, we just recently acquired BlazeMeter. It’s a fantastic capability and at the heart of continuous testing. You know, it’s a commercialization of open source projects, JMeter and Taurus, which allows us to automate any open source testing tool, whether it’s the JMeter testing, which is the second most widely adopted community developed testing product, or Selenium, which is the most widely adopted testing product. Gatling, Locust, et cetera, so a host of open source testing engines.

    We add value above and beyond that. It’s all hosted in the cloud and deploys both in public and private clouds for the tests themselves, and so it’s highly automated, it’s very scalable, and it allows us to left shift the testing all the way into the integrated testing, the component testing, and the unit testing of the new life cycle processes.

    We also have put together a number of tools that improve testing efficiency around test data management, so how you can’t automate your tests unless you automate the test data, and providing test data with the right sort of attributes in order to drive the tests in a productive way. We have service virtualization software, which allows us to simulate test environments, and to emulate the test environments and abstract away things like mainframes or databases, which allows for both parallelized development. When other components aren’t available, we can simulate those or emulate them, and then in the testing practice itself, we’re able to isolate applications and put them under load testing in an effective way.

    All the way out into our operational tools, where we’re able to shift right, and provide kind of the—you know, what’s done in pre-prod gets used in production, how do we get the integration and the feedback loops back into the testing and the development processes.

    And so we’ve really been focused on putting together that next gen toolset around continuous integration, continuous testing, continuous release and deployment, and continuous operations. And again, we’re in a unique position to do it. We’re unique in the fact that it’s a disruption within the market and we’re able to put together this tool chain, and we’ve made a lot of progress in developing that tool chain up ‘til now. And we’re finding companies like—the people we’re working with across the industry adopting the CA tool chains, you know, we’re finding some significant improvements in not only the velocity but the quality and the cost effectiveness of their software development practices.

    So, for example, companies that were getting one release out every year are now able to do 30,000 deployments per month on 300 applications in both the test, the pre-prod and the prod environments. We’re able to significantly reduce the cost of handling data and increase the automation of testing, up international the 85, 95 percent range, lowering the costs and achieving ROIs, in some cases, of over 300 percent in paybacks on the investment measured in months—you know, two to three months, which is very unusual around what people would normally expect in an enterprise software vendor.

    So we’re really excited with the difference we’re making in the lives of our customers—the operating benefits, the business benefits, and then the overall, you know, the impact that we’re gonna make in the industry as a whole.

    Shimel: Fantastic. Hey, Jeff, we’re way over time. I apologize, here. I apologize to—well, I’m not apologizing to those listening, I think they’ll find it worthwhile. But we do try to keep these at 10 to 15 minutes, and we’ve gone over—but I think it was worthwhile, we had a lot of information to share.

    Jeff, continued success in leading up the CD business at CA Technologies, and we’re looking forward to more exciting news soon, and we’re actually looking forward to the CD Neighborhood on devopsy.kinsta.cloud really becoming a go-to place for people looking for information around it. So thanks very much on the sponsorship for that as well.

    We’ll be in touch again, soon. Until next time, I hope you stay well. Jeff Schaeffer, he runs the CD business at CA Technologies—thanks for being our guest on this episode of DevOps Chat.

    Schaeffer: Thank you, Alan.

    Shimel: Thank you. This is Alan Shimel for devopsy.kinsta.cloud, and we’ll see you again on another DevOps Chat.

    — Alan Shimel

  • When Technology Doesn’t Matter

    When Technology Doesn’t Matter

    Over 10 years ago, Nick Carr wrote an article in the Harvard Business Review with the title, “IT Doesn’t Matter.” As you might expect, an article with a title like that generated a significant amount of controversy. CEOs from leading technology companies and other writers at the time panned Carr’s premise in a way that, in retrospect, seems a bit overly defensive.

    His point, after all, was not that IT was not unimportant; rather, IT (as vaguely defined in the article) was so ubiquitous that it was no longer a competitive advantage. Rather, it was what companies did with their IT technologies that provided competitive advantage. It’s also worth noting that his (seemingly) intentionally vague definition appeared to focus on the generic notion of IT as PCs, servers and things that had become commonplace at the time.

    This has been a common pattern throughout the history of technology: Early adopters enjoy a competitive advantage, but only as long as the technology they’ve adopted remains scarcely used. Any advantage goes away when the technology becomes ubiquitous. The technology remains important—even critical—to a business’ operations, but it’s hardly an advantage when everyone else has the similar technology.

    Carr’s article uses the example of electricity: In the late 19th century, when electricity was an emerging and scarce technology, factories that were able to leverage electricity for their manufacturing efforts held a significant advantage. Today, no factory can operate without electricity, yet it’s hardly considered a strategic asset.

    Today in the 21st century, we’re seeing a similar trend repeated, but on much compressed time scale. Providing free Wi-Fi was once a lure for customers of restaurants, coffee shops and the like, but today it’s essentially table stakes. Likewise, leveraging clouds was once a competitive advantage, but with more than 90 percent of companies using some form of public or private clouds, one would be hard-pressed to argue that cloud usage alone provides any significant advantage. However, how you use these clouds can, in fact, become a competitive advantage. CA offers a variety of tools to help you manage, secure and accelerate your use of clouds.

    It’s an important lesson to learn: In the application economy, early adopters enjoy an important—yet relatively short-lived— competitive advantage. Knowing when to jump on an emerging technology can be the difference between surviving and thriving.

    Today, there are several technologies that are on the cusp and moving quickly to adopt them can provide a significant competitive advantage. The ability to deliver software continuously—while not exactly a single technology—is on this cusp. Continuous delivery is a core component of a successful DevOps implementation, and means essentially what it sounds like: the ability to deliver software from planning to production in a near constant and continuous fashion. Achieving true continuous delivery means you must test continuously, develop continuously and release continuously.

    Continuous delivery is not easy to achieve, but for those who do the advantage is significant. Companies implementing continuous delivery can get to market 20x faster with 98 percent fewer production errors. That’s a powerful benefit.

    To learn more about CA’s portfolio of continuous delivery solutions—and hear directly from several customers—you can check out the replay of Jeff Scheaffer’s keynote presentation from CAWorld 2016.

    — Brendan Hayes

  • CA Technologies Announces Intent To Acquire Automic

    CA Technologies Announces Intent To Acquire Automic

    Acquisition to Provide Cloud-Enabled, End-to-End Automation and Orchestration Platform for Applications and Business Processes

     NEW YORK, December 1, 2016 – CA Technologies (NASDAQ:CA) today announced it has signed a definitive agreement to acquire Automic Holding GmbH, a leader in business automation software that drives competitive advantage by automating IT and business processes. The transaction, valued at approximately 600 million euros, net of cash and cash equivalents acquired, has been unanimously approved by both Boards of Directors, and is expected to close in the fourth quarter of CA’s fiscal 2017. Headquartered in Vienna, Austria, Automic has approximately 600 employees across Europe, North America and Asia.   

    With Automic, CA will add new cloud-enabled automation and orchestration capabilities across the portfolio and increase its reach into the European market. Automic’s European presence coupled with CA’s worldwide expertise and broad portfolio, offers customers a global solution that complements their existing technology investments to address the challenges of automation across the enterprise. 

    CA will add Automic’s automation and orchestration capabilities to its portfolio to give customers options that address their IT operations and DevOps needs on-premise, in the cloud and hybrid cloud environments. With real-time analytics incorporated into the end-to-end platform approach, customers will benefit from increased business agility with solutions that move from IT-centric task automation to business-centric intelligent automation and orchestration.

    “Global businesses need the flexibility and agility to move workloads to the most appropriate locations across heterogeneous hybrid cloud environments, with continuous availability, to stay ahead of their competition,” said Ayman Sayed, president and chief product officer, CA Technologies. “With the acquisition of Automic, we will deliver automation, scale work flows and business processes while reducing costs and greatly improving accuracy. This level of intelligent automation will give our customers the insights to achieve more agility and realize business value. We are pleased to welcome Automic, which is profitable and growing at a healthy clip, into CA.  Strategically, it accelerates our position with its cloud enabled platform.  Operationally, it expands our reach across Europe.  And, financially, it meets our rigorous hurdle rates while providing the highest likely return on offshore cash.”  

    Automic’s automation technology underpins digital transformation by helping enterprises move from siloed automation to intelligent and orchestrated automation with real-time analytics.

    “Enterprise customers are engaging with vendors to support their digital transformation initiatives to increase velocity, reliability and scalability among their businesses processes,” said Todd DeLaughter, Chief Executive Officer, Automic. “Together with CA Technologies, we will help organizations further propel their intelligent automation capabilities to the next level, driving the agility and speed demanded in this era of Digital Transformation.”  

    Founded in 1985, Automic has offices in Vienna, Paris, Asia Pacific Japan (APJ), and Bellevue, Washington and serves a wide range of customers in the energy, financial services, healthcare, manufacturing, retail and telecommunications sectors.  

    Foros acted as financial advisor to CA Technologies on this acquisition.

    Updated Guidance

    Assuming the transaction closes in early January, CA’s preliminary expectation compared with its previous fiscal year 2017 guidance, is that the acquisition will:

    • Add one-half percentage point of revenue, both as reported and in constant currency
    • Adversely affect GAAP and non-GAAP total company operating margin by 1 percentage point and will primarily impact the Enterprise Solutions segment
    • Be modestly dilutive to cash flow from operations and GAAP and non-GAAP diluted earnings per share, both as reported and in constant currency

    Please see below for information regarding non-GAAP financial measures, the cautionary statement regarding forward-looking statements, and the reconciliation of projected GAAP metrics to projected non-GAAP metrics. 

    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.

    — Alan Shimel

  • CA Technologies to Acquire BlazeMeter to Drive Speed and Quality of Application Testing Practices

    NEW YORK–(BUSINESS WIRE)–CA Technologies (NASDAQ:CA) today announced it has signed a definitive agreement to acquire BlazeMeter, a leader in open source-based continuous application performance testing. Terms of the agreement were not disclosed. The transaction is expected to close by year end.

    The acquisition of privately-held BlazeMeter will enable CA Technologies to extend its DevOps portfolio. BlazeMeter will seamlessly integrate with CA’s continuous delivery solutions to further improve testing efficiency and accelerate the deployment of applications.

    “BlazeMeter has redefined performance testing with its simplicity, fast-deployment SaaS model, and rapid time-to-value,” said Ayman Sayed, president and chief product officer, CA Technologies. “The acquisition will reinforce our leadership position in continuous testing, and our efforts to democratize performance testing as organizations accelerate their DevOps journey to drive speed and quality in the delivery of new software updates and innovations.”

    As development teams move to Agile and continuous delivery practices to improve time-to-market of applications, enterprises are struggling to keep up. Testing speed is the major bottleneck in getting applications released faster. With BlazeMeter’s solution, developers and performance engineers can test earlier and often in the application lifecycle to improve their test coverage and avoid encountering performance problems too close to production.

    “Developers and performance engineers want to achieve superior test coverage by using open source tools and tools that can integrate well into the developer ecosystem,” said Alon Girmonsky, founder and CEO, BlazeMeter. “Joining forces with CA Technologies will enable BlazeMeter to continue developing our technology while enjoying the vast resources of CA Technologies to better serve our customers.”

    BlazeMeter’s commercial, self-service continuous application performance testing solution is fully compatible with Apache JMeter™ as well as other open source software tools like Selenium, Gatling and Locust.

    Founded in 2011, BlazeMeter has offices in Tel Aviv, Israel and Palo Alto, Calif.

    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.

    — Jules Louis

  • Industry Alignment: Supporting Real-World DevOps Workflows

    Industry Alignment: Supporting Real-World DevOps Workflows

    In our ongoing work to advance the interests of customers around adoption of Agile, DevOps and continuous delivery, the theme of evolving workflows to better suit human-scale work cycles often comes to the fore.

    While  it’s easy to say that build, test, release and monitoring capacities should feed into each other to promote continuous collaboration, realizing this vision in the form of integrated tooling is still no trivial feat. And it is further exacerbated by the reality that DevOps teams typically utilize a wide range of products built by a diverse set of providers, from larger players such as CA Technologies to open-source projects.

    If the goal is to drive  application lifecycle processes and supporting technology to better support human work cycles—along with accelerating organizational velocity and improving quality—somewhere in this domain of tooling integration there’s a need for relevant vendors to participate.

    That work officially begins today.

    At the Jenkins World 2016 conference this week, CA, along with a dozen other leading DevOps solutions providers and the DevOps Institute, announced the DevOps Express consortium. Joining us, along with CloudBees and Sonatype, which spearheaded this effort, are Atlassian, BlazeMeter, Chef, GitHub, Infostretch, JFrog, Puppet, Sauce Labs, SOASTA and SonarSource.

    So what’s the big deal? The direction of this initiative—which will focus first on supplying reference architectures that describe field-tested integrations of best-in-breed solutions—strikes directly at the heart of the central DevOps tenet: collaboration.

    The immediate result is that these providers are moving to boost interoperability across a typical production DevOps toolchain. It is truly noteworthy that these solutions providers, some of whom maintain palpable competitive interests, are putting aside those considerations to advance the interests of end users; that is a very DevOps phenomenon.

    In many other areas of IT, this type of cross-pollination either never commences or doesn’t emerge until the sector is so well-established that industry collaboration seems more of an effort to fend off perceptions of commoditization. To anyone familiar with the incredible pace of innovation ongoing in the automation sector, and the potential for competition between many of the companies involved in DevOps Express, it should be immediately obvious that this is a partnership that truly puts customers first.

    Yet, if we’re serious about empowering the kind of wholesale software factory reinvention that we espouse around DevOps, this is something that had to take place. How can an industry talk endlessly about eliminating stovepipes and marrying long disparate processes, and then defer to a walled garden worldview as it relates to the enabling products? That certainly wouldn’t really add up.

    It’s amazing to see what’s going on in the world of technology these days, and ever more exciting to be a part of it. We’re proud to be a member of DevOps Express.

    It’s a great time to be involved in this space.

    — Jeff Scheaffer