23 ms·
Banks should let COBOL die
- wonderwonder 10y agoIt's not just banks, a good number of industries still run legacy COBOL systems. Timeshare for one.
- doublethedee 10y agoBanks have no issues hiring ex-offshore contractors who have been doing the work for years. These guys can maneuver themselves through mainframe technologies and show their proficiency with quite ease.
- HelloNurse 10y agoBanks also have no issues retraining their IT staff to learn COBOL and ascend from the Mostly For Fun Open Systems department to the Really Important Mainframe Systems department.
- sigzero 10y agoMaybe so, but that would be an immensely huge undertaking costing a lot of $$$$. Good luck getting them to do that.
- mattmanser 10y agoPR piece for Auka. A classic example of one of pg's submarines[1]. Auka CEO Döderlein, mentioned a mere 5 times, says there are only 3 options, ignore the problem, big bang rewrite, or bolt on new pieces. Don't panic! Just call Auka. They have your new piece. There's no mention of the option we would all pick, a gradual migration, of course. [1]http://paulgraham.com/submarine.html http://paulgraham.com/submarine.html
- jacquesm 10y agoAgreed. And besides that, banks should do what they want to do. That COBOL software they are running is hardly ever a problem, the problems are usually in the new stuff which has been far less battle tested and is connected to a hostile network.
- Bluestrike2 10y agoLegacy COBOL systems (hell, a lot of legacy code in general) is a perfect example of the "if it's not broken, don't fix it" mantra. There's an incredible amount of work involved in rewriting legacy code, and when you're talking about doing so in a constantly updating, critical context like financial transactions, it kind of highlights the need to take things slow and carefully. My experience with old legacy systems (20+ year old C in particular) is limited, but it was enough to recognize that just ripping it all out is an awfully ignorant approach compared to a gradual migration of what needs to be replaced. It's also an incredibly expensive one, especially since it's a recurring situation. No matter how clean and clear you think your code is, or how thoroughly you've commented everything, in a decade or two, someone is probably going to be groaning about it being legacy code.
- deleted 10y ago[deleted]
- erikb 10y agoIt's a pity that pg drifts off in the end assuming that the medium blog would be more serious just because of its existing. It's just that the main text content market hasn't hit the internet yet at the time of the writing. Or maybe it was part of his PR campaign to bring HN to life, who knows.
- jcranmer 10y ago> Döderlein says that banks have three options when it comes to deciding how to deal with this emerging crisis. Option 4, which is what banks are actually doing to the best of my knowledge, is to train new hires on how to write COBOL.
- deleted 10y ago[deleted]
- Brass 10y agoSmall businesses are doing this as well (where I learned COBOL). Having experienced it, I do not feel there's really anything wrong with COBOL itself. The language is verbose and relatively straightforward, however it requires a different approach from what most people are used to.
- erikb 10y agoIs it true that just for knowing the language you are getting compensated much better? How easy is the job market?
- adamkruszewski 10y agoIt might not always be the case. Hiring young people and teaching them Cobol (or whatever) without paying large amounts upfront might be also a viable business practice, ie. think about it as an entry level job. All depends on requirements, clients, etc.
- Brass 10y agoThis is how I learned. The team I was on consisted of several entry-level people who were taught COBOL. After a couple years or so most of us have moved on to better compensated positions at other companies.
- stoshe 10y agoGlad to see someone else pointing this out. The problem with these systems is that they are very old, and thus do not benefit from many of the more modern developments in the field nor do many quality developers learn the language. The benefit with these systems, though, is that they are very old. With that age comes completeness. They're battle hardened, thoroughly tested, and a known quantity within the institutions that leverage them. History is littered with companies that attempted to replace the core of their business with one big project written with newer technology, only to fail catastrophically. During my first gig with a bank, I was appalled to see the ancient technology in play at the heart of the bank's systems, and the retired developers coming in part time on schedules they set for outrageous hourly rates to do maintenance tasks on that system. Over time, though, I came to realize that this was the most reliable and cost effective solution the bank had available. The third option listed is what I see happening, but at a much slower pace than the article suggests: > Basically, Döderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems. However, the key thing is how the connection to the old system is made. > Gradually banks will be able to address each and every product need that they have with new platforms that will replace the overly complicated COBOL add-ons. This compartmentalizes the banks’ COBOL-problem and makes it cheaper to fix, as it won’t have to be done all at once. It's a glacial pace, but it's being attempted. The heart of the old systems, though, were still untouched last I had visibility into those inner workings.
- alnorth 10y agoSay I wanted to learn COBOL, has anyone got any resources they'd recommend?
- jacquesm 10y agoProgramming in COBOL is best learned by signing up as a trainee employee in a company that has been using it for a long long time and that employs a bunch of old programmers who will be more than happy to teach you. It's a quirky language, (omit a single '.' somewhere and you're in a for a world of hurt) has its neat parts and in general will come across as limiting once you have been exposed to other, more expressive languages. But that's probably also the reason it is still around, think of it as JAVA but then conceived in the gray past. The original intent was to make a programming language that would allow managers to program. That didn't quite work out.
- mercer 10y agoHey, apologies for randomly hijacking a comment for this question, but over the past years you've been popping up all over HN's comment section with (it seems) a rather eclectic and broad mix of experience, knowledge, and (possibly) talent. I'm almost starting to suspect you're multiple persons (but not really). Have you ever written about how this came to be? I find myself to be similarly broad in interest/experience, but I'd judge myself much more superficial/limited in this regard because of the breadth of it all. I'm curious how you manage it all.
- logfromblammo 10y agoYou've never heard of Jacques Mattheij, inventor of the live webcam?
- mercer 10y agoNope, perhaps too young for that? That said, the guy doesn't even have a Wikipedia page! So how should I know?
- samBergeron 10y agoIt's not only banks, I took an internship at an insurance company a couple of years ago that had their entire mainframe written in COBOL. Not only do they have a hard time finding people to replace their retiring veteran developers, but for smaller companies (like this one) that can't afford to pay ridiculous salaries for a top notch COBOL dev, they have to settle for mediocre aging developers that can write COBOL and are on the job market. These devs are getting paid good money to work on critical systems and aren't skilled enough to properly maintain them. It would be so much cheaper for these companies to pay better devs to do more recent tech. But it's hard for them to get out of that loop. Makes me rethink where I have my money.
- skocznymroczny 10y agoRewrite it in Rust/Javascript
- jacquesm 10y agoYou're going to have a hard time selling that combination.
- protomyth 10y agoIs there a proper decimal library for either language?
- jacquesm 10y agoMeh, who cares about a few cents ;)
- protomyth 10y agoI still remember tracing down an odd bug involving taxes and contract calculations that resulted from a programmer I thankfully couldn't identify using a single precision float to do calculations that involved unit of measure conversions that then had calculations involving contract terms and weights. The original unit stored was a decimal with 30 total digits and 10 decimal digits. When I finally found the part of the code where decimals suddenly because floats, I was inclined to do violence given it was 3AM and I was chasing a couple of hundred thousand pennies in various places. It was deep in the middle of a stored procedure so the standard excuses don't apply. I swear there are not enough classes about numbers.
- jacquesm 10y ago> I swear there are not enough classes about numbers. Yes. This is one thing that irks me about these fads in programming, they all solve problems that have long ago been solved and then re-introduce all the bugs that were already discovered, fixed and forgotten about ages ago. Old software is a very nice repository of information about edge cases and real world complexity. A $0.75 accounting error turned out to be named "Markus Hess". Precision matters. If it works good. If it works but you don't know why it works: bad. If it works, but has a small problem and you don't know why: bad. If you run a $1M budget and you're off by $0.75: bad. And so on. You really don't want to store anything to do with money in floats.
- maxxxxx 10y agoI wonder what people will say in twenty years about our NodeJS, AWS, microservices and JavaScript systems.
- kristianc 10y agoHopefully in twenty years that kind of complexity has been abstracted out of existence. Microservices may still exist as an organizational concept but I'd be stunned if we're still thinking about things like containers in 20 years.
- maxxxxx 10y agoEvery generation of developers thinks their stuff will be replaced at some point but then they realize it's still used twenty years later. Happended with Y2K, Linux timestamps and a lot of other things.
- echelon 10y agoMicroservices are here to stay, especially in large engineering orgs. NodeJS and Javascript, on the other hand, I'm not so sure about... Many of the engineers I know view this technology as a "cancer" when compared to Java, Go, etc. Their reasoning is that Javascript doesn't offer the safety or maintainability that other languages do.
- pjmlp 10y agoMicroservices are just the new bandwagon name for Sun RPC and DCE. Every couple of years people decide to redo distributed computing stack.
- Tom4hawk 10y agoNothing critical (banks, military, factories) runs on NodeJS/JavaScript/AWS so probably nothing. Do you think a lot about some old BASIC Accounting Software? There are probably only two languages which might face similar problem as COBOL: C and Java. For now they are both actively maintained and used for new projects - so we are fine for at least next 50 years.
- mavhc 10y agoIf I were a bank I'd start a new bank, in Not COBOL, and put all my new customers on that. Then after 10 years offer to move people still at the old to the new bank, to get new offers.
- kristianc 10y agoHow do you message to your existing customers that you're holding their life savings on fragile 1970s tech? Also, you'll still have to write wrappers for the old tech (iPhone apps which access the COBOL core) in order to maintain feature parity with the other banks.
- coldtea 10y ago>How do you message to your existing customers that you're holding their life savings on fragile 1970s tech? You mean "battle tested for 40+ years, totally solid 1970s tech"? If anything, it's any crap they'd write now that would be MORE fragile.
- deleted 10y ago[deleted]
- kristianc 10y agoYou're thinking like an engineer. You're right, of course, but the public is trained to trust the latest and greatest. If 'battle tested' was the most salient selling point we'd be on Series 60 or QNX phones. 'We're putting new customers on the latest technology and keeping existing ones on our old systems' is not going to be an easy thing to message to the general public.
- GFischer 10y agoIf 'battle tested' was the most salient selling point we'd be on Series 60 or QNX phones. Actually, there are more Series 40 and Symbian phones sold today than iPhones - 350 million to 200 million (India / rest of Asia, Africa and Latin America are the main buyers). Many people here still miss the old Nokias. Of course, Android is the new Series 60. http://gadgets.ndtv.com/mobiles/news/nokia-sold-35-million-feature-phones-in-2016-strategy-analytics-1663745 http://gadgets.ndtv.com/mobiles/news/nokia-sold-35-million-f... http://tech.firstpost.com/news-analysis/india-smartphone-shipments-to-overtake-feature-phones-in-2016-cmr-295949.html http://tech.firstpost.com/news-analysis/india-smartphone-shi...
- marktangotango 10y agoI get tired of seeing these same sensationalist falsehoods propagated without challenge. So I shall challenge. >> We did a piece the other day about how learning the ancient programming language COBOL could make you bank. >> Which can only maintained by small group of veterans, that grows thinner every day. >>There are almost no new COBOL programmers available so as retirees start passing away, then so does the maintenance for software written in the ancient programming language. This is false because there is in fact tons of COBOL talent around (in the US). The waves of offshoring in the '00s left many thousands of unemployed COBOL developers. I personally know of 100's in the local market. A prominent financial services and BPO firm off shored mainframe development, and laid off many 100's here. Most got out of software development all together. This skills shortage simply doesn't exist.
- samBergeron 10y ago>> The waves of offshoring in the '00s left many thousands of unemployed COBOL developers If you were a developer affected by stuff in the '00s, you're probably nearing the end of your career (unless you'd just started) The problem here is the lack of a NEW talent pool.
- le-mark 10y agoWhy do you think this would be true? For example, I went through a mega corps cobol bootcamp in 2003 with 30 other people. They ran two courses a year up until 2008 or so. It's not as if all cobol training stopped in the 60's.
- DanBC 10y agoAge 30 in 2000 is 47 today. Is 47 really "near the end of your career"?
- pjmlp 10y agoI guess if one lives in SV, it might be.
- washadjeffmad 10y ago
- agentgt 10y agoI know very little of COBOL but I have often wondered if bank COBOL software could be transpiled (a quick googling shows there are transpilers). That is COBOL -> Some_Other_language and perhaps Some_Other_language -> COBOL. Then in theory you could write unit tests in some language to test the real COBOL and the transpiled COBOL.
- juliangoldsmith 10y agoThe problem is, when you have 10M lines of complicated COBOL, transpiling it to JavaScript will make things completely unmaintainable.
- agentgt 10y agoSo it sounds like COBOL really isn't the problem. Its that is 10M lines of complicated probably poorly written (in terms of hard to understand and little comments and no test coverage) code. Otherwise companies successfully transpile far bigger code bases than 10M lines... IMO the first thing they should be doing is writing automated tests against the existing COBOL. A transpiler might help this process.
- marktangotango 10y agoYou are absolutely right, that's the nuance that's often missed in these discussions. The COBOL applications in question grew organically over decades to encompass business processes for entire industries. There was never a single design document or even goal. The other thing is how these systems were architected. They were mostly all green screen apps that build data files that were then fed into extensive (complex, large) nightly batch processes. For example today when you do a transfer between bank accounts, you may expect the transfer to be immediate. most often it's shown in a pending status until after the next nightly process. This is why.
- marktangotango 10y agoEdit: further, the problem with transpiling is that these systems are still under active development. For example, banking systems have to be updated annually for changes in regulations and tax laws. If you translated all you COBOL to Java (which results in truly inscrutable code (cobol has unusual control flow constructs, even besides go to)). Then as an organization you're face with either modifying the Java code (this is very, very, very bad), or regenerating from COBOL periodically, which kind of defeats the purpose.
- squozzer 10y agoCompared to COBOL, that IBM PC is a whippersnapper. An IBM 370 would have been a better match. https://en.wikipedia.org/wiki/File:IBM_System_370-145_und_Bandlaufwerke_2401.png https://en.wikipedia.org/wiki/File:IBM_System_370-145_und_Ba... My dad programmed in COBOL for the Army, and he retired in 1975. That's how old COBOL is. Knowing my dad, he probably still has his manuals, though finding them might prove an archaelogical exercise
- dhimes 10y agoThis old argument again? It seems like every 25 years somebody brings this up....
- lightedman 10y agoEvery 25 years? COBOL's only been around for about 60. You make it sound as if it were something we've had happen far more frequently.
- coldtea 10y agoI wonder what banks would do if it wasn't for those genius suggestions in the article... /s
- einrealist 10y agoThere is another important problem: the hardware and software these production COBOL applications runs on (mainframes) is a burden for vendors like IBM. Unless these mainframe systems are replaced by commodity hardware and software, banks will always have to fear EOLs or high prices to keep development viable for vendors.
- sandGorgon 10y agoHas anyone ever been part of any kind of migration from Cobol to anything else ? What happens to underlying hardware - is it even possible to migrate from mainframe to the cloud without a complete reengineering ?
- candiodari 10y agoNobody uses mainframes anymore (except banks). They have emulators however, that emulate a mainframe on windows.
- 0x445442 10y agoNot true. I recently worked at a major auto parts retailer and all part pricing and availability data was stored in mainframes. Currently I work for a major insurance company which has multiple data centers with many, many mainframes... Think ~60K square feet worth of mainframes per data center. Mainframes are pervasive and aren't going anywhere anytime soon.
- 0x445442 10y agoI worked on a project to convert a city's billing and payment system for their water department from COBOL to JEE. It was actually pretty straight forward. The key to the project was being to easily convert the data in the mainframe to standard RDBMS tables, Oracle. After that it was just a matter of "mapping" the green screens of the system to web pages, i.e. displaying the same data and providing the same actions. The only time I really needed to grok any COBOL was when there were discrepancies between the old green screens and the new web pages. After a period of user testing it was basically do the final data dump to Oracle, turn on the new system and turn off the old one. However, there were many other programs running on the mainframe so the hardware didn't go anywhere.
- bpyne 10y agoThe issue with rewriting to newer technologies is relearning - the hard way - all the requirements encoded over 40-50 years. Decision-makers are rightly afraid of the $100M mistake. As some posters here said already, organizations have to slowly phase in newer technologies and phase out COBOL ones. The track record of Big Bang rewrites is not a good one. A few years ago it was either ACM's CACM or IEEE's Computer magazine that profiled several high-profile failures. The financial and time cost overruns were spectacular. Banking and Insurance are not the only industries using COBOL. If you're in higher ed and your institution uses Banner, you've got COBOL. During every upgrade, our Banner team has to license the latest and greatest COBOL compiler set from (I believe) Micro Focus. I have to wonder if a split in technology exists between commercial and investment banking.
- JackFr 10y agoAs someone who has worked in a few investment banks, Perl is a SIGNIFICANTLY larger problem than COBOL. While verbose, COBOL enforced structure and discipline, and it is very possible for code to be maintained by someone other than the author. On the other hand in the 90's and early 2000's many critical pieces of software were written in Perl. While it is quite suited as a scripting or glue language, I've seen elaborate integrated systems written in cryptic, unstructured and undisciplined Perl, often with proprietary extensions. And no one learns Perl anymore. There is no way to maintain these projects, and in at least two projects I've seen, what should have been a straightforward change lead to a large scale retire-and-replace project.
- PaulHoule 10y agoHell yeah. Every time I've written Perl with another programmer, I learned something new.
- EvanAnderson 10y agoI dread working on Perl code I wrote even just a few years ago. If I've context-switched away from the code for more than just a few months it often looks incomprehensible. It really is a write-only language.
- woliveirajr 10y agoSometimes the "no one learns Perl anymore" just means that no one is willing to pay a good money for some change that the company wants.
- protomyth 10y agoYep. I know Perl (5 not 6) really well and programmed in it for about 10 years. No one I've seen actually wants to hire for it. I'm fine with that because it wasn't something I loved much like the Transact-SQL programming (love Objective-C and looks like Swift will be more work not love).
- collyw 10y ago
- shepardrtc 10y agoThe idea that large corporations are simply going to move on from COBOL is out of touch with reality. It really can't be overstated how deeply old COBOL programs are embedded into these corporations. I worked for one that had been using them since the language itself was created, and while they all could see the writing on the wall, the money to do the change simply wasn't there. Not only would they have to do a code change, they would also have to do a hardware change because all of this is running on mainframes. Not only does this cost a lot of money, but it would also take an enormous amount of time. What mid-level manager is going to stick their neck out and push for this? What exec is going to ignore the guaranteed transactions that a mainframe and a decades-old COBOL program can offer simply to secure a solid future for which they may not even be around for? 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.
- nickpsecurity 10y ago"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? " 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.
- bluedino 10y agoLearning cobol (or any language) isn't the hard part - its understanding a massive legacy codebase and business practices that's the hard part.
- nickpsecurity 10y ago
- potato_mOWX2EVX 10y agoPeople who don't know COBOL, IBM Mainframe or the industry write these type of articles. You want to loose the hardware - there's a solution for that. You want to create modern web services over - there's a solution for that. You want to code in a modern IDE - there's a solution for that. If the systems that use IBM Mainframe were using Amazon ECS or Azure... the same people would write articles about the lack of reliability of core servers like banking and airlines.
- erikb 10y agoI think they actually do. But very slowly. Last time I checked the amount of known COBOL solutions was already surprisingly small. It's mostly people who don't know anything about COBOL and COBOL fans who still believe that COBOL is that important.
- codingdave 10y agoThe decisions to keep these systems around are not about technology -- they are about risk. Every IT lead in every bank knows the options for updating the systems. But they also have risk management concepts attached to their decisions, and because we are talking about banks, there is no such thing as small consequences. Banks are extremely risk-averse, so if the system is working and changes bring risk, you don't do the change. Figure that by the time there really is nobody left to maintain it, somebody else will have taken on the risk, and new products will be available. So there is less risk in waiting for those products than in taking on new development efforts yourself.
- dbg31415 10y agoAnd we should all switch to Metric, give up fast foods, and call our mothers once a week... but look, it's never that simple because all of these things take effort.
- jlebrech 10y agoif you think COBOL is bad you haven't seen RPG yet.
- ravenstine 10y agoI don't know about anyone else, but one reason I wouldn't get into COBOL is I wouldn't want to be that guy who thought he could learn an archaic language but lost the banks millions because of programmer error. I suspect a lot of people simply don't want the kind of responsibility that working with bank mainframes entails, even if they know COBOL.
- neillyons 10y agoI quite like the fact that programs written decades ago are still in use. In the web development world there is so much churn. Anything you write now will have been rewritten a year later. It is quite disheartening. I like this quote from https://teuxdeux.com/purpose https://teuxdeux.com/purpose > On that note, why the heck does every app need to change all the time? Can’t something on the Web be more or less finished? However I have no idea what COBOL is like to work with so I am probably being unrealistic.
- jecel 10y agoOne of the design goals for COBOL was that non programmers should be able to understand it with a little training. That would allow non technical managers to have a bit more control over their projects than they would have with Fortran, Algol or PL/1. I don't know how well that worked out, but other than Hypercard all other languages I am familiar with (and they are many) only make sense to those who can program in them. So though Java is often considered to be the modern COBOL, at least in this regard it isn't.
- deleted 10y ago[deleted]
- mcgrath_sh 10y agoI am probably the odd man out here, but I took two semesters of COBOL and really enjoyed it. I have been trying to figure out how to get into COBOL programming, but the job postings are few and far between and seem to want more experience than I have. I honestly think I would be really happy programming in COBOL day in and day out. As an aside, I think part of the reason I like COBOL is because I am an above average to very good academic writer. I enjoy writing papers and find it hard to meet page minimums because brevity and clarity is important to me. These characteristics (good, clean, to the point writing) seem to translate to COBOL more than any other language that I have used.
- norea-armozel 10y agoIt's kind of heartening to see programming languages like COBOL, Fortran, and Ada still are chugging along helping folks solve their problems. I think instead of trying to replace the language how about we design modern hardware and software to work around it? Isn't that where virtualization can help (I'm assuming too much probably with this question considering how many programs of that era are hardware specific)?
- merb 10y agowouldn't it be great to have something like COBOL-grpc and rewrite everything in rust/scala/java/c# but not all at once, more like the simple things first? I think that would probably be a good business.
- zcdziura 10y agoI work for a large brokerage company that has a deeply integrated system written entirely in COBOL on the IBM mainframe. That sucker is going no where, and for good reason: it's incredibly efficient for what it does. As a batch processing system, the mainframe simply can't be beat. We deal with millions of dollars worth of transactions every day that have to be correctly accounted for and reconciled. In order to get the performance required to do all of that, we stick to the mainframe. However, I do see the appeal for building off of the COBOL foundation using more modern languages. Writing a UI in COBOL on CICS is an absolute nightmare to deal with and maintain (not to mention my firm's egregious install and deployment process that is nothing but red tape and TPS reports). I'm working on a project right now where we're migrating some of our reconciliation screens to the web, where the UI communicates with a Java/Spring Boot server that itself interacts directly to the database using DB2 Stored Procedures. In this space, I see a need for moving away from COBOL. But for the batch processing? Not a chance.
- eggestad 10y agoIf you read the article carefully you'll notice that most banks DO NOT maintain their own software! They licence the software, and usually the job of running the system, from a software house. The article is based on an intervjue of the CEO of Auka. Auka is a software house for a peripheral piece of banking software. (read, he's selling software licenses). Try to look at this from the banks point of view. My first job was in one of these software houses for banking and finance(B&F) who made both core system and peripheral software. A bunch of us programmers tried to make the same sell to one of the bankers we had on staff. (You need bankers to do the job of products manager in this business). He looked at us like we're morons, and asked a rather pointed question: "OK, say we rewrite the whole software stack in C++ (this was 1998). What NEW banking products can we make in C++ we CAN'T make in cobol?" Answers is of course; None, zip, nada. Last time you changed bank, did you ask who's banking system is being used and in what language it was written in ? I'm guessing not. So banks go to the software houses to license a core banking system, and they care pretty much about only two things: 1) Is it solid (i.e bug free. Few things evaporate trust in a bank faster than there being questions about the banks ability to do basic math right). 2) price There have been a few cases when a new core banking system have been written from scratch, and most have been failures due to being too buggy when launched. Word get out among the banks and the system is dead. All will wait until it's proven, no one will be the first one out of the gate. The bug free requirement is a show stopper from the getgo. On to price. The development cost of such a system is in the neighborhood of 250 - 500 million USD. The only way to get that down is to strip down the features to a much simple system. The other software houses are just going to sell an existing cobol system, with disabled features to match yours, and underbid you. Bankers, unlike most CS majors, actually understand how to calculate cost of investments! Say 500M USD development cost, a future value calculation will yield that you'll need a return-on-investment (ROI) of 20-50M US EVERY YEAR FROM HERE TO INFINITY to make the investment pay off. (That's PROFITS, not revenue) Core banking systems are so feature stable, and have been so thoroughly debugged over DECADES, that there is very little maintenance to be done. I'd expect that each of these systems have a staff of 10-20 programmers maintaining them (and they spend a lot of time doing other things). How big a staff of maintainer will you new banking system need after launch? Even if it was zero and you assume you pay each maintenance programmer 250k USD, a staff of 20 still only cost 5M USD. The article have a section "what can the banks do" left out a fourth option. Instead of using CS majors to code cobol, you use B&F majors, and give them a 1-2 year education on doing cobol programming. The CS majors need 1-2 years of on the job experience to reach a B&F Bachelor level understanding of what a core banking system need to do anyway. Cost is the same. One last point, say you do write a new system today your choice of language will be either Java or C#. As database there is no viable alternative to SQL. In 30 years no fresh CS major will touch Java or C# with a ten foot pole, and you'll have to do another rewrite to the tune of 100-200M USD (assuming that programming will require less hands). Much cheaper to keep on educating non CS majors to do cobol.
- deleted 10y ago[deleted]
- filereaper 10y agoThere's a misconception that COBOL is dead, its not, there are developers and new compilers being built for it. [1] IBM isn't sitting around waiting for COBOL to die out, its working out hooks between COBOL and Java and introducing new languages like NodeJS [2] The problem isn't money, its risk. No CIO is willing to risk moving to a new system, and that's the problem that needs to be attacked. [1] https://www.ibm.com/developerworks/community/groups/community/BinaryOptimizer https://www.ibm.com/developerworks/community/groups/communit... [2] https://developer.ibm.com/zsystems/documentation/java/workshop/java-and-cobol-interoperability-introduction/ https://developer.ibm.com/zsystems/documentation/java/worksh...
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- taylodl 10y agoCOBOL has been "dying" since the late 70s. Since that time I have seen several languages and platforms come and go. Where I work our core application driving the business is written in COBOL. Estimates are between $500 million to $1 billion dollars to replace it due to the number of systems interacting with it and all the business processes affected by it. For that kind of money the business wants a technology they can hang their hat on for twenty to thirty years. So what are you going to choose? What languages and platforms in widespread use today are going to be around in twenty to thirty years? Here's what I think it will be: C, C++, Java and COBOL Hmmm. COBOL is in that list. So if I think COBOL will still be around in twenty to thirty years and the system is working fine now then what reasons do I provide to the business for spending $500 million to $1 billion for the upgrade? Yeah - I can't think of any either that warrants that kind of expenditure. So COBOL remains.