Automating the Managed Application Lifecycle Helps Delta Airlines Better Deliver Critical Business Applications

Transcript of a sponsored BriefingsDirect podcast, the second in a series discussing a new book on ALM and it's goal of helping businesses become change ready.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: HP.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you're listening to BriefingsDirect.

Thanks for joining this sponsored podcast discussion that examines a new book on application lifecycle management (ALM) best practices, one that offers some new methods for overall business services delivery improvement. Complexity, silos of technology and culture, as well as the shifting landscape of applications’ delivery options have all conspired to reduce the effectiveness of traditional applications’ approaches in large organizations.

In the book, called The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle, the authors pursue the role and impact of automation and management over applications, as well as delving into the need to gain control over applications through a holistic lifecycle perspective.

This is the second (read more about and access the first podcast) in the series of three podcasts on the "Application Lifecycle Management" book. We're here with the authors, but we are also here to learn about how one enterprise, Delta Air Lines, has moved successfully to improve its applications’ quality and impact and to better deliver real business results from those applications.

We will hear Delta story from two IT executives there and gain the reactions to the new application life cycle book’s findings. So please join me now welcoming our panel, David Moses, Quality Assurance Manager for Delta’s eCommerce IT Group, and John Bell, Senior Test Engineer in the eCommerce IT Group at Delta.

David Moses and John Bell: Thanks for having us.

Gardner: And we're joined by book’s authors, Mark Sarbiewski, Vice President of marketing for HP Applications, and Brad Hipps, Senior Manager for Solution Marketing at HP Applications. Welcome back, Brad and Mark.

Mark Sarbiewski and Brad Hipps: Thanks, Dana.

Gardner: Before we get into Delta’s experience, for our listeners, I'd like to explain a bit more about the book. Mark, what were the driving needs or necessities that prompted you to write this and then perhaps get into some of the high-level takeaways and bindings?

Combination of factors

Sarbiewski: It really is a combination of factors, but the headline for me is that, more than ever, business moves as software moves; as your website moves, as your ERP system is advanced, your supply chain, and your financials.

Businesses are driven so much by software now that it's really the long pole in the tent. Standing up infrastructure is a necessity. Potentially, it can be done really fast. How quickly can I innovate on my capabilities for my customers or my internal users?

So, business moves as software moves. When we look at how we've done over the last 10 or 15 years, I could sum it by saying that legacy applications and approaches are just too slow. Not only are they too slow, they are too costly. They're riddled with security holes, which are increasing the challenges out there.

So, we have this dynamic that the business needs to move faster. Software is a prime driver in innovating for the business, and where we've been is simply too slow. We need to rethink our approach across the board, because there is no one silver bullet. It really boils down to I have to leverage the latest technologies for things like reuse, where I get huge leverage for richer customer experiences that need those wonderful new web application technologies that we have.

I have new processes that I can leverage in forms of agile and iterative types of things. To keep the cost in line. I really want to be able to leverage global teams for flexible low cost, but expert resources around the globe. I want them acting as if they were all local, like a dynamic Tiger Team that was all local.

That’s a lot of change to make happen to serve the ultimate business needs. We took the opportunity to take a step back and ask how all these things come together and how you can blend this modern approach to really deliver what you need to deliver for the business.

Gardner: Brad Hipps, do you have anything to offer in terms of what people will take away from the book?

Hipps: A lot of it is the chance to take a step back and have a bit of brain space to consider and contemplate a lot of things Mark just touched on -- what are these ramifications for my organization?

Nine times out of 10, most of us who are in IT developing applications, trying to get on top of what it is the business wants, don't generally have the luxury of taking a step back and asking has the ground shifted underneath my feet with regard to all the things I am now expected to do and the ways I am expected to do them, whether that’s process shifts, organizational shifts, or technology shifts.

Generally the case is that the ground has shifted. Am I equipped, organized, and oriented to respond effectively to all these changes? That’s one of the driving factors of the book and one of the hopes that gives people a chance to step back, contemplate what these changes have been, and also give a bit of guidance about how we might better get on top of these changes and really wring the benefit out of them that we had expected when we first began to make them.

Gardner: Let's go to David Moses at Delta Air Lines. This isn’t just academic now. This is something probably near and dear to you in your day-in and day-out activities. Maybe you could sum up for us quickly what it is that you are doing there at Delta and why your customer-facing applications are so important to your business.

Innovating for customers

Moses: The biggest thing that we have at Delta is to make sure that we innovate for our customers and give them the latest greatest ability to take control of their situation. If somebody wants to book a flight, they should be able to do it on any media they like.

We want them to be able to make it in as few clicks as possible and as little typing as possible. We really want to make it as convenient for the customer and through the entire experience from the inspiration, all the way to when they are back home. We want to deliver quality products to them.

That comes down to innovation and speed, because you can innovate for ever and never actually release the product. For us, getting it out the door is very, very important. Some of the things that we've heard already from Mark and Brad touch on the need to back away, get out the weeds, and look at your overall lifecycle to make sure that you can get that speed. A lot of times, if you're doing the status quo over and over again, you never realize how fast you can be. So, you raise your head up, look around, and try to make some big changes.

Gardner: John Bell, what do you see as some of the hurdles that you need to continue to get over, in order to get into that innovation and speed? What are some of the complications that are typical, when you're trying to move these applications fast, but you also need to make them of a high quality?

Bell: One of the things that’s really important to us is that we work with multiple vendors in multiple locations and with multiple time zones. It's important to make sure that all of them are using the same processes and that we're all using the overall tools. We use quality center personally to help organize a lot of the requirements and things like that in our testing efforts.

It's important that all of our vendors, whether it's in-house or people outside, are giving us the same processes and that we are able to leverage any of our automation or any of our business process testing or any of those tools, and that we can actually deliver high quality software quickly, can reduce our turnaround time, make sure that we're giving customers their best experience, and that we are getting our time to market in a timely manner.

Gardner: David Moses, we heard a lot of in the book about automation and management and then integrating those as much as possible. Maybe you could give me some perspective on that higher level ability to excel at applications, multiple applications with rapid iteration, but not lose control, and not let the complexity lead to chaos.

