For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.
The topic of ALM will be a big one at next week's HP Software Universe conference in Barcelona. In anticipation, join us as we explore application lifecycle management (ALM) best practices for overall business services delivery improvement.
In this discussion, the last in a series of three, we underscore the conclusions from the forthcoming book and explain how organizations can begin now to change how they deliver and maintain applications in a fast-changing world.
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 forthcoming book, called The Applications Handbook: A Guide to Mastering the Modern Application Lifecycle, the authors evaluate the role and impact of automation and management over an application's lifecycle, as well as delve into the need to gain better control over applications through a holistic governance perspective.
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 the 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, 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. The discussion is moderated by BriefingsDirect's Dana Gardner, Principal Analyst at Interarbor Solutions.
Here are some excerpts:
Sarbiewski: 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.
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.
We built out a model for ALM maturity, and it’s in the book.
... 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.
If you can understand the results that you are seeing, that ought to help you figure out where you could be. What we've seen is a progression from the spectrum of companies, ... [many] have fairly immature processes.
We see people just getting started, and they have a relatively ad hoc, narrow, point tool, with lotsof 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.
So our idea around maturity -- and tying it to outcomes -- is the results that we see. ... 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.
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.
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 the competitors to the punch with capability is enormously important.
More of a scorecard
Hipps: 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.
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."
Speaking from the application domain, our friends in the agile communities have been the leading champions of this notion. Our default stand [as development teams] 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 that 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.
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.
This 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 still 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.
Unconscious sabotage
Sarbiewski: 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.
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.
Hipps: The spirit of this book, and probably the spirit of a lot of these kinds of books, ... 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.
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."
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 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:
No comments:
Post a Comment