Brad Hipps: Mastering the Modern Application Lifecycle
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Brad Hipps: Mastering the Modern Application Lifecycle

on

  • 900 views

 

Statistics

Views

Total Views
900
Views on SlideShare
861
Embed Views
39

Actions

Likes
1
Downloads
19
Comments
0

3 Embeds 39

http://www.sg.com.mx 28
http://www.scoop.it 8
http://sg.com.mx 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • [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…
  • … 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.
  • 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.
  • Despite having the right objectives and having adopted the principles of modern delivery, application teams continue to experience frustration in the results. Why?
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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).
  • 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.
  • Well the first step is to understand where you are….
  • Download at: http://h20229.www2.hp.com/partner/protected/assets/pdf/4aa3-1949enw.pdf

Brad Hipps: Mastering the Modern Application Lifecycle Presentation Transcript

  • 1. MASTERINGTHE MODERN APPLICATION LIFECYCLE
    Brad Hipps
  • 2. The Application Reality
    ERP
    inventory management
    Most enterprises run major software operations.
    wikis
    supply chain
    PoS
    mobile apps
    HR
    billing
    website
    payments
    order entry
    Embedded software
    CRM
  • 3. Business agility depends on application agility.
  • 4. Application Delivery: Yesterday & Today
    P
    people
    DISTRIBUTED TEAMS
    CO-LOCATED TEAMS
    P
    process
    FLEXIBLE METHODS
    SEQUENTIAL METHODS
    P
    tech.
    THIN CLIENT,
    SELF-CONTAINED
    COMPOSITE, CLOUD, RIA
  • 5. Right Aims, Wrong Results
  • 6. MODERN PRESSURES ON DELIVERY FUNDAMENTALS
    TECH. POLICY
    CODE
    TESTS
    MILESTONES
    REQMTS.
    TESTS
    CODE
    REQMTS.
    High quality apps?
    Predictable outcome?
    Responsive to change?
    ~60% of IT leaders say distributed teams significantly impacts productivity.
    –Forrester
    On average, 25% of application defects are found by customers.
    –Capers Jones
    An enterprise raises 2,000-70,000 RFCs per month.
    –Gartner
  • 7. RESTORE CORE DELIVERY FUNDAMENTALS
    UNIFIED SHARED ASSETS
    REQUIREMENTS
    DEFECTS
    MILESTONES
    CODE
    TESTS
    High quality apps?
    Predictable outcome?
    Responsive to change?
    • Full requirements mgmt.
    • 8. Agile, RIA, service testing
    • 9. Integrated performance, security
    • 10. Innovative lifecycle automation
    • 11. Traceability, change impact
    • 12. Real-time metrics
    • 13. Workflow automation
    • 14. Collaboration & asset reuse
    ~60% of IT leaders say distributed teams significantly impacts productivity.
    –Forrester
    On average, 25% of application defects are found by customers.
    –Capers Jones
    An enterprise raises 2,000-70,000 RFCs per month.
    –Gartner
    PREDICTABILITY
    QUALITY
    CHANGE-READINESS
  • 15. THE UNSEEN LIFECYCLE
    “For a business application that is used for 15 years, the cost to go live is, on average, 8% of the lifetime TCO.”
    RUN
    PLAN
    –Gartner
    DELIVER
    RETIRE
  • 16. The Integrated Application Supply Chain
    Solve for the Complete Lifecycle
    Burn rate, go/no-go metrics
    Seamless RFC capture and prioritization
    RUN
    Architectural policies & compliance
    DevOps integration for performance SLAs
    PLAN
    Project planning & tracking
    Data archival, application end-of-life
    Requirements capture & mgmt.
    DELIVER
    Development mgmt.
    RETIRE
    Functional validation
    Performance validation
    Security validation
  • 17. RUN
    SLA trends
    Break/fix volatility
    PLAN
    Cumulative spend
    Technical debt
    Age and usage
    DELIVER
    RETIRE
    A Complete View of Business Investment
    Solve for the complete lifecycle
  • 18. IT PERFORMANCE SUITE FOR APPLICATIONS
    CORE LIFECYCLE EXCELLENCE
    COMPLETE LIFECYCLE COVERAGE
    PPMC
    RUN
    SOAC
    Lifecycle Management & Automation
    Project & Portfolio Management
    Requirements
    Application Governance
    SMC
    Development Integration
    Business Availability
    Quality & Performance
    Service Management
    PLAN
    ALM11
    Security
    Archiving
    MSVS
    BAC
    QC
    IDE & SCM integration
    Eclipse
    PC
    DELIVER
    ASC
    Fortify
    RETIRE
    DBA
    CollabNet
    TRACEABILITY & INSIGHT
    UNIFIED PLATFORM
    TECHNOLOGY AGNOSTIC
    LEADERSHIP IN QUALITY
    BEST-IN-CLASS
    MODULAR
    HETEROGENEOUS
  • 19. 90% resources freed for innovation
    Saved $3.9M per year
    Cut release cycles in half
    HP HELPS DELIVER WHAT THE BUSINESS WANTS
  • 20. Why hp?
    Integrated management & automation: instead of loosely coupled point tools, HP provides a cohesive platform for lifecycle management and automation.
    Technology & methodology agnostic: broadest support for heterogeneous environments (.NET, Java, SAP, Oracle, etc.) – covers more than 70 environments. Covers traditional and Agile methods in single solution.
    Project ready, enterprise scale: whether for a team of ten, or an enterprise of tens of thousands, HP solutions offer proven configurability and scalability.
    Complete application lifecycle: no other company offers the integrated product coverage of HP to support applications from beginning to end.
  • 21. Where TO start?
  • 22. A Matter of Business Outcome
    APPLICATION LIFECYCLE MATURITY MODEL
    Level 5
    Integrated Lifecycle
    Level 4
    Cross-functional Proficiency
    • Delivery progress integrated into portfolio view (normalized, dynamic)
    • 23. Efficient DevOps connection for application deployment, security, performance
    • 24. IT as integrated “supply chain” for app. change management
    • 25. Automation across complete lifecycle
    • 26. ‘ROI ensured’
    Level 3
    Functional Excellence
    Level 2
    FunctionalCompetence
    • Program progress measured by KPI
    • 27. Inter-project sharing, reuse
    • 28. Enterprise tech. policy and automated enforcement
    • 29. Complete requirement traceability
    • 30. Automation across core lifecycle
    • 31. Integrated tool suites
    • 32. ‘ROI expectant’
    • 33. Project progress measured by KPI
    • 34. Intra-project sharing, reuse
    • 35. Inter-project tech. policy, manual enforcement
    • 36. Tools with some integration
    • 37. Regular test automation
    • 38. Quality for projects of variable-size
    • 39. ‘ROI aware’
    Level 1
    Ad hoc
    • Effort is correlated to progress
    • 40. Point tools
    • 41. Intra-project technical policy, manual enforcement
    • 42. Pockets of test automation
    • 43. Consistent quality for projects of like-size
    • 44. Delivery by heroic individual effort
    • 45. Progress is guesstimated
    • 46. No tools (management by Excel)
    • 47. No common technical policy
    • 48. Quality variable; customer as tester
  • A Matter of Business Outcome
    APPLICATION LIFECYCLE MATURITY MODEL
    Level 5
    Integrated Lifecycle
    Level 4
    Cross-functional Proficiency
    • Delivery progress integrated into portfolio view (normalized, dynamic)
    • 49. Efficient DevOps connection for application deployment, security, performance
    • 50. IT as integrated “supply chain” for app. change management
    • 51. Automation across complete lifecycle
    • 52. ‘ROI ensured’
    Level 3
    Functional Excellence
    Level 2
    FunctionalCompetence
    • Program progress measured by KPI
    • 53. Inter-project sharing, reuse
    • 54. Enterprise tech. policy and automated enforcement
    • 55. Complete requirement traceability
    • 56. Automation across core lifecycle
    • 57. Integrated tool suites
    • 58. ‘ROI expectant’
    • 59. Project progress measured by KPI
    • 60. Intra-project sharing, reuse
    • 61. Inter-project tech. policy, manual enforcement
    • 62. Tools with some integration
    • 63. Regular test automation
    • 64. Quality for projects of variable-size
    • 65. ‘ROI aware’
    Level 1
    Ad hoc
    • Effort is correlated to progress
    • 66. Point tools
    • 67. Intra-project technical policy, manual enforcement
    • 68. Pockets of test automation
    • 69. Consistent quality for projects of like-size
    Integrated portfolio
    • Delivery by heroic individual effort
    • 70. Progress is guesstimated
    • 71. No tools (management by Excel)
    • 72. No common technical policy
    • 73. Quality variable; customer as tester
    Complete lifecycle
    Excellence
    Core lifecycle
    Fundamentals
  • 74. (It’s free)
    YOU’VE SEEN THE SLIDES, NOW GET THE BOOK!
  • 75. LET’S DO AMAZING