I wanted to pause a bit and reflect on a macro issue within IT. Larger organizations have several legacy systems in need of modernization. In particular, these organizations are finding many of their systems aren’t capable of supporting the new approaches of continuous delivery and cloud deployments for the digital economy. What got us to this point?
Before we dive into that, while these systems can be modernized, this almost always requires significant investment. A modernization effort is usually done as a project of some kind that includes a cut-over date that may overlap with the original system, meaning for a period of time both systems are operational (which is costly). Even when Agile approaches are used, the cut-over is usually done with a big bang, increasing the likelihood of failure with its intended userbase (that probably) hasn’t been heavily involved. Rollout strategies and change management become increasingly important as the application that a small audience has been reviewing and providing feedback gets pushed to its larger user base.
And let’s not forget data migration! We’ll need to do that as well. And heaven forbid this gets perceived too differently from what the original system did that would totally erode confidence. And are we sure we’ve designed the best user experience for this application since we never got actual usage feedback or performed A/B testing? And the team to do all those changes: big! And then… We’ll drop this on a smaller maintenance team right?
This kind of thinking can unnecessarily burden your budgeting process. You can read more about that in a previous post.
So how did we get here? By thinking in terms of projects as opposed to products.
Project life-cycles are used for the modernization/replace – maintained with a little effort type of mentality. Every enhancement request may get some scrutiny and have it deferred until a later point. This increases release size, and thus roll-out strategies.
Product life-cycles on the other hand tend to have a ‘forever’ view. A product is continually assessed as to whether it meets a customer’s need and adds value. This then results in a continuous adaption of the product’s features with re-prioritization and elaboration as needed. The product’s technologies is also continuously evaluated, perhaps in conjunction with a technology radar such as this one for dotnet technologies. The result is one of continuous modernization rather than big bang legacy modernizations.
With this change from project to product thinking, maintenance costs as well as the larger migration costs become associated with smaller continuous changes. This will likely move to a constant longer-term team size that will be somewhere between the smaller maintenance team and larger than the legacy modernization team. This team will also include the role of product manager and will continuously update the application features and technologies with the determination that when the product no longer produces useful value, the product will sunset and the team members will move onto something else. This may or may not be cheaper. However, it will have the distinct advantages of lowering risk, taking in real user feedback, and by holding to a constant team size, the budget will be easier to calculate and you won’t have a brain drain after each release.
So where are you now? If you are on the road to modernizing a legacy system, don’t stop. Most likely you have wound up a bit boxed in and are forced to do this change. Just be cognizant though how you go about doing this modernization so that you establish a means for making smaller more continuous changes. Consider applying the Mikado Method along with Kanban as you make this update. For further information you can read an independent take of my SATURN’15 presentation. You can also find the slide deck here – be sure to download the slides as they contain useful animations.