Optimality requires a goal.
And goals aren't the most stable of things.
For example, lets say your goal is to implement this in the quickest time, and lets for he sake of argument measure this by total hours on the clock from... hmm.. now.
So you throw up some quick design ideas:
- Duplicate the current code and modify it
- Pick an Enterprise™ platform and reimplement it in it
- Pick a language, development environment, operations platform and rewrite it.
- Hire 12 programmers to re-implement it.
Now which one is the quickest? Every second you spend now is just making the quickest solution take more time. But how to decide?
Hiring 12 programmers sounds great. After-all any solution they go with will take 11 times shorter right? Probably not, they need time to form working relationships, get used to their new tools, consider this problem from end to end (which is something you've already done), not to mention the time spent hiring which can take months.
Okay, What about a new language? Well that is going to take time to explore, to choose between various options. You are going to have to learn a few to enough skill level to be able to judge the time needed to implement something within it. Not to mention picking the programs to form the development environment. You might even need to consider how this will be deployed. Wow that is a lot of time and decisions to make before you even start writing the solution.
Surely big Enterprise™ have already solved this. Why yes I believe they have with Data Manipulation Program 234123, just pay 3 trillion dollars here and in 2.6years you can have 80% of the functionality. Hmmmmmmm....... Do you really trust that salesman.
Okay, lets do this directly. Duplicate all of those programs and rename them _2 (please don't do that, pick something meaningful). Now just change the few lines of code to get the desired functionality. Except the reason you want a better solution is probably because:
- The current code is unsupported
- You don't have the inhouse skills to do this easily
- The system probably won't meet a perform requirement once duplicated
So no that is going to take time to reunderstand someone else's thinking that was probably half-baked, highly distributed between non-communicating individuals, or in a paradigm you can't quite grasp.
Sarcasm aside, the problem isn't even that you don't have a goal. You're pretty clear about wanting to rewrite. Its that you don't appear to have your Values in order.
What you value identifies what goals you have which in turn highlights what is optimal.
For example a Business usually has conflicting values:
- Biggest bang for Buck
- We want to exist in 5 years time
In pursuit of the biggest bang for buck goal, you will value fast coding over long term coding.
In pursuit of the we want to exist in 5 years time goal, you will value clean and well managed code over quick changes.
Not saying you can't have clean well managed code that supports quick change. But you do need to know, when the chips are down, which goal, and hence which value wins. Does the change get delayed till its good? or do we rush the change out, and try to cleanup the mess while also delivering the next change?
This also applies to your question about what is the best way to handle your new functionality. What is valued?
- Does your organisation value a simple copy and extend over a rewrite?
- Does your organisation value keeping the language and tooling standard for its developers, or does it value many niche language systems?
- Does your organisation value simplifying the operational technology stack, or do they value not fixing what isn't broken?
When you know what the answers are to those questions, and questions like it. You will be able to whittle down the field of options quite drastically.