1. New Book Explores Automating the Managed Application
Lifecycle to Accelerate Delivery of Business Applications
Transcript of a sponsored BriefingsDirect podcast, the first 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.
We'll explore the current state of applications in large organizations, and how
complexity, silos of technology and culture, and a shifting landscape of
application delivery options, have all conspired to reduce the effectiveness of traditional
applications approaches.
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 first, in a series of three podcasts, on the ALM book, and we're here now with the
authors to learn, first and foremost, why they wrote it, and to explore their major findings.
Please join me now in welcoming Mark Sarbiewski. He's the Vice President of Marketing for
HP Applications. Welcome, Mark.
Mark Sarbiewski: Thank, you Dana.
Gardner: We're also here with Brad Hipps, Senior Manager of Solution Marketing for HP
Applications. Welcome, Brad.
Brad Hipps: Thanks, Dana

2. Gardner: I wonder if we could first begin by looking at why applications have been in trouble,
what's going on, and why is there a huge opening now for improving how they have been built,
consumed, and managed. Why don't we start with you, Mark?
A silver bullet
Sarbiewski: It's really a combination of factors, which is part of the challenge that customers
have. They're looking for a silver bullet.
In most large enterprises, applications have been built up over many, many years.
You throw acquisitions into that and you end up with layers of applications, in a lot
of which there is redundancy. You have this wide mix of technology, huge amounts
of legacy, all built different ways, and the business just wants response faster,
faster, and faster.
So, we have old technologies hampering us. We have an old approach that we've built that
technology on, and the modern world is dramatically different in a whole host of ways. We're
changing our process. We're changing the way our teams are structured to be much more global
teams, outsourced, nearshore, far shore, all of that stuff, and the technology is fundamentally
shifting as well.
That's the context for why you see all these horror stories and these stats about the businesses'
level of satisfaction with the responsiveness of IT, particularly in applications. If you think about
it, that's what the business experience is.
They understand, have you automated this business process? Have you helped me take the
website to a better place and give me a richer experience for my customers? It's the apps that the
business experiences. When they see it move at glacial pace for all those reasons we just talked
about, that's where IT organizations are looking to change the game.
Gardner: Brad Hipps, from your perspective, these have been problems that have been building
for a long time. So why the book now?
Hipps: I'll speak from not only conversations with customers, but my own personal experience
when I was running application delivery teams. A lot of these trends that we talk
about -- outsourcing, service-based architectures, more flexible methodologies,
whether it's iterative or agile -- you wouldn't necessary call any one of those brand
new. Those things have been around for a few years now. Many enterprises we
speak with and deal with have been leveraging them for a few years in some form
or fashion.
If you're an owner of application teams or of a series of applications within an
enterprise, these things tend to sneak in. By "these things" I mean these trends.

3. They tend to sneak in on the perimeter, and you wake up one morning and realize all of a sudden
that fundamentally the way your teams have long operated has been changed.
In some ways, it's death by a thousand cuts. No single one of these initiatives is going to force
you to take a step back and say, hold the phone, let's figure out if the way we deliver applications
now requires us to, in some significant way, rethink the mechanisms by which we conduct
delivery.
From my own experience, it's difficult to get the time or the brain space to do that. Usually,
you're neck deep in getting the next application out the door. You've got deadlines. You've got
other applications or enhancements coming down the pike.
Necessary questions
You may not have the time to take a step back and say, "Wow, we're using these different
methods" or "We're relying more on outsource teams, so we are not all
colocated," or "We've got these new technologies we have begun delivering.
What does that mean for performance and security of the application?" -- all
the questions that those kinds of trends beg.
One of the objectives of this book was to do just that. Mark and I had the
luxury to take a step back and think about what these trends mean soup to nuts for the way
applications get stood up and delivered and how, from an enterprise perspective, we have
responded or not responded to those new complexities.
Gardner: Mark Sarbiewski, in the book you guys deliver a really interesting comparison. You
say the jet fighter cockpit was an example of where too many things happening at once
overwhelm the pilot. So, rather than try to keep improving what the pilot was capable of, perhaps
beyond what was natural, they redesigned a cockpit. How does that relate to what we are talking
about here with ALM?
Sarbiewski: That’s a decent analogy for one of the critical design principles that we think is a
way an enterprise should approach delivering and running applications. The idea is that you need
both management and automation to achieve your end goals.
People have long thought of those things in very narrow ways. They've thought of management
of a narrow domain space, like managing requirements and automating GUI functional tests.
Those were all good steps forward, important things, but there was little connection between
management across the lifecycle and automation across the lifecycle.
The example of that jet fighter you can even extend to you driving a car. You're managing the car,
managing how fast you go, and seeing the gauges. They're giving you information about the
direction you're headed, if you have a nav system, how long it's going to take, all that. When you
hit the gas, automation takes over. When you turn the wheel, it goes in a different direction.

