tag:blogger.com,1999:blog-8764541874043694159.post11166884327783361..comments2024-03-28T12:23:39.665+00:00Comments on Coppola Comment: The legacy systems problemFrances Coppolahttp://www.blogger.com/profile/09399390283774592713noreply@blogger.comBlogger38125tag:blogger.com,1999:blog-8764541874043694159.post-31320288242665351492013-12-18T00:42:28.704+00:002013-12-18T00:42:28.704+00:00Frances
I was directed to your blog by a colleagu...Frances<br /><br />I was directed to your blog by a colleague... and what a great read.<br />You (and various other people in this blog post) have accurately reflected the current state of banking IT... and even a step beyond, i.e. the asset managers, custodians etc.<br /><br />In my past 20 years in the industry, it is scary to see what really happens 'under the hood' of these great institutions. What I first saw in the early 90's, is still common practice in many organisations that often pride themselves of being leaders in good governance, risk management etc.<br /><br />Excel is still a common culprit when looking at 'wrapping' around a core application, founded on a 1970's vision.<br /><br />When some people say there are 'dozens of layers'... in my experience, we often see hundreds of applications wrapped around a core system. Yet, the industry is suffering from lethargy and a willingness to act. Not many people will disagree that there is a strong need across the industry to rectify this problem, but not many are willing to take the long term risk and project on their hands.<br /><br />Recent news of large major IT projects that have failed (ref: http://www.cio.com.au/article/533907/worst_it_project_disasters_2013/) is not increasing comfort levels with IT Managers. Also, statiscally smaller projects have a much higher success rate (70%) than larger ones (10%). Yet, this does not remove the current critical state of the industry and the need to act. Question is - who wil be the last to act, and who would want to be in that situation?<br /><br />It is estimated that at least US$20trillion (25% of the global assets) is currently at the mercy of legacy technology.<br />(Ref: http://www.simcorp.com/Knowledge/Industry-reports/Download-the-Legacy-Systems-Report)<br /><br />This is our pension and children's inheritance. Are we willing to have our future sitting on 70's technology, suffocating under 'wrapped' short-term solutions?Anonymoushttps://www.blogger.com/profile/08778640815887440511noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-32089687753211358372013-12-06T12:04:21.166+00:002013-12-06T12:04:21.166+00:00Of course it would be a huge project. That is prec...Of course it would be a huge project. That is precisely why I asked.<br />At least the subtext of this blog is whether the current systems will<br />sooner or later simply stop working. So from a shareholder’s point of view<br />the cost of a new system must be balanced against the possibility<br />of the greater evil of system failure bankrupting the entire bank sometime.<br />Go by the military maxim : hope for the best, plan for the worst.<br /> As for running in parallel, the one advantage of the current system <br />is that it actually works ( most of the time )<br /> and any new system must do at least as well.<br />The old system provides the benchmark, in other words.<br />If you take cash out of a cash machine that is trivial in terms<br />of VOLUME of data transmitted from machine to mainframe.<br />It would also be relatively trivial to send a COPY of that <br />data somewhere else ( any new system ). <br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-87309276437383573672013-12-05T20:14:59.515+00:002013-12-05T20:14:59.515+00:00If your system is processing 100 million transacti...If your system is processing 100 million transactions a day (figure plucked out of the air, but the true figure for a bank like RBS/Natwest certainly wouldn't be much lower), and if most of those transactions are happening online, how on earth would you run a replacement system "in parallel"? We're not talking about loading up a duplicate deck of punched cards for an overnight run. And that's supposing that you'd managed to build such a system - which would take much longer and cost much more than your shareholders would like. Philhttps://www.blogger.com/profile/07009879034507926661noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-7307737076477600702013-12-05T15:24:44.660+00:002013-12-05T15:24:44.660+00:00In terms of cost is it out of the question for a b...In terms of cost is it out of the question for a bank to<br />a) rewrite ts entire system from scratch;<br />b) keep the CURRENT system running unless and until the new version runs successfully in parralel<br /> for a least one year?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-35123997744985080452013-12-04T17:11:59.211+00:002013-12-04T17:11:59.211+00:00Just wandered in from Stumbling & Mumbling and...Just wandered in from Stumbling & Mumbling and was struck by this in particular:<br /><br /><i>banks like RBS are still running massive traditional mainframe computers. Their software won't run on anything else. I suppose it keeps IBM in business, but it is not what we might expect for a modern real-time, mission critical banking system.</i><br /><br />Did you ever chat with anyone from Lloyd's - or, more to the point, TSB - in your time in IT? At the time of the takeover, TSB were running their core banking system on a massive traditional mainframe (a Univac, as it happens); Lloyd's were running theirs on a variety of IBM systems. The TSB system was getting old (it had been built in the late 70s), it was written in Cobol over Assembler, and where can you get techies with Univac experience? It only had one advantage, which was that transactions were processed online and real-time. Guess which one Lloyd's Banking Group are using now.<br /><br />You don't need to black-box your legacy back-end (which, I agree, is a recipe for trouble) if the back-end system is good enough. When I worked with IBM midrange people - under siege at the time from NT & Exchange Server - they used to say that the definition of a legacy system is "one that works". That's certainly true when it comes to Lloyd's "legacy" mainframe.Philhttps://www.blogger.com/profile/07009879034507926661noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-77198482678139294122013-12-04T14:39:29.727+00:002013-12-04T14:39:29.727+00:00I don't know the cause of the recent problem b...I don't know the cause of the recent problem but the last RBS fiasco was caused by offshore outsourcing and the large number of UK technical staff that RBS has made redundant.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-35061688670432049432013-10-16T04:57:14.444+01:002013-10-16T04:57:14.444+01:00David Timoney, I agree that software is immortal a...David Timoney, I agree that software is immortal and hardware breaks down less often. The main point of the author which was not explicit is that human being are NOT immortal and when the people who wrote the programs die off (or retire, not to be morbid), so will the ability to keep these systems up and running. Anonymoushttps://www.blogger.com/profile/07880511177512900195noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-78158306572118568922013-07-16T13:09:33.825+01:002013-07-16T13:09:33.825+01:00Skill shortages? The Great global ruse!!
Unfortun...Skill shortages? The Great global ruse!!<br /><br />Unfortunately I feel our colleagues and thousands of other IT professionals have experienced the same fate. Careers become experience, and with experience come senior opportunities, and with senior opportunities becomes maturity. <br /><br />It was a sad day when the BCS endorsed through its publications the political stand to utilise outsourcing, offshore and increased graduate programmes justified as economic industry drivers. This has paved the way for economic benefits in the technical arenas and increased investment in the consultancies markets with reduced responsibilities within the industry markets. This has had a major impact on the UK past and current IT communities whom have given their lives and careers to building the IT presence in industry today. It is a “fitting tribute” to those whom have made the UK an industrial IT centre and major power from the past to today. The irony of these decisions are that with the loss of nurtured experience to support low cost IT models, provides newer, fresher, less experienced needs and hence has turned the IT career fore runners into a perception of more expensive, high risk and less adaptable work force. This of course is not true but is the perception and view taken by the businesses and the IT recruitment marketers to endorse their approach to resourcing. <br /><br /><br />I have been at the senor end of Business for many years and have seen how all these short term economic decisions will level out and the IT sector will not be as competitive as it is currently. At this point industry will look at the IT sector and ask why it can not achieve the major investment benefits it is using to gain market share and have a competitive edge. They will have no other option but to look to their own businesses and markets to make further economic growth. <br /><br />It is this day, which industry will ask what happened to all the long term IT career professionals as the market of expensive global consultancies or provision of standard solutions with reduced control, will be the market offerings to industry. I hope the BCS will stand and be counted for not providing the direction for both the industries it provides and the thousand’s of individuals whom have made the IT industry what it had become.<br /><br />The extremely sad aspect for many of today’s IT community, is that those of us with experience, that helped initiate and build the IT industry have spent most of our time forging diversification, as initially the market only provided a few main global providers in IBM, Honeywell and Wang to name a few. You could ask if the industry is going back on its self. <br /><br />As a result, attending the many Recruitment and Executive fairs and meeting some of the thousands of proven quality professionals whom have so much to offer, and are in their prime, both in maturity and searching for security, is surely the finest resource of all.<br /> <br />Kevin B Forbes MBCS CITP<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-61606023305005100362013-07-16T13:05:01.767+01:002013-07-16T13:05:01.767+01:00Frances,
I have only just found your blog. I agre...Frances,<br /><br />I have only just found your blog. I agree in essence with most of what has been said and peoples comments. How ever I feel there has always been another reason.<br />I have 30 years experience as a developer and career to a corporate VP senior bank Head of IT for largest Retail banks in Europe, and worked for all the main conglomerates. Now out of work for 8 years applied for over 7000 jobs and am 59 years old now. Age Discrimination and outsourcing has destroyed the nucleus of IT Professionals in the finance and banking sector. Two facts. Last year only 1.7% of young students took "A" levels for IT in the UK, with 14% taking mathematics. The country risks not having an IT sector in further years. IT companies in the UK are 1.3% in the top 500 companies where as in the USA IT companies are 17.9% in the top 500. <br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-80001935604424177062013-07-16T13:01:09.313+01:002013-07-16T13:01:09.313+01:00One possible business approach to escaping the clu...One possible business approach to escaping the clutches of the legacy core and all its wrappings is to start releasing new banking products that do not rely on it. Basically, if you want to start offering customers a new type of account, then you need to put the replacement core system in place to support those accounts.<br /><br />With a new, gradually proven core system running alongside, the business should then be moving towards only new products that run on the new system, gradually phasing out the older account types and potentially considering converting those that can (and are worthwhile to) be converted.<br /><br />I understand that this is a simplistic view, although it is one that is touched upon by a previous commenter suggesting that customers should just go to more modern banks. This split-personality approach provides two linked, but independent road maps for banking services and systems, while reducing the risk of a massive conversion.<br /><br />Thoughts?Anonymoushttps://www.blogger.com/profile/12842606260651074105noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-17517912979765571202013-03-18T09:30:58.878+00:002013-03-18T09:30:58.878+00:00Almost all banking software in the Northern Europe...Almost all banking software in the Northern Europe runs on ancient Java, if one is lucky. Thus old-timers are kept close by in dozens because they are the only ones who can understand it. <br /><br />Your claim: "things have not changed much since the beginning of the new millenium" is trueRobert Jakobsonhttp://www.discoveryourdesigner.comnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-36561197532664940422013-03-11T23:50:01.479+00:002013-03-11T23:50:01.479+00:00In the US, all SDLC costs can be capitalized up to...In the US, all SDLC costs can be capitalized up to the point of user training. Many companies do not elect capitalization. Some reserve treatment for only the largest, multi-million$ types of projects. <br />@pacecar86Anonymoushttps://www.blogger.com/profile/03611434221960730306noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-64295962399311732542013-03-11T10:48:27.303+00:002013-03-11T10:48:27.303+00:00Some thoughts:
-Companies outsourcing of individua...Some thoughts:<br />-Companies outsourcing of individuals with unique knowledge of the systems in question or the same time their lack of training employees have caused these issues to take place<br /><br />-The Business cycle is much faster/demanding than the ability of the IT department (Taking into account issues as above) to complete the required task. For example M&A action, can be quite demanding and instant but the IT systems will take years in order to reach a final stage.<br /><br />-Legacy systems can be an issue and there has to be a perspective of long term planning/replacement. This must be in place and must be tracked.<br /><br />I think the banks attempt to outsource everything and do not retain core knowledge has/had been a big mistake in the past. You cannot knowledge transfer many years of experience.<br /><br />From someone with initial background in the telco sector, I always found it quite scary how basic were the systems/software used/applied in banks.<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-2796823907905458882013-03-11T09:54:55.010+00:002013-03-11T09:54:55.010+00:00There is a fine line between "if it ain't...There is a fine line between "if it ain't broke, don't fix it" and sensible investment in new software through which a business can evolve seamlessly.<br /><br />The basic banking functions haven't changed for hundreds of years now but I suspect that is because the paper-based technology didn't change either. 50 years ago computers started to replace the paper trail and have generally proved their worth. <br /><br />Just as web-based applications now do more than just replicate the shop for which they were originally designed, and enable all sorts of new ideas to become profitable businesses, the same is unlikely not to be true in banking.<br /><br />I suspect no-one actually learns COBOL these days unless they are in a shrinking number of industries (although I would agree that C++ is not a good idea for transaction processing). This makes the whole process very expensive to run and places the power in a small number of (possibly outsourcing) organisations but also <br /><br />I think the underlying issue is that if London wishes to remain a major financial centre, its business processes need to be fit for purpose for the next 50 years. The recent problems at RBS raise some doubt about.John@TheMoneyPrinciplehttp://www.themoneyprinciple.co.uknoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-1156842313415781402013-03-10T16:48:34.341+00:002013-03-10T16:48:34.341+00:00Re "banking is restricted by the design of th...Re "banking is restricted by the design of these legacy programs". That isn't necessarily a bad thing. <br /><br />The core systems of a bank will cover traditional activities such as the posting and reconciliation of daily transactions between accounts. In terms of the business process, they are doing what used to be done with ledgers and quill pens. As the rules of account management have not changed much since the invention of double-entry book-keeping, there has been little need to change these legacy systems up until recently. <br /><br />The commercial push for real-time account updates and instant clearing is changing this, however many banks remain reluctant to upgrade their core systems. This ultra-caution is often attributed to the high risk involved in a switchover, but I think it also reflects a conservative desire to hang on to something that is at least comprehensible to bank management. <br /><br />The choice of programming language is a minor consideration. The real issue is architectural separation of the core ledger management (which you will always need) from the customer-facing apps (which may come and go over time). Retaining legacy systems has been an effective way of ensuring this prudent isolation.<br /><br />PS: Pedantic techie points ... <br />a) Ironically, legacy procedural languages like COBOL are better suited to ledger processing than object-oriented languages like C++. The strength of the latter is the ability to change the code (e.g. add a method to a class), but that is typically not a priority for a ledger system. <br />b) "One cannot black box software" - well, conceptually, that is precisely what you are doing when you create a class in OOP. This is the principle of encapsulation.David Timoneyhttps://www.blogger.com/profile/03568348438980023320noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-41477771490316544612013-03-10T16:03:47.887+00:002013-03-10T16:03:47.887+00:00I agree with YankeeFrank. Further, if you can'...I agree with YankeeFrank. Further, if you can't or don't read the code then you don't know how it works. Documentation is no good here because, over time, it becomes decoupled from the code logic so it may become misleading. If they don't know how their own systems work they must inevitably fall over; especially after they've outsourced the code maintenance.Jack Eddyfierhttps://www.blogger.com/profile/00546379110958307956noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-80630941202672134792013-03-10T10:28:27.553+00:002013-03-10T10:28:27.553+00:00It is not only the legacy support problem for soft...It is not only the legacy support problem for software and hardware, the multiple functionality and definition problems, the messy interfaces, the hack support, the manual intervention and above all the massive cost of such operations that have been highlighted in your post and the comments. <br /><br />It is the fact that banking is restricted by the design of these legacy programs. Contemporary object-orientated languages are capable of much more and with much more security and coherence, which would enable banking to become more efficient.<br /><br />The problem then becomes how to get to that position from where we are now because the longer this goes on, the more likely we will be to have a complete banking meltdown with catastrophic consequences. Maybe the way to go would be to migrate the legacy functions to the front end (with suitable firewalling and proper protection) and only when all the functionality is reproduced correctly over a long period of time, remove the legacy system completely. But no doubt there are committees of people trying to work this out as we write! And no doubt the antics of some macho senior management make that an impossible task. Targets and timescales are very difficult to achieve in such an environment.<br /><br />I suspect that these issues are common to all banks everywhere in the world, not just RBS and the UK. And if some smart upstart does bring in a contemporary IT approach, once they get big enough they are either crushed by the big guys or bought out. <br /><br />Whichever way, true competition is not working to the benefit of the customer paying the bill. So I suspect that only by regulation will banking IT ever be brought into the 21st centuryJohn@TheMoneyPrinciplehttp://www.themoneyprinciple.co.uknoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-306641993369474272013-03-09T19:58:21.683+00:002013-03-09T19:58:21.683+00:00@Dave Timoney
The GDP school argue that in our po...@Dave Timoney<br /><br />The GDP school argue that in our post-industrial (?) society investment in hard tangible assets is declining and is being replaced by investment in soft intangible assets. They argue that this trend has accelerated since the 2007/2008 crash and has now become significant. They argue that self-constructed (ie built in-house) intangibles exacerbate the problem<br /><br />They argue (I believe) that ONS has not caught up with this trend and continue to measure GDP in the way they always have. Consequently, the GDP school suggests ONS is not treating expenditure on intangibles as investment expenditure and that this new type of capital formation activity is being omitted from GDP (Gross Value Added). In particular, I believe they focus on the case of software development costs to illustrate their stance.<br /><br />I am not convinced because software development is labour intensive and most of a project's cost would be labour. Only a small portion of such a project's cost would consist of bought-in materials and services. Labour costs do not affect GVA calculations whereas the cost of bought in materials and services does.<br /><br />So in my view, the accounting treatment of self constructed assets (whether tangible or intangible), at least in cases where they are labour intensive, would have only a marginal effect on the GVA (GDP) calculation. <br /><br />Purchased intangible assets must be capitalised on the purchasing company's balance sheet as mandated by law. Moreover, it is likely that the selling firm will be classed by ONS as a capital goods supplier. The latter's output would be captured by ONS in the GDP figure as investment expenditure. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-81885027642845222522013-03-09T18:54:29.577+00:002013-03-09T18:54:29.577+00:00There are three problems with the theory that chan...There are three problems with the theory that changes in capitalisation policy might be influencing falling productivity.<br />1) Inhouse software development is unlikely to be sufficiently large in GDP terms to make a material difference.<br />2) Productivity went into a nosedive in the last few years, which would imply a sudden change in policy. Why would this happen?<br />3) Had there been a change in many companies simultaneously, the auditors would have noted this. This would have brought it to the attention of the ONS et al.David Timoneyhttps://www.blogger.com/profile/03568348438980023320noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-38579258666556966962013-03-09T18:52:15.180+00:002013-03-09T18:52:15.180+00:00This comment has been removed by the author.David Timoneyhttps://www.blogger.com/profile/03568348438980023320noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-70725863979574780442013-03-09T17:50:44.030+00:002013-03-09T17:50:44.030+00:00@Dave Tomoney
Yes, it seems software development ...@Dave Tomoney<br /><br />Yes, it seems software development costs fall under SSAP 13, the accounting standard related to R & D. You are correct that a company has a choice over whether to capitalise or expense qualifying development expenditure. My only concern is that the Companies Act requires financial statements to show a "true and fair view". I personally don't believe that expensing qualifying software development costs, as per Frances's post, does show a true and fair view. It's only a judgement, I know, but one I am happy to defend.<br /><br />@Frances<br /><br />The reason why I picked up on this issue is that it ties in with competing explanations of the UK's productivity puzzle. As you know, one camp suggests that GDP is being under stated by ONS, and the other school looks to the UK labour markets for an explanation.<br /><br />The GDP school argues, I believe, that GDP (or gross value added) is being understated because of the practice of expensing internally created intangible assets. The expensing of software development costs, which they believe, correctly in my view, should be capitalised is a stark example of their case, I believe. <br /><br />I am skeptical that GDP measurement is very sensitive to this matter but, nonetheless, the topic itself throws up some interesting issuesAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-65239182269078896752013-03-09T14:31:16.135+00:002013-03-09T14:31:16.135+00:00One cannot black box software just like one cannot...One cannot black box software just like one cannot black box hardware. Well, more accurately, one can do these things, but in time, hardware degrades and requires replacement, and software becomes obsolete. Patching on functionality as is done in banking and likely every industry is a hack, and in time all these hacks become a mess. Its hard to believe anyone with knowledge of software design principles and practices (e.g., code must only provide specific functionality in one place) would argue this point. Unless of course their job depends on toeing that line. YankeeFranknoreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-72633104588189686562013-03-09T12:00:18.362+00:002013-03-09T12:00:18.362+00:00In-house software development can be capitalised (...In-house software development can be capitalised (though you're not obliged to) and amortised over the useful life of the asset. The costs can include design, development and testing, as well as project management and implementation. Training has to be expensed. <br /><br />Once capitalised (i.e. on the asset register), the software may also be eligible for capital allowances in respect of R&D, though this requires you to convince HMRC that you've essentially invented something you couldn't buy off-the-shelf.David Timoneyhttps://www.blogger.com/profile/03568348438980023320noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-74217330550117463232013-03-09T11:45:39.747+00:002013-03-09T11:45:39.747+00:00My point was less about the technology and more ab...My point was less about the technology and more about the metaphor. Of course you cannot expect all software to remain in use for ever, but the fact that bank systems retain this "legacy" core is telling, and I'm sceptical that this reflects solely a reluctance to invest in infrastructure. Banks pay ridiculous sums for IT contractors with legacy skills, so they don't lack imperatives for change.<br /><br />What I think is interesting about the "legacy" issue at banks is that it points to the dual (and conlficted) nature of the industry: a dull and conventional core purpose (let's call it Captain Mainwaring) "wrapped" within an outer shell of dodgy customer service, product mis-selling, and leveraged trading (let's call it Fred Goodwin).<br /><br />RBS's "system problems" look to be human failings, and specifically errors in operational planning and risk management. Sound familiar?David Timoneyhttps://www.blogger.com/profile/03568348438980023320noreply@blogger.comtag:blogger.com,1999:blog-8764541874043694159.post-30884969521937372432013-03-09T01:10:14.694+00:002013-03-09T01:10:14.694+00:00Well I don't know the specific circumstances o...Well I don't know the specific circumstances of your software projects or even whether your bank was accounting for its assets correctly. Perhaps not, given the bank involved and its record in other matters.<br /><br />A major in-house software project, as per the type you allude to in your post, is a capital project. The project's costs are easily traceable to the project (materials, labour and some overheads). These costs should be capitalised and amortised over the expected lifetime of the asset. <br /><br />Expensing the costs of such an asset (whose labour cost is likely to be high) in the income statement in the year(s) of construction would indeed give rise to the very problem you identify, where the bank is afraid to replace its system because of the impact on the income statement. This is a reason why such assets should be capitalised and why the bank may have fallen victim to its own flawed accounting. <br /><br />Had the asset's costs (including labour costs) been capitalised and taken to the income statement smoothly over the asset's lifetime, then the cost of replacement would not have the impact on the income statement which you suggest acts as a deterrent to the asset's replacement.<br /><br />Anonymousnoreply@blogger.com