The legacy system modernization trap

Government agencies have often failed at efforts to modernize their legacy systems. Even when the effort is not labeled a failure, it is expensive, time-consuming, and risky. There is a good reason for this: we should not be doing legacy system modernization projects at all.

Why not? To begin with, “modernization” is not a business goal. It does not in itself represent a business outcome that adds value to the enterprise. As a result, its scope of activities can never be clear, the business cannot feel a sense of urgency (and as a result wants to hold off releasing until the system is perfect), and good prioritization and trade-off decisions cannot be made. It is a project that is all risk and no return: there is already a functioning system, so the agency is only risking failure. A modernization effort can never end, since being up-to-date is a goal that slips away as we approach it.

Legacy modernization also does not lend itself to an agile approach – that immediately should be a give-away that something is wrong. We cannot release the modernized product incrementally, beginning with a minimally viable product, because the business will not want to use something that does not at least match the functionality of the legacy system. This means that the scope of the first release is fixed and cannot be adjusted to fit within a time box. The legacy system must be replaced in a single release.

Yet there is a way to modernize a system. The first goal should be to bring contemporary technical practices to bear on the legacy system as is. And the first step in doing that is to bring the legacy system under automated test. A wonderful reference on doing so is Working Effectively with Legacy Code by Michael Feathers. Once the system is under automated test, regressions can be avoided and the code can be restructured and refactored at will. The second step is to re-architect (as little as possible) to make re-engineering pieces of the system efficient. In many cases this will involve creating elements of a service-oriented architecture – or at least finding ways to loosely couple different pieces of the system.

Now to the real point of the exercise. We need to work from real business needs – capabilities that the system does not have. For each capability we change the system to deliver it. We do so in an agile way, and we use our automated tests to feel comfortable that we are not breaking anything. Over time, the system becomes easier to change as components are replaced by more “modern” components. But we never do anything without a good business reason to do so.

In other words, we’ve modernized our system without doing any such thing.

Advertisements

6 thoughts on “The legacy system modernization trap

  1. Kevin braybon

    Hi Mark. With – as always – scarce testing resources to stretch between agile projects, ensuring time is allocated to building these automated tests is always challenging. How can I persuade a timid stretched management to invest in this? Your advice?

    Like

    Reply
    1. markschwartz2014 Post author

      Not sure of your exact situation, but I don’t know if I’d invest in it until it is necessary – that is, until you want to make substantial changes. At that point bringing it under automated test is something you’d spend on as part of making the changes, and the case I’m making is that it will actually reduce the cost of your enhancements (and the risk), so it should be justifiable. Another idea is that as you are making small changes you put in place automated tests for those changes and for any regressions that occur. Slowly you build the automated test suite as you go. Perhaps some combination of those approaches? In any case, I think doing a “big bang” creation of automated tests with no added business value is probably the wrong approach. Hope that helps frame your thinking.

      Like

      Reply
  2. change agent

    Mark,

    Nice article. Couple of pointers – People tend to comment/hospital the test cases to get the pipeline faster. So in the end, have we achieved the stated goal? It is not enough people follow the letter of the law, they need to embrace the spirit of it as well. Also the way the gov. writes these contracts and hands them out is so insane and archaic. It doesn’t lend it self to the faster pace of the biz needs/changes.

    Like

    Reply
    1. markschwartz2014 Post author

      Thanks for the comments. I’m thinking that commenting out the test cases to make the pipeline run faster is strange – if using a testing pyramid, most of the tests should be small and should run very quickly. In any case, the tests could be divided into a group that runs on every build and a group that runs a few times a day in the background – that would be better than commenting out the tests entirely.

      As far as government contracting goes, you are right. The interesting question is whether the way the rules are set up it has to be that way, or whether we can work within the rules and still achieve agile objectives. Jury is out on that one.

      Like

      Reply
  3. StevenZ

    Mark, good read.
    Automated testing will help discover deviations of modernization effort as they occur.
    But regarding added business value…
    What if modernization effort optimizes a business process, makes it faster, easier to monitor and more reliable, without changing the business function?
    Then there is added business value in terms of higher productivity of the enterprise, although the business function remains the same.

    Like

    Reply
    1. markschwartz2014 Post author

      Agreed! Improving a business process, if there is a business case for doing so, certainly adds value. What I worry about (I’ve seen it happen) is cases where there is no sense of urgency from business stakeholders because the “modernization” is all under the covers – all technical change, no difference in what the system does. In your example, there could easily be urgency. Thanks for the comment.

      Like

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s