Demonstrating software integration resilience in the Financial Services world
Software based systems within the finance industry are becoming increasingly complex as legacy systems are integrated with new functionality. They also have to be very robust from both a regulatory perspective as well as from a user experience perspective; people must be able to get their cash.
The typical approach to the development of software based systems has a cost profile heavily weighted towards the end of the project; this represents considerable project risk. For systems and software in Banking, Financial Services and Insurance (BFSI), the key is to demonstrate that the systems do what has been required, with no side effects. They have to be resilient in isolation, but often have to interact with others systems both within a company and with other companies systems.
Demonstrating integration resilience is very difficult, even within one company’s systems, because taking systems off-line means loss of service and loss of revenue. With increasing regulatory interest in the sector, ensuring that BSFI systems work correctly, that people can deal with the industry and know that their assets are safe, is crucial to a trustworthy brand.
Current systems have legacy technology, the replacement of which is a considerable risk. Integrating new functionality through upgrades to these legacy systems or replacing such legacy systems also brings risk. Understanding the transformation from the ‘as-is’ system to the ‘to-be’ and ensuring that throughout development integration integrity is maintained is paramount. The production of evidence that the system design is sound normally only becomes available at the end of the development process and hence there is a tension as development completes and is launched.
The production of evidence should drive the selection of the best development life cycle, processes and tools. The production of verification evidence through either review, analysis or test to provide assurance of resilience should be a by-product of the use of such techniques and be responsive to inevitable change as understanding increases though the development process.
The use of formal methods can be used to provide analysis for both architectures and software. To date, it has been assumed that experts are required to write formal specifications by hand and then to prove the necessary properties using appropriate qualified tools as support. This is not necessarily a quick or repeatable process and where in other industries formal techniques have been used, they have become company specific knowledge, not available to the wider community. Therefore in order for formal techniques to be adopted more widely across industry, they need to be automated in order to achieve the required flexibility, repeatability, have a low training overhead, as well as providing evidence of resilience.
D-RisQ has taken an approach which enables the power of formal methods to be exploited without any specialist training. By using commonly available tools such as Stateflow®, it is now possible for current engineers to develop software systems architectures in a rigorous manner, whilst gaining as a by-product, the required evidence to confidently support system release.
Modelworks® proves that requirements have been correctly captured in a design expressed in Stateflow®, or will show the manner in which compliance has failed. The design can be of a System of Systems, a single system or a software program. It allows a designer to check that the design does what is required. More importantly, it allows a proof that undesired properties will never happen, a check that is typically attempted at the end of a development life-cycle. It is also possible to show behaviour under failure conditions. Modelworks® can be used to show the behaviour of highly distributed Systems-of Systems, including the behaviour of human interaction where necessary.