Download to read offline
Uploaded byCorecom Consulting
DevBoss May 2019 Presentation
The document outlines an event schedule focused on transforming legacy applications, featuring presentations and discussions on the need and strategies for software modernization. Led by experts in software development, the session covers topics like technical language shifts, cloud migration, and the risks of stagnation in legacy systems. Case studies highlight different transformation approaches, including gradual upgrades and complete rewrites, addressing the business goals of efficiency, security, and maintainability.
More Related Content
Similar to DevBoss May 2019 Presentation
DevBoss May 2019 Presentation
- 1.
- 2. Schedule for thisevening ● 6.00pm - Networking ● 6.30pm - Welcome and Introduction: Lewis Horwell, Corecom Consulting ● 6.40pm – Presentation from Keith Williams, Software Development Manager, IRIS Software ● 7.30pm - Buffet and Refreshments ● 8.00pm - Group Discussions ● 8.30pm - Refreshments and networking www.corecomconsulting.co.uk
- 3.
- 4. Hi, I’m Keith! •Development Manager for Cascade HR • Currently modernising Cascade • Long history of creating legacy messes https://www.iris.co.uk https://www.cascadehr.co.uk
- 7. Agenda Why transform? How totransform? Case studies
- 8. What is transformation? Technical Languageshift New architecture Cleanup Infrastructure Hosted to cloud Desktop to web Web to app Product Bespoke to SaaS Feature pivot UX revamp
- 9. Examples • Rewrote fromJSP to Angular • Upgraded to .NET Core • Moved from desktop to the web • Replaced Access with SQL Server • Migrated to the Cloud • Moved to hosted SaaS model
- 10.
- 11. WHY? What is legacysoftware, and why do we need to transform it?
- 12.
- 13. Commercial reasons App is End-of-Life Regulatory environment Costdoesn’t justify benefits
- 14. Bad technical reasons Following the latest fad Developerego Lack of interest in the business
- 15.
- 16. Reasons to transform RecruitmentRetention Security Performance Productivity Maintainability Operability Features
- 17. The risks ofNOT changing STAGNATION CULTURE COMPETITION
- 18. HOW? Strategies forlegacy transformation
- 19.
- 20. Clear the dead wood •Marie Kondo your codebase • If it never went live, it’s going in the bin • Break up mono-repositories if possible • Aggressively target code “noise”
- 21. Find some edges •Utility apps, customer portals, mobile sites • Split off, refactor • Choose the smallest one, try a rewrite • Proving ground for new tooling
- 22.
- 23.
- 24. Do the maintenance •Upgrade dependencies • Remove dead code • Refresh styles • Pay down technical debt
- 25. Trade-offs PRO • Low up-frontcost • Keep the lights on • No customer migration • Deliver as BAU • Quick returns CON • Core tech debt remains • Can’t fix a broken model • Still the same tech • Still the same app
- 26. Case study: UltimateManager • ASP.NET WebForms application • Rotting since 2010 • Upgrade to .NET 4.7 • Update all dependencies • Lift-and-shift to Azure PaaS • 3 months to market
- 27. If the techisn’t that bad, and the app is stable, maybe it just needs some TLC
- 28.
- 29. Side-by-side • Plan andbuild a new architecture • Start writing side-by-side • Small, incremental deliveries • Slowly “strangle” the legacy app • Maintain backwards compatibility
- 30. Trade-offs PRO • No impacton users • Iterative improvement • Continual feedback • No customer migrations • Clean new architecture CON • Can’t fix a broken model • Can’t fix broken data • Compromise for compatibility • Split dev resources • Two codebases to maintain
- 31. Case study: Cascade“Novo” • Classic ASP/ASP.NET WebForms app • 2.7 million LoC • New ASP.NET Core + Angular app • Modern service-based architecture • Dependency on common database • 6 months to EA, 12 to market
- 32. If the techis bad, but the data is sound, make a new view of the data
- 33.
- 34. Nuke the sitefrom orbit • File New Project • New model, new architecture, new code • One big upgrade, no going back • Reimagine product from ground up
- 35. Trade-offs PRO • Clean newarchitecture • New model to suit business • Easier to recruit developers • Faster than Strangler CON • Long wait for pay-off • Must migrate customers • Must admit old app is EOL • Split dev resource • Legacy distractions • Easy to underestimate • Risk of solving old problems
- 36. Case study: Sunrise •ODIN: Classic ASP/COM app, 1 million LoC • Sunrise: Ground-up rewrite, no shared code or data • Migrate existing customers one by one • ASP.NET MVC + Azure PaaS architecture • 3 years to market
- 37. If the techis bad, and the app doesn’t suit the business, you might as well re- write it from scratch
- 38.
- 39.
- 40.
- 41. “How do youtransition Senior Engineers into leadership roles?” www.corecomconsulting.co.uk Discussion 1:
- 42. “What are thebest approaches to gain buy-in for change?” www.corecomconsulting.co.uk Discussion 2:
- 43. “When working inan agile environment, how do you avoid too many meetings and not enough coding?” www.corecomconsulting.co.uk Discussion 3:
- 44.
Editor's Notes
- #5 Hi - I'm Keith, and I'd like to start with a confession: During my 16 years in this industry, I have created many, many legacy applications I've build PHP monstrosities and Access nightmares. Even the apps that I thought were cool and cutting edge in 2006 are now clunky WebForms and WCF graveyards. The tech that I advocated as new and exciting in 2010 is now just so much technical debt that will never be paid down.
- #14 First, let's look at when you might NOT want to transform an app