4. Part of what we're trying to get at here is this interplay. You've got to think about both -- not only
across the lifecycle, but how they interlock -- to create the situation where I see what's
happening. I see across these very complex endeavors that I'm undertaking, many people, many
teams, many stakeholders, lots of projects, lots of interdependencies, so I have that visibility.
When we need to step on the gas and go in a particular direction, and speed everything up
without blowing everything up, that's when I can rely on nicely integrated automation.
Gardner: Now, we are also seeing in the market a definition shift in applications. There's a new
emphasis on services, agility, reuse, rapid iterations, and even ecosystems, where we're getting
services and applications from a variety of sources.
This is different from what we could call super apps or the big honkin' packaged and integrated
apps of the past. How is that shift impacting this, and how does that relate to your book? Let me
start with you, Brad.
Hipps: We were talking earlier about these trends and complexities. You can speak about them at
a headline level, but then you can take a particular example, like the one you're touching on. The
nature of an application today is that it's not a monolith. It's not owned by a single project team
or a program consisting of several teams.
Leveraging what we can
More often than not, it's something that has been assembled using a series of subcomponents,
reusable services, or borrowed function points from other applications, etc. It's this thing that is,
in the best sense, cobbled together. Rather than writing it all from scratch, we're leveraging what
we can.
We can all agree that this makes sense, it’s the right way to do it, it's much more assembly line
production versus handcrafting everything, which is certainly the direction we want to be headed
in, from a software perspective.
But, that also presents us a lot of new challenges. How do I have visibility or discover the
components that are out there, that are available for me to use? How do I trust that those
components are reliable, that they are going to behave and perform in the way I want them to?
Given the fact that I, as a given developer, didn't actually create it myself, how can I have faith in
it? And, how are we going to authenticate all these different pieces?
It was one game of validation when, as I say, it was a monolith and all self-contained, and we
executed our test from top to bottom, but now we have these individual subparts. We have to test
each of them of themselves and then we have got make sure that connected they also do the same
thing. A lot of them are GUI, so that presents its own complexity. How am I automating the test
against something that has no GUI front-end, but I can record a playback?

5. I am speaking just at the the technical level. If you marry some of those tricks or hiccups against
the reality of how that's going to be delivered, it's going to be delivered by multiple teams.
Almost inevitably, those teams are not all going to be sharing one building. They're going to be
located in different places.
So you've got these questions. How do we collaborate? How do we communicate? How do we
notify each other of defects? How am I aware when something is ready to retest? Relying on
email is, let's just say, less than ideal. And, of course, we may be using different methods.
Multiple teams could be using different methods. Those over there are working in agile fashion,
we are working in waterfall fashion.
So the catchphrase we have, which may or may not make sense, it's not complexity plus
complexity, it's more like complexity times complexity, when you consider modern delivery and
its particulars.
Gardner: I suppose another change over the past 10 or 15 years has been the impact that these
applications have on a business. In the past, they may have been great for building efficiency,
approving productivity, maybe even just a nice to have, versus more manual ways of
accomplishing business.
But nowadays, and I would like to borrow quote from the book, the business moves, changes,
and expands only as fast and as efficiently as the applications do. So, applications are vastly
more important now to a company. Mark, help me better understand why that's the case.
Sarbiewski: You'll see from a variety of industry folks that these eras of computing, when it was
data processing, information management, or MIS, came through to the web, it's gone from "let's
collate information and spin it around for the business" to "this is literally how we conduct nearly
everything that we do."
Internal users
I'm talking internal users, whether it's working with their training systems, working with their
expense systems, recording sales, tracking customers and prospects, just about everything goes
into some software application.
Between companies and the supply chain is highly automated, all sorts of software, gluing
partner and ecosystems together, and increasingly direct to the customer. We just take it for
granted now that I actually don't ever really have to go to a bank anymore. I can just do
everything I used to do in person now via their website, their web applications.
I talk to our customers about the challenge. This is another thing that crept up on them. Just
about every square inch of the enterprise is automated in some way by software. You always get
a lot of nodding heads. What it has meant for IT teams is that you now have to understand every
square inch of the business, and the businesses are incredibly dynamic. So, any part that changes

