I bet you half the problem is the software being specified in a synchronous and not asynchronous manner.<p>If a flow chart is expressed synchronously, it immediately bottlenecks around the slow backend systems. e.g. check the applicant has 4 kids, and if that checks out, present them with these options.<p>I attribute some of these problems to inadequate advances in today's mainstream programming languages.<p>For instance, if futures/promises were common parlance in programming, some of these bottlenecks would have been identified earlier.<p>I once read an interesting essay on what future programming languages could work on. One of the interesting ideas is a language that allows programmers to implement undo/redo easily. Recently there was a blog post about fuzzy computing, where a function is able to return approximate values when it is busy. The Knight Capital incident teaches us that if we architected our monitoring systems the same was as intrusion systems are done, we could have stopped activity when suspicious incidents occur outside the normal operating range. There was another incident where a Japanese trader accidentally keyed in the wrong number and promptly lost his employers a lot of money. Languages that incorporate ideas like validation and expected values as first class constructs might be able to help here. The Adriane reminded us how badly humans do when reasoning about systems where multiple agents perform the same task.