Skip to content

May 7, 2018

Case Study: Compuware DevOps Transformation

By IT Revolution

David Rizzo is the Vice President of Product Development at Compuware. He led the organization through their transformation to an agile and DevOps company, and at the DevOps Enterprise Summit he shared the story.

Below, we’ve transcribed the key takeaways and main highlights of Rizzo’s presentation (which you can also watch on YouTube here.)

1 — Recognizing we had a problem

When we took a look at our company, these were the problems that we identified:

  • We had been doing Waterfall for 40 years.
  • We had been a slow-moving development organization.
  • We were trying to compete in the digital economy, which requires you to be fast, (fast beats slow.)
  • We needed to be innovative, and have lot of new ideas. Ideation is the key to success in the new economy.
  • We needed to maintain quality. Being a software vendor, quality is number one. So we had to make sure that we were able to measure, maintain, and ultimately improve our quality as we moved through a transformation to a full DevOps organization.

2 — Define our desired state and how to get there

For us, the solution to these problems were-

  • Agility: We knew we wanted to be fully agile so that we could have continuous code drops and fulfill business needs in a timely basis.
  • Confidence: We wanted to have the confidence to know that when we made changes, what we were delivering was going to work and was good, so we had to know that we could move at a fast pace to be able to deliver what we wanted.
  • Efficiency: We had to be efficient, and move across the entire enterprise.
  • Ease of use: Our tools had to be easy to empower our developers to be able to move at that pace, and to make updates and enhancements that would be valuable, provide business needs, and meet the business objectives.
  • Integrations: Being in our enterprise companies, the mainframe integrates across the entire enterprise, through the cloud, and all the way back to your mainframe system of record. So we had to make sure that those integrations would be available.

3 — Determining the right tools

So, how do we put something in place that makes it possible for us to move at that pace and fulfill our objectives.

For us, the big thing that we had to do was look at our tools.

What we did was put in a toolchain, below you’ll see an example of our Compuware DevOps Toolchain that we use to develop our software.

First, in the upper left hand side, we start with Salesforce, which is how we interact with our customers so that they can provide ideas to us, and we can communicate using that portal.

We then use Confluence. When we have a new idea that comes in, we put it out in Confluence, and we get a lot of collaboration from our people around the world who are interacting with our customers and using our products.

Finally, we use JIRA for all of our project management, for all of our task management, for our agile boards, etc. so that we can keep track of everything we are doing.

The next phase happens as we move through code editing, application understanding, to validate our code, debug our code, edit, and manage our code, etc.

For this stage, we use the Compuware Topaz base, which is an Eclipse Base ID which interacts with our mainframe tools. It works with our interactive debuggers, and it can integrate with all the different tools.

Next, we have to make sure that we have some version control, so, we use two version control systems.

We use ISPW, which is our mainframe source code management system; and we also use Git for our distributed code. We believe that the source code should be managed on the platform where it is going to be built and executed, so mainframe code stays on the mainframe, distributed code stays on distributed platform.

We use Jenkins for our continuous integration into ISPW and Git to identify when code changes are made. Once those code changes are made, it automatically initiates automated testing; both mainframe, distributed platforms as well as builds.

Then the results from our testing go into Sonar where we can use it to identify code quality, identify how the changes are made to our products, and how our code is impacting the quality of what we are delivering.

For test automation, we use not only our Topaz products, but we also use Zephyr and Hiperstation Strobe for performance. So we’re monitoring the continuous performance and continuous viability of our code changes. We have code coverage product that we use to make sure that our testing is getting proper code coverage along the way. We like to ensure that we have at least 50% code coverage as we move along.

And then, finally, we get to where we have to deploy. Again, we use ISPW and XebiaLabs XL Release to do our deployments across different platforms, and that allows us to move and confidently move code changes from development to QA to production.

Then, once we’re in production, we have to monitor if there’s faults, errors, or any performance issues. We continuous monitor performance using Strobe, and we have an integration back into JIRA. Within the environment, if an issue is found, JIRA issues can be opened and sent back to developers so that they can keep a continuous integration in the true spirit of being fully DevOps enabled.

4 — Metrics that matter

Now that we’ve looked at the specific tools we’ve used, let’s take a look at what have we accomplished.

  • Through this toolchain, we’re able to cut our deployment time by two thirds, which means we were able to more rapidly deploy the software that we have.
  • We estimate that we do about two times more code delivery per developer per year, and that’s not measured by lines of code. We actually measure that by stories, tasks, and enhancements that are delivered. In other words, we’re measuring on the value that we are providing to our end users in applications that we’re delivering, not just simply lines of code.
  • Another one of our biggest accomplishments that I’m most proud of is our code quality. Being a software vendor, once we provide our software to customers the worst thing that can happen is an external defect be reported to us. However, through automated testing and the use of continuous integration, year after year we have reduced the defects reported by our customers and end users by seven percent. We’re very proud that we’re able to take what we’ve done and use that to be able to ultimately create a more positive experience for our end users.

So in summary, here’s what we’ve done:

We’ve mainstreamed the mainframe, which was our goal. Being able to include mainframe development into the mainstream of an enterprise do cross enterprise integration, applications don’t run simply on the mainframe. They run both in different platforms other than the mainframe, and there has to be integration.

The toolchain that we use is used on both sides, whether it’s mainframe or not mainframe, and we have that integration. And as our DevOps infinity loop shows, as we go through the process, we show on the bottom many of the mainframe components that are needed to do that; and at the top are a lot of the integrations, which are not typically considered mainframe, but they do integrate with the mainframe and be able to allow us to achieve the complete DevOps experience on the mainframe and across the mainframe.

5 — How did we really achieve this?

We’ve been doing this for about three years now, but you might be asking yourself ‘How did we really achieve this? What was the process that we followed?’

What we’ve done is created our 10-Steps to Agile Development and DevOps on the Mainframe.

Step 1 is to define your desired state, or define where you want to be. And step 10 is to get to a cross platform, continuous delivery, the true DevOps point.

These steps, #1 and # 10 are fixed, but numbers 2-9 can go in any order based on the maturity level of the organization and current processes, policies, procedures that are in place in your given organization.

By using these 10-steps, in conjunction with the tools in the toolchain we’ve been able to accomplish those metrics and transform our organization.

You can learn more about the 10-steps on our website,

Watch the entire presentation here:

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

No comments found

Leave a Comment

Your email address will not be published.

Jump to Section

    More Like This

    Frankenstein vs. the Gingerbread Man
    By Leah Brown

    In a previous post, we mentioned how the new book by Mark Schwartz, Adaptive…

    The Three Team Interaction Modes
    By IT Revolution

    In many large organizations, and even in some small ones, poorly defined team interactions…

    The Making Of The Phoenix Project
    By Gene Kim

    Ten years on, let's take a look back at how The Phoenix Project was…

    Ethics, Digital Transformation, and Frankenstein vs the Gingerbread Man
    By Leah Brown

    "If there’s an elephant in the room, it must be chased out quickly or…