Compuware CEO: Mainframes Can Be Agile - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

10:05 AM

Compuware CEO: Mainframes Can Be Agile

Compuware has gone back to its mainframe roots, and it has made the trip agile, CEO Chris O'Malley tells InformationWeek in an interview.

10 Top CIO Priorities: The Reality Vs. The Ideal
10 Top CIO Priorities: The Reality Vs. The Ideal
(Click image for larger view and slideshow.)

Compuware started selling software for mainframes more than 40 years ago. After years of expanding their efforts into software for other systems, the company has refocused on software for mainframe systems. And Chris O'Malley, Compuware's chairman and CEO, says that the big opportunities are in big iron.

O'Malley's vision of the mainframe software has a lot of extremely un-mainframe parts and pieces. He's very open about the reasons for leaving much of mainframe software's legacy behind.

"The mainframe can't just come into the digital economy with pixie dust. We had to re-invent every aspect of the company," O'Malley said in a telephone interview with InformationWeek.

Within the re-invented mainframe market, O'Malley sees some very simple reasons for optimism.

"There's no cloud derivative that can be used to replace the mainframe; the IP on mainframes makes companies dependent on the mainframe for the next 10 years or more," he said. And he doesn't see the mainframe as a museum piece stuck in a huge glass case as part of "bimodal IT."

Making Mainframes Modern

"Bi-modal IT doesn't make sense," O'Malley said. "This is like hiring Dr. Kevorkian to be your family physician. A house divided against itself doesn't allow you to win," O'Malley said, explaining, "Executives need to see that they need one process, one culture, and not two."

That it's important for mainframe developers to look forward and not focus on history.

"We're not just maintainers, or morticians, we have to be inventors," O'Malley said. "The toolsets have to transition and transcend the platforms. We have to let the programmers do their magic and work on the mainframe as well as other platforms."

For O'Malley, allowing programmers to "do their magic" means changing two critical aspects of mainframe development: Programming tools for mainframe developers need to look like the programming tools for other platforms; and waterfall development methodologies must be replaced by agile discipline.

SonarLint is an example of the sort of development software O'Malley feels programmers should have at their disposal.

(Image: Compuware)

SonarLint is an example of the sort of development software O'Malley feels programmers should have at their disposal.

(Image: Compuware)

On the tools front, O'Malley is blunt.

"We have to make the mainframe look like other platforms -- the old green screen isn't working any more," he said. In this he echoed what a growing number of IT managers are saying: If a company wants to attract the best talent among younger programmers, it can't offer them nothing more than 1980s-era interfaces for their development work.

Programmers today expect to see visual interfaces and highly integrated environments at their desks. Without them, they're likely to look for a desk in another organization.

The new development tools should be deployed as part of an agile development discipline, O'Malley said.

"You can't innovate with waterfall -- it's impossible. You can't have two systems -- it's got to be all agile," he said. It's not as simple as just changing processes, though. "But you have to give them the right tools. People don't wake up and say, 'I want to work in the IT department of an old-line company and use crappy tools.' These are the people who are going to re-invent your company. You have to give them the tools," O'Malley said.

Changing The Culture

O'Malley warmed to the topic of re-invention and used his experience at Compuware as an example.

"There's a co-dependency that exists. The culture is always the hardest part," O'Malley said. "We went from 40 years of waterfall to re-training everyone in Agile in 3 days, and burning all the boats."

[Read more about agile development.]

O'Malley saw that the radical change process was necessary because of the sheer magnitude of the change. "The gravity against change is huge. The culture is the hardest part and the biggest problem for executives. CIOs aren't transformative and they have to be. They're more of technologists than inspiring leaders, and they have to change things dramatically," O'Malley said.

Compuware CEO Chris O'Malley

Compuware CEO Chris O'Malley

Cultural change is hard, O'Malley said, because team members will always come up with a "rational" reason that their particular area can't change, even if they see the necessity of change for the rest of the organization. He said:

I talk about going through the changes and having the 7th employee of Compuware coming in and telling me that the changes in everything else was great, but agile was crazy for development. He saw it as going back in time to the wild west. He was lying to himself by putting a cloak of rationality around the cynical person he had become. We have to do what's required, not just best efforts.

O'Malley says that the software development group should be the engine of change for the entire organization.

