Transcript of Dana Gardner's BriefingsDirect Podcast on Application Modernization

Edited transcript of BriefingsDirect[TM] podcast with Dana Gardner, recorded Aug. 21, 2006. Podcast sponsor: Hewlett-Packard.

Listen to the podcast here.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to a sponsored BriefingsDirect podcast. With us today are two executives from Hewlett-Packard (HP) to discuss application modernization. The idea is to deeply analyze an enterprise's applications and legacy code base to determine what could -- and just as importantly, should -- be redeployed on modern, agile platforms.

We are told that there are some 10,000 mainframes operating worldwide, consisting of some 200 billion lines of code. These are mostly on older systems. Today’s modern architecture allows for a great deal of lower-cost standardization and agility. How do we bring these two trends together? With us to discuss this are Rick Slade, the America’s practice principal for HP’s Application Modernization Service. Welcome to the show, Rick.

Rick Slade: Hi, Dana.

Gardner: Also, joining us is Paul Evans, the worldwide practice leader for application modernization for HP Services. Welcome to the show, Paul.

Paul Evans: Hi, Dana. Pleased to meet you.

Gardner: As I mentioned in our set up, we have a vast amount of mainframe applications worldwide. There is also a move now toward some finalization of architecture benefits around Services Oriented Architecture (SOA). There is a need for companies to become agile and fleet.

So I am wondering, are we just talking about mainframe applications, or is there a larger set of applications inventory involved? What is the addressable resource or asset library, if you will, for what we’re discussing around application modernization?

What’s the inventory here? Why don’t you try to take that, Rick?

Slade: Sure, Dana. Inventory, it’s a big subject. It certainly is a lot more than just mainframe applications. You talk about the big number of mainframe installations in the world today, and it is a big number. But there are also a lot of applications that many would consider legacy, that are running on more modern platforms or other platforms -- even on our own platforms from HP.

And so, what we’re looking to do is to help our customers transition or transform those applications to platforms and to software architectures that allow them to respond to change quicker, and hopefully cheaper. As far as an appropriate application ... for us it is any applications that constrains your business -- by not allowing you to move as you quickly as you’d like, due to competitive pressures or regulatory requirement changes.

Our goal is to look at these older applications built on more linear monolithic architectures, and transform those onto platforms and server architectures that promote flexibility. Architectures that actually let an organization achieve the "Adaptive Enterprise" vision that HP has been talking about for years.

Gardner: This is a scary proposition for a mainframe CIO, for someone who has been living in the mainframe world for a long time, and [where the systems have] been actually performing quite well and living up to expectations. I suppose the old adage, “If it’s not broken, don’t fix it,” plays into their thinking. What do you tell someone who seems to be in the mainframe environment and is satisfied with it?

Slade: That’s a great question, Dana. Let me say this, the mainframe is a stable platform, it’s a solid platform. The problem is, it’s a very expensive platform on which to deliver business services. The problem that organizations are having today are not so much from a stability standpoint, their problems are their inability to respond to change fast enough.

I read an article recently from Gartner, and their contention, based on research that they’ve done, is that 80 percent of an information technology (IT) budget is typically spent in maintenance -- in just maintaining their existing application stacks. Our objective would be to reduce that maintenance cost. If we can take that down by 20 percent for an organization, that’s a substantial amount of money. And then resources that can be applied to new value creation by the IT organization.

I think these modern architectures will allow our customers to ... respond [better] to these competitive pressures, as well as regulatory requirement changes -- certainly faster than they are today. We recently had an instance where a customer took their time-to-market, regarding adding new customers to a particular system, from nine months down to six weeks. That’s real business value that IT can now deliver back to the business due to use of these more modern application architectures.

Gardner: Now, we’ve seen a tremendous improvement in the functionality of hardware. We’ve seen a wide embrace of open standards and open source approaches. What are we talking about when we look at targets?

We’ll talk about a little bit later about the "how," but we’re still into the "why" to do application modernization. In order to understand the benefits of this change, this disruption, what is it that we are going to take these applications and their logic to? What are the typical targets these days for application platform modernization?

Evans: I’ll answer that one, Dana. I think the point is that there are several forces out there. And I think that Rick has hit on some of them. But in addition to that, this whole emergence of the SOA is making customers look at what they’ve got, and begin to ask themselves the question, "If we like some or all of the aspects of SOA, are we ready for it? Can we embrace it? Can we move toward it easily?"

So for most customers that have legacy applications ... running a stable but costly environment called the mainframe, this becomes quite a complicated task. What we’ve been trying to do is work with customers to begin to understand where the biggest bang for the buck is. Where should you go first in order to start gaining improved agility, lower cost, and the reduction of the maintenance cost of the software.

