Nationwide to perform IT equivalent of 'replacing jet engine mid-flight' Nationwide Building Society will become the first big UK banking firm to pull its core computing functions off mainframe computers and run them on SAP servers in the next few weeks. It's an operation that an insider described as like replacing the engine on a jet plane, mid-flight. The launch of the five-year project is …
What the SAP are they thinking about?
So Cobol Devs are hard to come by. At least you can be sure of the results you get back. This is not always the case with SAP (BAPI transactions) where your transaction can be returned as 'Ok' but it could still fail as it might have been passed onto another BAPI via a queue.
SAP application development is even more wrapped in secrets than Mainframes.
I'm glad I'm not with them any longer. If I were, I'd be giving every transaction I made with them a really detailed going over.
Anon because my current employers are thinking of adopting SAP themselves and I want to eke out my job here as long as possible.
"... old beardy COBOL dudes know what the f**k they are doing ..."
Erm, yeah, right, pull the other one.
My one and only exposure to COBOL: in 1986 my then-employer sent me on a one-week course to learn about ICL (now Fujitsu) mainframes, to be "qualified" for a job with a particular client. All the course examples happened to be COBOL. I was the only member of the class who wasn't a COBOL person in my day job, yet I was top of that class. How does a person who's never seen the language before beat 15 people who "know what the f**k they are doing"?
This post has been deleted by its author
(Not in the UK, in case you are trying to identify them.)
A very, very painful experience. From a stable, integrated system to a wholly distributed Linux based system. The Linux part was fine, but the learning curve for distributed lasted years. We also had to learn new techniques for keeping track of requisitions for hundreds (>800) of new Intel servers and their constant ongoing maintenance+upgrades once they were installed.
Saved a lot of money on mainframe rental and 5-yearly upgrades - or rather the upgrades are now spread over years instead of in one big bang so they aren't so noticeable. We now have more people maintaining the system and had to develop new monitoring and alarming systems which weren't necessary before.
I suppose it had to be done it wasn't fun. I think the new software system is more capable, but much less stable, and with many new sources for instability. No matter how old the 2200 mainframe concept was, it was much easier to live with.
but on Xerox Sigma systems in the late '60s and early '70s. I really don't think that the article writer is likely to have used XOS.
But it is clear that there are still mainframe class systems that are not IBM compatible. Unisys have their ClearPath range using intel Xeon processors and running MCP, which is popular in US Government circles. NEC in Japan also have Itanium based mainframe classs computers running an OS called ATOS, which has evolved from GCOS (nee GECOS - which should be a familiar term to any UNIX sysadmin).
Although they are classed as mainframes, they actually have Intel processors of various types in them, and could be considered as enterprise class rack based Intel servers rather than mainframes. For anybody working on these other mainframe systems, please note I'm not quibbling, I'm just pointing out that they are different from IBM z/OS based mainframes.
They are huge computers, generally running XOS, mostly produced by IBM and they process transactions in batches.
Looks like the "XOS" bit has been corrected in the article, but I'm still mystified by the "process transactions in batches" bit. Yes, many mainframe cycles are spent on batch jobs in environments such as JES; but many are consumed by online processing, too. IBM has CICS and IMS. Unisys 2200-series OS is inherently a batch system, but allows interactive transactions. A general claim that "mainframes" are batch-only is simply incorrect.
Did they omit to mention that management of all this is being outsourced to India? The plan now is to let Accenture, IBM and TCS fight it out for the 'bid that brings the most benefits to the organisation'. Which is business parlance for cheapest. In fact, all the testing for this implementation was already outsourced and the permies have been less than impressed with the results. No-one below board level is positive about anything at the moment.
AC for obvious reasons.
Outsourcing could be the final straw for the "morality" of my savings account. Natiowide was the last of the big mutuals - but they seem to be behaving more like a bank these days. Time to think about spreading my savings round several smaller mutual building societies - the interest rates can't be any worse.
Zopa is a great idea but you are playing on a field tilted against you. Put your money in a bank, and the government guarantees you'll get it all back, even if the UK economy tanks and many people that the bank has lent your money to default on their loans. Also the bank is too big to fail, so it makes reckless loans and drives loan rates down, knowing it cannot go bust. Bankers! Lend your money through Zopa, and you are on your own. Yes, you get more interest, but personally I don't believe you get enough to compensate for the risk to your capital, especially after it's taxed.
Silly question of the day: if the government takes 40% of your interest in tax, shouldn't it reimburse 40% of your losses if things later turn sour? :-(
Just to clarify - "properly behaved" means not outsourcing. A UK mutual should employ all its staff in the UK.
I don't have a strong feel for new IT versus old IT. Nationwide's history was one of amalgamating many smaller building societies, so I'd not be surprised if their current IT wasn't recognised as a danger zone after the RBS fiasco.
Sadly Nationwide basically acts like a bank these days and I found is not "on your side":
- Drops savings interest rates before banks (e.g. NW dropped it's 3% rate, Santander 3% savings did so 2 weeks later)
- Cuts interest on saving accounts once it's got enough punters for a product (like banks - see their esavings for a good example)
- No interest on current accounts any more (again like banks)
- Interest rates on accounts IMHO aren't any better than banks.
- Pretends to give you "flexclusive offers" which are basically thinly veiled promotional partner adverts.
- Offers an exclusive account for loyal customers... but has only just started it. The interest rates on this
account is IMHO only enough to prevent people moving i.e. Nationwide's self interest, there are much better rates elsewhere.
- Charges interest on <24 hours negative balance accounts (some banks don't do this - LloydsTSB I *think* is one)
- Adds foreign card transaction charges (that it used to swallow)
- Gave me bad advice for which I financially lost out and refused to refund (this made me move)
.... there's more but this is a ranting enough.
and the major downside to not being a bank?
- Won't change money in branch, forget about breaking that £50.
The sad thing is that almost all banks are the same. The only decent one I found for customer service was M&S bank which is open shop hours too (good for the late 10pm opening stores).
The principle is correct, At least Nationwide have recognised a serious problem (highlighted by the RBS systems failure): legacy systems written in COBOL with a light sprinkling of assembler and JCL that can't be migrated and for which all the remaining experienced people who understand them are nearing retirement age.
I'm not sure I'd have chosen SAP as the target - frying pans and fires come to mind for some reason. But I like Nationwide (at least, more than the other major clearers, which isn't saying much), so good luck to them.
I've just turned 40 and know a where to get a rich vein of people who understand Cobol, JCL and Assembler - including myself :)
Whether you would be willing to pay our rates is another matter - although I would struggle to see how we would price outselves out of the the market when compared (to a properly trained) SAP-ite. Properly trained being the operative word of course.
Some of the bigger Mainframe Assembler and Cobol shops used to run the equivalent of grad schemes (I came from one of the last classes of those run by my former employer.
The real issue is failure of long term thinking by senior management.
CA-7 is really just a more sophisticated form of JCL. Well done, to AC 08:45 - I think you have a secure earning platform for life. But you make my point for me, in that 40-year-olds are about the youngest people with Cobol skills and by definition the pool is diminishing at about 5% pa as they reach retirement age (probably much more quickly than that as I suspect there are many more in the 50-60 age bracket than the 40-50 one).
There's going to be a humongous amount of work to be done in converting these systems, and I reckon that those (mainly financial) institutions that haven't made a start in the next 5 years will never find the manpower to do it. Of course, since the event horizon of senior management is <<18 months, this work will never get authorisation. I confidently expect that at least one major financial player will go under as a result.
"There's going to be a humongous amount of work to be done in converting these systems, and I reckon that those (mainly financial) institutions that haven't made a start in the next 5 years will never find the manpower to do it."
Not going to happen, IMO, the big banks and other financial firms will hire and train COBOL programmers before moving away from their billions, multi-trillion collectively, investment in those applications and platforms.
The RBS failure was nothing to do with the JCL, COBOL or assembler, it was a human error causing the loss of the CA-7 job queue, which hadn't been adequately backed up prior to someone working on it.
This was on a mainframe, but it could just as well have been run from any other platform CA-7 can be installed on.
legacy systems written in COBOL with a light sprinkling of assembler and JCL that can't be migrated
The hell they can't. Those migrations have been keeping me in bacon for nearly two decades now, and the market shows no signs of slowing.
And the "mainframe skills shortage" is an economic effect. There are plenty of experienced COBOL and mainframe programmers who are under-employed because people don't want to pay reasonable rates. Or, from another point of view, people think the TCO of a rip-and-replace approach, like what Nationwide are contemplating (and many others have tried, with varying degrees of success), will be cheaper than paying market rates for the necessary expertise plus the ongoing costs of mainframe hardware and software.
And it's entirely possible to train new ones. In fact, should the market warrant it, it's easy these days to pick up most of the necessary skills using freely available software (Hercules only includes quite old versions of mainframe environments, but the concepts remain relevant; there are a number of free COBOL compilers; docs and specs can be downloaded). Rip-and-replace is a choice; it's not being dictated by circumstances.
(Also, I'll note that other comments have indicated that Nationwide is using Unisys and Fujitsu/ICL, they won't be using JCL - they'd be using, what, ECL (OS 2200) or WFL (MCP) and SCL (ICL)? But that's just a quibble.)
Maybe not a coincidence.
The Voyager spacecraft used Jupiter to gain speed in it's mission to the far end of the solar system.
Jupiter was also the name of an ill-fated Centrica project to migrate it's billing systems to .... SAP. In that case Accenture got it's arse sued off for the failures and problems after the project went live.
Hopefully that is the only commonality - as Voyager is still running well, long beyond expectations (much like banks' COBOL systems). I wonder if those SAP implementations will be able to make the same claims in 30 years time?
Getting the staff: - there are a lot more people trained in the various aspects of SAP. That doesn't mean that they are any good; in fact I've seen a lot of consultants that were less than satisfactory. However, I would accept that the odds of getting at least a few of the better people are higher.
Real-time: - the SAP system can be real-time for their own transactions, but it will still effectively use batch transfers when moving information to other systems. So not really the benefit that that they hope for there. As for anomalies, they will only be caught if the system is programmed to do so.
Flexibility: - (quietly snorts laughing). SAP is not the most flexible of systems unless you have been drinking the SAP kool-aid, in which case you will believe anything. As recent reports show, SAP licencing can also be horrendously expensive and support costs can get totally out of hand. As for scaling up and down; presumably that menas they will rely on the IBM datacentres; they will scale up but I've never yet seen them scale down.
Insights: - Remember the old saying "Garbage In, Garbage Out". This still applies in this case, and the "Business Insights" will only be of any benefit if they have the right people to identify the requirements, design the structure, apply the changes and analyse the output. I've seen some really good output information and I've also seen some stuff produced on a daily basis for years that no-one was ever able to understand.
The biggest issue is the outsourcing; I don't wish to sound as if I am putting the out sourced staff in India down, but in most cases they have limited expertise. They have a culture of moving on after a very short period of time (months rather than years) and never really gain the knowledge that would allow them to be as effective as they should be. Add to that, many of them seem to have gained their knowledge through training facilties that are not approved by SAP.
I don't use Nationwide; and I might think twice about doing so for at least a few years until they get the bugs out of their systems.
(For reference, I've used SAP over the last 5 years on several projects and undertaken a number of certs. It can be made to work, but that is entirely down to the quality of the implementation team.)
"and they process transactions in batches."
Mainframes have been processing transactions "realtime" for decades where required through the likes of CICS, they are still what "modern enterprise" computing aspires to be and had features that more modern platforms still struggle with.
As for the migration mentioned in the article, just wait for it to fail, or the management to suddenly realise they have tied themselves into a proprietary platform that can charge what it likes once they are hooked.
"Mainframes have been processing transactions "realtime" for decades" - yes, I was writing realtime* mainframe stuff in 1966. The problem was never the mainframe it was senior management/beancounters who wouldn't believe a) that a realtime system could provide an 'audit trail' or b) that an audit trail was pretty pointless (which do you believe if there's a discrepancy?).
Transition from mainframes can be done gradually and safely by parallel running e.g. with a dual purpose front end until everyone is convinced the results match.
And SAP may be taking them off mainframe hardware but the whole of SAP is a mainframe design and mindset!
AndyD
Batch processing has considerable advantages. You have large-scale commit rather than small-scale commit. The batch is either processed in its entirety, or not at all. (Or at least, if it's being done right, that's how it should be).
That ought to make disaster-recovery easier, which is why the RBS fiasco was so shocking. Not only was there a loss of service for some considerable number of days, but it became clear there was also a loss of data integrity in the case of some customers' accounts.
Total nonsense that batch processing is because of mainframes. IBM with CICS, MQ and IMS (on mainframes) has led the world in OLTP (online transaction processing) since the 1970s. Every time you withdraw cash etc - you are making a CICS transaction. As for Uni graduates knowing more about SAP than COBOL - ha ha very funny - but also outstandingly ignorant. You have just written a press release for SAP, not an informed article.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