6. almost drags along, or in some cases, is led by, and has to be led by, innovation in the software to
make that happen.
I often tell customers that you are running significant large scale software or entities inside your
business. You may not think of yourself that way, but a big business will have potentially
thousands of apps. It will have software and potentially products that it builds. It will be
orchestrating a whole huge mix of technologies, and inside and outside teams, which is more
complex than what a lot of independent software vendors (ISVs) do. And my argument to them
is that you need to make software a core competency if you are going to differentiate your
business going forward.
So it's hugely important. There is example after example of innovations that businesses have
created. One of my favorite ones to talk about is Bank of America's Keep the Change initiative.
We had a little bit of insight into what that involved. That was an IT-led thing. The ability to use
a debit card, have the leftover change rolled into a savings account, required massive software,
updating new stuff to have it happened, and it has been hugely differentiating for that company.
Hipps: Mark, if I am not mistaken, there were tens of applications behind that one initiative,
were there not?
Sarbiewski: Absolutely. Updates to existing ones, many tens of new ones, all had to come
together on launch date. Think about that? IT is not reacting to "It would be nice if we could
have this capability. It would make our lives easier." This was, "We are going to differentiate our
business based on this. So, those 70 odd applications that you are building or modifying will
have to be here on the launch date, because it's a business initiative."
For more information on Application Lifecycle Management and how to gain an advantage
from application modernization, please click here.
Gardner: So, while we've had incredible increase in complexity, we have redefined these
applications over a period of years. They have now taken on a much larger role within the
company and yet, in many organizations, there is this legacy mechanism in place for how
applications are treated. This perhaps is the disconnect
I'll throw that out to either of you. How bad is that? How much of a lag do we have here between
what's required in organizations to do ALM properly, and what's the real run-of-the-mill way of
doing it?
Hipps: The first company I worked with building applications probably had three of four major
applications they worried about. One of the biggest ones, not surprisingly, was the billing and
rating system that they had created. I think the first release of that system took us two years to get
out the door. It was your classic custom-developed application. Many hands were on deck,
cranking out code, running tests, and all the stuff you would expect.

7. Traditionally, in our legacy world, the push was always, can we get the application delivered?
Can we get it stood up and working and out the door? And if we did that, we went to our ops
brethren and we said, "Look guys, just don't kick the plug out. Just leave it alone, and we'll wait
until we have another release sometime next year. We will have the next big push."
When we lived in that world -- and for many of us in apps who grew up in that world, not 40
years ago, but 15 years ago -- it's understandable that we've long taken this view that as long as
we get the application built and stood-up, we've done what we need to do for the business.
A lot more planning
If we try to fix that legacy view against what we have been talking about today, which is
effectively that the business can't twitch without requiring some change in a set of applications
somewhere, we know that the reality of the world is that there is a heck of a lot more planning
activity that goes on. We've got applications everywhere. They're going to be under constant
review, modification, enhancement, addition, etc., and that's going to be a an endless stream.
We've got an expectation, given the web world we live in, that these applications, many of them
anyway, are going to be always on, always available, always morphing to meet whatever the
latest, greatest idea is, and we have got to run them accordingly.
We have got to make sure that once they are out there and available, they are responsive. We
have got to make sure that the teams that own them in the data centers are aware of their
behaviors, and aware of which of those behaviors are configurable, without even coming back to
the application teams.
The legacy view said, "Wow, the software development lifecycle (SDLC) is the end-all, be-all. If
I get the SDLC right, if I get requirements and deployment done right, I win." We realize that this
is still critical. What we would describe as the core lifecycle is still where it all begins.
But, this thing is going to live for 15 years. It's going to undergo endless amounts of change in
that process. If I'm going to really be successful against what it is the business is after, I do have
to account for this complete lifecycle. All the stuff that's happening before requirements, the
portfolio investigation that's occurring, the architectural decisions I am making, have got to be
true across the enterprise, as well of course as everything that happens once that thing goes live.
How well connected I am with my operation peers? Have I shared the right information? Have I
shared test scripts where possible? Am I linked into service desk? Am I aware of issues, as they
are arising, ideally before the business is hearing about it? Those things are what we mean by
getting your arms around the complete lifecycle is what's necessary, when you think about the
modern delivery of applications.

