HP's New ALM 11 Guides IT Through Shifting Landscape of Application Development and Service Requirements

Transcript of a sponsored BriefingsDirect podcast on application lifecycle management and HP ALM 11 from the HP Software Universe 2010 conference in Barcelona.

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

Dana Gardner: Hello, and welcome to a special BriefingsDirect podcast series, coming to you from the HP Software Universe 2010 Conference in Barcelona.

We're here the week of November 29, 2010 to explore some major enterprise software and solutions, trends and innovations, making news across HP’s ecosystem of customers, partners, and developers. [See more on HP's new ALM 11 offerings.]

I'm Dana Gardner, Principal Analyst at Interarbor Solutions and I’ll be your host throughout this series of HP-sponsored Software Universe Live Discussions. To learn more about HP’s application life-cycle management (ALM) news and its customer impact from the conference here, please join me now in welcoming Mark Sarbiewski, Vice President of Product Marketing for HP applications. Welcome, Mark.

Mark Sarbiewski: Thank you, Dana. Good to be with you.

Gardner: Good to be with you. We've seen, over the past several years, sort of a shifting landscape of how applications are delivered and deployed. It seems as if the traditional way of doing this just isn’t working, and there seems to be complexity, slowness, and quality issues. First, why is that, and then second, what is HP doing about it?

Sarbiewski: It’s a question that we talk to our customers about all the time. It boils down to the same old changes that we see sort of every 10 years. A new technology comes into play with all its great opportunity and problems, and we revisit how we do this. In the last several years, it’s been about how do I get a global team going, focused on potentially a brand-new process and approach.

You’ve got changes in how you are organized. You’ve got changes in the approach that people are taking. And, you’ve got brand-new technology in the mix and new ways of actually constructing applications. All of these hold great promise, but great challenges too. That's clashing with the legacy approach that people in the past took in building software.

Gardner: What is HP going to about this? We’ve got kind of an inflection point, a generational shift. Now, what’s the response?

Sarbiewski: The short answer is that that legacy approach is not going to be the right path for delivering modern applications. As far as the core problems that I just mentioned, we’ve been hard at work for a couple of years now, recasting and re-inventing our portfolio to match that modern approach to software, going through them one-by-one.

What are the new technologies that everybody is employing? We’ve got rich Internet technologies, Web 2.0, approaches and our technology is there. For composite applications, we’ve built a variety of capabilities that help people understand how to make the performance right with those technologies, keep the security and the quality high, while keeping the speed up.

Moving to Agile

So it’s everything from how do we do performance testing in that environment to testing things that don’t have interfaces, and how do we understand the impact of change on the systems like that. We’ve built capabilities that help people move to Agile as a process approach, things like fundamentally changing how they can do exploratory testing, and how they can bring in automation much sooner in the process of performance, quality, and security.

Lastly, we’ve been very focused on creating a single, unified system that scales to tens of thousands of users. And, it’s a web-based system, so that wherever the team members are located, even if they don’t work for you, they can become a harmonious part of the overall team, 24-hour cycles around the globe. It speeds everything up, but it also keeps everyone on the same page. It’s that kind of anytime, anywhere access that’s just required in this modern approach to software.