A lot of organizations spend upward of 70 percent of their IT budget just keeping what they’ve got going, just doing the routine adds, moves, and changes that keep those applications delivering to the business. But the challenge is that a lot of those applications are written in COBOL. For a lot of those applications, we’re seeing that the actual amount of COBOL written is still going up by 10 percent a year. That’s not because people are writing new applications, it’s because they’re just amending the old ones.

And many senior-level IT people understand this is a one-way street. We just have to turn around at some stage and begin to identify the sort of applications that would respond well to a modernization approach, and that may well take them toward this sort of infrastructure Nirvana, as it were, called SOA.

But sometimes it's difficult to understand, "Where do I start?" Do I start with a simplistic application that would have limited business impact? Or do I go to the other end of the scale and choose very complicated applications that run the business, which could be viewed as risky.

So, what we’ve been trying to do is go with an approach that allows us to identify where you should move first, to gain an accepted service level. But more importantly, we believe in taking the essential step of actually modernizing the software architecture.

Gardner: All right. So perhaps I was not thinking of it in quite the right way. It's not so much about where I'm going in terms of a definitive destination, but how can I actually take these assets and resources and put them on an architecture journey -- perhaps a lifecycle journey -- that might end up on a number of different targets over a period of time. Is that the end goal here?

Evans: It is very much so. I think most people in IT would state that the systems they have today have been relatively organic. There was never a master plan. Most mature, large companies have grown their IT resources over 20, 30, or 40 years. They have seen enormous change in technology during that time -- especially in the hardware platforms. The amount of power we can put into a system today has just grown beyond anybody’s wildest dreams.

So, once we’ve been able to harness that power -- to produce systems that are smaller, faster, cheaper, and develop less heat output -- we can effectively shrink datacenters. I think the IT industry has responded extremely well in harnessing that capability and delivering it to customers. Users have similarly utilized virtualization or consolidation. But we see a lot of customers today reducing their datacenter footprint because they can harness a lot more power in a much smaller space.

The days when mainframes were run by people with white coats behind locked doors are gone. The point is, we have seen enormous growth on the hardware side, and software technologies have grown up and matured, too. The real benefits, we believe, for customers to really exploit that power comes when you apply a similar amount of focus and attention to the software environment; just as you’ve done in the past to the hardware environment.

Rather than take an organic approach, I think customers and companies and organizations are striving for a master plan. It doesn’t have an end date, but it's like a journey. They know where they’re going. They want to develop a system architecture that allows them to make the decisions of what am I going to include going forward, and what am I not going to include. And that will help them make the decisions about choice and moving forward.

Slade: I'd like to make a point. I believe that architectural-targeting decisions are driven by business requirements. I think you said it properly earlier, in that we don’t have pre-defined targeting solutions. Our attempt, our goal, is to look at the business requirements and to help the customer determine what is the right platform -- what is the right application architecture -- on which to deliver that business service.

That doesn’t mean we don’t take into account existing corporate standards or existing corporate policies. Those things are important, and they feed into the decision-making equation. But again, the belief is to let business requirements dictate technology solutions, so that the organization can respond as cost-effectively and as quickly as possible.

Gardner: And just expanding on that point about business requirements, what is the business rationale typically? Is this strictly a dollars-and-cents thing? Is it a bit more qualitative than that? Obviously we want to cut down the ongoing operating costs. When it comes to bringing the chief financial officer (CFO) and the chief executive officer (CEO) in on this to get the funding -- to get the go-ahead -- what typically are the business rationales for embarking on application modernization?

Slade: Cost is always a part of the discussions, but it's not strictly the only element. In fact, most organizations that are talking to us today have a need to be more responsive to their business users.

I was talking to a chief operating officer (COO) not long ago, and he made it very clear to me about the potential cost reductions that he could have by modernizing his application stack. His response was, "That’s good, Rick, and that’s certainly something we need to talk about. But my problem is more about time than cost." And that’s an important point.

It takes IT organizations too long to respond to business-change requirements today. We, as IT professionals, have to determine how we can be more responsive to the business. Quite often the only way to do that is to change the software architecture, to use more modern architectures that allow us to make changes fast.

I think that is what this is all about. So cost certainly is an issue. I certainly believe that we can reduce the cost every time. I think that’s been proven time over time. But I think the big issue that is causing organizations to look at this today is through their inability to respond as fast as a business would like.

It’s been an age-old problem between the business users and the IT departments -- businesses always complain that IT can’t respond quickly enough. And the problem is that typically it takes so much time to do impact-analysis and impact-testing on these very monolithic and linear software applications. If we can reduce that time-of-maintenance, we can improve their time-to-market as an IT organization.

