Listen up you bunch of bankers. Here are some pointers for less crap IT The Bank of England has teamed up with other regulators to offer UK banks a little advice on sorting out their woeful IT systems. BoE, Prudential Regulation Authority (PRA) and Financial Conduct Authority (FCA) have come up with a shared policy summary and consultation to strengthen resilience in the financial sector. The Old …
-set impact tolerances for each important business service, which quantify the maximum tolerable
level of disruption they would tolerate;
-take actions to be able to remain within their impact tolerances.
"hope that helps"
Oh Heavens no! Your suggested phrase is almost complete devoid of bullshit Bankspeak. That won't do at all.
That will be bad, but not as bad as negative interest rates that can be applied to ensure you don't keep cash in the bank. Base rates are effectively floored at 0% because people would rather bury cash than wear a negative interest rate, which won't be an option in your scenario.
Unfortunately, they have read the ITIL documentation, but they didn't understand it...
And besides with all the hype about DevOps and Agile and the like, the day-to-day unglamorous operations are kept into the hand of outsourcers, totally unable to understand what they are doing and blindly following the procedures which have been provided (with parts removed because anything longer than 3 pages is outside the SLA and anyway you don't need the obvious steps of course - until implementation is outsourced, like ticking a specific box because otherwise the application can't be deployed, which is self-evident for a specialist but not for the aforementioned drone (*) ).
Note that even if you see banks success stories about DevOps and Agile on Linkedin, don't be fooled, nothing done will ever go into production, because it doesn't follow the agreed upon processes and SLAs.
(*) it is not like I spent 3 hours waiting for a complex deployment process running today to see it fail because a box was not ticked as I put in the impplementation documentation... :-(
But it looks good on a resume...
At the bank I worked at they were happy to send ops staff on the (then current) ITIL v2 2 week Service Manager course so the intent was there. The problem was that so much of service delivery was managed and almost completely staffed by people who knew fuck all about computers. I tried to get a problem manager to explain to me the difference between the root cause being "program", "software" and "application" and a couple other that escape me. It didn't go well. Nor did my attempt to explain orthogonal defect classification. Symptomatic of a wider problem of course.
Sadly I was too busy explaining the code to my replacements overseas to actually teach them how computers worked or the basics of software engineering as opposed to coding. It was painful to watch the SQALE ratings fall in our code.
Barclays claim they've ditched all their legacy but still need 20,000 IT staff for their new world cloudiness?? Sounds like BS to me.
These banks are awash with legacy tech in every nook and cranny; the fact that execs might really believe it's all new, shiny and cloudy is terrifying. Especially when they decide to slash their headcount without any grasp of the real legacy stuff these people are maintaining. Sticking legacy apps with waterfall update cycles in EC2 doesn't make them any less legacy! If you're not doing full software defined infrastructure with CI/CD delivered apps, you're doing legacy.
Personally I reckon it's worth splitting your money across multiple banks and putting at least some in Starling, Monzo etc - I think in terms of banking IT failures the worst is yet to come, and it won't come from the new kids who are doing cloud native and know how to do it resiliently.
Two minicab firms.
One has a brand new fleet all of the same type - and they are maintained by the main dealer.
The other has a fleet fill of the sort of cars that should have been 'retired' 5 years ago, and yes, sometimes some cars break down and they are then fixed - not always perfectly, admittedly.
Fast forward 10 years
One of those minicab firms will know what to do should a key supplier fails.
If its running a live service, then its not 'legacy'. That immediately implies that it can be ignored and left alone - and its that attitude that causes all the problems. I hate the term 'legacy'. Its an attitude that leads to complacency, and that leads to massive disruption as time goes on.
The number of times I have heard PHBs trot out the "Oh it's legacy, we're not going to invest any money in it" is astounding, despite such systems being key to the company and not in a state where its going to be replaced for years.
Even worse, because some sales droid (and Enterprise Architects believe it or not) sell the idea that Cloud is the nirvana to their problems (which most of us know is not the case for everything), that attitude becomes even more pervasive.
I also hear the L-word used for systems that people want to get rid of, but they hope that they can just stick it in a corner and hope it will eventually biodegrade because the New Shiny Thing Is Coming.
I've ended up nursing a lot of these poor old things, making people plan properly for migrations, making sure data gets backed up (or destroyed) as appropriate, and doing all the things necesary to take a system out of service without any unforseen consequences.
(Maybe I need a new job title and business cards - should I be "Systems Executioner" or "The Decommissioner" ?)
Banks (and others) have removed almost all their senior IT technical staff. There is virtually no one left with sound IT knowledge who is senior enough that senior management will listen to them. Junior IT staff (with sound knowledge) are so low in the totem pole that the Board and senior management will not listen to them and the bosses of the junior staff will not pass problems and misgivings up the chain for fear of their own jobs.
(Senior IT staff whose knowledge is hopelessly out of date can still be found - however they are part of the problem not part of the solution.)
I agree with most of what you are saying - but I am intrigued about why you think senior IT staff with historic knowledge are part of the problem?
I am such a person - my knowledge not only keeps archaic systems operational well beyond their intended life, I am also able to guide things forward into new environments/deployments with minimal disruption. I try to drive innovation and movement into new areas. I am extremely vocal when it comes to PHBs refusing to spend money to upgrade/transform their business systems.
I would suggest my 'out of date' knowledge is still very relevant when trying to maintain a service for the customer base. Your problem is with the PHBs refusing to spend money (as IT doesn't generate money in their eyes - its always seen as a burden), not with the people who work their asses off trying to keep what they have running.
I agree with most of what you are saying - but I am intrigued about why you think senior IT staff with historic knowledge are part of the problem?
Most of them haven't coded in anything more recent than C++ (I'm not slating the language, its great, but for LOB apps you probably want C# these days or maybe Python), meaning they've missed out on all the sound engineering practices that have happened since - design patterns, solid, test pyramids, ci/cd, cloud, and modern language design and capability. In short, they're effectively so out of date as to be non-technical.
Most of them won't have a github profile, never mind a continuous green ribbon spanning years. Coding and technology may once have been their hobby and then their job, but now that's golf, and talking shit, to put it bluntly.
People working in technology chose a profession where you have to stay up to date or you become the problem others are trying to solve. Either learn something new or retire; don't linger like an unflushable turd. Sorry if that sounds harsh, but that is the message an awful lot of the people lower down the totem want you to receive, and for good reason.
Absolutely correct. The FCA and PRA are issuing the advice to the Business staff, not the IT staff.
IT staff have been protecting the Business staff by insisting on security and resilience. I'm not saying they always get it right, but the fact most stuff is available 24/7 with the odd outage is a good sign.
Business units now have the ability (and appear to have been given the rope to hang themselves) and can bypass "IT". I wouldn't like to be the new CEO of an organisation following that model, it will be very career limiting when it all goes titsup in 2020.
Jon Cunliffe, Deputy Governor for Financial Stability, said: “FMIs, both wholesale and retail, lay at the heart of the financial sector. They are the plumbing that allow the financial system to operate. The safe and resilient operation of FMIs is therefore crucial to the Bank’s financial stability objective. FMIs need to consider not only what steps they need to take to minimise operational disruption, but also how quickly they can recover from any operational disruption.” ..... https://www.bankofengland.co.uk/news/2019/december/building-operational-resilience-impact-tolerances-for-import-business-services
You might like to realise, Jon C, FMIs already have considered what be expected and proposed to them and of the needs to feed to satisfy requirements, and have already implemented them with all manner of unusual and unconventional seeds intelligently designed to also provide for their future total protection.
It is therefore the Bank of England, PRA and FCA Troika which is rendered extremely vulnerable to suffering all the risks in these new ways of doing things disrupting events. Do they have any adequate viable defences is the one question for now that I would ask of all three of them?
There's more than just a lot going on out there in the CyberIntelAIgent Realm and here, El Reg, but surely not at all unexpected .....
Some places do. Even as a humble sys admin I have to fill in risk assessment matrix thingies to cover the services my team provide to other part of the business. When something goes wrong and it either loses us money (or comes close to it) and any part of the kit I look after has something to do with it, then I have to fill in more paperwork on what happened, what we did to fix it and why it's not going to happen again.
I work at a known, but not particularly big brokerage. Makes you wonder WTF the high street/merchant banks are up to...
I'd not heard of fintech or Monzo until I read https://www.theguardian.com/money/2018/jul/07/heres-how-scammers-get-away-with-it
I immediately opened an account with them, as their approach to security didn't appear to involve excessive secrecy and obscurity or denying that there is a problem but was an integrated part of growing the business.
I trust that more than anodyne soundbites about 'robust systems', how many bits of encryption are used and other such 'nothing to see here' statements.
Then on the other side of the new and shiny FinTech coin N26 had security holes you could drive a bus through a couple of years back, mostly to do with the server trusting the client too much and having a non-rate limited API which was too chatty. Hopefully their standards have improved since then.
Let me try ...
1. For ever 24 hours of outage (or up to 24 hours) = £50 credit to the customer(s) affected.
2. Proof by affected service can be submitted by screenshots or photos taken from phones.
3. Processing time by the bank will take no more than 4 calendar weeks. Any delay will incur an additional 10% interest per day.
1. Don't off-shore development, ever. Don't use consultancies, ever.
2. Hire the best developers you can - not too many of them - give them the best tools for the job and trust them. If they're all contractors - so what? Pay them well. Treat them well and respect that they may be smarter than you. That's fine. Don't hire anyone thicker that you, ever.
3. IT managers all the way to the top should've coded in their career path; trust no manager who doesn't know at least one OO or functional programming language; they are a waste of space.
4. Report anyone who tries to micromanage to their manager and to HR. They have personality problems and have no place in your firm.
5. "Agile" is not a replacement for "Talent" or "Understanding". Talented developers who are given trust and freedom will be naturally agile.
6. Nor is "Devops".
7. When people "sprint" they aim to run as fast as possible with little regard for the later consequences to them or to others. People can't sprint forever, but only in very short and infrequent bursts. Think about it.
8. They are not "the users"; they have names, jobs and they are your colleagues. Ensure you and your team know them and what they do and that they know you.
9. "The cloud" is computers you don't own, run by firms that don't care about your business as cheaply as possible. Use it if you must, but it's more risky than on-premises, every time.
10. Unit and functional tests are your friends.
11. Get rid of bullies and twats immediately. If you give them a second chance, you are just validating their rotten behaviour. You can't cure them, don't waste time trying.
12. Diversity is fine but a talented team who gets on with each other is way better, despite what HR might want you to believe.
Number 12... A stock question on our HR standard formatted interview now is to ask what you think is the benefit of a diverse workforce? An interesting philosophical experiment is to hire a team of 12 clones identical to yourself. I am quite sure I would be driven quite, quite mad in such circumstance.
At the other extreme hiring people just to satisfy some arbitrary must have a mix of age, gender and pigment at the expense of capability is equally daft behaviour.
Reality, like everything, is in moderation and prescriptive HR-ese policies on I&D serve only to run counter to needs.
Diversity is a interesting issue, how do you define it? A diverse range of skills can be very useful as are diverse personalities, within limits. Most other criteria are arbitrary, should you have the 'correct' number of employees who are from Devon? Anyone growing up in Devon is not going to have the same opportunities that growing up in London provides so they will need a little extra help to make the cultural shift and should not be held back by prejudice against their yokel dialect. It is a facetious argument but where do you stop the in diversity debate.
While I pretty much agree with all of your points, I don't mind working with contractors that are technical specialists. Team composition should be around personality, skill and general capabilities. You generally need more than one type of tool in your belt to create a system.
The big unacknowledged issue is that banks have lost a huge amount of business knowledge. If you want to build a new system you need to know what and how and why the current system does what it does .
The staff in head office who have never been without the existing system and have not been in their current role more than 18 months are useless SME.
Your principles are sound, and you might be able to pull this philosophical change off in small enterprises.
The big banks are far too big for this to be implemented on a day to day basis. Most are like oil tankers and take years to turn. You can put the tiller full to Starboard (or Port, don't want to discriminate), but she's not going to change direction quickly. It takes a long time for all the parts to get the idea they're moving in a new direction, and you have multiple layers of managers who report through each other, and they don't learn new tricks quickly - they're managers ffs, they know how to do this!.
#cynical
I have worked in COTS package implementation, system integration, data centres, DR, infrastructure design, testing and operations at different time. I've an engineering masters, various IT body certifications and I've never ever coded in my career. I've had to do a hell of a lot of scripting and some code reviews but I have never coded anything since a half assed robot control programme in college during the last century. Don't assume your career path is the only career path.
One advantage of public cloud is that to implement anything there you have to be able to describe it and the vendors generally offer good patterns and guidelines that mean it's harder to do something completely stupid without anyone noticing than in your own data centre. Just figure out how you plan to monitor and manage everything before putting it live.
Integration tests, operational tests - just because it works doesn't mean it works with everything else. This is probably coming from someone with a coding background (see 3) who doesn't see scale and complexity.
Get some young smartarses straight from college, get some greybeards, get some women, get someone whose spoken english isn't too good and makes you explain in simple language. I can't see my own blind spots and neither can anyone else my age, educational and cultural background.
PS: I work (currently) for a large UK bank
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
