1 / 26

How to Write Programs That Will Last Forever Future proofing your applications

How to Write Programs That Will Last Forever Future proofing your applications. Darren Self. Space is big. Enterprise Application Facts - Size. ~200 Million lines of code. EA Facts – Scale of COBOL source. Over 310 billion lines of code in use 1.5 million new lines written per day

lei
Télécharger la présentation

How to Write Programs That Will Last Forever Future proofing your applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How to Write Programs That Will Last ForeverFuture proofing your applications Darren Self

  2. Space is big...

  3. Enterprise Application Facts - Size ~200 Million lines of code

  4. EA Facts – Scale of COBOL source • Over 310 billion lines of code in use • 1.5 million new lines written per day • 200 times more transactions each day than Google • 500 million cell phone connections per day • 60 million patient records per day • Up to 18,000 ATM transactions per minute in the UK alone

  5. EA Facts – Run the Business Retail Banking Business Intelligence Supply Chain Life Insurance/Loans Trading CC Processing CRM Billing

  6. EA Facts – Diminishing Skills • Original architects and programmers moved on • Redundancy • Retirement • Hard to train skills • Platform • Corporate standards • Often undocumented • Ingrained knowledge

  7. EA Facts – Poor understanding

  8. What drives change? • Technical • Platforms/technology evolutions • Web • Mobile • Cloud • The Y2K problem • Business priorities • Mergers & acquisitions • Emerging markets • Legislative • Sarbanes-Oxley • FRS17

  9. Options for change • Do nothing • Stagnation • High costs of maintenance • Often not a viable option • Buy off shelf • Doesn’t always meet business needs • 40% cancelled before going live • Often require substantial tailoring/integration • Rewrite • High risk/cost • 75% failure rate • Reuse

  10. 42% never delivered or very late Outright Project (Failure) Exceeded estimate by over 50% (very late) Exceeded initial estimate (late) The risks ERP Implementation Risk Factor • Implementing new packages takes years • 42% either never delivered, or more than 50% late(source: Gartner Group) • Package projects: years to implement, canceled 35% of the time & rarely fully deployed (source: Standish Group) • Most large AD projects never deliver on promise • 74% either fail, or are late and over-budget • Deactivating legacy systems is almost impossible Source: Gartner Group Package: 42% chance of failure or excessive delays Re-write: 74% chance of failure or excessive delays

  11. Case Study – Hershey Foods Magnitude of Failure • Sales fell 12% in qtr after system went live, down 150.5 million from year before • 3rd qtr profits dropped about 18.5% • Retailers and distributors forced to order from rivals • Candy sat in warehouses on eve of peak season Market Reaction • Analysts estimated Hershey could lose .5% market share ($65 million) • During a booming stock market, Hershey shares ended the year down 27% from the year high “Retail sales lagged the industry’s growth rate as a result of our shipping problems.” Kenneth L. Wolfe, Chairman, Hershey Foods Sources: USA Today, Dec. 7, 1999; CIO Magazine, June 1, 2000; Business Week Online, Sept. 2001; www.thespot4sap.com; “Top 10 Corporate Information Technology Failures”; Hershey Foods 2000 Annual Report

  12. Hershey Foods – What happened? • Candy sat in warehouses where previously it sat in shops • Issue caused by massive distribution problems following flawed implementation of a $112 million package ERP system • Inaccurate inventory data (+ other problems) caused shipment delays, incomplete orders during second half of 1999 • Seriously affected shipments to stores in peak Halloween and pre-Christmas sales periods • After investing millions, things that used to worked stopped working, resulting in financial catastrophe Source: CIO Magazine, June 1, 2000; “Top 10 Corporate Information Technology Failures”

  13. Case Study – UK Passport Agency • Impact • Processing time increased 4 fold, from 10 days to 8 weeks • Over 1 million telephone calls unanswered in 1 month alone • Lack of service forced travellersto line up outside passport offices demanding passports Magnitude of Failure • $180 million on a new passport system • Processing costs up by 30% per passport • Additional staff hired to handle the backlog • Compensation paid to thwarted travellers • New law rushed in: free 2-year passport extensions “Senior government ministers were forced to make lengthy explanations in the House of Commons... Home Secretary Jack Straw promised to move ‘heaven and earth’ to get a passport to a woman for her honeymoon.” Source: CIO Magazine, Aug. 1, 2000

  14. UK Passport Agency – What happened? • Passports which previously were being processed on time sat unprocessed • Cause was due to new system not being able to provide the throughput to process passports in appropriate timescales • Backlog of unprocessed passports reached 538,000, 1000s of vacations jeopardized • A PR nightmare -- thousands of angry travellers who lined up in rain forced agency to purchase umbrellas • Officials prioritized people into “urgent”, “non-urgent” and “awfully urgent indeed, old chap” categories • After investing millions, things that used to worked stopped working, resulting in financial catastrophe Source: CIO Magazine, Aug. 1, 2000

  15. Evolutions we’ve seen... • User Interfaces • Platform Modernisation • Globalisation • Service Oriented Architecture • The Web • Mobile Access • The Cloud

  16. Case Study – History of the ATM No screens Limited functionality

  17. Case Study – History of the ATM Buttons alongside the screen

  18. Case Study – History of the ATM Touch screens & palm scanners

  19. Case Study – History of the ATM What runs these systems? Standard desktop OS’s

  20. Case Study - ATM Reasons for change • Hardware • Connectivity • Security • Robustness • Accessibility • User expectations • Real time access • Full range of financial services • Convenience

  21. Case Study – ATM UI Considerations • User Interfaces change • Back end services remain constant • Modular • Extendable • Flexible • Robust • Secure

  22. Everlasting programs - 1 • Modular design • Easier to extend • Well defined interfaces/contracts • Reusable • Flexible

  23. Everlasting programs - 2 • Quality • Well documented • Clean design • Automated tests • Unit • Integration • Graphical • Processes • Source control • Build & delivery • Continuous integration

  24. Everlasting programs - 3 • Maintainability • Readable • Keep it simple • Don’t make assumptions • Design patterns

  25. Conclusions • Enterprise Applications are important • Underpin businesses • Run the world! • Software evolves • Evaluate the options • Beware the risks • Design for re-use • Maintainability • Simplicity • Modularity

  26. Essay Topic Reflect on the challenges encountered and strategies employed when long-lived Enterprise Applications are exposed for re-use in new environments such as the Cloud, the Web and mobile devices. You may want to consider such areas as interfacing to the existing Enterprise Application, accessing data, real-time and/or concurrent access, testing strategies and usability.

More Related