It's about getting rid of all the clutter, reducing the complexity, having simple processes, getting rid of all the ones that don't matter, and just really streamlining.

Moses: Complexity is always the enemy of speed and innovation, isn’t it? The idea is to make it as simple as possible by having one version of the truth. You really have to get to that point, a central repository of data, a central tool that everyone can use. As John said, we use Quality Center. We keep everything in that, requirements, tough cases, automation. We pull scripts and things from there for our test plans. We have one area with all that data, so all of our areas can come to that and pull that information.

Whenever somebody needs to start up a script or anything like that, they’ve got a library that they can pull from. They can bring it into their project. When they are done with their manual testing and they place their test plan back in the library, John can then take those pieces and immediately automate them.

Somebody once said they required a form to find out who they were going to, or what pieces they were going to automate. For us, if you have one version of the truth, you know when things are checked back in. You know when your test plan has been updated and your automation people can make that decision. So, it's about getting rid of all the clutter, reducing the complexity, having simple processes, getting rid of all the ones that don't matter, and just really streamlining.

Gardner: Also, David, when you have a lifecycle mentality, you can fall back to that single system of record for the application process. You can extend that not beyond just the development test and deploy phases. It’s something that probably benefits the operation side, maintaining, iterating, and improving on that app over time.

State of the application

Moses: Definitely. It's a great tool, because everyone has access to it. Everyone from our business side people to our IT side, our operations people, can look in this and see exactly what state the application is in at any time. They've got that snapshot. They can go in and determine what new requirements they need to make and what enhancements they want. It's really helpful.

Gardner: John or David, I don't know which of you would be more comfortable, but can you tell us a bit of about the recent development activity, maybe moving towards multiple devices or entry points for customers. I know that's important to me when I fly. Tell us about the way that you have been executing on this innovation, maybe relating that back to some of the principles in the ALM book.

Moses: Recently, we've brought in some of the mobile devices like the iPhone and some of those types of applications. In the past, a large number of our customers have always been using the .com form. Now, we're finding more and more users are going towards the mobile devices.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

We wanted to make sure that a lot of the applications lifecycle testing we had done with the .com could also be used with the mobile. We were able to take automation and a lot of the test cases and type things we had used with .com and use it with mobile.

We did write automation associated with mobile and were also able to bring that back into Quality Center, running that via Quick Test Pro. Even though mobile was a newer area for us, we were able to get the speed to market up on that as soon as possible.

Also, we were able to leverage that and use some of those automated scripts. We run those on a daily basis against our production mobile environment. If something is wrong with that, we know early in the morning. We run these scripts early in the morning before we come in, and we can know right away if something is there.

They can go in and determine what new requirements they need to make and what enhancements they want. It's really helpful.

So we were able to take the lifecycle information and the wins that we have got from the .com, and bring that into our mobile apps, and it's really helped us a lot. Our speed to market has significantly improved with that.

Bell: Another case would be our new homepage. We're sitting here at the end of October 2010. About a month ago, we released a new, more streamlined homepage, a lot more innovative. A lot of people looked at that. We hid the logo during usability testing, and people were surprised to find out it was an airline website. They thought of us as one of the cool guys out there in the travel world.

We're getting much better in this area. By using all the feedback that we get from the customers, importing information in the Quality Center, tracking everything that we have in there, we were able to look at what we needed to make changes to. Once we released this, it was something that the customers were wanting, so it got a lot of good response.

Gardner: Mark Sarbiewski at HP, tell me as you are listening to these gentlemen discuss their efforts, how would some of the principles from the book help. It sounds to me as if it was very complex going mobile or recasting your website. It could slow things down. It sounds like because they took the proper steps, and it actually fell right into the place.

Getting visibility

Sarbiewski: One of the keys that I heard them talking about here is giving everyone visibility into not just the state of where things are, but the next things that have to happen. One of the important things that to tease out of those kinds of statements is the integration of the management information. What are the requirements, which have been covered? What remain? What tests have been run? What defects are found against what code?

There are a million things that happen to progress that project along. When a test fails, a bunch of stuff has to happen. You've got to go find that and fix that. In all those granular activities, there's a huge opportunity for lag, mis-communication, finger-pointing, claiming it's not a defect, and all that.

When you have a system that pulls everybody together like that and gives a real-time view, it really helps to advance the work forward as well. I also heard them talking about how tying automation into that management system allowed them to do a cool website, that Web 2.0 feel, very slick with a rich user experience, which is a must today, as well as mobile, which is a must, without slowing things down.

To me the translation: Enormous competitive advantage in the marketplace. This has probably never been more true. The technology teams are giving business an enormous competitive advantage, like the kinds of stuff that they are doing.

Gardner: How about that David Moses? Toot your horn a little bit. The applications that you and John are helping to develop and deploy, how impactful is this for Delta? How many of your airline tickets are now being purchased and the customer service elements being delivered through these apps? Is this sideline or is this much more main stream?

Mobile is the future. Everyone is going towards mobile devices and portable devices.

Moses: It's truly huge. I mean if you look at Delta.com, it's the main revenue driver for the entire company. So it's our face to the world, and streamlining that process where people are making it better and making the customer experience better is our number one goal. We want to really give our customers what they want and make it easy for them, because we have a wide range of customers.

We have pleasure customers who travel with their families once or may be twice a year, sometimes even less, and then we have people who travel with us every week. So we have two very different types of audiences and we have to cater to both. We have to make it fast and enjoyable and we have to allow them to dream a little bit and be inspired by where they want to go.

It's one of the biggest things that we have on our plate with mobile. Mobile is the future. Everyone is going towards mobile devices and portable devices. You're seeing more and more iPhones, iPads, and Android devices out there in the world, especially when you walk through the airport. We don't like that it happens, but sometimes things are out of our control like weather. And, we are always safe, so these things impact our schedule.

Our devices now will allow you to jump right online and rebook, and take care of yourself. We're actually going to do it for you first, and we are going to give you the option of keeping our suggestion, but if you want something different, you have got that choice. Its options and speed that really count, when the customers want to do something that impacts their lives. When they are trying to use the product, they can impact whether they get home to see their kids tonight or not. You need to give them options and you need to give them something really quick.

