The original designs were generally OK. The main problems were that systems documentation was usually terrible and was seldom or never maintained once the system was up and running. I've worked on sites where the analyst team solved *that* problem by shredding their records once a change had been designed, implemented and was up and running live. I've also worked on far too many systems where the only reliable documentation was the program source - and you just had to hope that the variable names and comments were written to help rather than hinder future maintenance.
Of course, it doesn't help when the documentation is on paper and the program sources are on cards or paper tape: the chances of the two being even vaguely in sync approximates to zero. I suggest that the un-noticed revolution occurred when source version control systems, e.g CVS, came into general use and so let the documentation and program source be stored in the same place and maintained together. The only advance on that is something like the JavaDocs utility, which lets module-level documentation be included in the program source, where it has at least a small change of being kept up to date.
However, these aren't any use in the face of a PHB who considers that maintaining the documentation is just a waste of time and money. And banks are full of PHBs, which explains everything about the state of their computer systems: the old code is still running because by now its almost impossible to understand or maintain and nobody in management is about to pay for documenting it well enough to re-implement: that would use up the money that rightfully belongs in their bonus packages and we can't have that, can we?