One of the major cost factors in integrating with 3rd party tools and services in your application is the availability of the tool in your dev/test environment. Whether there is a cost to use the tool in pre-production or there is downtime for that 3rd party causing an interruption to your schedule, both situations cost time and money in the application development cycle.
The answer to this is not to pull back from 3rd party integrations, it’s to leap forward and eliminate the constraint to your dev/test cycle.
In the banking world, the SWIFT messaging protocol and network infrastructure is an almost mandatory integration for international interbank messages. The SWIFT standard provides a secure and reliable transfer of messages containing financial transactions between banks and other financial institutions. If you’re transferring funds across exchange rates or even dealing with an intermediary – SWIFT is the most secure way to transact.
As with most 3rd party live services, the live SWIFT service comes at a cost; one that banks are willing to accept when transacting real business as they can charge back the fee to the end users. However, when these companies are developing and testing their SWIFT integrated applications, the cost is not as easily justified. How can banks get around this pre-production nightmare and not “break the bank” before they get their application out to the masses?
Cost of access to the live service: Accessing a live service to test continuously is costly. Many simply wait until integration testing to see if a 3rd party integration works causing defects to be found at the pricey end of the software development life-cycle.
Testing with canned data: 3rd party environments do not often enable testing with real data and instead provide a canned one or two transactions for testing purposes. Negative testing is limited to none and without true data, quality suffers. Defects simply spill to production.
Non-human readable transactions: Swift messages are complex and not human readable. Spot checks by manual or user acceptance testers can be difficult with no ability to completely match transactions with their expected results. Without proper validation of messages, errors are likely to occur.
Changing Standards: There are several SWIFT standards (MX, SEPA, MT) that change quarterly causing constant updates to live systems. This adds complexity to the validation of messages and ensuring any tests being performed are updated with the latest data available.
Cost of access to the live service Banks can virtualize subsystems which are sending and/or receiving SWIFT messages; completely eliminating the pre-production transaction cost and any fluctuation on the SWIFT live service.
Testing with canned data With a virtualized SWIFT service, data passed in and out of the system is not restricted by a 3rd party test environment. Test data can be captured with various tools and pumped through systems during the pre-integration test phase without restriction.
Non-human readable transactions With service virtualization, SWIFT Transactions can be ‘translated’ into human-readable XML for easy troubleshooting of requests and responses. In addition, with the proper tools, syntax and semantics of SWIFT messages can be validated, dates can be identified in the transactions and stateful transactions can be captured and understood properly.
Changing Standards Automated tests can be set up for each version of the SWIFT standard and updated before the new standards go live.
We should not fear the 3rd party integration! With a combination of virtual services and automated tests with proper SWIFT assertions, financial institutions can remove this live service constraint from their development and test environments, thus increasing quality and reducing cost and time to delivery of their applications.