Gardner: Brad Hipps, as I listen, I also recall that one of the principles of the book you and Mark wrote was about being change ready, and I think you were talking about being change ready in terms of how you develop applications. With Delta, that change readiness comes at multiple levels. Not only do they have to innovate rapidly in their development, but their application themselves have to be change ready. That is to say, they need to be able to react to changing weather and very high scaling multiple variables involved with keeping all the people up-to-date.

Maybe you can help me get your impressions about how important change ready is and Delta is probably a poster child for that.

Core lifecycle

Hipps: I think that's right. In the book, when we talk about the core lifecycle, historically the SDLC -- we just call it the core lifecycle, so as not to get lost in alphabet soup. Within that we see traits among world-class organizations. There tend to be four traits that these world class organizations have mastered, and we list these traits as being change ready. They have a high degree of predictability, high degree of repeatability, and certainly their output is of high quality.

So those four: change readiness, predictability, repeatability and quality, tend to be abstracting some traits that we see across these great orgs. Those tend to be the key ones that really they are very effective at. David and John have talked about that we have got data points in each one of those, in some of the examples they have given.

A lot of this change readiness to a large degrees is formed by the point that we made in the beginning in the podcast, which is that fundamentally everything that business wants to do is going to have some applications or set of applications behind it. There is going to be a dependency there.

As Mark said, the business is only as nimble as its applications are. That puts applications teams in a position where they are not holding the business off at arms length, and saying, "No, no, no, no, no, I can't do that. No, that will take months." That rigidity may be historically where we came from, when we had fewer applications. They changed less. They were much bigger, more monolithic, and brittle. That is not the world we live in today.

Today, change is the expectation. David and John have been talking about this code being lead revenue generator and delta.com being the lead source of revenue on the Delta side. It's a great example. Clearly, anything the business wants to do to advance its market presence is going to come through that application.

You’ve got to have that one version of the truth. I would highly recommend getting that, the central tool that everyone can use and that you can put everything in.

The fact that they have leveraged automation and asset reuse and taken the time to build requirements traceability are all tick marks you put against organizations that have configured themselves to be change ready. That means they have stripped out as much latency as possible, the time it takes to do impact analysis.

They can see pretty quickly what all the dependencies are as a new change comes across. That’s just speaking of the assessment. There is, of course, the execution, which depends on automation, asset reuse, and all the things they talked about. We probably covered four of those, but certainly the change readiness does stand out.

Gardner: David Moses, the idea that more businesses are going to have to do what you have seems pretty clear. You're already well into updated web, very fast change transactional integrity, bringing in mobile devices, and it sounds as if you are well advised in terms of the ALM principles that the book discusses. For those organizations that are not quite there, that are still getting up to speed that are transitioning from legacy approaches and methods around development, what advice might you give them in terms of trying to get to where you already are?

Moses: This is my favorite topic too. First of all, you’ve got to have that one version of the truth. I would highly recommend getting that, the central tool that everyone can use and that you can put everything in.

Second, it’s about mindset and alignment to your goals. You have to have alignment to the customer. You still have to have department goals, but they should be aligned to what the customer needs.

Contradiction in goals

A lot of times, you see a contradiction in goals between the business group and an IT group. Delivering what the IT group wants to do may not exactly get what the business wants. And if the business was focused on the customer and the IT groups are focused on how many projects they can get out, but doesn’t really matter what projects they are, then there's an issue.

So, you have to really align very closely between business and IT, so much so that if you even have something that is a huge impact to your company, you may want to wrap a special forces team or integrity team around that, and have that group be one. Business and IT all in one group -- that way you completely eliminate the us-versus-them mentality. If you can’t do that, definitely make sure that you're aligned to the customer.

Gardner: John Bell, any further words of wisdom that you might want to share with folks who are making the transition from older legacy, development, deployment, and test practices to some of these newer principles?

Bell: One thing to add to that is that, at first, it can be a little scary moving things in, like moving all your requirements into one area and getting all the test cases and things and even looking at automation.

Sometimes, you have to take a half step back in order to take a full step forward. With us, even as we were moving things and centralizing it, there could be a little pain point in doing that, but that pain point will more than payoff in the long run. A lot of the people who are holding on to the old methodologies and ways of doing business, are thinking, "We're going to have to take a step back to do this."

You're going to get that money back, plus your time, so quickly that you will be shocked.

Whatever step you take in that direction and whatever pain point you take as you move forward, once you start getting the automations in place, once you get these tools in place, you’ll see that you can start moving faster and faster that any initial pain point you took. You're going to exponentially get that money back, plus your time, so quickly that you will be shocked.

Just look at the changing world that we live in. With delta.com now, we live here in Atlanta. If you go over to the airport, you realize that our business is not just flying customers within the United States in English. We now have kiosks in six different languages, and you meet people from all over the world that are now using our products and our websites in everything from simple Chinese to French.

It’s important that we realize the global nature of what we are doing, and that our methodology and our IT departments have to align ourselves, so that we can move this quickly. Without the automation and without the centralized tools and things we would never be able to put out as much work as we currently do.

Moses: If I can jump back in, there is one thing that John said that reminded me of something, as far as taking those steps. You need to take a step back to take two steps forward, when you are coming down to requirements -- another one of my favorite topics. I spent so much time trying to convince other managers in the organization, especially the BA manager to really input requirements in the Quality Center. I really wish I had Quality Center 11 at that time, because now it’s like a Word document to enter your requirements, which is what everybody wanted, right?

Back then, there was a lot of resistance to it, because there were forms and windows and things to fills out. So, it would have such an easier discussion. I hear that often too, whenever I am at HP Software Universe and people are talking about this. They say that there is such a resistance to certain things and certain teams incorporating their work, but now it’s so much easier that it’s almost a no-brainer.

As I said, I wish I had QC 11 back at the time I was fighting that battle, but thankfully we won, everybody saw the benefit of it, and we have been going forward ever since.

Requirements are important

There's another benefit, whenever you're talking about companies moving forward and innovating. I'd like to talk about requirements and not having your quality assurance people sitting in requirements meetings. To me, your quality assurance group really wants to know what the requirements will be, not what they may be. So, they're sitting in a meeting for a few weeks or months at a time to get requirements down, talking about what may be, when they could be testing.

