We recently finished a project fully documenting a very large existing system. The ecosystem was made of about 30 applications working together and was obviously very complex. This is not unusual in large organizations. The goal of the project was to understand enough about the existing requirements of the system to completely replace the system.
This project was not unique by any means. Every Fortune 500 company that we have worked with has had a similar level of complexity in their IT systems. Here are some random thoughts about working with these very large legacy migrations.
1) Big bang migrations are incredibly difficult to make work. It is possible, but requires a lot of talented people to pull off. If you imagine that the ecosystem that you have today has had 20 years to mature with hundreds (or thousands) of small releases. In that time you can probably estimate the total number of severity one defects. Because the upgrades were released over time, the pain was spread out over 20 years. Now think about getting all that pain at once in a big bang release. It is still a challenge, but think about how you can slowly isolate and then replace pieces of applications.
2) Don’t feel bad if you are lacking in documentation. Everyone we work with seems embarrassed that they dont have much in the way of requirements, business process, design or even user documentation. What they don’t realize is that no one seems to have that documentation. I haven’t figured out if maintaining the documentation is cost effective or not, my gut says that it is.
3) The people, systems, data model that we use really is comprehensive when trying to document one of these large legacy systems. Take a look at some of the blog posts below where we discuss the models and the overall people, systems, data concept.
4) Traceability to make sure you haven’t missed anything is incredibly time consuming. The tools today are simply not sufficient. We need to be able to trace not only between requirements but between requirements and elements in visual models (flow charts, data flow diagrams etc).
5) Agile methods won’t work on these projects. In fact for most of the projects we work on lack of planning is the biggest killer to the success of the project. Agile has a role on smaller projects. But when you are trying to coordinate 20-30 developers, having written plans and a very clear and detailed understanding of what is to be built is critical.
These were just some random thoughts I had about our experiences with these huge projects. I would love to discuss this further, so see you on the messageboard.
