Brad Hipps: Mastering the Modern Application Lifecycle

Editor's Notes

• #2: [This slide and the next can be presented in relatively quick succession together.] In the not-so-distant past, even large companies relied on asmall handful of “super apps” to power the major businessprocesses (payroll, accounts receivable, etc.).Not anymore.Most of us would have trouble naming a single business processthat doesn’t depend on an application or series of applications—from the tiniest wiki to the grandest enterprise resourceplanning system…
• #3: … what does this mean? Applications are now so integral to the modern enterprise that business nimbleness depends on application agility: You don’t get one without the other. The business moves, changes, and expands only as fast and efficiently as its applications do.
• #4: Recognizing this fact, IT organizations have fundamentally changed the ways their people, processes, and technologies deliver applications. We’re seeing projects with offshore or near-shore support structures; a process shift away from document-heavy methods like Waterfall to flexible ones like Agile; and new technologies such as richer clients (RIA), cloud computing, service-based architectures and composite applications. These initiatives characterize modern application delivery:STABILITY/AGILITY: Where once the primary goal was that the application not fall over in production – effectively, get the damn thing stood up, and back away – now the expectation is that the application will undergo regular (weekly, monthly) change and be accordingly responsive. Think of it as the Siebel vs. Facebook paradigm – the move to the always on / always available / constantly changing application. “Do as I ask” / “Bring me ideas”: IT is no longer an esoteric back-office function, there simply as order-takers for the business. The business and IT are attached at the hip, and the primacy of the application means that the biz now looks to IT to provide innovative ideas about what is possible – how customers can be better reached, with greater efficiency, etc.COST REDUCTION: Yesterday, IT was the engine for biz cost reduction. Now, IT itself is also a target for cost reduction.EXHAUSTIVE / JUST ENOUGH: Where once IT processes were characterized by heavy documentation and exhaustive checklists, increasingly we see a borrowing from manufacturing’s lean principles so that the new flexible processes (and applications) aim for “just enough” documentation/features.“Does it work”/”Does it impress”: This again reflects the application’s evolution to its primary spot in the business. Where in the Web 1.0 days the main concern was simple data-entry screens and the corresponding business validation, RIA/Web 2.0 is pushing for applications for richer, more impressive applications that truly advance the company’s brand, both inside and outside the company’s walls.
• #5: Despite having the right objectives and having adopted the principles of modern delivery, application teams continue to experience frustration in the results. Why?
• #6: The first challenge we see is that the fundamentals of good delivery are under pressure like never before. The best delivery organization operate with a high degree of predictability – they know the state of their programs, and time and again can forecast with confidence if they’re on track. But when we consider modern application delivery, we see a scattering of teams, which introduces unprecedented difficulties in getting a single view of overall progress. Moreover, project assets are distributed across a multitude of repositories and file servers, meaning that reuse often goes by the wayside and wheel reinvention becomes the norm. Finally it is difficult for these teams to collaborate and work in coordinated fashion – there is a loss of line of sight among project members. Spreadsheets and phone calls might have been workable when teams shared an office space, or at least an office campus, but these old methods are no match for the modern, distributed organization.Application quality has never been simple, but when we see the rise of RIA, Web 2.0, services, Agile, etc. we see complexity threatening quality. What does it mean to test a component that has no GUI? How do we account for the performance and security concerns of RIA? Are my quality folks integrated into Agile delivery, or are they standing on the sidelines watching developers crank out code? The volume of application change (“RFC” = request-for-change) is astounding. Gartner estimates that large enterprises may see upwards of 70,000 RFCs per month. Businesses move and change only as effectively as their applications. But when we consider the previous points – distributed teams, uncertain views of progress, a lack of sharing, complexity threatening quality – and add to this the sheer challenge of understanding what any given change will mean to an application that has hundreds of moving parts spread over multiple teams… the problem becomes clear. If I have requirements in Word documents spread across multiple file servers (and local hard drives), and perhaps tests in Excel spreadsheets in an equivalent state, to say nothing of the application code itself – how do I see the connections and dependencies among all these assets? It takes days (if not weeks) to determine change impact and to understand what must change and where.Because many of these modern trends are adopted piecemeal, we see that too often a delivery organization continues to rely on its legacy mechanisms to execute modern delivery. These organizations may not realize how different and complex their delivery world has become until the complexity has become overwhelming. In short: to achieve the intended outcomes, modern delivery requires modern solutions.
• #7: What should these modern solutions do? They should restore the fundamentals of core delivery:PREDICTABILITY: the solution must produce a single, central view – a single “pane of glass” – that shows the state of the overall program. This should be based on real-time metrics such as # requirements successfully tested, that is, the binary measures of progress. It should automate the hand-offs among project teams, so that team members know immediately when some task is ready for their involvement. Finally, it must provide a central repository of reusable assets so that any team, regardless of location, can see at a glance whether a test has already been created that they can reuse, or a requirement already elicited, or a defect already raised.QUALITY: Furthermore, the modern solution must put quality at the center. It must allow me to capture the business requirements – functional and non-functional – and ensure that these don’t become historical artifacts but remain living reflections of business need. These should then drive all our verification activities. The quality solution must be able to account for all the myriad new technologies my applications are built on, not only verifying functionality but also performance and security. And the solution should allow my teams to work in collaborative fashion regardless of methodology – I should not need a series of dedicated point tools to support each new method.CHANGE-READINESS: Finally, to achieve true change-readiness, the solution must provide an array of innovative automation to strip out manual activities and reduce latency wherever possible. This must be combined with a single end-to-end view of asset relationships and dependencies. I should be able to select the requirement under change, and see at a glance all dependent artifacts – tests, even down to line of code. In this way I ensure efficient and accurate impact analysis, and accelerated but thorough change execution.
• #8: Getting core delivery right is no small victory. But it’s the first battle, not the last. A second reason modern delivery fails to deliver the expected business value is that too many enterprises miss that there is a broader application lifecycle. An application doesn’t begin life as a set of requirements; it begins as a business idea. And it doesn’t end the day it goes live; in fact, go-live only marks the birth of something that’s bound to live a long life.Gartner has determined that the work to initially deliver an application represents a mere 8% of its total cost of ownership (TCO), assuming a 15-year life. The other 92% of TCO derives from the loops that must be made around the complete lifecycle – identifying change, prioritizing, implementing and re-deploying; accounting for new enhancements, etc.
• #9: This means companies must solve for what we call the complete lifecycle. Doing so delivers considerable tactical value, effectively creating an integrated application supply chain. This includes: Ongoing planning activities that reflect metrics from live projects, compare costs and burn-rates, and help to determine whether certain projects are in danger of having their costs outweigh their expected value. Establishing architectural and technical policy that must be true across the enterprise, and observed by all delivery teams. Sharing key pre-production assets such as performance tests with the production teams so that the latter do no have to recreate on their own, and reciprocally, harvesting real usage from production to augment and improve pre-production tests. Providing for seamless capture, prioritization, and implementation of change. And finally, seeing that applications will live a useful life and should not be maintained beyond it. This means providing for the archival of the application’s data, and being able to take the application offline and to re-provision its resources (maintenance spend, servers, etc).
• #10: Beyond the tactical advantages of solving for the complete lifecycle, there is a broaderstrategic advantage. The enterprise now has a wealth of data about the application at its fingertips. This allows for a historical picture of the application, one that captures the cumulative investment. How has the app performed against its service level objectives? What has been the rate of break/fix? Is it still an application with heavy access and use? Has it remained mostly in compliance with technical policy and standards, or has it reached a state of brittleness and spaghetti code such that any change is now a tremendous ordeal [this is what “technical debt” refers to – in essence, coding shortcuts taken for the sake of deadlines, but which create a cumulative impact on the simplicity and efficiency of the code].Think of it this way. Every enterprise understands that things like land, buildings, equipment and inventory are assets: things whose investment must be formally justified upfront, and which will diminish in value over time, ultimately to a point where the costs to keep the asset outweigh the benefit. Why should an application be any different? Solving for the complete lifecycle allows an organization to treat and track the application just as it would any other business asset.
• #11: So what can HP’s solutions do?It starts with providing comprehensive management and automation solutions for core delivery. This means a single platform for managing the core delivery lifecycle, including requirements and quality management, and robust integration to the developer’s environment. All of this issues from a single platform. Our operating principles for our core delivery solutions are at bottom-right (white).But we don’t stop there. We help customers solve for the complete application lifecycle. This means our core delivery solutions sit at the center of a fully integrated, complete lifecycle solution set. The operating principles for the broader portfolio are at bottom-left (blue).
• #12: In early 2010, we hired Forrester Research to confirm for us what our customers top objectives were as they adopted the initiatives of modern delivery. Here is the response of 206 global IT leaders. Increased agility topped the list, followed in priority by innovation, cost reduction (interesting that came in third, not first), and finally two that we might group together as a better application experience.We’re pleased that as we’ve worked with customers around the globe, we’ve been able to help them deliver against precisely these objectives.
• #13: Well the first step is to understand where you are….
• #14: Download at: http://h20229.www2.hp.com/partner/protected/assets/pdf/4aa3-1949enw.pdf