You need to get things out to the customer. You can leverage your team like that. We do a ton of work with the small amount of people that’s comparable to other people in the industry, and that’s one of the main reasons we can do that.

Gardner: I guess we could sum that up as being focused on change ready not change waiting.

Moses: Exactly.

Bell: Absolutely.

Moses: Well, you have to have the right tools and you have to have enough knowledge in your group to be able to pull that off, and you have to have great documentation too.

Gardner: Thank you, David Moses. We're going to wrap it up there. We've been discussing how a shifting application’s landscape has provided a huge opening for improving how applications are built, consumed and managed by using new ALM methods and concepts. And we've seen how Delta Air Lines, in particular, has moved successfully to improve its applications quality, and gain the ability to deliver better business results from their efforts.

I'd like to thank our guests today. We've been joined by David Moses, Quality Assurance Manager for Delta. Thank you.

Moses: Thank you very much.

Gardner: And I should also add that he is in the eCommerce IT group there at Delta along with John Bell, who is a Senior Systems Engineer. Thank you, John.

Bell: Thanks for having us.

Gardner: We also have been joined by the authors of the book. That would be Mark Sarbiewski. He is Vice President of Marketing for HP Applications. Thanks, Mark.

Sarbiewski: Thank you, Dana.

Gardner: And lastly, Brad Hipps, Senior Manager for Solutions Marketing, HP Applications. Thanks, Brad.

Hipps: Thanks again.

Gardner: This is a second in a series of free podcast on ALM. We're examining a new book on the subject, The Applications Handbook: a Guide to Mastering the Modern Application Lifecycle.

Our first podcast (read more about and access the first podcast) explored the actual need for the book and why organizations should rethink how they develop and deploy applications, and our final podcast will underscore the conclusions from the book, and explain how other organizations can now begin to change how they deliver and maintain applications that better serves a fast changing world.

We hope that you can join us for the rest of our series, and we also hope that you get a chance to get the book and examine it in more detail.

This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.

For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: HP.

Transcript of a sponsored BriefingsDirect podcast, the second in a series discussing a new book on ALM and it's goal of helping businesses become change ready. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• New Book Explores Automating the Managed Application Lifecycle to Accelerate Delivery of Business Applications
  
  
• Delta Air Lines improves customer self-service apps quickly using automated quality assurance tools strategically
  
  
• HP Shows Benefits from Successful Application Consolidation With Own Massive Global Supply Chain Project

Doing Nothing Can Be Costliest IT Course When Legacy Systems and Applications Are Involved

Transcript of a BriefingsDirect podcast on the risks and drawbacks of not investing wisely in application modernization and data center transformation.

Listen to podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett Packard.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion on the high, and sometimes underappreciated, cost for many enterprises of doing nothing about aging, monolithic applications. Not making a choice about legacy mainframe and poorly used applications is, in effect, making a choice not to transform and modernize the applications and their supporting systems.

Not doing anything is a choice to embrace an ongoing cost structure that may well prevent significant new spending for IT innovations. It’s a choice to suspend applications on, perhaps, ossified platforms and make their reuse and integration difficult, complex, and costly.

Doing nothing is a choice that, in a recession, hurts companies in multiple ways, because successful transformation is the lifeblood of near and long-term productivity improvements.

Here to help us better understand the perils of continuing to do nothing about aging legacy and mainframe applications, we’re joined by four IT transformation experts from Hewlett-Packard (HP). Please join me in welcoming our guests. First, Brad Hipps, product marketer for Application Lifecycle Management (ALM) and Applications Portfolio Software at HP. Welcome, Brad.

Brad Hipps: Thank you.

Gardner: Also, John Pickett from Enterprise Storage and Server Marketing at HP. Hello, John.

John Pickett: Hi. Welcome.

Gardner: Paul Evans, worldwide marketing lead on Applications Transformation at HP. Hello, Paul.

Paul Evans: Hello, Dana.

Gardner: And, Steve Woods, application transformation analyst and distinguished software engineer at EDS, now called HP Enterprise Services. Good to have you with us, Steve.

Steve Woods: Thank you, Dana.

Gardner: Let me start off by going to Paul. The recession has had a number of effects on people, as well as budgets, but I wonder what, in particular, the tight cost structures have had on this notion of tolerating mainframe and legacy applications?

Cost hasn't changed

Evans: Dana, what we’re seeing is that the cost of legacy systems and the cost of supporting the mainframe hasn’t changed in 12 months. What has changed is the available cash that companies have to spend on IT, as, over time, that cash amount may have either been frozen or is being reduced. That puts even more pressure on the IT department and the CIO in how to spend that money, where to spend that money, and how to ensure alignment between what the business wants to do and where the technology needs to go.

Given the fact that we knew already that only about 10 percent of an IT budget was spent on innovation before, the problem is that that becomes squeezed and squeezed. Our concern is that there is a cost of doing nothing. People eventually end up spending their whole IT budgets on maintenance and upgrades and virtually nothing on innovation.

At a time when competitiveness is needed more than it was a year ago, there has to be a shift in the way we spend our IT dollars and where we spend our IT dollars. That means looking at the legacy software environments and the underpinning infrastructure. It’s absolutely a necessity.

Gardner: So, clearly, there is a shift in the economic impetus. I want to go to Steve Woods. As an analyst looking at these issues, what’s changed technically in terms of reducing something that may have been a hurdle to overcome for application transformation?

Woods: For years, the biggest hurdle was that most customers would say they didn’t really have to make a decision, because the performance wasn’t there. The performance reliability wasn't there. That is there now. There is really no excuse not to move because of performance reliability issues.

What's still there, and is changing today, is the ability to look at a legacy source code application. We have the tools now to look at the code and visualize it in ways that are very compelling. That’s typically one of the biggest obstacles. If you look at a legacy application and the number of lines of code and number of people that are maintaining it, it’s usually obvious that large portions of the application haven’t really changed much. There's a lot of library code and that sort of thing.

That’s really important. We’ve been straight with our customers that we have the ability to help them understand a large terrain of code that they might be afraid to move forward. Maybe they simply don’t understand it. Maybe the people who originally developed it have moved on, and because nobody really maintains it, they have fear of going in the areas of the system.

