Have you heard of legacy applications being discarded even when there are paying customers, purely because they cannot be maintained any more?
This “end of technical life” is painful for any company, because you are leaving money on the table. (Contrast that with “end of business life” where your application is obsolete and no one wants to use it.)
It is commonly estimated that 85% of the cost is during software maintenance phase (with only 15% in the development phase). It is not constant during the life of the software, but keeps growing — primarily because of two events:
- You change the functionality of the software. This disturbs the codebase. Some times the design gets compromised and heterogeneity gets introduced. Now there is more effort needed to maintain this larger / heterogeneous code base.
- The programmers who maintain the application change. The older programmers know more about the code base, and the newer programmers have to start from scratch. The larger the code base (and more ill-designed) the more is the learning curve, and more is the risk that some other place would break when a change is made. The need of testing effort goes up.
Both these kinds of events are inevitable over the life of the software. The maintenance effort keeps ever-increasing exponentially till the software gets discarded. The end of technical life is the point where it is no more possible or feasible to support the software.
Re-engineering of the software, possibly to a modern architecture, is a common solution to this. Of course, when a monolythic application (single, large code base) is re-engineered into another monolythic application, then sooner or later it is bound to get into the same issues. Re-engineering the application to a distributed architecture such as microservices is seen as a better alternative because the former single codebase is broken up into a number of smaller code bases that can be maintained separately.
The Solution: Re-engineer to Xsemble
Acism specializes in the use of Xsemble. Xsemble looks at an application as the assembly of individual components.
These components are tiny, a lot tinier than microservices. We call them the molecules of software. To give you an idea of the scale, consider that while a monolythic application may be broken into five or six micro-services, the same application may be broken into hundreds of components. The other major difference is that while microservices are individual programs which communicate using standard inter-process communication mechanisms (such as web services, REST API), the Xsemble components collaborate within a single process, the overheads of communication being negligible.
Re-engineering a monolythic application into hundreds of tiny Xsemble components achieves a very high maintainability. The programmers keep working on one component at a time. The events where the maintainability gets low in conventional approach are dealt with very easily:
- When you change the functionality of the software, that essentially would translate into changes to a few components, may be addition or deletions of a couple of components. What is important is that the rest of the code remains inconsequential. The code complexity at component level still remains low.
- Even when the programmers that maintain the application change, that is not highly significant. The new programmer is going to handle individual components on an as-needed basis, and the learning curve before being productive is almost non-existent.
As a sum total of this, your maintenance effort will remain almost flat throughout the life of the software. In theory, there is no reason to reach the end of technical life, so you keep making money out of the software as long as there are paying customers.
Acism offers consultancy services for migrating existing applications to Xsemble. Since Xsemble supports Java technology, it is specially beneficial if the original legacy application is in Java too, as some code could be copy-pasted. We have also identified tools and the procedure that can be used in this migration activity.
The classic approach to re-engineering is summed up in the geeksforgeeks course of Software Engineering.
However, a big bang approach rarely works for re-engineering, especially where the operand is a large and complex application that is already in operation, which is often the case. We therefore recommend using the Strangler pattern (also called as the Strangler Fig pattern), where you replace the old system part by part for most cases. The benefits of this patterns are explained well in a freecodecamp article. Some more practical considerations, especially when re-engineering a legacy application to microservices, are covered in Michiel Rook’s blog.
There are some rare cases where one could still go for the big bang approach. Case in point is with a partially completed application which is not yet been used in practice. The application is not well tested, and there are reasons to suspect its workmanship. Such kind of application is better ported to Xsemble and be made available in one go, so that one does not have to duplicate the testing and bug fixing effort.
Many legacy applications are a pain to maintain or to enhance. Migrating them to the Xsemble platform would yield a great ROI, by helping reduce further costs drastically. It would also increase product life.