Reengineering Activities: Well Begun Is Half Done

Having acquired expertise in reengineering enterprise software systems, I want to share what I believe to be the main points that allow us to make projects successful.

There are a number of risks from clumsy solutions when changing software. That is why I think that preparing for the project is one of the most responsible stages of the process.

First of all, there are no grounds for reengineering if there is no need for it. If the software system works efficiently, without complaints about its performance, stability or reliability, why should anything be changed? I would like to point out four possible reasons to consider when thinking about starting a reengineering project:

1. Obsolete technologies used – If the technologies are not supported anymore, it is impossible to fix most of the problems. Moreover, it may be difficult to find people able to maintain such a system. Also, obsolete technologies may cause the rest of the problems listed.
2. Note: If the technologies used are supported, you can regularly update versions of the libraries and tools (databases, cache tools, application server, etc.). These actions let us avoid reengineering or reduce the costs of this process.
3. Low performance – I wrote about performance problems. Performance is often evaluated subjectively, but it should be measured. Performance testing is used to measure and determine whether this problem really exists and where the bottlenecks are.
4. Note: When the system is being developed, tools for metrics and profiling should be included in the package. This way we can gather performance indicators of the system.
5. Unstable software – A system like this periodically crashes which may cause data loss. Working with unstable software is inconvenient and annoying.
6. Note: While developing and maintaining the software, code reviewing practice would help improve code quality and, as a result, reduce the risk of system crashes.
7. Wish for the newest technologies – Sometimes the software owner wants to benefit from modern features and trends which the technologies used can’t handle. Then, even if the technologies are not obsolete, they may be replaced with the newest.

If any of these problems require immediate attention, reengineering may be up for discussion. To have a constructive discussion, a detailed technical and business analysis of the software system is required. The results of this analysis should include the following:

• Formulation and metrics of the existing problem(s);
• Ways (methods, resources and technologies) to solve the problem(s);
• Expected outcomes;
• Possible risks identification and evaluation;
• Estimating cost and time.

One important note: When analyzing resources and technologies to solve the problem(s), only prospective ones should be selected. Otherwise, you risk finding out that they’re obsolete before the revamped system is released.

Incomplete or inefficient analysis may result in a complete failure of reengineering. On the other hand, well begun is half done: comprehensive and responsible analysis done by experts can guarantee thought-out solutions, although the success of the project depends on every stage of the process.