Also, what has changed is the growth of architectural components, such as extract transform and load (ETL) tools, data integration tools, and reporting tools. When we look at a large body of, say, 10 million lines of COBOL and we find that three million lines of that code is doing reporting or maybe two million is doing ETL work, we typically suggest they move that asymmetrically to a new platform that does not use handwritten code.

That’s really risk aversion -- doing it very incrementally with low intrusion, and that’s also where the best return on investment (ROI) picture can be portrayed. You can incrementally get your ROI, as you move the reports and the data transformation jobs over to the new platform. So, that’s really what’s changed. These tools have matured so that we have the performance and we also have the tools to help them understand their legacy systems today.

Gardner: Now, one area where economics and technology come together quite well is the hardware. Let’s go to John with regards to virtualization and reducing the cost of storage. How has that changed the penalty increase for doing nothing?

Functionality gap

Pickett: Typically, when we take a look at the high-end of applications that are going to be moving over and sitting on a legacy system, many times they’re sitting on a mainframe platform. With that, one of the things that have changed over the last several years is the functionality gap between what exists in the past 5 or 10 years ago in the mainframe. That gap has not only been closed, but, in some cases, open systems exceed what’s available on the mainframe.

So, just from a functionality standpoint, there is certainly plenty of capability there, but to hit on the cost of doing nothing, and implementing what you currently have today is that it’s not only the high cost of the platform. As a matter of fact, one of our customers who had moved from a high-end mainframe environment onto an Integrity Superdome, calculated that if you were to take their cost savings and to apply that to playing golf at one of the premier golf places in the world, Pebble Beach, you could golf every day with three friends for 42 years, 10 months, and a couple of days.

It’s not only a matter of cost, but it’s also factoring in the power and cooling as well. Certainly, what we’ve seen is that the cost savings that can be applied on the infrastructure side are then applied back into modernizing the application.

Gardner: I suppose the true cost benefits wouldn’t be realized until after some sort of a transformation. Back to Paul Evans. Are there any indications from folks who have done this transformation as to how substantial their savings can be?

Evans: There are many documented cases that HP can provide, and, I think, other vendors can provide as well, In terms of looking at their applications and the underpinning infrastructure, as John was talking about, there are so many documented cases that point people in the direction that there are real cost savings to be made here.

There's also a flip side to this. Some research that McKinsey did earlier in the year took a sample of 100 companies as they went into the recession. They were brand leadership companies. Coming out of the recession, only 60 of those companies were still in a leadership position. Forty percent of those companies just dropped by the wayside. It doesn’t mean they went out of business. Some did. Some got acquired, but others just lost their brand leadership.

That is a huge price to pay. Now, not all of that has to do with application transformation, but we firmly believe that it is so pivotal to improve services and revenue generation opportunities that, in tough times, need to be stronger and stronger.

What we would say to organizations is, "Take a hard look at this, because doing nothing could be absolutely the wrong thing to do. Having a competitive differentiation that you continue to exploit and continue to provide customers with improving level of service is to keep those customers at a tough time, which means they’ll be your customers when you come out of the recession."

Gardner: Let’s go to Brad. I’m also curious on a strategic level about flexibility and agility, are there prices to be paid that we should be considering in terms of lock in, fragility, or applications that don’t easily lend themselves to a wider process.

'Agility' an overused term

Hipps: This term "agility" is the right term to use, but it gets used so often that people tend to forget what it means. The reality of today’s modern organization -- and this is contrasted even from 5, certainly 10 years ago -- is that when we look at applications, they are everywhere. There has been an application explosion.

When I started in the applications business, we were working on a handful of applications that organizations had. That was the extent of the application in the business. It was one part of it, but it was not total. Now, in every modern enterprise, applications really are total -- big, small, medium size. They are all over the place.

When we start talking about application transformation and we assign that trend to agility, what we’re acknowledging is that for the business to make any change today in the way it does business, in any new market initiative, in any competitive threat it wants to respond to, there is going to be an application -- very likely "applications," plural, that are going to need to be either built or changed to support whatever that new initiative is.

The fact of the matter is that changing or creating the applications to support the business initiative becomes the long pole to realizing whatever it is that initiative is. If that’s the case, you begin to say, "Great. What are the things that I can do to shrink that time or shrink that pole that stands between me and getting this initiative realized in the market space?”

From an application transformation perspective, we then take that as a context for everything that’s motivating a business with regard to its application. The decisions that you're going to make to transform your applications should all be pointed at and informed by shrinking the amount of time that takes you to turn around and realize some business initiative.

So, in 500 words or less, that's what we’re seeking with agility. Following pretty closely behind that, you can begin to see why there is a promise in cloud. It saves me a lot of infrastructural headaches. It’s supposed to obviate a lot of the challenges that I have around just standing up the application and getting it ready, let alone having to build the application itself. So I think that is the view of transformation in terms of agility and why we’re seeing things like cloud. These other things really start to point the direction to greater agility.

Gardner: It sounds as if there is a penalty to be paid or a risk to be incurred by being locked

That pool of data technology only gets bigger and bigger the more changes that I have coming in and the more changes that I'm trying to do.

into the past.

Hipps: That’s right, and you then take the reverse of that. You say, "Fine. If I want to keep doing things as is, that means that every day or every month that goes by, I add another application or I make bigger my current application pool using older technologies that I know take me longer to make changes in.

In the most dramatic terms, it only gets worse the longer I wait. That pool of data technology only gets bigger and bigger the more changes that I have coming in and the more changes that I'm trying to do. It’s almost as though I’ve got this ball and chain that I’ve attached to my ankle. I'm just letting that ball part get bigger and bigger. There is a very real agility cost, even setting aside what your competition may be doing.

Gardner: So, the inevitability of transformation goes from a long horizon to a much nearer and dearer issue. Let’s go back to Steve Woods of EDS. What are some misconceptions about starting on this journey? Is this really something that’s going to highly disrupt an organization or are there steps to do it incrementally? What might hold people back that shouldn't?

More than one path

