Business agility and legacy applications

Presentation at Agile Business Day 2017

Transcript

1. BUSINESS AGILITY
   AND LEGACY APPLICATIONS
   Matteo Vaccari
   @xpmatteo
   

   View Slide

2. We will buy your software!
   …if you implement X, Y and Z
   

   View Slide

3. …The ability to change quickly and cheaply
   What is business agility?
   3
   TURN ON A DIME…
   FOR A DIME
   Craig Larman
   

   View Slide

4. …Business agility depends on software agility
   Unfortunately…
   4
   

   View Slide

5. Most valuable software is
   hard to change
   • It’s a tangle of IFs. It can only be changed by adding more
   IFs, thus making the situation worse.
   • Depends on a legacy DB, accessed by many apps and
   nobody is sure anymore what all the tables and columns
   are for.
   • Has a tangle of configuration options, and nobody is sure
   of which combination of options work correctly together.
   • Or worse, there are many forks, one per customer, and it
   is hell to backport new features to all forks
   

   View Slide

6. What does “easy to change” look like?
   6
   

   View Slide

7. What does “easy to change” look like?
   … it is SIMPLE
   7
   

   View Slide

8. What does “easy to change” look like?
   … it is SIMPLE
   8
   

   View Slide

9. Ideally, we’d like to be able to…
   implement new features in new files
   9
   …without touching existing files
   

   View Slide

10. So… how do I
    refactor
    legacy code?
    

    View Slide

11. So… how do I
    refactor
    legacy code?
    YOU CAN’T.
    

    View Slide

12. Can I rewrite my legacy app then?
    

    View Slide

13. Can I rewrite my legacy app then?
    • Stop all new developments
    • Wait for 12-24 months
    • On day X we replace the old app
    • And voilà: it works
    

    View Slide

14. Can I rewrite my legacy app then?
    • Stop all new developments
    • Wait for 12-24 months
    • On day X we replace the old app
    • And voilà: it works
    

    View Slide

15. View Slide

16. Strangler application
    Database
    nuovo
    App Nuova
    Database
    legacy
    App Legacy
    Batch Sync
    Utenti
    Apache
    Perl filter
    Utenti migrati Utenti non migrati
    Router
    Old and new
    apps
    Update
    mechanism
    

    View Slide

17. Strangler app
    antipatterns
    

    View Slide

18. The router is inside the
    legacy app
    BAD
    ⇒ have a separate
    router component
    Old App New App
    Batch
    sync
    

    View Slide

19. Sharing the same VM
    Old App New App
    ⇒ old and new should not
    share any resources
    BAD
    

    View Slide

20. The update mechanism
    is a new API
    in the old app
    Update
    Mechanism
    Old App New App
    Router
    ⇒ implement the
    update mechanism
    as a separate component
    BAD
    

    View Slide

21. The update
    mechanism is a
    separate component
    GOOD
    The old app
    is not aware
    of the new app
    Old App New App
    Router
    Update
    

    View Slide

22. The new app and the legacy
    should not be aware of each other!
    • Reduced need to involve the developers of the
    legacy
    • Reduced risk to break the legacy
    • You can start, test and change the new app on
    the developer machine, with no need to start or
    connect to the legacy
    So that strangulation is faster, safer and cheaper
    

    View Slide

23. twitter.com/xpmatteo
    thoughtworks.com
    THANK YOU
    WE ARE HIRING!
    YES, IN ITALY!
    

    View Slide