A key issue with outsourcing is the management of data and processes that are business critical. The problem is one of trust: how can the business trust an external supplier with these important assets?
One solution is scripting: various packages are available that run “on top” of the outsourced systems, and monitor them. The scripts are managed by one or more trusted in-house teams, and provide an early warning system for any problems.
The scripting is expensive because it needs top-of-the-range skills (usually java and SQL) and, in a way, the scripts “reverse-engineer” the outsourced system, in order to verify that the processing is correct.
An example is in credit-card processing. A critical process is the calculation of interest. Apart from being technically demanding (the degree of precision required in the calculation – often a leftover from mainframe systems – can challenge software and hardware alike) it has to be carefully monitored because the potential for fraud and damaging errors is high.
In order for a script to verify the credit-card interest calculation, it has to perform the calculation itself, perhaps at a summary level, and on randomly selected accounts, and verify the results are correct within a range of tolerances.
For better control, an in-house rules-engine can be considered for critical processes. The interface (fact-model) is designed into the outsourced software, and, in our example, the credit card calculation is performed within the rules-engine.
Rules engines can be very efficient as development platforms: XpertRule is quoted at 0.3 hours per function point, and DROOLS at 1.5 hours per function point, the respective equivalent of 50 and 10 rules per day per developer (DROOLS reaches 30 rules per day if pattern rules apply).
This means that a small team can cover a large area of code: a team of 3 can cover 1000 rules comfortably in most situations.
The simple nature of the rules means that they can be directly monitored by management, internal audit, regulatory and security staff for correctness.
The use of the rules engine helps secure the system because the rules developed by the Business Analysts do not leave the organisation – they go directly to their own rules team for implementation. All details that a business would want kept confidential are held in the rules, and not visible to the outsourcing organisation. This can include control-account ids, the way control-accounts are updated, and even the use of hashes (e.g. account-no x amount).
The extraction of control data for balancing can/should be done within the rules to give a secure point-to-point validation of the processing.
The business can usually identify the critical processes without any difficulty, but for completeness the methodology we use is:
- identify critical LDM entities (e.g. transactions, accounts, customers)
- identify where those entities are changed, created, or deleted.
- implement those change/create/delete activities with rules.
So, as an example, in the case of our credit card system, during the calculation of interest, transactions are created. This identifies the process as a candidate for a rules-engine.
.