"You used to think that sales people were the folks who were going to change your company, but it's your devops people who will transform the company," he said. The payoff for doing it right can be huge. "When you build a culture of agile it's amazing how quickly things can be done."

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
1/25/2016 | 7:30:36 PM
Agile - All In
I've had the opportunity to work in a waterfall development environment for many years and then help lead the transformation of that same organization to Agile. Compuware has done what many, including some reading this article, think is the impossible: transform the entire Compuware development organization to agile in a very short period of time. Was it changing the process or th people or the tools? The answer is it was ALL of them. Agile is having the right people, working on the right thing, at the right time with the right tools. Agile is more than a devleopment process, it is the attitude of the organization with a desire to deliver what customers need. All parts of the organization have to move together to achieve success. It was terrifying to consider changing the entire orgnaization to agile at one time but looking back it was absolutely the right thing to do. When going to agile, the 'pilot program' or one group at a time scenario is not practical because it allows the doubters to go back to their old ways. Going agile is not simple and there will be bumps in the road but you have to manage the bumps and not turn back. Having everyone in the organization moving in one direction makes it difficult to keep bad habits and reduces the resistance.

When considering is the 'all in' approach the correct approach, you should consider a few things. How many cultures does your company have? A company has a culture and changing part of the company to a different culture will be difficult if not impossible. When thinking of development groups, how will other groups know what type of interaction is needed? Is it reasonable to expect human resource, finance and other groups to remember who works in an agile group and who works in a waterfall group? Success is achieved throughout the entire company and expecting the same people to work in different ways for different groups will certainly cause confusion. Bi-Modal IT is not an all in approach.

User Rank: Apprentice
1/25/2016 | 6:14:11 PM
Re: Should mainframe software be re-architected?
Hi Charlie,

It is great that the mainframe can run Java, JavaScript, Node.js but the value of the mainframe to most companies in the existing data housed in corporate DBMS (DB2, DATACOM, IDMS, IMS) and the business applications almost exclusively writtien in COBOL that contains the business logic to access it.   COBOL and to a lesser degree PL/1 and other speciality languages running in z/OS (nee MVS) process the world's economy.

There are more than 250 billion lines of COBOL code in use on mainframes today.   When I say mainframe I generally talk about z/OS.  There are some companies doing great things with Linux on z systems but the bulk of the value is in the core z/OS applications.

Tools matter a great deal to make new develoeprs confident and productive in making changes to existing COBOL applications.  Its more than an IDE its using tools like Visualization to provide quick application understanding of both source and execution.

Tools like Topaz for Program Analysis can help a smart but inexperienced programmer understand an existing monolithic COBOL application. 

The key is tools and techniques that make the mainframe different only in syntax.  COBOL is not any harder than Java or Ruby on rails if you have intuitive tools to understand the structure and flow of data, programs, and a freindly editor. 

The concepts of SOA are visible in web enabled mainframe services.  Concepts like microservices will become more prevalent over time.


Best Regards,

Sam Knutson

Director, Product Management



User Rank: Apprentice
1/24/2016 | 9:01:21 AM
Agile ...Yes, Bi-Modal a necessity
Good post, I agree completely on agility side but I have to say I disagree on the points about Bi-Modal IT. Bi-Modal is unavoidable for a period of time as people evolve and old waterfall prodcuts end date and disappear. Let's be honest, some legacy people will end date with the legacy products. A big bang shift to Agile is wonderful in principle but utterly resisted in practice. Waterfall people support waterfall products, they are as ingrained in the way the product is developed and you cannot move that overnight to Agile. Technology can be changed faster than people. The investment in the people side to embrace Agile, then train in it and see what good Agile is takes time and during that period Bi-Modal is unavoidable. In my experiences of course ... but like I say good article to elicit discussion
Christopher O'Malley
Christopher O'Malley,
User Rank: Strategist
1/22/2016 | 5:35:01 PM
Response to comments.
Hi Charles,

Hope all is well and thank you for the comment.

First, please let me explain the problem that Compuware is working to solve.

We did a survey last year of 350 CIOs with some interesting key findings:
  • 88% believe IBMz mainframe will be a key business asset over the next decade
  • 81% reported IBMz mainframe continues to evolve-running more new & different workloads than 5 yrs ago
  • 78% see IBMz mainframes as a key enabler of innovation

These figure might shock some people, but there is a clear reason as to why CIOs are long on the IBMz mainframe.  Collectively, mainframe customers have invested more than $1 trillion in mainframe intellectual property (IP) in the form of 225 billion lines of Cobol code that increases every year.  This IP is 50 years of continuous IBMz mainframe customers' development efforts to codify effectiveness/efficiency measures, business rules, operating reports and fulfill regulatory compliance requirements.  In a real sense this is the DNA of these IBMz mainframe customers in code and data.  These mainframe applications continue to be the means of core processing for 96 of world's largest 100 banks, 23 of largest 25 US retailers, 9 of largest 10 insurance companies, 9 of the top 10 global life & health insurance providers, and the vast majority of large governmental agencies.  70% of global Fortune 500's day-to-day, second-to-second operations depend on the mainframe.  This reliance is further demonstrated in IBM's most recent systems z hardware financial performance.  Since the launch of the new z13 early last year, IBM system z hardware revenue is up 35%. Simply said, Cobol and the IBMz mainframe are here to stay.

