Thank you. So much internet arm chair analysis falls into this category.
It's also a great proposition for a grad student. They don't have to unlearn much, they're in a perfect position to absorb a new language, and the term 'set for life' can be thrown around liberally.
Wouldn't be surprised if this was already a thing, probably in the form of COBOL-specific Consultation services.
You can. Our local, community college ties its classes to what industry in the area wants. It has classes on COBOL, RPG, and so on. That's because there's quite a bit of it out here in big companies.
Do all students just care about learning the hype and creating the next flapping bird game?
Creating a new flapping bird game is exciting for students because it can give them an opportunity to create something from nothing. You aren't going to get that opportunity doing COBOL development. You will most likely spend the rest of your career doing maintenance work rather than any greenfield development. There is nothing wrong with that but not everybody likes the fact they can't create something new.
The driving factor was a suite of new services and features they wanted to implement, we came up with a creative way to run parts of the system as proxies to the COBOL applications backing them and to decorate the requests and responses with data from the newer systems.
We were done much faster and cheaper, for a project of its scope there were surprisingly few hiccups or post launch rework projects, and we got the end result they could've spent 10x the money to achieve- and all with way lower risk.
I'm assuming we were in a fortunate position that the general flow of data could be handled from the various source streams, but I wonder why this isn't at least an option for moving forward from some of these ancient systems. It seems like a good first step, at least.
Other companies have worked together to essentially make boot camps before SV even thought to do so.
Running mainframes isn't cheap. COBOL programmers aren't cheap. Not being able to improve these systems / innovate with them can cost the business a lot of time/money. And if we're talking COBOL, we're talking at least 25 year old corps.
How long's the ROI on moving over? How expensive does the maintenance of antiquated systems get? It's easy to say that they're rock-solid and never need to be touched, but is that really true? For example, lot of banks today have a lot of absurd UX, often because of absurd internals and I know a lot of that usually is "the system is ancient and nobody really touches it anymore, that's just what it is now".
What language would you suggest? Remember that decimal reliability and predictability is important. Plus, let's pick a language likely to have a very long service life because we need to have our investment rewarded.
Frankly, the iSeries machine we have is pretty cheap to run. We bought it 10 years ago for about $15k and have had a maintenance contract that doesn't cost that much (about the same as our Red Hat service contract). We probably will buy another one since they just released a sub $10k one that will more than meet our needs. Never lost any data, easy enough backup that the biz office does it themselves[1], and IBM is pretty quick about any fixes. Much cheaper than any Linux, BSD, or Windows system we have ever had. Plus, I don't mess with it like the others. It just works.
1) we've tested it multiple times, after all, an unrestored backup is not a true backup
Maybe someone should be thinking about a COBOL replacement language instead of the plethora of C / C++ replacement languages.
I imagine within the "a few years of development" is budgeted some time to figure out what tool to use
It will be a lot more than a few. Things absolutely cannot go wrong or even change in production. One slip-up can result in real money being lost. This whole "go fast and break things" doesn't apply to bank accounts.
Or you could not do any of that. You could just accept your situation. Mainframes are essentially a subscription service. For a yearly cost, IBM has offered you guaranteed performance and guaranteed hardware (they fix it immediately if there is a problem). So, all you have to do is pay your subscription and pay some people who like to have a steady, unexciting job and your business will continue to run like clockwork.
I'm obviously not saying banks should just switch today cause it's easy and all, but if the ROI on switching is 10, even 20 years, it still makes sense to do if you're a bank.
I can't find the post now, but some folks from the US govt who frequent HN talked at length about the ongoing replacement of mainframe-type services with newer tech. What I gathered from that is that the cost isn't ridiculously low at all when you take into account the impact it has on the organization's ability to get things done.
You are at a known state but you now have to re-create the steps to get to that known state as I'm sure a lot of the domain knowledge around the product is not there anymore. Not only that, you now most likely have other sources consuming the output of the original COBOL application so you have to ensure that the other applications are able to consume the new data and that those don't break either.
What you have to remember is that when the COBOL code was written, it replaced hundreds, maybe thousands of people doing manual data entry and manipulation, maybe even pen-on-paper. That gives you a fantastic ROI. After that's been done, replacing one computer system with a newer one is completely different, a spectacular case of diminishing returns.
I've seen it attempted first-hand and it was a dismal failure. And it was their third or fourth attempt. And it wasn't even a full replacement! Just a simple data lake to dump things into. Google or Facebook or Amazon could do it, but few companies are like them.
Success isn't guaranteed, maybe as low as 50%. When you say 'few years' it intimates you don't appreciate the scale of some these systems. In the end, retiring legacy systems isn't a technical problem, it's a product owner, product management, and business problem. The business owners have to make concerted, multi year effort to document their process as implemented, define the replacement, and manage it's (re)implementation. This never happens.
I wouldn't say it never happens, but it certainly takes a couple tries and a lot of time and money.
My employer is close to being off our mainframe(s), but it will probably take at least another 10 years to get rid of the last little dependencies. We've already spent about 15 years (with hundreds of developers) getting to the point where all the major online and batch processes have been reengineered and have very small mainframe dependencies. The mainframe development teams are very small and mostly focused on decommissioning work.
But yeah, it's a massive undertaking. In our case, the business was motivated to pay for it because mainframes just couldn't scale for our main use cases.
Very, very unlikely. The company doesn't even have technical writers anymore for internal projects, let alone technical historians. And with the time it's taken and normal staff turnover, I doubt that there's anyone who really could write about the whole effort based on their own experiences.
Basically, it consisted of building of building a new central datastore for our content (that was pretty mature by 2005, when I started). Then hundreds of smaller projects to migrate this or that process to read from or update the new datastore or keep it in-sync with the old one. There was also a lot of opportunistic piggybacking of new feature work onto migration projects or migration work into new feature work. However, I only have the view of a regular developer.
I see a lot of people here telling me I don't know what I'm talking about without actually giving an answer as to how long it would take and how much it would cost, which was my question in the first place and I'm being downvoted for asking it. Seriously, WTF HN?
What you can do is estimate the cost of implementation in today dollars. For example suppose Bank System X has been under development for 40 year with an averge of 10 developers per year. That's 400 person years. Suppose you find cheap labor at $100k per year, the sunk cost in personnel alone is $40M in todays dollars. So 40 people maybe could do it 10 years.
The above analysis is not satisfying.
Price for performance for certain workloads, as I understand, it can be.
> Not being able to improve these systems / innovate with them can cost the business a lot of time/money.
The banks use other technology for peripheral systems that interact with the core functions all the time (look at the drivers behind AMQP, sometime.) The core functions, OTOH, are about impelmenting requirements that haven't changed in centuries; until there is a desire to implement a fundamental new way of doing things (like blockchain, which financial institutions are exploring and probably aren't using COBOL on mainframes for their experiments) theres nothing to innovate on.
In fact, if you look at the existing COBOL banking applications, many of them aren't pure inhouse development, but packaged applications like CSC Hogan. Hogan runs on top of z/OS and CICS and is written in COBOL. Hogan shops will have a lot of their own COBOL they add to the Hogan system to implement customer-specific requirements. So for many banks moving off mainframe/COBOL, it is actually a migration from one packaged app to another, but of course they need to rewrite from scratch all their customisations.
In my personal experience, most banks doing this don't try to do it as a big bang. They identify subsets of functionality where they feel the current mainframe system is most limited – e.g. mortgages, mobile banking, whatever – and start by replacing that function only with the new non-mainframe software, and have it integrate with the pre-existing mainframe app for other functions. Then, the idea is, progressively they will migrate more and more functionality to the new system, and eventually the mainframe/COBOL systems can be retired. A piecemeal approach often involves less risk, costs less (in the short term) and is easier to justify to the business since they can see tangible results much easier.
This is a good excuse for a few years. But after decades?
And talking about banks?
---
The whole software industry is frankly pathetic. We are talking about actors with the HIGHEST profits of mankind, and yet "we don't have money for this" star to look pathetic.
Google, Apple, MS, IBM, Oracle, Banks, Defense industry, etc have not excuse to not invest in basic infrastructure.
This is the same thing with country that neglect self-investment in fundamentals. If you agree is smart to invest in road, electric grid, etc, then why we think otherwise when we talk about OUR industry.?
This isn't a "basic infrastructure" problem, it's a problem where the people writing the software didn't plan for obsolescence and many of the "best practices" we take for granted weren't even in place when this was being written. And it is about tracking real money, so if the system isn't exactly right, they could end up being tied up in court which makes it even tougher.
The risk is too high to let things as is today.
---
BTW, probably some downvoters think I'm advocating to move this to some hipster language like JS or something like that.
I work mostly for enterprise-alike customers, have work for government projects, etc.
So I'm aware of the work here. Also, have helped to move decent-sized code bases, several times, from OLD->NEW.
> ~$1 Billion to convert their old system
If things in AU is alike my country, this cost is inflated... For some project Oracle bid our customers 10x more than ours at the time.
But this is beside the point, anyway.
---
So, how this could be done?
====
The first problem is the need to have a solid hardware+OS, where linux is not there.
Solution? Stay on mainframes. Is basic.
The second problem is OLD cobol + Zero understanding in why, how, where, etc is the full system. This is the big one.
This is alike find a OLD C codebase, made like 3 years ago. Or even better, a OLD B codebase (or any kind of precursor to C, if it exist at the time...).
And pretend the solution is to STAY WITH THE OLD CODEBASE. For DECADES.
IS THIS MADDNESS!
NOT, IS IT!!!!
-- So, you build a better COBOL. Like CoffeScript->Js. You star moving the code from OLD to NEW. In the process, you document, and build testing. You end with a better cobol (or a transpiler) with a proper toolchain.
---- This can be look as the progress with another bad language, JS. You start with something terrible, with a huge installed base, yet, you star moving torwards something else.
In the process, you can do something alike ASM.js but for cobol, and whola, you can transpile other languages.
The main trouble is that customers on the enterprise side of the world have no respect for developers, and fired them after years or just not care.
Then, when in trouble, ask for external contractors that do not have the required knowledge (and maybe, not even the skills).
For this to work, it need to engage the on-site developers + maybe contractor or hire some additional hands for the mechanical work. Do it well, and this is fairly cheap for the benefit.
But this require to "do it well". And that is the "hard" part, because is the human factor the big issue here.
You can tell what a person's _real_ priorities are by what they do. Likewise, you can tell what a society's real priorities are by what they do.
Of course. But after decades of the same problem, is not time to admit that is time to change?
In other words, even though everybody complains about something, and even though it's theoretically fixable, the cost+benefit isn't always there. That doesn't stop people from complaining or offering conceptual solutions.
If nobody pursues a particular solution, that's strong evidence about the real implementation and problem costs. Not conclusively, of course. But as a passive observer it's usually the best evidence available.
Really, the answer to the COBOL "problem" is obvious and it's what basically anybody familiar with it suggests: a piecemeal and gradual shift according to cost, benefit, and opportunity.
But as far as training people to handle COBOL, well, that's simple. Look at vocational schools of years past. Why can't you train a random person just how to do COBOL? They don't need to do object-oriented programming or UX theory. They just need to maintain and occasionally update some ancient program that's been rock-solid for longer than they've been alive. It doesn't take a genius, it just takes very specific training. And there are a lot of people that would jump at a chance for some high-paying, steady job that they just need to train for a year or so at night school.