Acism specializes in re-engineering existing applications to the Xsemble architecture. This gives them benefits such as ease of maintenance and longer shelf life.
Modern software systems grow in terms of size and complexity over time. The exact functioning of the application, as well as many other critical parameters are lost inside the ever-growing codebase.
The inevitable shuffle of programmers complicates the matter further. A programmer on the team retains tacit knowledge about the application. When they leave, a new programmer easily takes a few months to be productive.
High code complexity mandates that all the team members be highly skilled and mature throughout the life of the software. It is hard for any company to ensure that. The software then becomes patchy, bulky and unmaintainable quickly.
The maintenance effort keeps growing till a point that the software can no longer be maintained. The software re-engineering is a must before this happens.
The Xsemble Path
An application made with Xsemble is much easier to maintain and enhance, for the following reasons:
- Errors can usually be traced at component level before involving a programmer. The modular nature of the application, the X-flowchart and Xsemble’s monitoring facility can aid in this. Now the programmer’s efforts can be focused only on fixing the erring component.
- Feature enhancements can be planned at the design level. X-flowchart enables different stakeholders to collaborate. At the end of this activity, the few components that get added or modified are already identified. The programming effort is then focused only on these components.
- At the component level, the coding complexity that a programmer faces is low, no matter the size and complexity of the application. In fact, it is orders of magnitudes lower than looking at the whole application code. This is a huge gain. Even a new programmer is able to quickly understand and fix a component code.
Thus, over the years, even while the people change, the application stays easy to maintain and enhance. The maintenance effort therefore stays almost flat, as depicted below.
Re-engineering to Xsemble
With reference to the above schematic, re-engineering an application to Xsemble can be seen as the process of making the application from the red trajectory to the blue trajectory. It is a one time effort, meant to impart your application the ease of maintainability and enhance-ability.
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.
The steps to re-engineer a legacy application are:
- Assess Modernization Needs: Often, the needs to upgrade technology and features are combined with the need for re-engineering. The re-engineering effort is expected to deliver on those aspects too.
- Design: Xsemble components are identified and X-flowchart is created in this step. Often, when the legacy application follows a specific framework, then the code structure gives clues to help one in identifying components.
- Generate Code Templates: Code templates for the identified components are generated using Xsemble, and the component dependencies are then set.
- Add Business Logic: Add the business logic code within these component code templates. If the coding language is the same, this a good amount of coding effort may be saved, as you could take the code from the legacy application.
- Burn and Test: Burn the application and test it for correctness.