Gardner: Before we get into the "how," let’s probe a little bit into the "what" of application modernization.

It seems to me that we are going to have to look at identifying code, cleansing code, making logic extractible, looking at the data set and separating that out and allowing it to emerge into another environment. And then there’s presentation logic, and going from one type of user interface (UI) to other accepted standards. Can you give us a sense of what is required, what does the process boil down to? What do we have to do in order to extract and modernize some of these typical applications?

Evans: The first thing that we don’t do is look at code, because that just wouldn’t tell us anything. I think, as Rick said, it’s the alignment between IT and business that counts.

Today, any business manager will complain, "It takes IT too long to innovate or change anything." Business wants to innovate. Their idea of maintenance is that it’s sort of interesting, but not essential. What they are interested in is innovation: "I want to do something, I want to improve my business, and I expect IT to be right by my side."

In some instances, there is lag -- there is a significant lag -- from when innovation is sought and when it happens. It’s as Rick said, what we want to buy people is time. And what we want to do is synchronize to some degree where the business wants to be and where IT is. And in many instances that’s just not the same. Business asks for something, and then six, eight, 12 weeks -- whatever it is -- later there’s a response. And in some business managers’ minds, that’s not acceptable. So, the first thing we are trying to do is to align these two -- business and IT -- much better.

But in terms of responding to a modernization request, the first thing we have to do is to understand just what is in the applications portfolio. You would be surprised, there are a lot of large customers we work with who are more than happy to admit that they don’t actually know all of the applications they have, and what those applications do. Because they grow up organically, no one has kept track of all these things.

So the first thing we may have to do is to perform an inventory of the critical applications a customer has, and then determine how they constructed them. We perform an Applications Rationalization. And what we are looking at here is the intersect of the criticality of an application to the business, versus its technical quality. What we are looking for is applications that are critical to the business, but that their technical quality is below par, below standard, holding the company back.

A typical example would be a mainframe-based application running in COBOL, monolithic in nature, very difficult to make significant changes to, where the documentation may have been lost or may have been never been produced, in which maybe the original architect no longer works for the company. And therefore it becomes quite a challenge if you are going to make significant adds, moves, and changes to those applications.

We are looking initially for the applications that are critical, and yet the technical quality is not what the customer needs. There’s really no point spending time on an application that is well-written, well-documented, and is actually not in the mainstream. And that application could be running on a mainframe too. As Rick said, we are not going in there just to get things off the mainframe -- we are going in there to help a customer understand what is critical to their business, what we could improve for them, irrespective of the platform it is running on.

Gardner: Anything to offer on that, Rick?

Slade: I agree completely with Paul. The first thing to do is to identify where you have a problem. And then to attack it from a more technical perspective. We look at the application stack and categorize different components that make up that stack.

From our perspective, most applications are made up of three major categories or components. We have runtime, development, and management components. From a runtime standpoint, you’ve got source-code, you’ve got data, you’ve potentially got a third-party or utilities purchase. As Paul indicated, we have got to take inventory of all those components to understand what the mapping strategy will look like.

So before moving to a target environment ... we have to understand how are they maintaining those applications today, especially those custom applications. I think one of the problems in the industry today is not looking at those components. [We need to examine] the management components before making this type of move, transformation or modernization.

One of the things that we try to do is take a very holistic perspective of modernizing an application, by looking at what it's going to take to support and maintain all of the application. We want to understand what is being used today to manage a particular application, what are the tools that you going to use to monitor it in production, and to make sure that we have the same capabilities going to the new target environment. These are critical to being able to provide the reliability and the availability of the business customers’ needs and demands in their production application stacks.

Gardner: Now, this does not sound in anyway trivial. Not only are you talking about finding and auditing all of the applications, but weighing those applications in terms of their use -- and not just in terms of their quantitative use but also their qualitative value to the company. And not only now, but perhaps in the future.

So, this sounds pretty tricky. Is there a secret sauce? Is there a specific methodology? How do you go about searching for these applications and then rating them in such a way as to say, “Here are the sweet spots, here are the ones that are going to be important, here’s what’s going to bring business agility and reduced-time-to-market?" And, at the same time, then move these customers to platforms that will reduce the total cost of ownership.

What’s the secret sauce here?

Evans: We would look very silly in front of a customer if we said, "This was easy." Because he would say, "Well, if you think it’s easy, then you don't understand." So, the first thing: This is complicated.