Woods: I think probably one of the biggest misconceptions is when somebody has a large legacy application written in a second-generation language such as COBOL or perhaps PL/1 and they look at the code and imagine the future with still having handwritten code. But, they imagine maybe it’ll be in Java or C# or .Net, and they don’t pick the next step and say, "If I had to look at the system and rebuild it today, would I do it the same way?" That’s what you are doing if you just imagine one path to modernization.

Some of the code they have in their business logic might find their way into some classes in Java and some classes in .Net. What we prefer to do is a functional breakdown on what the code is actually doing functionally and then try to imagine what the options are that we have going forward. Some of that will become handwritten code and some of it will move to those sorts of implementations.

So, we really like to look at what the code is doing and imagine other areas that we could possibly implement those changes in. If we do that, then we have a much better approach to moving them. The worse thing to do -- and a lot of customers have this impression -- is to automatically translate the code from COBOL into Java.

Java and C# are very efficient languages to generate a function point, where there’s a measure of

It’s looking at the code, at what you want to do from a business process standpoint, and looking at the underlying platform.

functionality. Java takes about eight or ten lines of code. In COBOL, it takes about a 100 lines.

Typically, when you translate automatically from COBOL to Java, you still get pretty much the same amount of code. In actuality, you’ve taking the maintenance headache and making it even larger by doing this automated translation. So, we prefer to take a much more thoughtful approach, look at what the options are, and put together an incremental modernization strategy.

Gardner: Paul Evans, this really isn’t so much pulling the plug on the mainframe, which may give people some shivers. They might not know what to expect over a period of decades or what might happen when they pull the plug.

Evans: We don't profess that people unplug mainframes. If they want to, they may plug in an HP system in its place. We’d love them to. But, being very pragmatic, which is what we like to be, it's looking at what Steve was talking about. It’s looking at the code, at what you want to do from a business process standpoint, and looking at the underlying platform.

It's understanding what quality of service you need to deliver and then understand the options available. In even base technologies like this is, with microprocessors, the power that can be delivered these days means we can do all sorts of things at prices, speed, size, power output, and CO2 emissions that we could only dream of a few years ago. This power enables us to do all sorts of things.

The days where there was this walled-off area in a data center, which no other technology could match, are long gone. Now, the emphasis has been on consolidation and virtualization. There is also a big focus on legacy modernization. CIOs and IT directors, or whatever they might be, do understand there’s an awful lot of money spent on maintaining, as Steve said, handwritten legacy code that today run the organization and need to continue to provide these business processes.

Bite-size chunks

There are far faster, cheaper, and better ways to do that, but it has to be something that is planned for. It has to be something that is executed flawlessly. There's a long-term view, but you take bite-sized chunks out of it along the way, so that you get the results you need. You can feed those good results back into the system and then you get an upward spiral of people seeing what is truly possible with today’s technologies.

Gardner: John Pickett, are there any other misconceptions or perhaps under-appreciated points of information from the enterprise storage and server perspective?

Pickett: Typically, when we see a legacy system, what we hear, in a marketing sense, is that the often high-end -- and I’ll just use that as an example -- mainframes could be used as a consolidation factor. What we find is that if you're going to be moving applications or you’re modernizing applications onto an open-system environment to take advantage of the full gamut of tools and open system applications that are out there, you're not going to be doing that on a legacy environment. We see that the more efficient way of going down that path is onto an open-standard server platform.

Also, some of the other misconceptions that we see, again in a marketing sense, are that a mainframe is very efficient. However, if you compare that to a high-end HP system, for example, and just take a look at the heat output -- which we know is very important -- there is more heat. The difference in heat between a mainframe and an Integrity Superdome, for example, is enough to power a two-burner gas grill, a Weber grill. So, there's some significant heat there.

On the energy side, we see that the Superdome consumes 42 percent less energy. So, it's a very

. . . Some of the other misconceptions that we see, again in a marketing sense, are that a mainframe is very efficient.

efficient way of handling the operating-system environment, when you do modernize these applications.

Gardner: Brad Hipps, when we talk about modernizing, we’re not just modernizing applications. It’s really modernizing the architecture. What benefits, perhaps underappreciated ones, come with that move?

Hipps: I tend to think that in application transformation in most ways they’re breaking up and distributing that which was previously self-contained and closed.

Whether you're looking at moving to some sort of mainframe processing to distributed processing, from distributed processing to virtualization, whether you are talking about the application team themselves, which now are some combination of in-house, near-shore, offshore, outsourced sort of a distribution of the teams from sort of the single building to all around the world, certainly the architectures themselves from being these sort of monolithic and fairly brittle things that are now sort of services driven things.

You can look at any one of those trends and you can begin to speak about benefits, whether it’s leveraging a better global cost basis or on the architectural side, the fundamental element we’re trying to do is to say, "Let’s move away from a world in which everything is handcrafted."

Assembly-line model

Let’s get much closer to the assembly-line model, where I have a series of preexisting trustworthy components and I know where they are, I know what they do, and my work now becomes really a matter of assembling those. They can take any variety of shapes on my need because of the components I have created.

We're getting back to this idea of lower cost and increased agility. We can only imagine how certain car manufacturers would be doing, if they were handcrafting every car. We moved to the assembly line for a reason, and software typically has lagged what we see in other engineering disciplines. Here we’re finally going to catch up. We're finally be going to recognize that we can take an assembly line approach in the creation of application, as well, with all the intended benefits.

Gardner: And, when you standardize the architecture, instead of having to make sure there is a skillset located where the systems are, you can perhaps bring the systems to where the different skills are?

Hipps: That’s right. You can begin to divorce your resources from the asset that they are creating, and that’s another huge thing that we see. And, it's true, whether you're talking about a service or a component of an application or whether you're talking about a test asset. Whatever the case may be, we can envision a series of assets that make an application successful. Now, those can be distributed and geographically divorced from the owners.

Gardner: Where this has been a "nice to have" or "something on the back-burner" activity,

The pressure it’s bringing to bear on people is that the time is up when people just continue to spend their dollars on maintaining the applications . . . They can't just continue to pour money after that.

we're starting to see a top priority emerge. I’ve heard of some new Forrester research that has shown that legacy transformation is becoming the number one priority. Paul, can you offer some more insight on that?

