During my 30 years in the industry of software development, I’ve witnessed one project after another failing in replacing an existing system. When the project for once is put into operation, replacing an old system, the budget has been exceeded and the project is remarkably delayed compared to the original plan. A better way to replace old technical solutions with modern ones, which is usually the purpose of these projects, must be found.
The recurring pattern I’ve noticed over the years, is how the new system is developed in a new project. This way, the resources are guaranteed time for this prioritized project. Otherwise, the resources will most possibly be enrolled in the support and development of the existing project. Development and support of the current system is usually necessary until the new one can take over.
The arising issues can be of several types, generally a combination of the following:
- The company does not succeed in allocating resources for the new project.
- Solely recently employed staff are able to get away from other projects.
- Critical resources are torn between the different projects, struggling to find time.
- The complexity of the old system is underrated.
- The old system is still undergoing a fast-paced development.
- The domain expertise is limited.
I won’t go deeper into these problematic areas, simply stating that the new project can’t keep up with the old one. After a number of years, the company realize they must continue developing the existing system, thereby failing in utilizing the anticipated advantages of new technology.
One example are all systems still running on the VAX/VMS operating system, which was popular developing systems for during the 80’s and 90’s. These systems become harder and harder to find hardware for, nevertheless many companies still won’t replace their old systems as long as the existing systems do what they should.
The largest project in this category that comes to my mind, is Telia and Ericsson’s AXE-N project (not really sure about the name) to replace the existing AXE-stations. As I recall it, the project was discontinued after multitude hours of work.
The latest ten years we have gradually abandoned the Waterfall model for the Agile project manner. Pros and cons can be discussed between these methods. Usually there are arguments outweighing one or the other in every certain project, although I personally advocate the Agile method as a basis for all system development.
Where is the corresponding new thinking when it comes to managing project aiming to replace an existing system? Which processes and methods should be used when planning and implementing a technical platform update of an existing system? What does the “agile” solution for these types of projects look like?
My first attempt is to conduct the transformation as a part of the development of the existing system. So, what does this mean compared to launching a new project? The advantages are, according to me:
- We have domain expertise.
- Long and short-term considerations must be taken within the project.
- Critical resources can focus on one task at a time, since the whole project follows the same priority.
- There is a knowledge concerning the technical solutions, also they are all tested.
Disadvantages are:
- The project might give lower priority to long-term activities for the sake of short-term benefits.
- Due to the project not starting from scratch, the development is restricted by the existing project.
Now don’t be mislead by the majority of benefits. The two disadvantages can, and probably are, remarkably difficult to handle and will require a great deal from the project.
How will the project enable a progress in the technological development?
- There must be a steering group, clearly stating the priorities. Articulate straight forwards objectives, preferably with impetus for every single employee. Such as a bonus, a personal development etc. when reaching the goal.
- The estimation of costs for development of the existing system must include the consequences of a delay of new technical solutions.
- Activities for exchanging components of the existing system must be available. For instance introducing an interface between different components, implementation of test automation etc.
- All alterations are regularly integrated, at least once for every iteration. The project must not diverge into two separated systems. It’s not one system replacing another, it’s the existing one developing in the right direction.
With this in mind, the conclusion can easily be drawn that the existing system should have been implemented so that further development would go smoother. Then again, it is always difficult to foresee what modernizations, if any, will be required during the lifetime of the system. Durings the 80’s, the systems were customarily built with reusable components, modularized etc. My personal experience from this strategy involves putting the system into operation way too late, as well as a waste of resources. A consequence from the difficulty of foreseeing alterations, making it impossible to take the “possibly useful in the future” investments into account.
In the end, we always come back to the fundamental problem: a self-inflicted technical debt in the developed systems. It can be anything from minor issues such as correct mishandling in an odd case, to not changing technical solutions until it’s absolutely necessary. Cultivating the existing system includes continuous investments, even when it might seem unnecessary. Otherwise, the system will sooner or later become too troublesome to modernize.