8. Gardner: Let's drill into that a little bit, now that we understand that. That gap needs to be
closed between what applications need to have in terms of support across your lifecycle and
some of the traditional ways of doing that. And your suggestions in the beginning of the book are
strong management and automation, but integrated.
Mark, what’s the need for integrating and what do you mean by integrating management and
automation?
Sarbiewski: It goes back to that analogy of driving a car. You're doing both, and both things are
happening in concert. I'm managing. I'm seeing the flow of information. I'm guiding this car,
stepping on the gas, etc., and the engine and the suspension system is doing the heavy lifting of
pushing me faster, or brakes are slowing me down, in a very automated way. I'm acting in a
management capacity, on the management information I have. I'm relying on automation to make
these types of things happen.
In the world of software delivery and obviously the operation phase, it's very similar. You have a
whole series of things. For example, we'll start at the beginning, let's assume. We would argue
that the beginning of an application is the idea, the request. I need to have X for the business.
Specific requirements
We judge whether or not this is of value against all other requests, and we decide we're going to
do something. Now, I get into trying to understand the specific requirements. Even in the
requirements, there is an aspect that can be a level of automation and a level of management.
Automation can come in when I am building a visualization, a quick prototype, and there are
some great solutions that have emerged into the market to help a non-technical user create a
representation of an application that has almost the perfect look and feel. We're not talking about
generating code. We're talking about using HTML and tools to create the flow, the screen views,
and the data input of what an application is going to look like.
You hear that a picture is worth a thousand words. This goes to one of the fundamental broken
things that we have had forever about requirements. You and I have a discussion, and I write
something down in text. This is a very poor articulation of what you really want and need, but if
I can show you something, you can play around with it and give a look and feel to it and make
comments on that -- very different.
Once we get to that look and feel of an app, at the push of a button, I can interpret all those
business rules, all those rules about where was data, what was on the screen, was this data
hidden, what was inputted, when did it flow to the next one, under what condition. All of that
will get translated into a series of text-based requirements, test assets to test for that logic, and
even the results and the rules and the data that needs to be input.

9. So, I have a process. I have had discussion and used some technology to visualize these
requirements. At the push of a button, I automated the complete articulation, with perfect fidelity,
including the positive test cases I want to run. I can manage those now, as I have always have,
and my systems and teams expected to.
Those requirements trigger test and defects and go against code, all of which can be linked.
Whenever progress is made in any dimension against those requirements, I have created a test for
one, I have run a test for one. I have run ten tests and eight paths. I have checked new coding
against the bugs. All of that can be tied together and automated with workflow.
So, you start to see how I've got a creative series of information. I use automation to advance it
to the next stage. I now can push that information to each of the key stakeholders and automate
the workflow behind that. This is what we mean when talk about changing the game and how
you deliver software, by doing just that, thinking about, what are the things that I have to manage
and how does automation speed things up, and create outputs with greater fidelity and greater
speed.
Hipps: In an ideal world, this idea of integrated management and automation is essentially a
move away from the world we've had for a long time in software, which is, I have a series of
individuated point tools that I use for particular siloed functions. As Mark said earlier, that was
necessary, that was useful, and that was the critical step, but we shouldn't expect that or view that
as the endgame.
The endgame should be that what I've got is a unified way of getting these various operations
connected, so that my management picture has a straight flow through from the automated things
that its kicked off. As those automated events occur, I'm getting a single, unified view of the
results in my management view, which is, nine times out of ten, not the world we have when we
look at big, big enterprise delivery. It is still a series of point tools, with maybe Excel laid over
the top to try to unify it all.
Gardner: It sounds as if this is a natural maturation of IT, perhaps along the lines that we have
seen with other aspects of business functions over the past 50 or even 100 years. Is that the case
now? We are simply letting IT grow up, going beyond a dark art or a mysterious craft, to more of
a regular recurring but dependable IT and/or business function?
Hipps: I think that's the case. It's funny, because for those of us who have been in software,
grown up in software, there is always a temptation to hold ourselves as being on the cutting edge
of everything and the sophisticated leaders of how work gets done.
Older and humbler
As I get older, I'm a little more humbled. If you want to understand the future of IT, you just
need to look at where manufacturing has come. We've plagiarized the lion’s share of what we do
in IT and the way we work a lot from what we have seen in manufacturing and mechanical
engineering. That extends to lean methods. It starts probably all the way back to waterfall.