Gardner: As I'm hearing the news here at the show being rolled out, it occurs to me that we're bringing together aspects of this whole lifecycle that for decades been very distinct and different, usually from different vendors, and with wholly different platforms beneath them. So, why is it important that ALM 11 pretty much has an integrated system with all the stakeholders, all the team member focused in the same direction or at least integrated at some level? [See more on HP's new ALM 11 offerings.]

Sarbiewski: When I talk to customers, I ask them, how they're supporting software. If we talk about software delivery, it's fundamentally a team sport. There isn't a single stakeholder that does it all. They all have to play and do their part.

When they tell me they’ve got requirements management in Word, Excel, or maybe even a requirements tool, and they have a bug database for this, test management for that, and this tool here, on the surface it looks like they fitted everybody with a tool and it must be good. Right?

The problem is that the work is not isolated. You might be helping each individual stakeholder out a little bit, but you're not helping the team.

The problem is that the work is not isolated. You might be helping each individual stakeholder out a little bit, but you're not helping the team. The team’s work relates to each other. When requirements get created or changed, it's the ripple effect. What tests have to be modified or newly created? What code then has to be modified? When that code gets checked in, what tests has to be run? It’s the ripple effect of the work we talk about it as workflow automation. It's also the insight to know exactly where you are.

When the real question of how far am I on this project or what quality level am I at -- am I ready to release -- needs to be answered in the context of everyone’s work, I have to understand how many requirements are tested? Is my highest priority stuff working against what code?

So, you see the team aspects of it. There is so much latency in a traditional approach. Even if each player has their own tool, it's how we get that latency out and the finger-pointing and the miscommunication that also results. We take all that out of that process and, lo and behold, we see our customers cutting their delivery times in half, dropping their defect rates by 80 percent or more, and actually doing this more cheaply with fewer people.

Gardner: So clearly HP ALM 11 is not going to allow sacrifice in the overall process for some individual choice and benefits, but let's get into the actual parts here. We have elements that are updated around requirements, development, and quality. Tell me a little bit about the constituent parts of this overall umbrella.

Sarbiewski: In requirements management, one of the big new things that we’ve done is allow the import of business process models (BPMs) into the system. Now, we’ve got the whole business process flow that’s pulled right into the system. It can be pulled right from the systems like Eris or anything that’s putting in the standard business process modeling language (BPML) right into the system.

Actual business processes

Now, everyone who accesses ALM 11 can see the actual business process. We can start articulating that this is the highest priority flow. This step of the business process, maybe it's check credit or something like that, is an external thing but it's super-important. So, we’ve got to make sure we really test the heck out of that thing.

Everyone is aligned around what we’re doing, and all the requirements can be articulated in that same priority. The beautiful thing now about having all this in one place is that work connects to everything else. It connects to the test I set up, the test I run, the defects I find, and I can link it even back to the code, because we work with the major development tools like Visual Studio, Eclipse, and CollabNet.

Gardner: So what are the parts we have? We’ve got this really interesting requirements manager that’s integrated with BPM, and I want to get back to that in a moment. The second part is Performance Center update, and then we’ve got a new LoadRunner, right?

Sarbiewski: That’s exactly right. You mentioned Development Manager a minute ago. It's hugely important that we connect into the world of developers. They're already comfortable with their tools. We just want to integrate with that work, and that’s really what we’ve done. They become part of the workflow process. They become part of the traceability we have.

You mentioned performance testing. We have the industry leading solution here and major market share there. What we hear from our customers is that the coolest new technology they want to work with is also the most problematic from a performance standpoint.

The bottom line is that the coolest new Web 2.0 front ends can now be very easily performance tested.

We went back to the drawing board and reinvented how well we can understand these great new Web 2.0 technologies, in particular Ajax, which is really pervasive out there. We now can script from within the browser itself. The big breakthrough there is if the browser can understand it, we can understand it. Before, we were sort of on the outside looking in, trying to figure out what a slider bar really did, and when a slider bar was moved what did that mean.

Now, we can generate a very readable script. I challenge anybody. Even a businessperson can understand, when they're clicking through an application, what gets created for the performance testing script.

We parameterize it. We can script logic there. We can suggest alternate steps. The bottom line is that the coolest new Web 2.0 front ends can now be very easily performance tested. So we don't end up in that situation where it's great, you did a beautiful rich job, and it's such a compelling interface, but only works when 10 people are hitting the application. We've got to fix that problem.

It speeds everything up, because it's so readable and quick. And it just works seamlessly. We've tested against the top 40 websites, and they are out there out using all this great new technology and it's working flawlessly.

Gardner: So, we've had some significant improvements and upgrades. We’ve got better integration. We're looking at this at the process level and we brought in BPM. But, I also heard from the main stage presentation here in Barcelona about a couple of new things. We have Unified Functional Testing 11 and HP Sprinter. Could you help me understand a bit more about those?

Lots of pieces

Sarbiewski: Absolutely. If you think about a composite application, it's really made up of lots of pieces. There are application services or components. The idea is that if I’ve got something that works really well and I can reuse it as part of and combine it with maybe a few other things or in a couple of new pieces and I get new capability, I've saved money. I’ve moved faster and I'm delivering innovation to the business in a much better, quicker way and it should be rock-solid, because I can trust these components.

The challenge is, I'm not making up software made of lots of bits and pieces. I need to test every individual aspect of it. I need to test how they communicate together and I need to do end-to-end testing.

If I try to create composite apps and reuse all this technology, but it takes me ten times longer to test, I haven’t achieved my ultimate goal which was cheaper, faster and still high quality. So Unified Functional Testing is addressing that very challenge.

We've got Service Test which actually is incredible visual canvas for how I can test things that don't have an interface. One of the big challenges with something that doesn't have an interface is that I can't test it manually, because there are no buttons to push. It's all kind of under the covers. But, we have a wonderful, easy, brand-new reinvented tool here called Service Test that takes care of all that.

That’s connected and integrated with our functional testing product that allows you to test everything end-to-end in the GUI level. The beautiful thing about our approach is you get to do that end-to-end, GUI level type of testing and the non-GUI stuff all from one solution and you report out all the testing that you get done.

Bring in a lot of automation to speed it up, keep the quality high and the time down low and you get to see it all kind of come together in one place.

So again, bring in a lot of automation to speed it up, keep the quality high and the time down low and you get to see it all kind of come together in one place.

Gardner: Right. I was going to say we’ve heard a lot about Instant-On here as well. I am assuming that Sprinter might have something to offer there.

Sarbiewski: Absolutely. Sprinter is not even a reinvention. It's brand-new thinking about how we can do manual testing in an Agile world. Think of that Instant-On world. It's such a big change when people move to an Agile delivery approach. Everyone on the team now plays kind of a derivative role of what they used to do. Developers take a part of testing, and quality folks have to jump in super-early. It's just a huge change.

What Sprinter brings is a toolset for that tester, for that person who is jumping in, getting right after the code to give immediate feedback, and it's a toolset that allows that tester to automatically figure out what test apps are supposed to go through to drop in data instead of typing it in. I don't have to type it anymore. I can just use an Excel spreadsheet and I can start ripping through screens and tests really fast, because I'm not testing whether it can take the input. I'm testing whether it processes it right.

A bunch of cool tools

And when I come across an error, there's a tool that allows me to capture those screens, annotate them, and send that back to the developer. What’s our goal when we find a defect? The goal is to explain exactly what was done to create the defect and exactly where it is. There are a whole bunch of cool tools around that.

The last point I’d make about this is called Mirror Testing. It’s super-important. It’s imperative that things like websites actually work across the variety of browsers and operating environments and operating systems, but testing all those combinations is very painful.

Mirror Testing allows the system to work in the background, while someone is testing, say on XP and Internet Explorer, five other systems, different combinations will be driven on the exact same test. I'm sitting in front of it, doing my testing, and in the background, Safari is being tested or Firefox.

If there is an error on that system, I see it, I mark it, and I send it right away, essentially turning one tester into six. It's really great breakthrough thinking on the part of R&D here and a huge productivity bump.

Gardner: Now, we have some major shifts impacting developers and basically the entire lifecycle around apps. There’s more emphasis on mobile suddenly, and there’s a need to integrate with the business process side of things. There's the need to do things faster. We're also seeing an emphasis on mixed sourcing or hybrid computing. Then, just to make things more interesting, there's an emphasis on bringing these things out in a way that helps the business faster, and in a more declarative way. That is to say, it hits the bottom-line in a good way.

What we hear from our customers is that they really do want their lives to be simplified.

How was it that this overall set of capabilities you’ve described fit into these trends? It seems to me that you are trying to strike the balance between inclusive, and integrated, but also agnostic and open to all of these different aspects. Tell me how that works.

Sarbiewski: What we hear from our customers is that they really do want their lives to be simplified, and the conclusion that they have come to in many cases is Post-It Notes, emails, and Word docs. It seems simpler at first and then it quickly falls apart at scale. Conversely, if you have tools that you can only work with in one particular environment, and most enterprises have a lot of those, you end up with a complex mess.

Companies have said, "I have a set of development tools. I probably have some SAP, maybe some Oracle. I’ve got built-in .NET, with Microsoft. I do some Eclipse stuff and I do Java. I’ve got those but if you can work with those and if you can help me get a common approach to requirements, to managing tests, functional performance, security, manage my overall project, and integrate with those tools, you’ve made my life easier."

When we talk about being environment agnostic, that’s what we mean. Our goal is to support better than anyone else in the market the variety of environments that enterprises have. The developers are happy where they are. We want them as part of the process, but we don’t want to yank them out of their environment to participate. So our goal again is to support those environments and connect into that world without disrupting the developer.

And, the other piece that you mentioned is just as important. Most customers aren’t taking one uniform approach to software. They know they’ve got different types of projects. I’ve got some big infrastructure software projects that I am not going to do all the time and I am not going to release every 30 days and a waterfall approach or a sequential approach is perfect for that.

Rock solid

I want to make sure it’s rock solid, that I can afford to take that type of an approach, and it's the right approach. For a whole host of other projects, I want to be much more agile. I want to do 60-day releases or 90-day releases or even more, and it makes sense for those projects. What I don’t want, they tell us, I don’t want every team inventing their own approach for Waterfall, Agile, or custom approaches. I want to be able to help the teams follow a best-practice approach.

As far as the workflow, they can customize it. They can have an Agile best practice, a Waterfall best practice, and even another one if they want. The system helps the team do the right thing and get a common language, common approach, all that stuff. That’s the process kind of agnostic belief we have.

Gardner: Last, Mark, tell me how you get started. When are these going to be available, and are there any changes in licensing or pricing in terms of trying to make it simpler for people acquire these?

Sarbiewski: They're available now. The great news is that today you can download all the solutions that we’ve talked about for trials. We have some online demos that you can check out as well. There are a lot of white papers and other things. You can literally pull the software 30 minutes from now and see what I'm talking about.

On the licensing side, we believe that the simplest approach is a concurrent license, which we have on most of the products that we’ve got here. For all the modules that we’ve been talking about, if you have a concurrent license to the system, you can get any of the modules. And, it’s a nice floating license. You don’t have to count up everybody in your shop and figure out exactly who is going to be using what module.

The concurrent license model is very flexible, nice approach. It’s one we’ve had in the past. We're carrying it forward and we’ll look to continue to simplify and make it easier for customers to understand all the great capabilities and how to simply license so that they can get their teams to their modules for the capability they need.

Gardner: Thanks to Mark Sarbiewski, Vice President of Marketing for HP Applications, for giving us the deep-dive on HP's Application Lifecycle Management news and its customer impact from the conference.

Sarbiewski: Thank you, Dana. I appreciate the time.

Gardner: And Thanks to you for joining us for this special BriefingsDirect podcast, coming to you from the HP Software Universe 2010 Conference in Barcelona, Spain.

Look for other podcasts from this HP event on the HP.com website, as well as via the BriefingsDirect network.

I'm Dana Gardner, principal analyst at Interarbor Solutions, your host for this series of Software Universe Live discussions. Thanks again for listening, and come back next time.

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

Transcript of a sponsored BriefingsDirect podcast on application lifecycle management and HP ALM 11 from the HP Software Universe 2010 conference in Barcelona, Spain. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Dave Shirk details how HP's Instant-On Enterprise initiative takes aim at shifting demands on business and governments
  
  
• New book explores automating the managed applications lifecycle to accelerate delivery of business applications
  
  
• Automating the managed application lifecycle helps Delta Air Lines better deliver critical business applications
  
  
• How to automate ALM: Conclusions from new HP book on gaining improved business applications as a process

How to Automate Application Lifecycle Management: Conclusions From New HP Book on Gaining Improved Business Applications

Transcript of a sponsored BriefingsDirect podcast, the third 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.

In this podcast, the last in a series of three, we'll underscore the conclusions from the book and explain how organizations can begin now to change how they deliver and maintain applications in a fast-changing world.

In our first podcast, we focused on the role and impact of automation and management of applications, and emphasized the need to gain control over applications through a holistic lifecycle perspective.

The second discussion in our series looked at how an enterprise, Delta Air Lines, moved successfully to improve its applications’ quality, and gain the ability to deliver better business results from those applications.

Finally, here we'll discover how to access and how well you can develop applications as an essential lifecycle core competency and begin to chart a course toward improvement. That's just in time because the topic of ALM will be a big one at next week's HP Software Universe conference in Barcelona.

But we're here now with the book’s authors to explore their conclusions. Please join me in welcoming Mark Sarbiewski, Vice President of Marketing for HP Applications, and Brad Hipps, Senior Manager of Solution Marketing for HP Applications. Welcome to you both.

Mark Sarbiewski: Thank you.

Brad Hipps: Thank you.

Gardner: We're now at the point where organizations recognize that they need to do something differently. They have a very complex application situation, and they certainly have a fast-changing set of business requirements. The stakes are very high.

How then do companies know where they are in the app spectrum? Obviously, there’s going to be variability from company to company. Yet how do you know as an individual organization where you stand in terms of application lifecycle competencies? Let’s start with you, Mark.

ALM maturity

Sarbiewski: Companies are truly interested to understand where they rank, what they do well, where their gaps are, and where they fall against their competition, their colleagues, or other folks in their industry, and even against best practice in other industries. So we built out a model for ALM maturity, and it’s in the book.

We wanted to take a slightly different approach to how we thought about maturity models. There are lots of them in the industry, not so much around ALM, but in sub-disciplines or in different areas. Our focus was the business outcomes that you see at different levels.

If you can understand the results that you are seeing, that ought to help you figure out where am I in terms of where I could be. What we've seen is a progression from the spectrum of companies, where they are really getting started. They have fairly immature processes. They're across the lifecycle of an application, and all the way up to very advanced.

One thing I would mention, before I go further, is that the life of an application is generally the same for all companies. There is a spark of an idea: "We need this. We need software to help us do something in the business."

We make an investment decision somehow. We may do this ad hoc. We may do it based on who screams the loudest. But, somehow a decision gets made. We build something somehow. We spec it, build it, release it, run it, poorly or not, and hopefully, although certainly not always, eventually we replace it, retire it, and so forth.

So, our idea around maturity and tying it to outcomes is the results that we see. For example, what’s our batting average for how many times we actually make the right kind of investment decisions? How many times do we execute against a good investment decision? How many times do we run it well and meet our SLAs in production and so on?

We see people just getting started, and they have a relatively ad hoc, narrow, point tool, with lots of manual work. It doesn’t mean they are never successful, but results vary highly. They're very mixed. Some project teams are great, and it all depends on the project team, and the next one may stink.

As you move up the curve, you start to see a maturity in the functional disciplines. We see them get better at requirements management. We see them get better at testing, designing software, or handing off, releasing into production. You see the functional competence begin to evolve. That has to happen first, before you can start to tie these functions together and begin to get cross-functional excellence.

There is a huge benefit in getting good at your functions. And, there is another big jump in return on investment (ROI) of getting better at having my functions and departments work well together. At the highest level, you start to be able to execute very complex programs, with lots of projects, across lots of functions every time. We talk about a level of portfolio excellence there.

So, it all comes back to the results. What kind of results am I seeing? If you look at the model in the book, it’s pretty easy to peg yourself as to where you are and the kinds of benefits you'd see from moving up that maturity curve.

Gardner: Brad Hipps, do you have anything to offer further on knowing where you are so that you can know where you need to go?

More of a scorecard

Hipps: As Mark has said, we configured this model, trying deliberately not to be ultra-prescriptive. There are many heavy-duty models that do exist, and people can dig into those to their heart’s content. This is as much a maturity scorecard as anything.

One of the examples that you might see or one of the ways you might begin to engage yourself is something like defect leakage. Defect leakage refers to the number of defects that you discover in live in the application that you could have caught earlier.

We have some figures that show that the average is in the neighborhood of 40 percent of application defects that leak into production and are discovered in live. They could have been caught earlier. It may be little higher than 40 percent, which is a fairly shocking number. Obviously, that’s a rough average. So, you've got to expect, if you are lower in maturity, that you may be even seeing more than that.

But on the high end, the world-class customers we worked with, see less than 5 percent of defects working their way into production. So right off the bat there, you're talking an 80 percent-plus drop in the number of defects that you're experiencing in a live environment, with all the attendant cost savings, brand improvement, and good will in the business that you would expect.

That’s one example of the kind of thing that you can look at, tease out, and begin to get a sense of where might I sit maturity wise. From that, you can potentially take a cue as to where is it that I want to start, where is it that I want to make the biggest investment, as I look to make myself more mature?

There are hosts of sophisticated KPIs we can design for ourselves, but one of the key ones was, "I want to know what the business thinks of us, and whether we are trending in the right direction."

Gardner: Brad, I suppose while it’s important to know who you are in order to chart where you are going to go, it would be nice to know how well you are doing along the way. Are there measurements of success here in your book that you can point to of how people can take score of how well they are progressing and then reinforce or move even further forward?

Hipps: I'll give a simple one. At least, I hope it’s a simple. I can’t speak for every enterprise, but this is one that I have used in my own history, and it’s no more complex than customer satisfaction.

In this case, your customers may be end users, who are harder sometimes to survey. But, more often than not, your customers are some business units, somebody within the business.

When I was running application teams, we were undertaking initiatives to improve ourselves, which is probably a nonstop undertaking within IT. Sometimes, you go through peaks and valleys, but that became one of my key checkpoints, as you might imagine. There are hosts of sophisticated KPIs we can design for ourselves, but one of the key ones was, "I want to know what the business thinks of us, and whether we are trending in the right direction."

Trumping the frustration

The reason that’s a good one for is that no amount of being a good guy, being nice to people, or being friendly in meetings, is going to trump the frustration a business person feels if the application is not doing what they need it to do. Either it's got too many defects, it takes too long to enhance it, or it’s too painful to get anything done, etc. There are a host of things.

So, we designed a relatively simple customer survey. It was something we executed, probably biannually, and that became one of the ways we tracked how we were trending. Are we going in the right direction? There are endless, complex KPIs, but that’s a simple one I would pluck out as being a way of simply tracking, "Are we getting better or worse, or are we just sort of treading water?"

Gardner: And, Mark, when we look at how progress has been made, we need not only look at the end-user perceptions and results from surveys, but perhaps we also need to look at the development team, the ops team, and the actual practitioners here. So, is there a way of gauging success based on what the team does and how well they're able to let go of the legacy mechanisms they've had over the years?

Sarbiewski: We talk about this a lot. We see pressure from the business to change how we do things and the technologies we use. From the business side, you see it in a variety of ways. You see, "Oh, it’s the consumerization of IT, and what I see in my consumer world I want in IT. I see this all moving fast and I don’t feel my business moving." You see that pressure.

But, you absolutely see pressure to change from the bottom-up, from the teams themselves. We want to work in a different way. We want to be able to execute faster. The whole move of agile has been, in large part, if not primarily built, then driven from development and delivery teams up. So, there is a huge motivation there.

You can start to look at some things like that, and as you see improvement, not only in the responsiveness, but the as number of issues go down.

And they are going to look at a variety of things. They are going to look at things, as Brad said, like customer satisfaction as part of that. How quickly does a change and a request get turned around?

That’s a pretty easy metric, because the changes come into systems like the service desk. There's a request. When did that thing get requested, and when did it actually get executed? You can start to look at some things like that, and as you see improvement, not only in the responsiveness, but the as number of issues go down, those are things that the team should be looking at as great measurements.

I often counsel clients to set up some MBOs and some rewards structures around that too, because this is something that the business is going to feel. It’s not just what’s there at release. What did we find here and how is it? It’s really that first 90 or 180 days of use in the business. I'm going to take a snapshot, and if it’s good, if we are constantly improving on that and hitting our targets, that’s where we get our bonuses.

It’s that result. And it shifts it from, I hit my date, I threw it over the wall to ops, and I washed my hands of it. No. We're all in business here. We're not in IT. We're in business, and business means this thing is running like it’s supposed to. That means apps and ops combining and taking a measure at 180 days.

There’s a lot of pride when you see the metrics go in the right way. The feedback that I've seen for our clients that do this really well is where the business comes back and says, "Oh my God. The responsiveness is incredible. Even if I'm not getting the massive stuff that I used to get once every two years, I'm seeing movement on a regular basis, and I love it." And lot of clients that we talk to are really fired up about that.

Those are the kinds of things to strive for, look for, and really have a great feedback loop for on your delivery teams.

Important points

Hipps: There's an important point there. As people know, there are an endless numbers of KPIs that are available to you, and all sorts of people who recommend which ones are the best. We probably didn’t make it this explicit in this version of the book, and maybe this goes in the next revision, but when it comes to how you're going to measure your success, I'd look at a few things in terms of the kinds of measurements you want to track.

First of all, I don’t know that I would pick more than three or four. You find yourself with six, seven, eight different things you are trying to stay on top of and measure, and it becomes its own game. I would keep it as simple as humanly possible. Three is a nice number of measurements.

The second thing is, I would want it to be pretty doggone intuitive what the business value is, if we are doing well in the measurement. I wouldn’t want to have to go through too many mathematical steps to get back to what the value is to the business, as I look at whatever measurement I have chosen to evaluate myself by.

The third aspect would get to what Mark was just saying was in an ideal world at least one of the measurements, if not all of them, and would speak to how well we're working pan IT. It's not just how well we're building the application or how quickly we're getting it pushed into operations hands, but how well we're working together as teams, as developers, as folks on the operation side, as planners, and as enterprise architects.

Mark was talking about looking at meantime from change request to production. Well, that's an example of the entire IT supply chain right there. Presumably, if I set some relatively easy target and start trending in that direction, then I can have at least some sense of satisfaction. We must be getting better about interoperating the way we didn’t operate.

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

Gardner: Thanks, Brad. Back to your conclusion in your book, you not only try to explain how people can assess their own progress, but you also look to what you consider world-class delivery organizations and try to learn from what they do well.

You have four traits that you point out, predictability, repeatability, quality, and change readiness. Mark, maybe you could drill into these and explain why these proved to be so important for these top players?

Sarbiewski: We've done numerous surveys, there are lots of other surveys out there about what the business is asking of these application teams and of IT in general. For the last couple of years, it's been pretty consistent. Surprisingly, to some degree, agility and innovation are right at the top of the list. Cost is up there in third place in our surveys. So, it's hugely important, but it's not the first thing, and that's almost a little counter-intuitive.

What we hear from our clients is that things are hyper-competitive and that technology, in particular software and applications, is a huge competitive advantage. So, our ability to move fast and beat our competitors to the punch with capability is enormously important.

You turn that around. Suppose I'm an application executive and I own this problem. How am I going to deliver that to the business? I've done all kinds of things to try to make that happen. I've brought in automation. I'm bringing management. I'm outsourcing to drive cost down. I'm adopting new technologies for this rich experience. I'm introducing a whole host of change to meet those business objectives.

Have to deliver

But, at the end of the day, I've to be able to deliver every time. I got to be able to know when I'm going to deliver. That's absolutely critical to it -- to deliver agility. What it means to me as an App owner is that I'm ready to make change. And that's a big statement.

So the change readiness comes in. Have I architected for change? It's not just that my people are ready for it, my processes are good for that, my software itself is changeable, and I have automation where I can make a change and know if I have broken something else.

I'm trying to deliver that innovation and agility for the business. I've introduced a whole host of things to be against that, and I have to manage this in an extraordinary way, in a different way than I've done this in the past. What's going to help me to be able to predict where I'm going to land, repeat this for every project I get, and be change ready and not sacrifice quality.

I've to do all that and keep quality high. Those becomes the North Star principles that I want to keep my team focused on and thinking about how things like being change ready are facilitating the agility that the business wants.

Gardner: Brad, change ready really resonates, nowadays. We've got cloud computing in many people's minds as something important for them to be focused on. We've got mobile computing and how that impacts enterprises and their processes. And we're looking more at sort of the social business with collaboration and rich sharing of data and information.

They're always on. There is nothing I can do in a business that isn't going to touch the application.

So. change readiness seems to be the norm or perhaps am I overstating that?

Hipps: No, I think that's right. Speaking from the application domain, our friends in the agile communities have been the leading champions of this notion for a long time in applications. Our default stand was one of being change averse.

By that, I mean that there was this whole contractual relationship with business. You tell us what you need, and we're going to document it as best as we can, down to having all the semicolons in the right place.

We're going to break out the quill pens and ink our signatures. Forever shall it be, and if you change anything here, we're going to hit you with the request for change, and it will go through a cycle of six weeks and maybe we'll agree to it, etc., etc. The longest time was the mindset. You can look at that and say it's awful, but when I had far fewer applications, and they took far longer to build, it was just the way of the world.

The recognition today for all of the reasons we've talked about in this podcast and others, our applications are everywhere. They're always on. There is nothing I can do in a business that isn't going to touch the application. It fundamentally means, we need to sweep from the table, that notion of being change averse. Instead, we need to be in a position of embracing change. We do need to be change ready.

It's not that the business is going to sit back and say, "You're right. We're sorry. We won't ask for so many changes." This isn't going to happen. From an IT, from an app perspective, we need to be oriented and positioned, rather than see change as something that we need to fear or protect ourselves from. It needs to be something we need to embrace as a fact of life.

The leading traits

As Mark said, we need to be architected and engineered, from our people process technology perspective, to put ourselves in a position to be that way. In the book, we talk a bit about some of the principles we think come into play for change ready organizations. But, that's why it is one of the leading traits, the leading principles, in world-class organizations.

Gardner: Okay, we've talked about an awful lot, and this book encompasses an awful lot. It might be difficult for people to get a handle on where to start, but you've addressed that as well. You've conceptualized this along three lines: think big, start small, and then scale quickly and adapt. Let's go through these. Let’s start with you Brad. Think big -- what does that mean?

Hipps: It could be a mantra of sorts, Think big, start small, scale quickly. The basic idea of think big is the idea that you want to spend some time making sure that you’ve all got a shared vision of where you want to be, and we talk a bit about whether that was a maturity model -- these principles of predictability and repeatability, etc.

Hopefully we've set at least some suggested guidelines for constructing what your end state might look like. But, this point about thinking big is that, as we all know, certainly in IT but probably anywhere, it's every easy to fall into a state of analysis paralysis. We've got to figure out exactly the right metrics to decide exactly what we're going to be. We've got to figure out precisely what our time line is.

We sort of can borrow from our friends in agile, who have said that you've got to understand the perimeter of what it is you want to accomplish, but it's bound to change. Those perimeters are bound to shift. You're bound to discover things about yourselves, your organizations, what's feasible, and what's not in the process of actually trying to get there.

It's important to set yourself an objective and make sure it's a shared objective. It's just as critical to get going to not fall into a trap of endless planning and reconsideration of plans.

So, it's important to set yourself an objective and make sure it's a shared objective. It's just as critical to get going to not fall into a trap of endless planning and reconsideration of plans.

If, you then pluck the low-hanging fruit, the easy things we could do starting this week, starting tomorrow, to advance us at least generally toward these ends, this end objective, that's great. Then, it becomes a matter of just continuing to move, scale, and adapt.

Somewhere, we make the point that, as an application team, certainly at least as an application member, I cared a lot more about measurable progress, seeing things actually advancing and getting better. Then, I cared less about how shiningly brilliant the end-state was going to be or exactly how we were going to get there.

I was far more interested in generally getting a sense of what our North Star was, and then getting going, and actually seeing progress. So that, in a nutshell, is what we mean when we say, think big, start small, scale quickly and adapt.

Gardner: Mark, any further thoughts on this philosophical approach to this issue about the lifecycle of application?

Unconscious sabotage

Sarbiewski: Absolutely. I spent a number of years in a former life doing process change for companies. There were some trade secretes in the firm I worked with. They recognized some unchanging facts that that people can consciously or unconsciously sabotage the greatest plans, any process you want, or any kind of a change.

You have to start with people. It does involve all the people-process-technology in that order, but it's the people considerations. Do we have that shared vision? Who are the skeptics? Where do we think this could go wrong? Are we committed to getting there?

There were some questions we’d as we were embarking on making this change. First of all we said, what project or what pilot -- if we did these changes on it -- would people in the organization say, "If it works for that project, it will work for us as an organization."

So, find that visible pilot project, not one that’s an exception. Don’t find one where there are four developers and they are in the same room. If you try something new, people can say, "Well, of course, it worked for that, but that’s so atypical." So, find that project.

Beyond that, find the champion who is really respected in the organization, but skeptical of the change. We would go looking for one or two people who were open-minded enough to really give it a go, but maybe steeped in how we’ve done it, and have been very successful in how we’ve done it. Then, people can say, "That’s the kind of project we do, so you need to be able to make it work there. If Joe or Mary or whoever it is, if they buy into and it works for them, I believe."

The one other thing I’d say is start thinking about those types of metrics, those cross-silo and lifecycle-oriented goals and metrics.

The one other thing I’d say is start thinking about those types of metrics, those cross-silo and lifecycle-oriented goals and metrics. We talked about ones just a bit ago where we reward our delivery teams after six months of being live. Maybe, let's reward jointly the operations and the dev teams, if they’ve met those customer satisfaction goals, those service level agreements (SLAs), and those low counts of defects in production. You start to create a different dynamic, when you think more about lifecycle goals and cross-team goals.

Gardner: Now, I know these books involve a tremendous amount or work, and it’s something you really have to pour your heart into. Brad, the last question to you. What do you hope happens as a result of this book?

Hipps: The spirit of this book, and probably the spirit of a lot of these kinds of books, is that our hope is that somebody gets this book, and maybe doesn’t read it cover to cover. That’s okay. They pick and choose their places, but they take away one idea that’s actually implementable. If I have one hope, it’s that we haven’t been so pie-in-the-sky in our thinking that somebody reads this and says, "Yeah, nice idea, but it will never happen here."

So, that would be my hope -- somebody takes one single way that’s implementable in the near term within their organization.

Gardner: And in fairness I should offer the same question to you, Mark. What do you hope happens as a result of the book?

Sarbiewski: Do you mean not The New York Times bestseller list. I can’t hope that.

Gardner: Regardless of its reach.

Software is important

Sarbiewski: What I’m hoping is that in these hundred or so odd pages that executives in these enterprises that we're talking to have that opportunity to take just a couple hours and have somebody give them a chance to think about how important software is, and what the true life of an application is.

Once you start to go down that path and you start to say, wait a minute, 10, 15 years of evolving this capability, what does that mean? When things are live and I’ve got hot request from the business to make a change, what needs to happen? How much money will I spend on that?

The one "aha" moment is seeing that the 12 to 15 years matter, when I’m delivering value to the business and innovating for the business. In order to be successful during those 10 to 15 years, I will make different decisions when I build this thing. I will focus on a process.

I will build the automation to a different level, because I’ve stopped thinking that my job is done when I go live. If that’s truly the job, you’ll make a lot of shortcut decisions to get to go live. But, if you think bigger, you think about the full life of an application and what it delivers to the business. All of a sudden, it makes a whole lot more sense to do things a bit differently, to set myself up for 10 years or 15 years of success with the business, as opposed to a moment when I can say, "Yup, I achieved a milestone."

Gardner: Very good, but we have to leave it there. We’ve been examining how our shifting applications and IT landscape provided a huge opening from proving how applications are built, consumed, and managed using new application lifecycle management methods and concepts.

I want to thank our guests, the authors of our book that we’ve been discussing. We’re here with Mark Sarbiewski, Vice President of Marketing for HP Applications. Thanks so much, Mark.

Sarbiewski: Thank you.

Gardner: And also Brad Hipps, Product Marketing Manager for HP Applications. Thanks to you, Brad.

Hipps: Thanks, Dana.

Gardner: This is the last in the series of three podcasts on ALM; we’re examining a new book on the subject, The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle. It offers some powerful methods retaining overall business services delivery improvement. Thanks for joining our series, and we hope you have 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 third 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

• Automating the managed application lifecycle helps Delta Airlines deliver better business results
  
  
• Dave Shirk on how HP's Instant-On Enterprise takes aim at new demands on businesses, governments
  
  
• HP Shows Benefits from Successful Application Consolidation With Own Massive Global Supply Chain Project

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