That’s why customers turn to the outside of their own organizations, because they are then dealing with people who have done these things before. It’s like anything, you know. But in terms of what customers ask for, they are looking for a process. They are looking for methodologies. They are looking for experience. They are not looking to be the guinea pigs.

They are looking for organizations that have done it all before. But they also need a methodology that can be explained to them, and that makes them understand the steps in order to start extracting data. And also to understand the basis of how we are going to make a decision.

This is not just about coming in and saying, "You are running a mainframe in COBOL. You need get rid of it. We’ll do a rip-and-replace over the weekend. And by Monday morning, we are back online." That isn’t going to happen. Anybody who says that will be out of the door by any credible customer.

This is a process that we have to move quickly in order to demonstrate to the customer that there is money to be saved and money to be made. So, our whole approach is to get in and at least do an initial exploration that will define where are we going, and what we are going to do and not do. And then after that, we begin the deep-dive to look at the code. Then we can determine, “Hey, is this good code, is this bad code, is this dated code?” We can find out if the code hasn’t been used in years, whether it supports any form of business process, or whether it is just sitting there taking up space.

So, those are the things we have to demonstrate to a customer in order to give him confidence. Those are the things that help us with the application modernization decision-making process. Rick?

Slade: Oh, I absolutely agree. I think the key, Dana, in modernization efforts -- especially against these mission-critical production applications -- is a very systematic process. And we believe that we have put one together that is very robust. It's very disciplined. Quite honestly, a lot of engineering rigor is built into the system -- all for the purpose of mitigating risk.

Risk mitigation should be one of the key characteristics of modernization efforts. Again, we are talking about your production applications. Transitioning those, as Paul indicated, is a complex task. We believe we have built a rigorous approach based on our own experience. And we have implemented best practices from software engineering to our overall methodology to help us manage risk, and then to extrapolate the information we need to properly diagnose and determine what the targeting strategy should be.

The other key component in our solution -- and maybe a part of that secret sauce, as well -- is in the use of technology and tools to help us with the different phases of modernization and analysis. I think that to manually go through a lot of these systems is a complex, difficult, and expensive proposition. To do it manually is unacceptable.

So the use of the right technology is essential -- and we have spent a tremendous amount of resources, time, and money looking at this technology. We’ve developed in-house technology, as well as technology available in the market. And we are constantly looking at technologies to help us be more efficient in the analysis work that we do. Once that analysis step has been completed and a strategy developed in the proper use of technology, then we actually assist with the transformation process.

Again, it is not a simple exercise. It’s a very complex exercise. The use of technology allows us to minimize risk because we are working in an automated fashion, a consistent fashion. And I think that’s critical in transforming these applications. So, two major components that are key to our success: The proper use of process, and the proper use of technology -- both are needed to manage and mitigate risk.

Gardner: I would like to understand a little bit more about how you’ve applied this internally at HP. HP to me symbolizes a perfect organization for this sort of activity. You are decades old. You have gone through some massive mergers and acquisitions. There probably has been Digital mainframes, there’s a lot of HP UNIX platforms. You’ve been running a lot of systems. You are a global company.

How successful have you been at modernizing your own applications, and what have been some of the unanticipated consequences of going about this?

Evans: I think we would love to answer that with, "No, no, HP has never had this problem." [Laughter]

Unfortunately, you are absolutely right. I mean, mergers, acquisitions, etc. And therefore our internal IT folks are challenged just like everybody else’s. We may have a slight preference on supplier, but putting that to one side, the challenges faced in terms of an applications portfolio are no different than for any other organization.

So, we have seen significant gains. As I started off saying at the beginning of the chat, the situation is that we have seen significant gains when we have investigated our applications portfolio and then aligned that to the business need. This is especially true if you are in mergers and acquisitions -- and every major organization today is either been acquired or is being acquired.

And the point being is, it can lead to massive duplication. And like I said, if you’re going to be spending 70 percent of your IT budget to stay exactly where you are, you are not innovating. You’ve to go to look around and start to understand where the lower-hanging grapes are, to address application duplication, and determine which applications are absolutely critical.

And inside of HP, one of the first things we’ve done, is to really have the dialogue with the businesses, to ask, "What do you need? And more importantly, what do you not need?" And that’s very difficult, because everybody is obviously keen to start new projects and to develop new applications.

It’s amazing what we have found internally, that applications have been identified as being redundant and not supporting the current business processes. It's amazing. As soon as you claim that an application is redundant, then overnight it becomes strategically important. But you’ve got to get through that. You’ve got to understand the business processes that you are really looking for. And, of course, the challenges here are with the older applications, those business processes that are embedded in COBOL.

