I'd switch bank if I was one of the effected. It's very easy to do nowadays.
TSB outage, day 5: What do you mean you can't log in? Our systems are up and running. Up and running, we say!
Embattled bank TSB has claimed its IT systems are now "up and running" – despite many users still reporting they can’t get into their accounts. The bank’s online services have been down for almost a week, after TSB's planned migration off former parent Lloyds’ tech infrastructure – some five years after its split from the …
-
-
Wednesday 25th April 2018 14:14 GMT wolfetone
"I'd switch bank if I was one of the effected. It's very easy to do nowadays."
I wouldn't. I'd open another bank account with a different bank not connected to the bank you already have.
Why? Well at least you have access to some money if your bank has gone up shit creek with their 2,500 man years of work as a paddle.
I was considering dropping the Co-Op for TSB and have accounts with both of them, but as you can guess right now I'm feeling fairly safe(ish) that while I can't access my TSB account I still have access to the Co-Op one.
-
Wednesday 25th April 2018 13:58 GMT Anonymous Coward
All code is written by offshore idiots to the lowest price
This shitty code is in your medical devices, cars, industrial systems, phones, apps and most devices in your homes. It's present on every website you visit.
Insecure by negligence and stupidity, it's everywhere in your life.
But hey - psychopaths are running the companies that make this stuff & they don't give a shit. They are cutting cost to get paid. You are not the 1%, so fuck you.
-
-
-
-
Wednesday 25th April 2018 16:15 GMT colinb
Re: All code is written by offshore idiots to the lowest price
That's for clearing that up, in that case Accenture Spain is different to Ireland in that respect.
Spain is offshore to the UK in this case.
Worked out well for them, hasn't it. Normally their failures are kept very private. They should have paid more attention to how public this would be.
-
-
-
Wednesday 25th April 2018 17:33 GMT Anonymous Coward
Re: What about auto-updates?
There are idiots, offshore and onshore, in this and every other field. Bootnotes have served up many a tale.
The corollary to your statement then is that if you aren't the highest paid in your industry you are an "idiot" to someone else. There is some truth to this - we all don't know something..
The race to the bottom on price is where the problem is at. You get what you pay for.
-
-
Wednesday 25th April 2018 14:13 GMT Anonymous Coward
AIOOB and BeanFactory Exceptions being surfaced all the way to the front end HTML in a retail bank's customer facing web products, after it's been claimed that everything is fixed.
This may qualify as one of the more comprehensive failures of software engineering, testing and delivery that I've seen.
And yet that failure pales in comparison to the organisational failures and managerial incompetents that caused it happen.
-
-
Thursday 26th April 2018 15:35 GMT Anonymous Coward
"It's 2018 and people are still using arrays..."
... because in the hands of competent analysts and programmers they remain one of the best ways of representing a myriad kinds of data, and because, properly used, they enable the functionality of some of the most advanced high level languages available.
-
Friday 27th April 2018 10:00 GMT rmacd
The masochist in me wants to see some of this code. Especially where AIOOBs aren't being caught. The other part of me wants to see it just to give me an ego boost.
There is something intensely gratifying about seeing CIO's fucked over by outsourcing.
No doubt though, the blame will be pinned on the (non-technical) PM than the shitty devs who don't know their arses from their elbows.
-
Friday 27th April 2018 14:24 GMT Anonymous Coward
"Especially where AIOOBs aren't being caught"
The code is clearly Spring in nature, which means the entire application is almost certainly wrapped in a global exception handler; Spring often uses Exceptions as a standard control flow mechanism. This means someone has decided it's a good idea to pass through AIOOBs to the presentation layer (probably through a default catch & rethrow "handler"), and the presentation layer has decided it's a good idea to display internal Exceptions verbatim.
This is first year software engineering student shit that doesn't even pass static analysis, never mind professional code review. Stinks of a rush job.
-
-
-
Wednesday 25th April 2018 14:25 GMT Voidstorm
"Load Balancer Errors" is the clue
Having been a client-server Java developer for many years, this is the sort of thing you get in a postQA environment when you rollout a live solution and the stress-test hasn't been done well, and the stress-testing environment doesn't replicate the live one sufficiently effectively.
The internal resource shortages (threadpool, database connections, config problems etc are good examples) don't truly manifest themselves until a *genuine load* hits the *live techstack*; even with the best will in the world.
The fact that all three front end layers (Web, App and In-branch clients) are evidencing "Javabean" errors speaks to problems at the server layer of the architecture; hence the restrictions on number of logged in clients => less chance of server resource exhaustion.
Clearly there are issues with the not-so-adequate scale of the backend infrastructure. From experience, these are the hardest to assess from the point of view of a development team; even if the solution is properly written and tested, and passes QA, the live environment can hilight resource problems where the infrastructure isn't well provisioned.
And thats assuming a perfectly solid Dev/QA process, into the bargain
-
Wednesday 25th April 2018 14:41 GMT Anonymous Coward
Re: "Load Balancer Errors" is the clue
It seems they threw in Netflix's open source load balancer and hoped it worked. You can tell because the error gets thrown to the mobile app.
They're boasting about throwing together a mobile app for TSB in "SIX MONTHS" (17:40). Use cogwheel icon to switch subtitles to Spanish (Auto generated) then again to turn on auto translate.
-
Wednesday 25th April 2018 16:24 GMT Anonymous Coward
Re: "Load Balancer Errors" is the clue
Regardless of all the stuff about load testing etc (which would certainly be a good idea, but probably doesn't catch all possible errors).
*** You don't migrate 1.9 million users in one big bang, and with no rollback plan!!! ***
You migrate 1,000 of them. Then next week 10,000 of them. Then maybe 100,000. Then if you're being cautious, 100,000 every week after that for the next 18 weeks. And if you're messing with people's money and their livelihoods, you should be cautious.
At each stage you check for system errors and user complaints, fix the problems if you can, and if necessary migrate them back again until you solve the problems.
It's not rocket science. It's certainly harder work to plan and implement (directing inbound requests to the correct system where each account could be on one of two different systems), but it's the right way to do the job.
You will almost certainly discover a bunch of stuff that you didn't know about your user base, such as legacy products and services which nobody even realised were there. You might be left with a small runt userbase on the old system while you come up with a solution for how to move them. This is better than breaking them.
-
Wednesday 25th April 2018 18:23 GMT Anonymous Coward
Re: "Load Balancer Errors" is the clue
You migrate 1,000 of them. Then next week 10,000 of them. Then maybe 100,000. Then if you're being cautious, 100,000 every week after that for the next 18 weeks. And if you're messing with people's money and their livelihoods, you should be cautious.
Trying to run old and new systems in parallel just brings a whole host of unnecessary headaches. Trying to reconcile transactions in two disparate databases which may not have the same structure or schemas is destined for failure.
-
Thursday 26th April 2018 04:01 GMT Anonymous Coward
Re: "Load Balancer Errors" is the clue
Been there, done that and happens to be a specialty here as I migrate systems from mainframe to (network of) server PC's and, sometimes, even back to mainframe, too. It's when you can't do this that should start Big Ben loud alarms inside your head.
Extra-points for turning your validation feature into an additional biz continuity feature.
-
-
Thursday 26th April 2018 08:51 GMT eamonn_gaffey
Re: "Load Balancer Errors" is the clue
As a veteran of many such migrations of bigger proportions, I can attest this this is the only sensible approach. To go 'big bang' on something like this is just too risky. I'm guessing the reason TSB did it was because some megalomaniac in charge decided to go for the macho high risk approach, and fucked it up royally.
Interesting to hear Paul Pester,TSB CEO, on BBC Radio 4 this morning. Sounded very upbeat, almost smug (if you can beleive it), now that he has a global IBM team on board !. I'm sure that will be productive for TSB's customers (or rather, IBM in terms of fees generated).
.
-
Friday 27th April 2018 14:54 GMT RegMigrant
Re: "Load Balancer Errors" is the clue
I heard the same report and couldn't believe how confident he sounded 'now that IBM are on-board' - he still missing the point that no-one get's rich from out-sourcing by putting their best (and therefore expensive) people on an account. Now IBM will charge a small fortune for fixing the issues which his own team probably highlighted as risks but were ignored because the expensive consultants told the board it would all work out - and yes there's a level of bitterness in there. It always reminds me of the Monty Python surgeon telling a pregnant mother to be quiet because she's not qualified to have a baby.
-
Saturday 28th April 2018 16:04 GMT Experience ? whats that
Re: "Load Balancer Errors" is the clue
Acknowledging that I'm an old Global Telco networks design and test chap who is obviously way out of date and sees agile when used in large apps/ infra projects as a bit "overly risky" . Not being nasty to the customers who are having difficulty this sort of complete and utter incompetence isn't actually unusual in the dark side of IT where I've crossed over to. PMs think that Risk based testing doesn't actually ever have a bad outcome or think doomsday will come true... and if it does we can make loads of dosh with a patch and release programme using the all new singing and dancing dev ops / CI Super Dooper automated high quality approach. Well I hope that ... the Cinderella that approved the risk register that agreed to : . no comprehensive live like representative test environment .. ok: or lets not do rollback and fail over - ok ; or lets go for Big Bang migration - ok ... is now looking for a new job. Hopefully its not the Test manager who was most likely bull dozered by the wish to meet a date.
-
-
-
-
Wednesday 25th April 2018 14:45 GMT Anonymous Coward
That's the problem with mahooosive waterfall releases...
You can't break small and fix quick. I can only imagine the CAB meetings to pile up the requested changes and upgrades to go alongside each other. Not knowing what broke what (I've been there in the past scrambling to find out the multiple root causes) and using more firefighting time to plaster up the cracks until the breaks again.
Traditional banks just won't change :(.
-
Wednesday 25th April 2018 14:59 GMT Alan J. Wylie
loading failed for script
https://pbs.twimg.com/media/DbiPvH7WsAAj3Iu.jpg
"Loading failed for the <script> with the source "https://dpm.demdex.net/"...
"Loading failed for the <script> with the source "https://visitor-service.tealiumiq.com/"...
What on earth are these doing on a supposedly secure page?
-
-
Wednesday 25th April 2018 16:17 GMT Bill M
Re: loading failed for script
It's secure https won't last for long
(index):1 The SSL certificate used to load resources from https://www.tsb.co.uk will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.
-
-
-
Wednesday 25th April 2018 15:24 GMT AbelSoul
Still humped
Been trying to get in all afternoon.
Finally got in a couple of minutes ago and second stage of 2 factor authentication crashed.
Tried again and finally got to see a list of my accounts, tried to access one and was greeted with a "Thank you! You have successfully logged out of your account." message.
Omnishambles springs to mind.
-
-
Thursday 26th April 2018 15:45 GMT Anonymous Coward
Re: Still humped
"From here it seems to me that they should have added another 2,500 man-years on the project."
Not necessarily. Twice as much incompetence will not necessarily fix the problem.
The issue is more quality than quantity, at every level - design, project management, QA, programming, executive decision, security, operations, and probably a few things I missed.
-
-
Wednesday 25th April 2018 15:29 GMT Daggerchild
But it was tested! Look, the box is ticked, see!
I am currently looking at another department making a staging environment for the stuff run by our department.
This staging environment looks, and acts, nothing like the live one, and is made from different tech. This has been explained, at length, to no effect, since the parts involved have the same *names*, that's good enough for them.
So, I entirely understand how TSB came about. I'm betting they have the loadbalancer in DeathBeam mode (concentrate all firepower on first backend to stand up, it goes into swap death, drops, restarts, slowly, meanwhile you wait and fry the next to stand up, rinse and repeat). On paper they genuinely have enough backends for the load...
-
-
Wednesday 25th April 2018 16:17 GMT katrinab
Re: Just emptied my account.
I'm going to bet that it will clear.
They have to respond by a deadline if they want to bounce it, and they won't. So it will be paid into your account, and not reversible because it isn't a fraudulent transaction.
What happens at the TSB end is another matter.
-
Wednesday 25th April 2018 18:13 GMT Ken Hagan
Re: Just emptied my account.
"They have to respond by a deadline if they want to bounce it, and they won't. So it will be paid into your account, and not reversible because it isn't a fraudulent transaction."
So any non-fraudulent (ie, you have the balance in your account) movement of funds out of TSB towards some other bank will clear in the usual time, but TSB might end up with an even bigger mess on their hands as a result.
Hmm ... That sounds like something that a lot of TSB customers ought to know.
-
Wednesday 25th April 2018 20:26 GMT katrinab
Re: Just emptied my account.
Even if you don't have the funds, but it is a "normal" level of transaction, ie don't write a cheque for £1m if your balance is 10p, then it will likely clear, but of course they are entitled to charge the usual unauthorised overdraft fees and ask you to pay it back. They have 6 years to do that, or 5 if your account is with a Scottish branch, sort codes beginning 87, which is around 1/2 of all customers.
-
-
-
-
Wednesday 25th April 2018 15:59 GMT Allonymous Coward
It's getting to the point where I hope this kills the company
Or at least severely maims them. Every so often the beancounters need a sharp lesson in what happens when you treat IT as an overhead and farm it out to low-cost body shops, rather than treating it as a core part of delivering your business.
-
Wednesday 25th April 2018 16:07 GMT Anonymous Coward
Fungible software engineers...
I had heard this so many times I had given up even discussing it any more. Then one fine day someone tried it at my current place of employment. The business hated it, the staff hated it and questions were asked. Ultimately the exec responsible for bringing it in was removed. Management still discuss this time and it's viewed as a big mistake.
Just because someone writes code for one application solution doesn't immediately make them fully skilled to work elsewhere even if it's the same language. It takes time to learn the existing code base, application domain, business policies and procedures. Unfortunately the C-suite types aren't aware of any of this.
The roles I find immediately fungible are the C-suite roles. There are laws to followed and regulators to obey. These are going to be largely the same for each organisation, can't these roles be outsourced?
Anon, for obvious reasons.
-
Wednesday 25th April 2018 17:10 GMT colinb
Re: Fungible software engineers...
This still surprises me. I've seen Oracle people put in to do a large SQL Server site, it didn't go well.
Its the same as saying look you fly an Airbus, just jump in that Boeing and do these runs for us please.
They are both planes, has a couple of engines, wings, steering wheel of some sort. I mean what's the problem.
The problem is its quite likely the plane would crash with all souls lost.
The regulators stop this with ratings, if you have not passed training in the type you cannot fly it. You can't even fly an A330 if you are rated on a A320.
That's why we have regulators and not PHB making these decisions.
-
Thursday 26th April 2018 11:15 GMT CrazyOldCatMan
Re: Fungible software engineers...
doesn't immediately make them fully skilled to work elsewhere even if it's the same language
The same holds for support skills - about 30% of your effectiveness is *site* knowledge (ie - yes, you needs to do this in order to get that to work - even if it's not the $VENDOR-approved way of doing it because that's the way it works in *our* environment).
Which is why the outsourcing model of 'assigning a support person from a pool, none of which know anything about your environment' is generally a disaster. Unfortunately, all the beancounters see is 'we are getting 5 people's experience for the cost of one!'.
-
-
-
Wednesday 25th April 2018 16:51 GMT colinb
Re: The Post-COBOL Apocalypse Has Arrived!
Actually given the information on other threads it seems like Proteo4UK is based on the Parents Proteo which is based on the Alnova banking systems which was a port of the Cobol version but retaining the Cobol syntax, so Cobol compiling to .NET using MicroFocus tools.
Any pro would have parsed the cobol and extracted the business logic, created a banking DSL and throwing away the god awful verbose Cobol syntax.
11 millions lines of code but easily 8 millions lines of framework crud.
That's actually probably the most stable part, the issue here seem to be the middleware and frontend services. All the new code basically.
-
-
Friday 27th April 2018 12:39 GMT Steve Channell
Re: The Post-COBOL Apocalypse Has Arrived!
So, the Java server falls over with EJB errors caused by Spring dynamic instantiation, and dumps unhandled error messages in the browser because of dodgy JavaScript code.. but lets all pile in and kick the COBOL code that works, and stops the money vanishing into suspense accounts.
MicroFocus COBOL has been porting mainframe systems for forty years, and running on .NET Common Language Runtime for twenty years.
-
-
-
-
-
-
Wednesday 25th April 2018 18:39 GMT d3vy
Re: Blimey! This outage is the most outrageous since...
Dont forget communication... Ive yet to receive any kind of acknowledgement from TSB that there is a problem or any communication of timescales etc.
No Text, No Email nothing.
I knew it was still fucked because my card didnt work on sunday night Ive got status updates from facebook and the news.
Now I imagine some of TSBs older customers might not be on facebook monitoring the TSB page for news... They might be in for a shock when they try to buy their shopping.
-
-
-
Wednesday 25th April 2018 19:46 GMT Uberior
I'm wondering if the details of people who have posted on social media are being harvested right now by crooks ready to make the call:-
"Hi, It's Sonia from TSB. I'm really sorry about the trouble you've been having with your account. Can I take you through security and we'll start to get things sorted out..."
Most of the cheques written in the UK are still using the heritage system of shifting bundles of paper around the country. I hate to think about the risks facing TSB right now if they haven't got a clue about the balance of their customer's accounts when the cheques hit. If someone timed it right by banking a large cheque on Thursday to hit on Monday in hope of system issues. The money will have cleared and swiftly moved on by now.
Tomorrow and Friday will be fun. It'll be payday for:-
Anyone who gets paid weekly.
Anyone who gets paid on the last Thursday/Friday of the Month
Anyone who gets paid on the 26, 27, 28 , 29th
It's going to be bloody.
-
Wednesday 25th April 2018 22:04 GMT Anonymous Coward
Former HBOS employee here, one that left prior to the crash and the redundancies that followed. We spent a decade modernising HBOS sales-side infrastructure; taking client side stuff off Z/OS into onto Windows Client/Server arrangements. Quite successfully if I do say so myself. The backend remained on Z/OS. A year after I leave, Lloyds get their grubby mitts on it and roll the whole shebang onto an old-school TSB-derived mainframe system. Leftovers from TSB first time around, not the "new" bank. No doubt this is the same system that was foisted onto "new" TSB. Owing to separation requirements, they were no doubt given marching orders to migrate away. Or advice that mainframe is old hat and hard to maintain. Maybe both. There is absolutely no illusion to anyone concerned that this was a very, very wet run of the migration that HBOS (under Lloyds ownership) will now have to repeat to exit mainframe legacy. Not to mention Lloyds itself (which I understand is also on an old TSB-derived mainframe!) Not saying any other banks are any better, but let's be honest, the proof is in the pudding. None of what is left of what used to be respectable organisations have a scooby do. Damn shame. Blame squarely pointed at the Exec and laissez-faire global non-regulation.
-
Thursday 26th April 2018 09:35 GMT Uberior
At the front end, I recall switching from the legacy NCS to Core Banking System. Whilst CBS wasn't pretty to look at it, I don't recall it ever going "down" during the time it was in use and was amazingly quick to use.
Then we switched from CBS to Lloyds CBS - awful. Glad I left.
(When I started work, we were still keying on a 3604 terminal and had microfiche in the sub-offices.)
-
-
Wednesday 25th April 2018 23:06 GMT Anonymous Coward
test1.int.uk.tsb
I wonder if the fact that the login page seems to attempt to want to load JavaScript from test1.int.uk.tsb might have anything to do with it?
Aren’t you supposed to configure your build system so that all references to the test environment are replaced with the correct values for the live environment when you actually go live?
And why do so many internet banking systems rely so heavily on just so much JavaScript? Surely that’s the first thing that a would-be hacker would try to compromise to see what sort of weaknesses they could exploit?
(At least this shows that they do have a test system, anyway!)
-
Thursday 26th April 2018 04:57 GMT Anonymous Coward
I'm a Tech Recruiter and not an Engineer so what follows may be bunkum. I suspect the major root cause of this lies with what I believe to be a migration to an IBM BlueMix and Microservices environment. More specifically, they used guys with J2EE & WebSphere, etc. skills who grew up building solutions in monolithic environments. In their rush to go Cloudy these J2EE guys don't yet have the expertise to build and test Microservices properly. Put another way, they're looking at their Cloudy environment through old, monolithic prisms and have created a massive TITSUP in the process.
For an effort of this magnitude, using BlueMix & Spring Boot Microservices, you need top, top, Engineers. i. e. FAANG quality guys who ain't cheap and don't reside offshore. It's all well and good jumping on the latest tech trends but if you ain't got the staff to do the work....well,you get shit like this.
-
Thursday 26th April 2018 15:53 GMT Anonymous Coward
"For an effort of this magnitude, using BlueMix & Spring Boot Microservices"
And there's your problem right there.
The whole 'microservices' concept is another of the miracle cures that pop up in IT every few years, and often do way more damage than they cure.
"Microservices" is ill-conceived and will probably die a well deserved death relatively soon, if we are lucky.
-
-
Thursday 26th April 2018 04:58 GMT Anonymous Coward
TSB's New Platform
TSB's new stack - that is, Sabadell's - comprises the following. This is from an employee's LinkedIn profile. Again, I bet their engineers are traditional J2EE/JEE guys who have no clue about Microservices development & testing in Cloudy environments. It's a very different animal to old-school monolithic software development.
Component of the BancSabadell Architecture team in the TSB project (TSB Bank in UK acquired by BancSabadell group) for the definition and implementation of a new banking platform based on the latest technologies and methodologies and oriented to a hybrid infrastructure between on-premises and public cloud
Technologies:
-PaaS (TIBCO SilverFabric)
-Micro services (Spring Cloud Netflix)
-SOA (TIBCO AMX Service Grid, TIBCO BusinessWorks, TIBCO API Exchange Gateway)
-Single Page Application (AngularJS)
-Asynchronous Messaging (TIBCO EMS)
-APM (Application Performance Monitoring)
-Distributed Search & Analytics (ElasticSearch)
-Containerization (Docker)
-
Thursday 26th April 2018 06:55 GMT hypnos
Have witnessed several bank migrations done by "offshore idiots". . .
. . . in Banks that could be named "provincial" compared to the UK/Western Europe behemoths. Never seen such shambles. Now that I think of it, there was this project by Accenture in Greece in the late ninetys. They just could not finish the implementation of a new system called Altamira. Eventually the customer bank threw them out and took over code and all. Migrated successfully in a few months. System running happily until present with in-house staff and monthly development cycles.
-
Thursday 26th April 2018 07:02 GMT Anonymous Coward
TSB, legacy IT
Back in 2004 I remember visiting the head of an IT department that had responsibilities for TSB's IT. There was an enormous system map diagram on a huge whiteboard in the guy's office, it wasn't pretty with lots of old systems cobbled together that somehow just 'worked', many undocumented and originally written in house. The challenge back then was that the IT team had an average age of 55 and final salary pensions that were going to kick in at 60, it was a ticking time bomb some 14 years ago...
-
Thursday 26th April 2018 10:29 GMT colinb
Re: TSB, legacy IT
They have just replaced that enormous system map with a new one, full of Service Buses, SOA, MicroServices and Containers (Docker). This will be even less documented as event type systems are very hard to reason about.
So its new, you can add new services quicker but is it better?
1. You have probably created more links, not less. With products you have to keep upgrading introducing who knows what issues in future.
2. The old system had known failures and all the main wrinkles stomped on over time, decades probably.
3. The new system has a whole new batch of failure modes, both in the scale, links and the logic some of which have yet to be found.
4. End to end testing now involves a mass of products that probably means a single developer will never see it in action, just a small piece.
The people there on the old system probably sat quietly, keeping the systems humming, to a foolish person it looks like they are doing nothing since the systems always work.
My take away, if you are going to replace decades of work, even with a huge head start of a running banking system, 24 months is not enough time, you need multiple end-to-end test environments with realistic load testing and you need real experts in the tech you will be using.
-
Thursday 26th April 2018 15:56 GMT Anonymous Coward
Re: TSB, legacy IT
"My take away, if you are going to replace decades of work, even with a huge head start of a running banking system, 24 months is not enough time, you need multiple end-to-end test environments with realistic load testing and you need real experts in the tech you will be using."
And you need to choose the right tech, which is not always the newest tech.
Anyone remember the "second system effect"?
-
-
-
Thursday 26th April 2018 08:38 GMT GSTZ
Shiny new systems ...
From yesterday's article: "TSB migrated from former parent Lloyds Banking Group's systems to shiny new ones" ...
Moving from centralized and highly deterministic systems to "shiny new" systems that (from the outside) may even look centralized too, but are in fact a highly complex conglomerate of many thousands of "PC's" all doing more or less their own thing but also being dependent on the outcome of many other "PC's" to complete their tasks isn't easy. It doesn't help much that these "PC's" are no longer small separated physical machines like in the early days of distributed computing, rather myriads of virtual machines running on some kind of x86 infrastructure coming with bombastic marketing wording but behaving like a bunch of PC's anyway. Predictability suffers, such systems are certainly "good enough" to handle enormous workloads for less critical applications like Facebook and Twitter but might be less than ideal for really critical stuff like banking operations.
This is not crying for the good old past based on legacy systems, as it has already been pointed out that old systems eventually become a real pain when too much new functionality gets added. At some point, it is better to start with a clean slate - but also on a highly deterministic system providing better reliability, predictability and security than the "good enough" gear that has become the de facto default for each and every new application these days. Unfortunately, most of the younger IT folks do not even realize that alternatives do exist.
The prevailing hardware stuff comes relatively cheap, but the business results tend to be mixed as reliability, efficiency and security have "room for improvement" and the cost to run and support those very complex systems becomes too high. Many user organisations now do escape to the public cloud, even the military are now considering such moves. However, it is unclear how cloud providers having less knowledge of the business requirements and less incentive to provide superior service levels for critical applications will be able to serve their customers better.
-
Thursday 26th April 2018 15:59 GMT Anonymous Coward
Re: Shiny new systems ...
"However, it is unclear how cloud providers having less knowledge of the business requirements and less incentive to provide superior service levels for critical applications will be able to serve their customers better."
And it appears very doubtful that cloud solutions can be made secure, partly for technical reasons, and partly for legal reasons (recent US laws giving them - thousands of US organizations - access to anything anywhere that a US company can somehow get, as one example of many).
-
Thursday 26th April 2018 09:58 GMT GSTZ
Wrong architecture ...
From today's article: "Shujun Li, professor of cybersecurity research at the University of Kent, said the main issue was not the initial failure – modern IT systems are too complicated and dynamic to be totally bug-free, he said – but because of the bank’s poor risk management."
Many people would agree to the above opinion, but only few would be willing to draw the resulting further conclusions: Modern IT systems (ie., the currently prevailing "good enough" stuff) are far too complex to provide deterministic behaviour and predictable results automatically by themselves. Hence, a lot of additional and pretty difficult work needs to be done to raise service levels beyond the threshold of "good enough". Which means that the number and severity of complaints need to be reduced far enough that an overall impression of somewhat acceptable system behavior can be achieved - which however isn't exactly the level of reliability one should expect from critical IT systems, and it is pretty costly too. How about another IT architecture that delivers more predictable results ? That's not rocket science, it has been done in the past and it is done in other areas like industrial IT and OT.
Maybe sometimes not having access to your account or somebody else having access to your account isn't seen as a major problem in today's banking industry. In industrial IT, the equivalent would be frequent production outages and small explosions all over the plant every once in a while ... (;-))
-
Friday 27th April 2018 07:34 GMT Potemkine!
This story shows how we became dependent of online apps. When the next major solar storm will hit Earth and disrupt everything, it will be chaos.
Biting the hand that feeds IT
