When Software Reengineering Is Recommended

| Vasyl Soloshchuk

Reengineering Recommended

Reengineering is not just a fashionable topic, it’s a required measure for some companies to revive their business software. But because reengineering is expensive, not every company is ready to take that step. A company may assume that maintaining the existing working software is justified and doesn’t require any extra work. Sometimes, a company using business software just doesn’t consider the need to renew it or make any changes.

When our company receives a request to maintain an enterprise software system, we first examine and analyze it. If the results show the expediency of providing reengineering instead of maintaining the system, we tell our client about the results and our recommendations, so that the client can make an informed decision.

I want to show an example of a software system that was supposed to be maintained, but based on our recommendations the client decided to reengineer it.

The client approached us to maintain an Enterprise Knowledge Management System and we started by analyzing it and found the following problems:

  • Java 5, used when the system had been developed, had few features, was slow and was not supported. Consequently, further system enhancements were limited. If translated to Java 7, these problems could be solved: the source code quality would be improved, performance would increase and memory use could be optimized because of performance improvements in core platform, extensions to JVM, improved libraries and better support. When upgrading the Java version, new issues could arise related to a huge amount of code and the need to save the system’s efficiency.
  • The model of working with data was inefficient. Changing the database structure could cause system breakdown. However, if optimized by addressing the database and logic of data manipulations, the system’s performance could improve.
  • The technologies that were used made system maintenance and further development complicated. If the obsolete and low productive client and server libraries could be removed, DHTMLX updated, Spring framework, Ehcache, Apache Maven and Apache Shiro used, then a background would appear for easier system development and maintenance, data consistency, increased performance, system scalability and security.

We re-presented a list of recommendations which included these and other issues. The client accepted the fact that system reengineering would be required. You can find more details of our work in the Case Study: Enterprise Knowledge Management System Reengineering.

There’s one more example. We had been maintaining a Remote Device Management system for several years. The source code, being tangled from the very beginning, became a real obstacle to further enhancements. Besides that, the system architecture having been created several years ago showed poor code decoupling. Therefore, we analyzed the existing system and presented our arguments for its reengineering to the client. Among others, I would like to highlight the following issues:

  • The complex system architecture required a considerable amount of time to provide enhancements and find all the bugs. Migrating to the Spring framework, compared to using EJB, would make it easy to work with the persistence layer using Spring Data. Spring Integration would improve work with distributed systems and adding protocols for managing remote devices.
  • In this system, using a relational database caused the need for a large number of queries to obtain the required data. Using a document-oriented database (i.e., MongoDB) would allow us to optimize the data storage scheme and provide better performance. At this point the need for a large amount of disk space becomes apparent, though using cloud technologies solves this problem.
  • The GUI had a lack of usability. RichFaces, more accurately its outdated version, had poor look and feel and was hard to support. Replacing the server-side framework with client-side frameworks (AngularJS and Bootstrap) would reduce server and network loads and allow to create a more flexible and scalable GUI. Replacing the framework and creating a new GUI would be a cost-effective alternative to improving the existing GUI in an updated version of RichFaces.

Currently, we provide reengineering for a Remote Device Management system and at the same time support the existing old version until all users integrate with the new release.

Maintaining an existing system is an important stage of the software system lifecycle. Over time the software gets older, the technologies used become outdated, maintenance problems and costs grow and business processes change. Then, reengineering is on the agenda. Reengineering will boost a software system’s longevity and help avoid new development costs.