• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Interesting Read From the Guardian

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #11
    Originally posted by BlasterBates View Post
    My experience in banks is that they usually have redundancy that developers are not aware of because they only know their bit. One bank I was working at had a spare trading room. Had the bank been nuked then then a moth-balled trading room could have been switched on and up and running in miinutes. I only know about that one because I had to work on it. I think all but the smallest banks wouldn't have duplicated their systems and thought about things the person in the article hadn't thought of like fire, or a break in, and could certainly deal with a hamfisted adminstrator.
    The DR in banks is usually well developed with duplicate sites and systems that can be switched over to quite quickly and effectively. However, what the guy was talking about in the article was the over-complexity of the systems and the inherrent interdependency within the IT landscape.

    I've been involved in a few migration and decommissioning projects in various places and it is a nightmare to try to work out the tangled threads that have been put in place by successive projects. It is perfectly possible for the failure of a single component to have a widespread impact that crops up in all sorts of unlikely places. The banks do have lists of applications that are categorised by the impact on the business if it becomes unavailable. However, I don't think they are as proactive with identifying the critical parts of the underlying infrastructure. There used to be individuals within the organisation that knew what was important, but, with the rush to outsource everything, this knowledge has been lost in a lot of cases and the scenario where a major bank gets into some serious tulip because of the failure of some obscure part of its IT systems is very believable.

    Comment


      #12
      Originally posted by alluvial View Post
      The DR in banks is usually well developed with duplicate sites and systems that can be switched over to quite quickly and effectively. However, what the guy was talking about in the article was the over-complexity of the systems and the inherrent interdependency within the IT landscape.

      I've been involved in a few migration and decommissioning projects in various places and it is a nightmare to try to work out the tangled threads that have been put in place by successive projects. It is perfectly possible for the failure of a single component to have a widespread impact that crops up in all sorts of unlikely places. The banks do have lists of applications that are categorised by the impact on the business if it becomes unavailable. However, I don't think they are as proactive with identifying the critical parts of the underlying infrastructure. There used to be individuals within the organisation that knew what was important, but, with the rush to outsource everything, this knowledge has been lost in a lot of cases and the scenario where a major bank gets into some serious tulip because of the failure of some obscure part of its IT systems is very believable.

      whs

      Those lists are probably worse than useless for anything other than managers covering their arses.
      And what exactly is wrong with an "ad hominem" argument? Dodgy Agent, 16-5-2014

      Comment


        #13
        Originally posted by Mich the Tester View Post
        whs

        Those lists are probably worse than useless for anything other than managers covering their arses.
        But can be useful when trying to identify the bits that you really have to test when rolling out upgrades to bits of the infrastructure. Quite a surprise once to discover that if HiPort went, that the entire group (not just the division) would cease to function within a matter of hours. Always ensured that got tested even if the bit I was impacting just blew some vague kisses with a coquetish wave in its direction.

        Comment


          #14
          Originally posted by alluvial View Post
          But can be useful when trying to identify the bits that you really have to test when rolling out upgrades to bits of the infrastructure. Quite a surprise once to discover that if HiPort went, that the entire group (not just the division) would cease to function within a matter of hours. Always ensured that got tested even if the bit I was impacting just blew some vague kisses with a coquetish wave in its direction.
          That's the kind of bug I just love reporting.
          And what exactly is wrong with an "ad hominem" argument? Dodgy Agent, 16-5-2014

          Comment


            #15
            In my opinion most financials have lost control over IT, the number of systems now in these places it crazy and grows at an alarming rate, I often see new products being launched that should have been extensions in existing systems that nobody wanted to touch, I maintain 5 applications just now on my own, when I first started working in banking it used to be teams looking after single apps.

            Another thing about banking is the life cycle of products, there is usually a team of up their own arse permie anointed ones who get first write of a new product then it gets passed onto some other bunch of schmucks to run in version 2,3,4... and then maintain till death. The problem with that model is the initial developers do not get to see how inflexible their initial system is when trying to shove in a large scale enhancement on later versions (that is when the hacks come in and technical debt goes through the roof), nor do they live with ongoing support issues caused by basic errors in the initial design. So these people who are usually under some arsey title "architecture and initial release team" or such like never learn to write better software through living with their mistakes and they keep churning out pish.

            Comment


              #16
              The Basic Laws of Human Stupidity
              And what exactly is wrong with an "ad hominem" argument? Dodgy Agent, 16-5-2014

              Comment


                #17
                I remember reading some stat that if the UK still had manual phone switch boards half the population would be employed routing calls to all the mobiles we have now. Probably made up but I would think it does have some basis in fact.

                I see the same problem with software, Britain is in no way capable of maintaining the software it requires to function by internal means, our systems are so badly written and so unmaintainable that we have to offshore and I see that trend exponentially rising.

                I am back at a place I was at 6 years ago, despite the down turn staffing levels have only dropped slightly in the UK office but they seem to have added a few thousand offshore Indians, the business model of the bank has not changed but everyone went crazy with SOAing their legacy apps so it is now a maintenance nightmare.

                If things keep going on as they are there will be a software heat death of the universe time point where we cannot maintain our software through internal and offshore means. (I will work weekends for double time if that helps)

                Comment


                  #18
                  Originally posted by minestrone View Post
                  I see the same problem with software, Britain is in no way capable of maintaining the software it requires to function by internal means, our systems are so badly written and so unmaintainable that we have to offshore and I see that trend exponentially rising.
                  The problem is that we offshore the development as well as the maintenance which only makes matters worse.

                  Comment


                    #19
                    Originally posted by Mich the Tester View Post
                    POTD.
                    While you're waiting, read the free novel we sent you. It's a Spanish story about a guy named 'Manual.'

                    Comment


                      #20
                      Originally posted by Bunk View Post
                      The problem is that we offshore the development as well as the maintenance which only makes matters worse.
                      Current client co have learned their lesson with that, seen a £100,000 estimate for a system to be built in India hit £10 million and when it got back onshore it cost a good few million to fix. The internal team quoted 8 million for build and management laughed and signed up with the bobs.

                      Client co no longer gives first version work to India.

                      Comment

                      Working...
                      X