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 the current state of applications in large organizations. 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.
This is the first in a series of three podcasts with the authors the ALM book to learn why they wrote it and to explore their major findings. They are: 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: 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.
... IT organizations are looking to change the game.
Hipps: 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. ... 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 differentmethods" or "We're relying more on outsource teams, so we are not all colocated."
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.
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'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.
Sarbiewski: The idea now 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.
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.
Just about every square inch of the enterprise is automated in some way by software. 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 almost drags along, or in some cases, is led by, and has to be led by, innovation in the software to make that happen.
... You need to make software a core competency if you are going to differentiate your business going forward. So it's hugely important.
Hipps: Business can't twitch without requiring some change in a set of applications somewhere. ... 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.
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.
Sarbiewski: 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.
... 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: 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 10, 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.
... 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 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.
For more information on Application Lifecycle Management and how to gain an advantage from application modernization, please click here.
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