Use fixed width files instead... along with a good old COBOL copybook. Nothing beats parsing fixed width records performance-wise. You can auto-generate staging and persistence tables, ETL jobs and quality control with just the copybook as input.
VISA (or Mastercard) do not 'run on top of' SWIFT. The net position of each VISA/MC institution will be transferred with SWIFT, but this is one payment with potentially millions of underlying card transactions.
I work in a product role at a mid-size enterprise. I'm happy to involve anyone and everybody in high-level product discussions. But in order to do that you actually need some kind of insight into the business you're actually working for.
How will the customers buy the product? Is this kind of signup suitable for our demographic? How will component Y delivered by ASP vendor X in the value chain be impacted if we do Z? How much money will we (roughly) make for each customer? What will be the total profit potential given N percent of our target customers sign up? Is this initiative significant or insignificant for our business? Is it regulatory compliance or a major new business?
The developer response is (unfortunately) very often a major discussion along the lines of "this should be a lambda function", "no, this should run in our k8 cluster" or "we should migrate the app we just built last year to some fancy new technology I just read about on Hacker News, then we can build this in no time".
Sorry, but that's acting like a craftsman. Acting like a craftsman gets you treated like a craftsman. Management (or I) don't care about serverless or Azure or AWS. And when you don't understand basic business priorities I won't trust the "agile developer" using a three hours fixing a pixel alignment issue on a non-standard Android Phone on the least visited "compliance only" webpage.
I vividly remind a session where one of our SVPs talked about the main business problems and plans for almost one hour in an all-department meeting. One front-end developer raised his hand and excused the slow rate of change of change at a certain (and important) application with "it was built with jquery and no one has touched it since 2014".
The exceptions are (we are not Google) rare and very valuable - which is why they often are promoted. In my experience business intelligence, backend developers and database people are most "business aligned" or "business focused". Front-end developers at the other end.
I'd argue that it's acting like an engineer not a craftsman.
Either way, I'd be thrilled to be treated like an engineer/craftsman. That would be a big step up from "interchangeable cog".
Also, I'm not clear on what's wrong with "it was built with jquery and no one has touched it since 2014". The fact that the system is built using an archaic technology, that technology is inferior to current technology, and the engineers are not familiar with the code base is completely relevant to how long it will take to make changes.
I agree, I think it’s an alternative to answering your SVP with:
“You remember how our entire team left last year because they were fed up? Those were all the people with knowledge of the system.
You also remember how you gave us a budget of 50k to hire replacements? Well, we used it on one developer, and he’s left university this year, so doesn’t even know what jQuery is, much less how to work on that system.
That’s why changes are slow.”
Much preferable to not shame him like that and just summarize it as “It was built 4 years ago with jQuery.”
The problem is that statement is completely ignorant of the audience. An engineer might understand "jquery" as an explanation for slow delivery speed, but it is not the right explanation for the standard exec (notice that you inferred a lot of information from that statement that someone unfamiliar with front-end technology would not).
What the exec needs to hear is "this is built on out-of-date technology that is slowing us down and to fix that we need to be given time to migrate the application to a modern technology".
Problem + proposed solution + no irrelevant details like the name of the technology.