Evans: That’s research that we're seeing as well, Dana, and I don’t know why. ... The point is that this may not be what organizations "want" to do.

They turn to the CIO and say, "If we give you $10 million, what is that you'd really like to do." What they're actually saying is this is what they know they've got to do. So, there is a difference between what they like and what they've got to do.

That goes back to when we started in the current economic situation. The pressure it’s bringing to bear on people is that the time is up when people just continue to spend their dollars on maintaining the applications, as Steve and Brad talked about and the infrastructure that John’s talked about. They can't just continue to pour money after that.

There has to be a bright point. Someone has got to say, “Stop. This is crazy. There are better ways to do this.” What the Forrester research is pointing is that if you go around to a worldwide audience and talk to a thousand people in influential positions, they're now saying, "This is what we 'have' to do, not what we 'want' to do. We're going to do this, and we're going to take time out and we're going to do it properly. We're going to take cost out of what we are doing today and it’s not going to come back."

Flipping the ratio

All the things that Steve and Brad have talked about in terms of handwritten code, once we have done it, once we have removed that handwritten code, that code that is too big for what it needs to be in terms to get the job done. Once we have done it once, it’s out and it’s finished with and then we can start looking at economics that are totally different going forward, where we can actually flip this ratio.

Today, we may spend 80 percent or 90 percent of our IT budget on maintenance, and 10 percent on innovation. What we want to do is flip it. We're not going to flip it in a year or maybe even two, but we have got to take steps. If we don’t start taking steps, it will never go away.

Hipps: I've got just one thing to add to that in terms of the aura of inevitability that is coming with the transformation. When you look at IT over the last 30 years, you can see that, fairly consistently, you can pick your time frame, and somewhere in neighborhood of every seven to nine years, there has been sort of an equivalent wave of modernization. The last major one we went through was late '90s or early 2000s, with the combination of Y2K and Web 1.0. So, sure enough, here we are, right on time with the next wave.

What’s interesting is this now number-one priority hasn’t reached the stage of inevitability. I

When you look at IT over the last 30 years, you can see that, fairly consistently, you can pick your time frame, and somewhere in neighborhood of every seven to nine years, there has been sort of an equivalent wave of modernization.

look back and think about what organizations in 2003 were still saying, "No, I refuse the web. I refuse the network world. It’s not going to happen. It’s a passing fancy," and whatever the case maybe. Inasmuch as there were organizations doing that, I suspect they're not around anymore, or they're around much smaller than they were. I do think that’s where we are now.

Cloud is reasonably new, but outsourcing is another component where transformation has been around long enough that most people have been able to look it square the eye and figure out, "You know what. There is real benefit here. Yes, there are some things I need to do on my side to realize that benefit. There is no such thing as a free lunch, but there is a real benefit here and it’s I am going to suffer, if not next year, then three years from now, if I don’t start getting my act together now."

Gardner: John Pickett, are there any messages from the boosters of mainframes that perhaps are no longer factors or are even misleading?

Pickett: There are certainly a couple of those. In the past, the mainframe was thought to be the harbinger of RAS -- reliability, availability, and serviceability. Many of those features exist on open systems today. It’s not something that is dedicated just to the high-end of the mainframe environment. They are out there on systems that are open-system platforms, significantly cheaper. In many cases, the RAS of these systems far exceeds what we’ll see on the mainframe.

That’s just one piece. Other misconceptions and things that you typically saw historically have been on the mainframe side, such as being able to drive a business-based objective or to be able to prioritize resources for different applications or different groups of users. Well, that’s something that has existed for a number of years on the open system side -- things such as backup and recovery and being able to provide very high levels of disaster recovery.

Misleading misconception

A misconception that this is something that can only be done in a mainframe environment, is not only misleading, but also not making the move to an open-system platform, continues to drive IT budget unnecessarily into an infrastructure that could be applied to either the application modernization that we have been talking about here or into the skills -- people resources within the data center.

Gardner: We seem to have a firm handle on the cost benefits over time. Certainly, we have a total cost picture, comparing older systems to the newer systems. Are there more qualitative, or what we might call "soft benefits," in terms of the competitiveness of an organization? Do we have any examples of that?

Evans: What we have to think about is the target audience out there. More and more people have access to technology. We have the generation now coming up that wants it now and wants it off the Web. They are used to using social networking tools that people have become accustomed to. So, it's one of the soft, squidgy areas as people go through this transformation.

I think that we can put hard dollars -- or pounds or euros -- against this for the moment, the inclusion of Web 2.0 or Enterprise 2.0 capabilities into applications. We have customers who are now trying that, some of it inside the firewall and some of it beyond. One, this can provide a much richer experience for the user. Secondly, you begin to address an audience that is used to analyzing these things in their day-to-day life anyway.

Why, when they step into the world of the enterprise, do they have to step back 50 years in terms

More and more people have access to technology. We have the generation now coming up that wants it now and wants it off the Web.

of capability? You just can’t imagine that certain things that people require are being done in batch mode anymore. The real-time enterprises are what people now expect and want.

So, as people go through this transformation, not only can they do all the plethora of things we have talked about in terms of handwritten code, mainframes, structure, and service-oriented architecture (SOA), but they can also start taking steps towards how they can really get these applications in line and embed them within an intimate culture.

If they start to take on board some of the newer concepts around cloud to experiment they have to understand that people aren’t going to just make this big leap of faith. At the end of the day, it's enterprise apps. We make things, apply things and count things -- and people have got to continue to do that. At the same time, they need to take these pragmatic steps to introduce these newer technologies that really can help them not only retain their current customer base, but attract new customers as well.

Gardner: Paul, when organizations go through this transformation, modernize, and go to open systems, does that translate into some sort of a business benefit, in terms of making that business itself more agile, maybe in a mergers and acquisition sense? Would somebody resist buying a company because they've got a big mainframe as an albatross around its neck?

Fit for purpose

Evans: Definitely, to have your IT fit for purpose, is something that is part of the inherent health of the organization. For organizations whose IT is way behind where it is today, it's definitely part of the health check.

