Complexity of Transactional systems

I have always believed that software development is an engineering discipline. Although software cannot be touched like other engineering structures, it should nevertheless be designed, constructed and quality assured according to the same engineering disciplines that one would use for construction of anything else. This is the way that we at Fundamo approach the building of our software and this is why we are so confident about the software's ability to deal with complexity.

I was therefore intrigues when reading the results of research done by Finextra and Mysis recently (read here). According to this research based on interviews with 100 product managers and directors at banks, IT complexity is viewed as the biggest obstacle to corporate transaction banking. The survey shows that 45% of banks believe that their ability is average to worse and that they are moving more and more of the functionality on-line to solve the problem. "At the top of the list of technical problems that banks say their customers want them to solve is greater integration with corporate systems and delivery of cross-border, multi-currency cash pooling services."

Anybody that worked on transactional systems would concur with these observations. One could possibly add that it is likely that the needs (and complexity) would increase substantially as markets develop and clients see more and more of need to be on-line and to perform financial transactions in realtime. What is the key thing that banks should do? Well, lets look at the art of engineering. The more complex the structure the more time is spent in designing and testing the architecture of the design. Get the architecture wrong and the bridge will collapse, get it right and even the construction is a breeze.

Banks should think carefully (and consult with experts) to get the architecture of their transactional systems right... and this is not a trivial task.