Chris Conway
Chief Architect, Quantiv
In the past, when an organisation needed IT support for its operations, it was possible for it to consider using a single computer system.
In part, this could have been because operations were simpler. After all, at one time there was no internet, mobile phones, or even email to complicate an IT solution.
But mostly, it was because IT systems themselves were less capable. In effect, organisations were constrained by what IT could actually do rather than what they wanted it to support.
Now though, the situation has almost reversed. The capabilities of specialist applications often go well beyond the requirements or imagination of even the most sophisticated user. And when these applications are combined, virtually any business operation can be supported.
But this wealth of opportunities brings with it its own problem: the need for different applications to cooperate as part of an overall solution. This cooperation really means ‘exchange information’ but is often taken simply as ‘send data’.
Insurance ‘quote and buy’
In the insurance sector, for example, a typical ‘quote and buy’ solution might use:
- A customer relationship management (CRM) application to communicate with existing and potential customers
- Specialist insurance ‘front-office’ (rating) and ‘back-office’ (capacity) applications to control the quotation process and ensure what’s quoted is actually available for sale
- A standard retail sales application to orchestrate the sale process
- A general accounting application to track revenue generated and costs incurred
- A claims management system (often located in partner companies) to ensure the compensation matches the cover provided
- Various other supporting applications
And while each application has its own specialisations, there’s still a need for each to share information. Often, this results in data being sent from each application that has the data to each one that needs it, i.e.:
- The CRM application could send a file about a potential customer to the front/back-office application
- The sales application could send a message to the insurance application to get quotes, and also when an order is confirmed
- The claims application could be updated every time a sale is made, or check against sales only when a claim is received
- The accounting application database could be updated every time a customer is registered, a sale recorded, or a claim made
Spaghetti systems
The approach explained above can get very messy (think spaghetti). That’s because it’s implemented on an ad hoc basis using message buses, staging tables, and even simple file transfers.
Such techniques mean data is duplicated and unstructured, and presentation can differ from application to application. Worse, it causes each individual application to be dependent on every other application to/from which it sends or receives data, and that means:
- The CRM application needs to know what the insurance and sales applications are expecting, and/or those applications need to understand the CRM application’s data structures
- The insurance application needs to know how to format data for the sales application and for itself
- The claims application must understand the details of the insurance application’s policy storage mechanism
- The accounting application must ensure its records are up to date with the CRM, insurance, sales and claims applications (it needs to know how to retrieve/accept data from all of them)
- Someone in the organisation will probably ask for a report on ‘operational performance’
In these situations, if any application changes, all the applications that depend on it must also be changed, or at least reviewed. And, faced with a potential update (for example, introducing telematics data to the quotation process) ‘change paralysis’ can ensue. So, nothing ever happens because the organisation fears the possible side effects.
A slightly better method
Rather than each application connecting directly to every other application, it’s possible to provide a central service to enable the delivery and retrieval of messages: a ‘message bus’ or ‘message broker’.
Operating in this way means each application only needs to know how to connect to the message bus, rather than to every other application. The message bus ensures data delivery is guaranteed.
But this really only solves the technical connectivity problem. The business problem of duplicated and non-standard data remains, so applications are still free to send data in whatever format they choose. This means data is still transmitted from point to point, with senders and receivers still dependent on each other. And the number of different connections supported means the message bus itself can become another source of complexity.
A much better approach
Instead of point-to-point integrations, it would be better for each application simply to expose its data in such a way that any other application could use it without any pre-registration.
Working in this way means data can still be shared among applications, but without introducing strong ‘functional’ dependencies, i.e.:
- Data publishing applications have no knowledge of consuming applications’ requirements
- Data consuming applications don’t need to be concerned with how publishing applications get their data
Plus, all applications can minimise ‘structural dependencies’ if they agree on a common format in which information can be exchanged and defined. This means consumer and producer applications have minimal dependency on each other, while information exchange is now as open as possible.
What’s more, the provision of a simple hosted persistence service – along with use of a lightweight, common format for data storage – means organisational information can now be used without the need for extensive integration development.
This pattern reduces the effort required to expose organisational information. And it puts what remains back where it should be: in the source and destination applications, rather than in a complex integration layer.
Quantiv’s NumberCloud platform and NumberWorks method are based on these principles. They allow organisations to use best-of-breed applications for specialised functionality, while ensuring information can be shared easily and securely, without introducing significant application dependencies.
