401K/Superannuation Fund Manager
A superannuation company in Australia running a large fund in excess of A$50 billion dollars that provides retirement benefits as well as financial advice services to its members.
The Operational Data Store ( ODS) project requirements can be summarised at a high level as:
- Provide the ability to capture contributions and transactions for members and/or accounts.
- Maintain and provide the capability to retrieve investment holdings for members/accounts; holding valuation must be calculated dynamically and should be based on the current unit price (updated daily).
- Provide business users the capability to write business rules to classify transactions based on certain criteria/rules.
- Business users must be able to view the current rules applied to the system.
- The Online Operational Data Store must respond to requests promptly; request requests such as
- Retrieve transactional data and contribution
- Retrieve investment holding support
- Retrieve reference data stored in the system.
- Ability to handle transactions arriving out of sequence and identifying duplicate transactions
In this organisation, all the customers account information, contributions and tax calculations are made by a centralised product that relied on a backend database. There is a CRM frontend available which queries this data and presents it to the customers. Since the volumes are high this company is experiencing very high query times resulting in long delays to refresh the web pages with data and resulting in bad customer experience. The call centre also doesn?t have a true 360 degree view of the customer and is often required to call the customer back due to the time it takes to get access to the data. This solution doesn?t currently offer the customer with a true real-time view of the accounts and status of the contributions.
TIBCO BusinessEvents® is used to create a real-time view of the customer through an Operational Data Store, providing a solution to process all the contributions and transactions in real-time, calculate the tax associated with those contributions based on the different types of contributions and generate a correct view of all the accounts this customer currently has with the company.
The existing core system now sends all events through a JMS channel to BusinessEvents for classification. The solution uses Decision Tables to identify the events coming in and create the appropriate event object within the engine. Once the events are categorised, the solution process them to calculate the amount being deposited or withdrawn from the account (or accounts) and also calculate the tax associated with the transaction(s).
Business Users can modify the calculation rules or the classification of the events using WebStudio to simplify and accelerate the turnaround time to introduce new classification or fix missing classification.
The solution is able to process out of order events and also notify when events are missing. A web-service is also available for any internal system to query the operational data store such as the online self-service customer portal or the Customer Service portal.
The solution is currently running with about 1 million customers with over 5 million accounts associated to those customers. 50 millions transaction events are stored in the cache and can be accessed at anytime. Those transaction details are stored for a defined period of time before being evicted and archived.
In terms of physical architect, the solution is running on premise in an Active/Cold setup with production being the active site and DR being the cold site. Each site has two servers running with 4 cores and 32Gb of memory.
The network configuration allow for the servers within a site to communicate using UDP, thus allowing the TIBCO BusinessEvents Cache to communicate freely between the cache instances and the inference engines. Two instances of the Cache are running on each server. The Cache is using a ?Shared-nothing? configuration allowing all data to be stored to local file in case a failure occurs but also for Disaster Recovery process. The files are replicated to the DR site and the solution can be restored to the same active state as the production environment within minutes. An eviction policy is in place to remove transaction events older than a configurable parameter.
There are two types of TIBCO BusinessEvents Inference engine: one for the ?core? processing and one for the ?web service? implementation. The ?core? includes the processing of all incoming transaction events, categorisation of those events, tax calculation and persistence to the Cache. Locking mechanism is implemented to allow Round-Robin and load balancing between the two running engines. Most of the inbound destinations uses pre-processors to process the incoming events. The ?web-service? engine is listening on two main channels (JMS and HTTP) and offers SOAP services for retrieval capability. The service returns the full view of a customer in one call, but can be broken down into multiple calls if required.
A third Query engine (not represented on the diagrams) is used during development for debugging purpose and is not deployed to production.
This solution has a simple implementation, yet the amount of data stored and used to quite significant. The use of the Cache in conjunction with a reliable messaging bus offers a Highly Available and Fault Tolerant architecture out of the box with minimal impact in terms of performance. The response times have dropped significantly from over 10 seconds to less than 10 milliseconds.
The result of this is that TIBCO can give a real-time 360 degrees view of their customers, which improves customer experience through multiple channels (online self-service, on the phone customer service and on mobile), supports personalisation and reduces costs.