Logical Architecture of a Rule-Based Calculation Framework

What is a rule based calculation framework, and why is it necessary? As discussed in my previous related article, a calculation framework is a fully configurable software solution to implement calculations that are typically required for financial planning, fee and price calculations, risk and scenario analysis etc. and other applications in business and science.

You don’t need a calculation framework to implement a single calculation function, however complex it might be. But what if you have a chain of functions, each with its own set of parameters, and you need to calculate, store and report the results of each function -with all its parametric variations- in a well-organized way?

Consider the simple price calculation engine shown in the figure above. A company wants to calculate the prices of all its products for the following year. There are three calculation blocks (or contracts) in the framework, each with its own set of input and output parameters. The final calculation block price calculator requires estimated costs and sales as well as fixed costs as inputs to generate the product prices.

High-level business requirements for this framework can be summarized as follows:

• The calculation framework should make all the required calculations correctly for all years and other parametric variations, and store all the results (i.e. outputs) including the intermediate ones like estimated costs and sales into a database for review and reporting.
• The calculation framework must be fully configurable. That is, all necessary parameters to configure the calculations should be available to the users of the framework. No hard-coding or programming overhead should be required to change some parameters, or to make them available to users.
• The calculation framework should allow easy integration with a manual workflow process for data adjustments and approvals. For example, some intermediate results like estimated costs might need some manual adjustments and approvals before calculating the prices.
• Performance: High calculation speed is desired due to the huge amount of data. A calculation process should be completed within, say, 10 minutes.
• Intelligent calculation process should avoid unnecessary re-calculations. For example, estimated sales need not be re-calculated if there is a change only in the variable cost data; only estimated costs need to be re-calculated. This intelligent calculation mechanism will save time especially if there are frequent changes in the input data, or adjustments on the intermediate results.
• The whole project, that is, configuring and rolling up the calculations for tests with real data should be completed within two weeks excluding the initial phase for requirement analysis and data integration.
• The implementation of reports or workflow processes for data approvals or adjustments are not within the scope of the calculation framework.

A logical architecture to satisfy general requirements

I will try to explain below the logical architecture to satisfy the general requirements as listed above. Though quite straightforward and sensible, note that this is not the single possible solution; just a solution I propose at the moment. I am sure it can be improved and extended in many ways.

1) A library of block functions that are based on elementary matrix and vector functions including date and set operations. Block functions are high-level functions that are built on elementary functions.

Some example block functions are generic allocation and distribution, date filters and samplers, function router, attribute filter and configurable formula function.

A calculation method, which is assigned to a calculation block in the framework is constructed (i.e. configured) by combining the function blocks available in the function library.

Customers may not know, or even imagine that certain calculations they want to implement are actually parametric variations of some general purpose functions like the generic distribution or reconciliation functions. They can even use different business terms for the parametric variations of the same function. A competent framework provider should but know that these are actually just parametric instances, and inform the customer accordingly. That is the real value of a function library; saving time and reducing complexity. Why spend so much time for problems that are already solved?

2) Modular framework structure based on calculation blocks (also named contracts). The whole calculation framework can contain multiple calculation blocks each with its own set of input and output parameters.

Each calculation block should be able to: a) Check the completeness and validity of its input parameters, b) execute its calculation method to generate the outputs, and c) Store its outputs (i.e. results) into the database (see writer function below).

Note that some output parameters of a calculation block can be input parameters for other calculation blocks. Parameters can be scalars, vectors or matrices.

As mentioned above, a calculation method which is assigned to a calculation block is constructed by combining the block functions in the hierarchical function library.

3) Separation of database from the calculation process. As shown in the figure at the left, a reader function gets first all the necessary input data from the database of the customer. The framework makes then all the calculations, and writes the results into the database through the writer function.

No hidden parameters, no hidden customer database connections during the calculations… The calculation framework should work independent of the data structure of the customer. In other words, the core calculation engine should be isolated from the customer’s database. Why?

• It will be very difficult for the vendor and customers to maintain multiple calculation frameworks if each framework has some customer-specific implementations that are dependent on customer-specific data structure.
• The slightest change in the data structure of a customer will cause havoc in the framework if its implementation depend on the data structure.

Only the specific reader and writer functions should be adjusted to the data structure of the customer. These functions should be the only connections (or interfaces) of the framework to the customer’s database.

Does that mean that the calculation framework should have no database at all? No, it can have its own database (for what reason I can’t yet imagine), but it must be a generic one with the same general-purpose structure for every project.

4) A place for ad-hoc formulas and custom functions.
The calculation framework should accommodate custom formulas and functions. That is, users must be able to create new block functions by either writing some formulas, or by programming. These custom functions can then be combined with other block functions in the library to configure new calculation methods.

5) Adjustments are just additional input parameters. Some customers may want to have a workflow for data adjustments and approvals. For example, they may want to check and adjust the intermediate results like estimated costs and sales before going on with the calculation to calculate optimal prices.

As shown in the figure at the left, adjustments -either additive or multiplicative- are just additional inputs for the framework. For each input parameter including the intermediate results, users of the framework should be able to configure additional inputs for possible manual adjustments.

In most cases, manual adjustments don’t make sense from both business and analytical point of views. They make everything more clumsy and complicated. Still, some customers want to have them; maybe legacy processes, maybe old accounting habits.

6) Workflow approach: Calculation process need not be interrupted for data reviews and approvals.
One might be tempted to interrupt the calculation if some intermediate results like estimated costs need to be reviewed and approved along the way. But this doesn’t make sense. All results including the intermediate ones can be reviewed after the calculation is completed. The calculation can be re-executed after necessary corrections and adjustments.

The calculation framework shouldn’t be entangled with some built-in workflow processes. Additional adjustment inputs should be the only interface of the framework to an external workflow engine. All workflow controls should be kept outside of the calculation framework.

7) Intelligent calculation flow
A calculation block should re-execute its calculation method to refresh its outputs only if there are new input values. For this purpose, each input parameter can be attributed with a sort of time stamp.

8) Business model: Separation of calculation and reporting
At least four expertise areas can be identified for a complete offer related with a calculation framework:

• Data integration in order to feed the framework with proper data
• Graphical User Interface (GUI) for configuration and workflow (may include also some reporting functions)
• Reporting

As a business line, developing and marketing a calculation framework should be separated from reporting because it needs different skills and profiles. Ideally, a vendor should focus only on a broad-scope calculation framework with complementary business partners covering other competence areas and sales channels.

Tunç Ali kütükçüoglu, 10. May 2012

Copyright secured by Digiprove © 2012 Tunc Ali Kütükcüoglu