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.
Thanks for joining this sponsored podcast discussion that examines a new book on application lifecyc
le 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, 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
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. 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.
You've got to think about both -- not only across the lifecycle, but how they interlock.
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.
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?
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.
It's not complexity plus complexity, it's more like complexity times complexity, when you consider modern delivery and its particulars.
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.
For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.
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.
Traditionally, in our legacy world, the push was always, can we get the application delivered?
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 CSA Aids 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
No comments:
Post a Comment