3 ms·

Most if not all such managers (I always look for explanations in these cases that are not ascribed to an abstract business entity, but to individual people) hav

Most if not all such managers (I always look for explanations in these cases that are not ascribed to an abstract business entity, but to individual people) have no stomach for porting. A typical manager's tenure over an organization that might have the scope to perform the port is shorter than the porting project itself. No manager wants to have such a large, expensive, risky project on their accomplishments list as "started, but not finished", especially if a successor gets to claim all the credit later if it does finish successfully: that successor then becomes direct competition on the corporate ladder climb. Also, I've yet to see such businesses opt for the safest porting approach. Build a transaction replication system, then a component of the ported system. Inbound transactions are replicated and dispatched to the legacy and the component of the ported system simultaneously. Build scaffolding to monitor key transaction metrics. Compare output and performance results. Let that "bake" for a year or two. Rinse and repeat with the next component (many such ported components can be developed in parallel, etc.), and so on, until the ported system reaches feature parity with the legacy system, then let the completed version "burn in" for 2-3 of the longest periodic process lifecycles. For example, if the the longest periodic process the application supports is once every 7 years, then you burn in for up to 21 years, comparing during the entire duration. By the time you "throw the switch" to the ported system, you have a very high certainty that it will work just as well if not better than the legacy system. Extremely low-risk, but extremely expensive, and considered extremely impractical. And with how business-critical some of these systems are, pretty much any risk mitigation short of this will get nixed by senior management. This doesn't even begin to get into other factors, like changing regulatory and business environment as you are porting (so you're porting and modifying for new requirements simultaneously), such a project can easily be targeted for the cutting block for just the cost savings to make someone in Finance look good, internal political issues, developer churn over such a long period, developers on the legacy system withholding key implementation or even business requirements information, that information simply not being available, binary-only parts of legacy, etc.

fork1 9y ago
As i've made clear in my other posts in this thread, i dont believe in rewrites. I've seen lots of very painful ones though, and never quite finished, nor iso-functional. However, there are other ways to unplug the mainframe. I would disagree with the assessment that management is too dysfunctional, it depends. But if they all were like you described, i would be out of work. And it just happens that we turned off a mainframe just 2 weeks ago.
- yourapostasy 9y ago
  How does your sales team address your customers' concerns that they are trading one vendor lock-in (IBM) with another (your company's)? From seeing how the risk is assessed in some of my customers, the kind of emulation approach you described (I've seen one for the old HP 3000, and it worked great) sells easily when the legacy vendor is so sclerotic and rapacious that the customer's management is practically pushed out of the relationship, and the economics don't have to completely pencil out to close the sale. The customer is tied down to a smaller (usually) vendor's emulation, and trust the fidelity of that emulation over time, and furthermore, over new versions. The customer must maintain a skill inventory that isn't "current" (though some people might consider that a plus). I can think of a couple ways to address those sales objections (lock-in isn't real: can always switch back to legacy vendor if all else fails, no need to revamp staff with crucial business/domain knowledge, etc.). But I'd be really interested in how your sales team deflects them, because I anticipate this legacy software issue will only get worse in our industry over time, and not just on mainframes. I'd like to try to figure out how to bring down the friction of such sales in the future. Thanks for your feedback, really appreciated.
- YeGoblynQueenne 9y ago
  >> And it just happens that we turned off a mainframe just 2 weeks ago. Aw. I hope you didn't hurt it.
YeGoblynQueenne 9y ago
>> A typical manager's tenure over an organization that might have the scope to perform the port is shorter than the porting project itself. I don't think that's the case. In the place I worked (major financial network) the average time people seemed to have ben with the company was 10 years. Especially in big companies, you can expect to see lots of people who go for a long-term career, instead of hopping from job to job (and promotion). I think the real reason why management doesn't dare to make big changes is that they understand there's a very real risk to cause a significant loss to the company (and lose their job, as a consequence). Which is why Cobol shops have absolutely mad processes. Where I worked, to make a change to a Cobol program -even if it was just the JCL that would run it- we had to complete a ten-page form, submit it and wait. They basically just don't let you touch the code. You work around it, sorta.

fork1 9y ago

As i've made clear in my other posts in this thread, i dont believe in rewrites. I've seen lots of very painful ones though, and never quite finished, nor iso-functional. However, there are other ways to unplug the mainframe. I would disagree with the assessment that management is too dysfunctional, it depends. But if they all were like you described, i would be out of work. And it just happens that we turned off a mainframe just 2 weeks ago.

yourapostasy 9y ago
How does your sales team address your customers' concerns that they are trading one vendor lock-in (IBM) with another (your company's)? From seeing how the risk is assessed in some of my customers, the kind of emulation approach you described (I've seen one for the old HP 3000, and it worked great) sells easily when the legacy vendor is so sclerotic and rapacious that the customer's management is practically pushed out of the relationship, and the economics don't have to completely pencil out to close the sale. The customer is tied down to a smaller (usually) vendor's emulation, and trust the fidelity of that emulation over time, and furthermore, over new versions. The customer must maintain a skill inventory that isn't "current" (though some people might consider that a plus). I can think of a couple ways to address those sales objections (lock-in isn't real: can always switch back to legacy vendor if all else fails, no need to revamp staff with crucial business/domain knowledge, etc.). But I'd be really interested in how your sales team deflects them, because I anticipate this legacy software issue will only get worse in our industry over time, and not just on mainframes. I'd like to try to figure out how to bring down the friction of such sales in the future. Thanks for your feedback, really appreciated.
YeGoblynQueenne 9y ago
>> And it just happens that we turned off a mainframe just 2 weeks ago. Aw. I hope you didn't hurt it.

YeGoblynQueenne 9y ago

>> A typical manager's tenure over an organization that might have the scope to perform the port is shorter than the porting project itself. I don't think that's the case. In the place I worked (major financial network) the average time people seemed to have ben with the company was 10 years. Especially in big companies, you can expect to see lots of people who go for a long-term career, instead of hopping from job to job (and promotion). I think the real reason why management doesn't dare to make big changes is that they understand there's a very real risk to cause a significant loss to the company (and lose their job, as a consequence). Which is why Cobol shops have absolutely mad processes. Where I worked, to make a change to a Cobol program -even if it was just the JCL that would run it- we had to complete a ten-page form, submit it and wait. They basically just don't let you touch the code. You work around it, sorta.