A Short Story about integration
Bob works at FastCorp, a leading insurance company whose main operations include dealing with claimants on the end of the phone – often providing or updating information and, sometimes, paying out for a claim.
There are two systems involved in his day-to-day duties: FastFinder, their main line-of-business application; and CleverPay: a third-party application, dealing with financial operations.
FastFinder and CleverPay are integrated, and communicate with one another in such a way Bob never directly accesses CleverPay. Instead, FastFinder accesses CleverPay’s features – making all processes much more streamlined!
There’s a problem though: As Bob will attest: “CleverPay takes forever to do anything. I click the button, or load a page, in FastFinder and it just sits there! I can’t do anything for the customer except make small-talk!”
How frustrating.
The problem
This is a story told all over the technological-world. Systems talk to each other, share data and interact to provide some streamlining for business processes.
But not all integrations are created equal: And there are good ways and bad ways to integrate software packages. Choosing the correct way can often mean the difference between paying an employee to effectively assist with a customer inquiry, or paying them to make small-talk because their hands are tied!
The User Experience
Bob hates his user experience. It frustrates him that he can’t do his job effectively because he’s waiting for the application to respond.
The developers that built FastFinder, and subsequently integrated in CleverPay, succeeded in their goal of integrating two separate software packages; but failed to consider the user experience.
When using the CleverPay through FastFinder, Bob is being blocked from doing anything more, whilst FastFinder waits a for CleverPay.
A Better Way
Developers who integrate software packages – especially in to line-of-business applications – should always be mindful of the end user and their processes.
In this example, the user interface was blocking – stopping Bob from doing anything more for the customer and, as a result, becoming less effective.
Applications that are integrated together should make use, where possible, of asynchronous operations. Asynchronous functions and operations are those that allow work to continue in the background, whilst the user continues to interact with the application.
Back to our Example
CleverPay may return some information, such as indicating whether a payment has successfully completed from an operation information. The user may need this piece of information to proceed. However, to avoid frustration and for the user to remain effective, they should still be free to use the rest system whilst waiting for the operation to complete.
Developers should make sure asynchronous or multi-threading techniques are used so that the user interface is unimpeded whilst operations complete.
Optimisation
It’s also important that solution architects build the system in such a way that critical operations are as efficient as possible. This often means the following:
- Adhering to standard coding patterns that are intended to provide a robust and highly efficient structure
- Closing connections to databases are opened and closed as quickly as possible
- Ensuring long-running tasks can be cancelled if required
- Error handling is in place to provide logging
- Timely and efficient clean-up of resources
Whilst these are good tenets to adhere to in most software systems, there are times in which an operation will simply take a long time: regardless of optimisation.
The Punchline
Bob wants to be efficient and wants to help the customer as best he can. Sometimes, this means Bob will need to run a function on CleverPay, and simply continue doing other things.
This is an example of “fire-and-forget,” where Bob simply cannot wait for the completion of this task. FastFinder, and the developers that with integrate CleverPay, should accommodate Bob.
Using asynchronous operations and tasks, we are able to allow normal operation to continue whilst our long-running tasks are in progress. We may need to disable / hide some areas of the user interface whilst this happens, but – in general – our user should be allowed to continue in their day-to-day operations.
In the end: It is the user experience that determines whether a system is successful!
