When you’re developing software, things don’t always quite go the way you expect them to. Of course, we all have standard software development methodologies and they all include a phase for conducting a full test of new code using live data. It’s a crucial quality control stage that no development team would ever think of missing out.
But what happens when circumstances make it impossible? That’s exactly what happened to us at LexisNexis when HM Courts and Tribunal Service decided to change the way claims, judgement requests, warrants and status updates were submitted to the County Court Bulk Centre.
Previously all requests were submitted by e-mail. However, the service decided that it would introduce a mandatory new electronic data transfer system using secure XML transmission called SDT. This came into effect 01 November 2014. And there were good reasons for doing so. Not only would the system be more secure, it would also provide a 24x7 service and allow online access to information via the Money Claim Online (MCOL) web site.
To accommodate the change we needed to update our Lexis Visualfiles legal workflow and case and matter management system. So we set about amending our existing module to allow our customers to configure an interface to SDT that met their requirements. However, there was a problem. Despite us requesting the ability to test the interface using live data, no facility was provided. Only limited testing for validating the ability to make a connection with the SDT system was provided. The only time a proper test would be possible, using data similar to that contained within a customer’s live environment, would be at go-live, which meant our customers could be compromised if there were problems.
Sure enough, when the early adopters amongst our clients went live they found some issues. However, we were able to jump on them immediately – we put our local support teams and the development team on high alert when SDT was released.
The support teams aided customers through the configuration process, while the development team rapidly created and supplied patches to resolve any underlying problems. The result was minimal disruption for first adopters and a smooth transition for later adopters as we provided fixes before they went live.
The moral of the story? When faced with a risky change to a key business process you can mitigate the risk and make the transition as smooth as possible by planning for the unexpected.