A reengineering does not always mean in everyone’s mind, rewriting our Legacy application into another language generally more recent, but it is nevertheless the option we chose.
When it is ‘only’ about reorganizing the code to make it more maintainable, but without porting it onto a new hardware or software platform – such as migrating a Mainframe Cobol application to a Unix architecture – I prefer to talk of a refactoring.
I remind you that this blog has no academic ambitions, so I will not worry about meticulously exact definitions, which lead most often on quadripilotectomic (1) discussions from specialists who have nothing else to do than gossip on any comma.
But this does not proscribe some degree of accuracy in order to avoid further misunderstandings and preconceptions. We first looked at what actions of refactoring we might consider for our legacy C application (Word 1.1a), using the plugin SQALE. Then we tried to estimate the cost of these actions and a ROI calculation.
Today I will discuss some things to take in account when considering a reengineering.
Product strategy and application lifecycle are obviously at the heart of a re-engineering plan: a software and/or hardware platform too costly or at his end of life, more and more trouble to find IT skills to maintain the application on this platform, maintenance costs too high, etc. But in any case, you want to keep the application, or the software product in the case of a software vendor, not to replace it with a software package or the development of a new application, or to put it out of the catalog for a software editor.
The preliminary step in reengineering is therefore a clear identification of the objectives.
Contrary to what one might think, a reengineering is not always a conscious goal. Of course, if your CIO is tired to see every year a salesperson announce him that:
- such software or platform will soon be deprecated AND
- he needs to purchase a new software to substitute it AND
- he will have to start an implementation project with their consultants, all as experts as expensive, AND
- the need to upgrade the IT infrastructure in order to maintain an acceptable level of performance for this new software platform AND
- new rates because of this upgrade, THEN
your CIO might consider a major technological breakthrough to put back his hand upon his IT and stop to be treated as a cash cow.
However, I have seen many cases where reengineering was not originally the objective, but has become a necessary and unavoidable choice after a series of discoveries, thoughts and decisions more or less formalized.
Reengineering and Application Portfolio
I did an assessment for a bank, or rather its Asset Management division which deals with the management of financial assets, about an application whose number of customers was supposed to be multiplied by three. Who says three times more users also says three times more data, and three times more (on average) connections to a database three times bigger. Hence a concern for performance from this bank. Their first reaction was to look for a performance and load testing tool, and then they began to wonder if it was possible to detect in the code any programming defects that could threaten the future response times.
If I remember correctly, it was a Visual Basic application, and for the usual reasons of confidentiality, they did not want me to analyze the entire code of their application. This is always a problem because the less code you have, the less defects in the code you will indentify and the more difficult to demonstrate the value you can bring.
So I proposed them to analyze a module of their application, but also to work on some J2EE and Cobol code, with a main objective focused on the identification of potential risks to the performance, and a second goal on the measurement of maintainability. They were not very much interested, I really had to insist. But when I presented the results, they were fairly impressed, and someone in the room said: « we must show that to the CIO. »
In fact, in addition to their concern for the performance of this application, the CIO also had a a serious worry about his application portfolio, which he felt was full of applications not always very critical, but often not maintainable, and without knowing where to start. We had a second meeting in which he participated, and in which we built almost ‘live’ a plan of refactoring for the Cobol application and a plan of reengineering for the Visual Basic application.
Conclusion: some use cases can lead to a refactoring or a reengineering that were not initially a goal. A tool to analyze and measure code quality is needed to know what applications of your portfolio will benefit from a reengineering, and where to start.
Reengineering of in-house software
Reengineering will sometimes be only on a small part of the application. In the 90s, with the emergence of the Client-Server and the first GUI applications, many companies developed their own middleware to ensure exchanges (asynchronous or not) between these new applications and their mainframe. A dedicated team was responsible for developing and maintaining the middleware, regularly delivering APIs and documentation that allowed its use by project teams.
The problem is that, like any application, this code accumulated technical debt, and maintenance of this tool became increasingly heavy, corrections and changes required by the projects more costly and time consuming to implement, the documentation more difficult to maintain, and knowledge of the code was lost as people went out of the team to other places or simply leaving the company. So came a time when this in-house middleware did give way to a tool like a MOM, a ESB, a EAI, or even a new architecture like SOA or EDA (2). No, do not ask me to define everything, I said at the beginning of this post that this blog was not a dictionary!
Of course, it was necessary to encapsulate this new tool into the existing APIs in order to minimize the impact on the applications using them. As the original middleware was most often programmed with a 3GL type language, but also given the enthusiasm of the team for new technologies, many of these APIs have been rewritten with Object Oriented languages.
Reengineering and user interfaces
A very common case of reengineering is related to applications with old obsolete user interfaces. This was the case of many mainframe applications with a character interface, which were migrated (not without difficulty) under Windows. There was even a time where you could find tools for generating automatically graphical interfaces from the original mainframe screens, with some comic results, although not so amusing for the end users.
The Internet bubble and the websites have caused much damage regarding compliance to the standards of graphical interface, but with the smartphone applications, we find again the necessity for these standards, although under the more modern vocable of UX (User Experience). So many applications are experiencing a reengineering of their presentation layer to be accessible both on the web and on your mobile.
Software publishers must also perform this kind of project quite frequently. An old HTML interface is a real dead burden when it comes to selling a software, which will require a relooking with a new technology: Flex or HTML5 for example.
This sometimes causes problems. Try to select one or more rows of a Flex table to make a copy/paste: users will have trouble understanding that you have adopted a newer technology that does not allow the most basic operations.
Often a software publisher will not interpret the evolution of the GUI as a reengineering operation but simply as a new version of its software with more beautiful screens. If he did, if he identified it as a clear objective of migrating to a new technology and a different GUI, he could perhaps consider the impacts to the end-users instead of waiting them to suffer these consequences when it is too late.
As we can see from the previous examples, it is important to have clear objectives and even to formalize them in order to avoid unintended consequences. Especially because these goals will condition the following question: reengineering to the equivalent, that is to say with the same functional scope, or with new features?
A reengineering is often a complex project that requires good knowledge of the original application and of the portions of code that are harder to read and understand, a good expertise of the new target platform, an accurate estimate of the current technical debt in order to proceed a proper assessment of the effort and of the planning, a minimal documentation and if possible test coverage.
As it is often the case, the project team will want to limit the risks by avoiding to introduce new features in the application. Now users will probably be very insistent on this point, since otherwise, they will not only have to wait for the reengineering to be done but also for the development of a next version that incorporates these new features.
Unfortunately for the project team, often the users will win, simply because it is usually impossible to rewrite an application without encountering technical problems, to be overcome by new processes and/or new design of some business functionalities.
For example, if you change the user interface, you probably change the data displayed on the screen. How many times have I seen, during a reengineering, multiple screens replaced by a single screen composed of multiple tabs (the syndrom of ‘I want it all and I want it now’)? Obviously, you must then change treatments to access the data layer, which can cause problems of longer response times. If it is not possible to adjust them from a technical point of view (with an upgrade of the technical infrastructure for example), then you need to ask users if it would be possible to carry out this business operation differently, in order to avoid loading so much data in the screen.
Another case to consider: a reengineering is not only on code and statements, but also on data. A new design of classes and programs will imply the corresponding changes in terms of data structures.
If a single program accesses a monster table in the database, you’ll want to cut this program and this table into entities of smallest granularity for better maintainability and probably an increased performance.
Put simply, you will take advantage of the rewriting of the application to modify some data types. Maybe the user has already asked some of these modifications that are easy to take into account, such as changing the size of a field or the precision of some figures. Or it is you who will find him to ask if he really needs a ‘comments’ field so large when it is almost never used.
So, for your reengineering project:
- Plan well the re-design of the treatments but also of the data.
- Think up changes in business processes.
- Incorporate one or more users to the project so that they are available for any question of business processing or reengineering of functions or data.
- Do not dismiss all change requests, but study well those that are likely to impact your project or that can be done easily.
And above all, always be aware of your objectives.
1. Tetrapilectomy. Neologism coined by Umberto Eco and his group of pataphysicians. Formed from the Greek prefix tetra (‘four’), from Latin pilus (“hair, hair ‘) and -ectomy(cutting, incision). The art of spliting hairs in four. Having excessive care in a futile activity.
2. MOM: Message Oriented Middleware. ESB: Enterprise Service Bus. EAI: Enterprise Application Integration. SOA: Service Oriented Architecture. EDA: Event-Driven Architecture.