10. Maybe it's no surprise that when you ask us to talk about what you mean by integrated
management and automation, we are borrowing an analogy from the world of mechanical
engineering. We're talking about what planes can do, what ships can do, and what cars can do.
So, I hope this is very much a natural advancement.
Sarbiewski: I talk about it to customers and I talk about the industrialization of IT. Sometimes,
there's a little pushback on that, because it feels heavy. Then, I say, "Wait a minute. Think about
how flexible Toyota or Boeing is." These companies have these very complex undertakings and
yet can manage parts and supplies for providers and partners from every corner of the world, and
every other car can be different coming off that assembly line. Look at how quickly they have
shrunk their product lifecycles from design to a finished model.
Part of what's done that is exactly what Brad was talking about, an enormous investment in
understanding the process and optimizing that, in supporting the various stakeholders, whether
it's through design software, or automation on the factory line, all of that investment. We didn't
do in IT. We built it ourselves. We used Excel and post-it notes and other things, and we created
from scratch everything that we have done, because we can, because we made it easy to do that.
We have made it easy to design and build it a thousand different ways.
There is this counterintuitive perception that because there is an infinite number of ways, we hold
ourselves to be different than that. People are realizing that's not really the case. In fact, the more
I can industrialize and keep it lean and agile, how I do this, the tools I use, if I give the people
incredible tools to do it, and not just point tools but integrated, the results really speak for
themselves.
When we talk to customers that have done this, they achieve incredible results in three critical
dimensions. There's a very longstanding joke that you can't go faster, you can't raise quality and
take cost down. It's not just possible. This is this impenetrable triangle or it’s squeezing a
balloon. We see with our customers that you absolutely can.
They have essentially industrialized their approach, they have integrated their approach, they
support their stakeholders with great technology, and they adopt to change their process. Guess
what, they go faster, they take cost down, they drive quality up.
Gardner: I'm afraid we have to leave it there. You've certainly piqued my interest in this book.
We've been examining how the shifting applications landscape is providing a huge opportunity
for improving how applications are built, consumed, and managed. You need to use these new
ALM methods and concepts to get to that point, move beyond the old, because the gap is deep
between what had been norm and what’s the new norm.
I want to thank our guests. We have been here with Mark Sarbiewski. He is the Vice President of
Marketing for HP Applications, and also Brad Hipps, Product Marketing Manager for HP
Applications. Thanks to you both.
Hipps: Thank you.

11. Sarbiewski: Thank you.
Gardner: This is the first in the series of three podcasts on ALM. We are examining a new book,
‘The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle,' and it’s
one that offers methods as well as means to overall business services delivery improvement.
Our next podcast examines how an enterprise, Delta Airlines, has moved successfully to improve
its applications quality, and gain the ability to deliver better business results from those
applications. We will hear their story from two Delta IT executives and get the reactions to the
new book's findings.
Our final podcast underscores the conclusions from the book and explains how other
organizations can begin to change how they deliver and maintain applications in a fast changing
world.
We hope you can join us for the rest of our series, and we hope you can get a chance to get the
book and examine it in more detail.
This is Dana Gardner, Principal Analyst at Interarbor Solutions. You have 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 first 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:
• Doing Nothing Can Be Costliest IT Course When Legacy Systems and Applications are
Involved
• Shoemaker on How HP CSAAids Total Visibility into Services Management Lifecycle
for Cloud Computing
• HP Advises Strategic View of Virtualization So Enterprises Can Dramatically Cut Costs,
Gain Efficiency, and Usher in Cloud Benefits