IBS Journal May 2015


Solution verification: embedded approach


In the second instalment of our core system transformation series of articles the focus is on solution verification and testing. We delve into the issue of how to reduce time for the process without compromising either the quality of the results or the stability of the system.


About the author


A typical core transformation project runs for 18-24 months and involves defining require- ments, designing and develop- ing solution and then verifying that it matches the bank’s busi- ness needs. Executives and board demand a shorter implementa- tion timeframe, so that business can focus on deriving value from the new application’s features rather than being locked in an implementation window. In every implementation,


core transformation experts try various options to reduce imple- mentation time. These options need to pass ‘acid’ testing by providing schedule reduction without posting much threat to application stability. The option being discussed


Anup Agrawal is an independent core banking software transformation specialist, having worked over the years across a number of such projects, with the latest being at Discover Finan- cial, assisting the US bank in its pioneering efforts to implement Infosys’ Finacle. Agrawal’s previous employers also include Oracle FSS, Infosys and HP.


in this article is to embed solu- tion verification while solu- tion development activities are carried out. This option might sound like Agile development, but it is not the same, since core transformations rarely follow the Agile development path, as there is a tendency to document each requirement and there are sign-offs from business, audit and compliance before the development can begin (typi- cally this is done offshore). This


article focuses on solution verifi- cation (testing) as this undertak- ing takes a long time in the full implementation cycle with less direct value addition. It should be noted, however, that this is not an attempt to undermine the importance of testing, as it is a critical activity – any defects need to be caught before the production roll-out. What the article is trying to do is to play with a schedule so that defects can be caught earlier. Embedded testing is a


theoretical concept that can be tuned to apply in practice. It starts with the assumption of testing organisation being part of solution definition, so that the team can start writing test scenarios/cases along with the requirement documenta- tion. During the solution design phase, these scenarios play a very important role, as the design needs to satisfy these scenarios. The objective is to be ready with test cases before the development begins. These test scenarios and test cases can be provided to the vendor who can consume them during development and certify that the solution is working as per requirements as well as per test scenarios.


50


© IBS Intelligence 2015


www.ibsintelligence.com


analysis: core system transformation


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56