Running an integration project –what to pay attention to?

A Canadian Bank Learned (after integration) that one set of the processes which were deemed “minor” caused an operational failure. All the “regular” processes were analysed and tested.
There were, however, few macro processes that business could execute when they feel extra reconciliation was needed (typically just to be sure). These processes were simply moved over (not much attention was paid in testing on these). It turned out that, after the integration, on Day 1, a large number of business users did want “just to be sure” and choose to execute them. The results caused much damage and delays in the next business' day start.

What can you do to avoid this?
Integration will be an event testing all your systems. Be sure that all interactions of business users are understood.
Review the type of work business users could deploy as “just be sure” – large reports that suddenly deal with more data may cause crashes on their own; let alone if suddenly invoked by number of concerned users.
In stress and performance tests, ensure that the increase in data is properly reflected. Do include a set of reports to run in parallel with main test – while this may “spoil” nicely planned performance tests, the reality is, on Day 1, everything will be challenged.
Day 1 is day of surprises and you will be ready – note however that Day 1 outputs will be significantly different (than pre integration). Are there any risks to overnight processes and Day 2 you may have overseen?

Comments (0)

E-mail address:

Registration

Register