As a business technology architect helping clients transform their applications, I sometimes feel more like a software archeologist. It is very interesting to see how heterogeneous the technology landscape is and how diverse it is being used at customers of all size and industry sector. But, there is one common question that we see throughout our engagements: “How can we transform this heritage to a future state?” and “Can you help us keep what’s important, but make it easier to manage?”.
There are many approaches on how to modernize existing, heritage applications (sometimes called “legacy”):
- COTS replacement: replace the application with a new COTS or SaaS-based product
- Rip out and rebuild: rip out the old business logic and rebuild a new custom solution from scratch
- Lift & Shift: re-host the application with little or no extension
- Symmetrical Transformation: code-to-code and data-to-data
- Asymmetrical Transformation: code-to-framework, code-to-rules engine, code-to-BI, code-to-code, …
In this post, I really want to focus on the re-architecture approach.
What does re-architecture really mean? Well, it is the idea of identifying certain artifacts like (business) functionality, rules, screens, data structures and so on from legacy source code, putting these into a platform independent model (PIM) or repository and then architecting a new solution by leveraging the information in the PIM. Based on the use case, the new solution can be architected in a symmetrical or asymmetrical way. The main difference between these two is the desire to look for patterns.
A symmetrical approach will transform legacy code into future state code. Please note that I am not talking about one-to-one code translation! I am, rather, saying that functionality implemented in source code in the heritage app will also be implemented in source code in the new solution. As an example, let’s consider a reporting function that is written in source code in heritage. The future will also implement this reporting module in source code (for whatever reason). The impact is that any and all reporting changes will require source code changes.
Asymmetrical, however, will look for patterns or suitable candidates that may not be require source code in the new solution. If we keep considering the reporting functionality from the previous example, an asymmetrical approach would re-architect this logic maybe into a reporting engine or BI tool. You can think of many more of these patterns and reporting is just an example. The core theme behind this approach is to reduce the amount of source code for a better ROI. In addition, this leads to better maintainability, less defects and increased standardization from an enterprise architecture perspective.
Let me help you with your heritage. Contact me to get moving.