Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Business agility and legacy applications

Business agility and legacy applications

Presentation at Agile Business Day 2017

Matteo Vaccari

September 06, 2017
Tweet

More Decks by Matteo Vaccari

Other Decks in Technology

Transcript

  1. BUSINESS AGILITY
    AND LEGACY APPLICATIONS
    Matteo Vaccari
    @xpmatteo

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. So… how do I
    refactor
    legacy code?

    View full-size slide

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

    View full-size slide

  12. Can I rewrite my legacy app then?

    View full-size 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 full-size 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 full-size slide

  15. 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 full-size slide

  16. Strangler app
    antipatterns

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  19. 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 full-size slide

  20. 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 full-size slide

  21. 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 full-size slide

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

    View full-size slide