To some degree, if you don’t want to get taken over or merged or acquired, maybe you just let your IT sag to where it is today, with mainframes and legacy apps, and nobody would want you. But then, you’re back to where we were earlier. You become one of those 40 percent of the companies that disappear off the face of the planet. So, it’s a sort of a double-edged sword, you make yourself attractive and you could get merged or acquired. On the other hand, you don’t do it and you’re going to go out of business. I still think I prefer the former rather than the latter.

Gardner: Let’s talk more specifically about what HP is bringing to the table. We’ve flushed out this issue quite a bit. Is there a long history at HP of modernization?

Evans: There are two things. There is what we have done internally, within the organization in the company. We’ve had to sort of eat our own dog food, in the sense that there are companies that were merged and companies that were acquired -- HP, Compaq, Digital, EDS, whatever.

It’s just not acceptable anymore to run these as totally separate IT organizations. You have to

When you take a look at the history of what we've been able to do, migrating legacy applications onto an open system platform, we actually have a long history of that.

quickly understand how to get this to be an integrated enterprise. It’s been well documented what we have done internally, in terms of taking massive amount of cash out of our IT operations, and yet, at the same time, innovating and providing a better service, while reducing our applications portfolio from something like 15,000 to 3,000.

So, all of these things going at the same time, and that has been achieved within HP. Now, you could argue that we don't have mainframes, so maybe it’s easier. Maybe that’s true, but, at the same time, modernization has been growing, and now we're right up there in the forefront of what organizations need to do to make themselves cost-effective, agile, and flexible, going forward.

Gardner: John Pickett, what about the issue around standards, neutrality, embracing heterogeneity, community and open source? Are these issues that HP has found some benefits from?

Pickett: Without a doubt. When you take a look at the history of what we've been able to do, migrating legacy applications onto an open system platform, we actually have a long history of that. We continue to not only see success, but we’re seeing acceleration in those areas.

A couple of drivers that we ended up seeing are really making the case for customers, not only the significant cost savings that we have talked about earlier. So, we're talking 50 percent or 70 percent total cost of ownership (TCO) savings driving from a legacy of mainframe environment over to an HP environment.

Additional savings

In addition to that, you also have the power savings. Simply by moving, the amount of energy that saved is enough to light 80 houses for one year. We’ve already talked about the heat and the space savings. It’s about a third of what you’re going to be seeing for a high-end mainframe environment for a similar system from HP with similar capabilities.

Why that’s important is because if customers are running out of data-center room and they’re looking at increasing their compute capacity, but they don’t have room within their data center, it just makes sense to go with a more efficient, more densely packed power system, with less heat and energy than what you’ll see on a legacy environment.

Gardner: Brad Hipps, about this issue about of being able to sell from a fairly neutral perspective, based on a solutions value, does that bring something to the table?

Hipps: We alluded earlier to the issue of lock in. If we’re going to, as we do, fly under the banner of bringing flexibility and agility to an organization, it’s tough to wave that banner without being pretty open in who you’re going to play with and where.

Organizations have a very fine eye for what this is going to mean for me not just six months from now, but two years from now, and what it’s going to mean to successors in line in the organization. They don’t want to be painted into a corner. That’s something that HP is very cognizant of, and has been very good about.

This may be a little bit overly optimistic, but you have to be able to check that box. If you’re going to make a credible argument to any enterprise IT organization, you have to show your openness and you have to check the box that says we’re not going to paint you into a corner.

Gardner: Steve Woods, for those folks who need to get going on this, where do you get started? We mentioned that iterative nature, but there must be perhaps low-hanging fruit, demonstrations of value that then set up a longer record of success.

Woods: Absolutely. What we find with our customers is that there are various levels in the processes of understanding their legacy systems. Often, we find some of them are quite mature and have gone down the road quite a bit. We offer some assessments based upon single applications and also portfolio of applications. We do have a modernization assessment and we do have a portfolio assessment. We also offer a best-shore assessment to ensure that you are using the correct resources.

Often, we find that we walk in, and the customers just don’t know anything about what their

We have the visual intelligence tools that very quickly allow us to see inside the system, see the duplicate source code, and provide them with high level cost estimates.

options are. They haven’t done any sort of analysis thus far. In those cases, we offer what we’re calling a Modernization Opportunity Workshop.

It's a very quick, usually 4-8 hour, on-site, and it takes about four weeks to deliver the entire package. We use some tools that I have created at HP that look at the clone code within the application. It’s very important to understand the pattens of the clone code and have visualizations. We have the visual intelligence tools that very quickly allow us to see inside the system, see the duplicate source code, and provide them with high level cost estimates.

We use a tool called COCOMO and we use Monte Carlo simulation. We’re able very quickly to give them a pretty high-level, 30-page report that indicates the size. Often, size is something that is completely misunderstood. We have been into customers who tell us they have four million lines of code, and we actually count the code as only 400,000 lines of code. So, it’s important to start with a stake in the ground and understand exactly where you’re at with the size.

We also do functionality composition support to understand that. That’s all delivered with very little impact. We know the subject matter experts are very busy, and we try to lessen the impact of doing that. That’s one of the places we can start, when the customer just has some uncertainty and they're not even sure where to start.

Gardner: We’ve been discussing the high penalties that can come with inaction around applications and legacy systems. We’ve been talking about how that factors into the economy and the technological shifts around the open systems and other choices that offer a path to agility and multiple-sourcing options.

I want to thank our panelists today for our discussion about the high costs and risks inherent in doing nothing around legacy systems. We’ve been joined by Brad Hipps, product marketer for Application Lifecycle Management and Applications Portfolio Software at HP. Thank you Brad.

Hipps: Thank you.

Gardner: John Pickett, Enterprise Storage and Server Marketing at HP. Thank you, John.

Pickett: Thank you Dana.

Gardner: Paul Evans, Worldwide Marketing Lead on Applications Transformation at HP. Thank you, Paul.

Evans: Thanks Dana.

Gardner: And Steve Woods, applications transformation analyst and distinguished software engineer at EDS. Thank you Steve.

Woods: Thank you Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast. Thanks for listening and come back next time.

Listen to podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett Packard.

Transcript of a BriefingsDirect podcast on the risks and drawbacks of not investing wisely in application modernization and data center transformation. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.