They are not exposed. They are business processes that are just mired away in millions of lines of code. And in the market today there are tools that can bring to the surface these business process. So you can say to a business unit manager, "Do you need this, really? Do you want us to spend 500,000 pounds, dollars, Euros, or whatever, per year in keeping this alive? Is it necessary for your business?"

The more of these processes that they agree are no longer required, the less money is spent on modernizing and maintenance, and the more that can be spent on real innovation. And that is where we have seen some really significant strides forward internally. There is this rationalization of the portfolio and by retiring applications in a well-managed and graceful way.

You are not walking in on a Friday night and turning it off. This is communicating to people that as of a certain day, an application is going to be shut down, and that you’ll be using a new application that is probably centralized and that works across a group of organizations rather than in a siloed one. And that process also puts in place a strategy that takes the old data and the application and archives it. For many of our customers, it’s a legal requirement for them to do that. They just can’t throw it all away.

Gardner: Okay, Rick, any unintended consequences in terms of what HP has discovered internally in going about application modernization?

Slade: The learnings are great, Dana, from a practical standpoint. I think that most people are aware of the huge datacenter consolidation network project that’s under way at HP. It’s been in the press. We in the consulting side do work with our IT organization. Quite honestly, our IT organization provides a lot of information back to the consulting organization. So it’s been a very nice environment. We have learned a tremendous amount in our own experience in the consolidation and modernization work that’s still in progress. But I think that we have also been able to share with our own IT organization some of the best processes that we have incorporated into our methodology. That allows them to move a little faster. It’s been a good marriage, and the work continues.

Gardner: Now, in trying to then put this into a larger context, application modernization isn’t happening within a vacuum. There are other larger trends afoot in a simultaneous fashion, which perhaps leads to the notion of, "A whole greater than the sum of the parts." I am thinking of virtualization, SOA, IT shared services, portfolio management, application life cycle management.

Are there other payoffs to application modernization? When we look at application modernization and we put it in the context of these other trends, is this a cog in the gear that grinds toward the fruition of some of these other productivity trends?

Slade: Well, absolutely. I was involved in meetings just recently about work occurring at HP and with their architecture and strategy groups in helping transform IT organizations. Application modernization simply becomes a component of that overall IT transformation. All of the initiatives that you talked about are things that companies are looking to do to help them deliver services better and more cost-effectively.

IT transformation is a major issue right now with HP. It's something that we are looking at and, in fact, are proving out. What we are doing now is to take those different services and roll them up under a common IT transformation umbrella framework. The possibilities are very exciting. The Adaptive Enterprise vision that HP came up with a few years back is an incredible vision. I think what we are seeing now is the realization of that vision -- how to achieve that vision -- and we are helping our customers with the services to actually make that vision a reality.

Gardner: Are there some larger competitive economic issues here? For example, let's say you are an established enterprise, you have been around for decades, you’ve gone through mergers, you’ve built out geography after geography. And now, perhaps, you’re going to be competing against a greenfield company that has just sprung up. Perhaps a Web 2.0-type of concern, built of outside services, using SOA. And they can be fleet. They can also be run inexpensively.

It seems to me that to compete with some of the newer companies that application modernization becomes a bit more critical. Is that overstating it?

Evans: No, I think this is where the "agility" word comes in. I think that’s why large companies, or parts of large companies, understand why this term "agility" has resonated so well. It's not a marketing buzz word -- it's what people want to be like.

When each of us gets out of bed in the morning, goes in the bathroom and looks in the mirror, we would like to look and see agile, nimble, you know, people that can respond to change extremely well. Organizations are no different. Things happened that they can’t predict.

As you say, new, very fleet-of-foot, greenfield company startups -- they have no legacy. They could move extremely quickly into markets, and large organizations have appreciated that. You know that painfully from the past. I now understand that if there is one attribute that IT systems need to be, it is agile. I want to do something in the morning that’s going to effect something in the afternoon. I do not want to be told when I want to do something in the morning that it is going to take six months. Because that’s just not acceptable.

Gardner: Well, I think that’s a good closing point. I want to thank you both very much for sharing your thoughts on application modernization.

We’ve been discussing this topic in a sponsored BriefingsDirect podcast with two executives from Hewlett-Packard: Rick Slade, the America’s practice principal for HP’s Application Modernization Services, and also Paul Evans, who runs the worldwide practice for application modernization for HP Services. Thank you both for joining in.

Slade & Evans: Thank you.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. Thanks for listening.

Listen to the podcast here.

Podcast sponsor: Hewlett-Packard.

Transcript of Dana Gardner’s BriefingsDirect podcast on IT shared services. Copyright Interarbor Solutions, LLC, 2005-2006. All rights reserved.