There is a lot of talk about legacy modernization. Most of the conversations I hear from my clients center on whether to modernize a legacy system, or which applications to modernize. However, engineers, developers, and software architects are often more concerned about the “how” of the modernization journey. It made me think about Shakespeare’s Hamlet, in which the Prince of Denmark, Hamlet, pondered a lot about “what” and “whether”, but seemed to have neglected the “how”.
Merging Redundant Software Functionality
What is IT modernization to you? Replatforming, refactoring, or replacing? Maybe, cloud migration? The least talked about, but perhaps the most common, most complex, and, the most impactful form of legacy modernization is the merging of redundant software systems.
One of my fintech clients considered merging several systems as a form of modernization, because it gave them the chance to take advantage of the latest technology within the target platform (the most modern of 5 different systems), and because it simplified the overall technology landscape -- both are common drivers for modernization, and both can result in significant returns on investment.
Merging legacy systems is difficult. First, you have to find the redundant software functionality. Then, you have to decide which systems to sunset, and where to migrate this functionality to. Don’t forget the human aspect, both users and developers who have become attached to the legacy systems you’re planning to sunset.
Seeking Proof of the “What”
The first step in a merging project usually starts with some hypotheses, someone suspects or “knows” there is redundant software functionality between two systems. Validating this is important. We can learn a lot from Hamlet about seeking proof. He was a persistent validator. While trying to get to the bottom of his father’s death, Hamlet confirmed and reconfirmed his theories before deciding to act.
As IT professionals, we should also be relentless in seeking proof of the “what”. We may hear murmurs from business users or teams in different time zones talking about redundant software functionality, but, like the second hand information Hamlet heard from his trusted friend, Horatio, it needs to be verified.
But sometimes, simply having corroborating testimony is not enough. Since Hamlet’s corroborating witness was the ghost of his dead father, he needed more validation. In fact, to be 100% sure of what he heard, Hamlet staged a play that mimicked the circumstances of his father’s death so he can observe the reaction of the suspected murderer.
It is prudent, and, often, necessary to conduct some kind of experiment to re-confirm the confirmed. Prior to a merge, you need to be absolutely certain that both the users and the business will benefit. Whether this is done via a focus group, prototypes, surveys, or time studies is up to you.
To Merge or Not to Merge Redundant Software Functionality, That is the Question
Now that you’ve established that there is redundant software, and there are two or more systems identified as candidates, you need to analyze the upsides and downsides of merging the systems.
While most people see Hamlet’s “To be or not to be” soliloquy as a literary marvel, I see a cost-benefit analysis. He actually makes two lists: one in which he itemizes the benefits and the other, the downsides of being alive.
In one of my projects, the merging of systems allowed my client to consolidate maintenance and enhancements through a single code base, which is easier and logarithmically cheaper. However, localized workflow and regulatory nuances require a new architectural layer to give the system flexibility that the different geographic regions have developed on their own over time. Not to mention, because the project will require different (and, possibly, disgruntled) teams to work together, it will be a coordination nightmare, and obscenely expensive.
But, Hamlet warns us, don’t fall into analysis paralysis. A LexisNexus survey of 1,700 workers around the globe spend more than half of their time receiving information, rather than working. Too much pondering, Hamlet says (I’m paraphrasing), gets in the way of action. So let’s get on with it!
“How”: Hamlet Falls Apart
So, this is where I advise you to stop following Hamlet’s approach to software modernization (or anything, for that matter). While he is great at analyzing, he never figures out the best way to execute.
I have seen this. Opportunities for modernization missed, because organizations have as much self-doubt as Hamlet: “we don’t have a perfect plan”, or “we need to wait until we stabilize the latest release”. Whatever the reason, the right moment never seemed to present itself, until the CIO finds some leftover budget at the end of the year, and decides to pull the trigger on the project with anemic funding.
In Hamlet’s case, too many missed opportunities and too much self-doubt caused him to accidentally kill the father of his love interest, instead of the true culprit.
Get Architectural Visibility (Look behind the Tapestry) - Inventorize all software functionality
While IT leaders should not overanalyze, there could be key pieces of information missing for the team to properly execute the merging of several systems. Teams without proper visibility and a great architectural design will not only end up missing the primary objective of merging the systems, but inadvertently damage user satisfaction.
Hamlet accidentally killed the wrong person, because he thought it was the murderer of his father hiding behind a tapestry. He stabbed wildly at the tapestry only to find that he made an irrevocable mistake.
To design a bullet proof (or Hamlet-proof) plan for your application merging project, you must have visibility. First, you need an inventory of all functionality. Now, if you asked your users to list all the functionalities in an application, you’ll probably get blank stares (just like when Hamlet speaks to the skull of poor Yorick). It’s not that your users are dense. It’s because that’s an unrealistic starting point.
Identify Functional Communities: Give your Redundant Software Merge Project a Jump Start
The concept of functional communities (otherwise known as “semantic clustering”) has been floating around the industry for possibly over a decade. A functional community is a set of interrelated objects (e.g. methods, stored procedures, database columns, etc.) that act together to deliver a single centralized function (e.g. manage a user’s data access rights, or generate analytics reports). Now, by tracing the links between objects and data, and then mapping it visually can give you clear guides on how many communities you have in one application. Users and business stakeholders can easily name these communities after you describe to them what they are technically doing.
Repeat this process for all the applications you have to merge, and all of a sudden, you have an objective comparison of functionalities between your systems. Further, when it comes time to merge, you will be able to quickly flip between the source of the different applications via these functional communities to make sure that you don’t miss anything during the rewrite.
Figure 1 - Representation of Similar Functional Communities in Two Different Applications
Easier said than done. But, with the help of software blueprinting solutions, like CAST Imaging creating a roadmap for merging redundant software functionality during legacy modernization become much easier. So, don’t be like Hamlet stabbing blindly at a tapestry. Look behind it, and then choose your action!
Interested in learning more about how CAST Imaging can help with merging redundant software functionality in your legacy modernization program? Connect with our architecture experts and schedule a walk thru.
SHARE