So with all this Cobol intellectual property, customer critical dependence on these Cobol systems and an increasingly retiring mainframe development workforce that's taken these Cobol systems from birth to middle age...what's a customer to do?

Rewrite in a different language?  This has proven to be a fool's errand for large enterprises.  When you take a highly evolved and involved application system that took considerable time/money to create and attempt to convert...what you get is a highly evolved and involved application system that took considerable time/money and, in the end, do the "same thing" in a different language.  This, however, paints a much rosier picture than reality for there is something very extraordinary about zOS Cobol running on a IBMz mainframe.  The IBM zOS Cobol compiler is a marvel of engineering that has been designed to fully exploit the unmatched characteristics of the IBMz mainframe platform.  Nothing comes close to zOS Cobol in terms of reliability, scalability, performance, security and resource efficiency.  Customers have found out the hard way that converting from IBMz Cobol to something else is far from the "same thing"...rather the resulting system is unworkably less reliable, less scalable, more costly, ... which has ended all too often in lawsuits. This reality is now being exposed by analysts.  Gartner published a paper on the, "Moribund State of the Mainframe Migration Market."

This is not an issue that can be wished away or, for that matter, converted away and mainframe silo'd organizations cannot be rebuilt.  DevOps artisans will either by design or default will be given the responsibility for mainframe application development which is a responsibility they will hold for decades to come.  They will most certainly require that this development work be done within their culture, processes and tools.

Compuware is on a quest to make the mainframe different only in syntax in the eyes of DevOps polyglot artisans.  There is nothing inherently different about Cobol, as a syntax, that prevents it from thriving in a DevOps culture and in an Agile process.  As an example, Compuware is fully dedicated to agile development on the mainframe including IBMz assembler work.  Culture is by far the biggest challenge, but solutions become the enablers or disablers in the effort to change.  The Compuware tools are designed to remove the esoteric differences of application development up to the edge of the mainframe and then integrate with the leading DevOps tools (e.g., SonarSource, Atlassian, AppDynamics, DynaTrace, Splunk, ...) in ways that normalize the platform.  For DevOps polyglot artisans, syntax differences are trivial, as long as, everything else remains as close to mainstream DevOps as possible and that's exactly what Compuware tools are designed to achieve in partnership with leading DevOps vendors.  

Would be honored to talk to you more about Compuware!

Best regards,

Charlie Babcock
Charlie Babcock,
User Rank: Author
1/22/2016 | 2:56:41 PM
Should mainframe software be re-architected?
I'm not too sure about the tools issue either. Java, JavaScript, Node.js all run on the mainframe, don't they? And there are plenty of integrated toolsets for them. Most mainframe programs leaned heavily on the monolithic approach and might be hard to break down into discrete services and segments, more amenable to agile development and continuous updates. I don't know what O'Malley's solution to that is. 
User Rank: Ninja
1/22/2016 | 12:55:21 PM
Not sure I get the connection between better tools and Agile? I didn't think Agile was tool based, simply a way of working. Or is CEO saying he wants his developers to deliver the tools using Agile?

IBM has had modern IDE's for a long time now, the Rational stuff. Funny though, I use to develop client browser code in Sencha Extjs (with the Aptana plugin) but still prefer green screen & PDM/SEU for the backend RPG code. It's just so fast and you are keying text source code, "visual tools" don't really help much with that.

I have been experimenting with Sencha's Architect for generating Extjs and Touch client apps. I do see the potential in that WYSIWYG tool in speeding up layout creation. But you still got to revert to keying text for code to control events, nothing visual about that either.

But you are correct, the green screen should no longer be the primary interface for mainframes. Only us old school guys appreciate it anymore and we are headed the way of the dinosaurs.  :-)
2021 Outlook: Tackling Cloud Transformation Choices
Joao-Pierre S. Ruth, Senior Writer,  1/4/2021
Enterprise IT Leaders Face Two Paths to AI
Jessica Davis, Senior Editor, Enterprise Apps,  12/23/2020
10 IT Trends to Watch for in 2021
Cynthia Harvey, Freelance Journalist, InformationWeek,  12/22/2020
White Papers
Register for InformationWeek Newsletters
The State of Cloud Computing - Fall 2020
The State of Cloud Computing - Fall 2020
Download this report to compare how cloud usage and spending patterns have changed in 2020, and how respondents think they'll evolve over the next two years.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Flash Poll