# 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

This entry was posted in Calculation engine and tagged . Bookmark the permalink.

### 2 Responses to Logical Architecture of a Rule-Based Calculation Framework

1. tuncalik says:

I used the term “rule based” for the calculation framework I introduced here. This term shouldn’t be confused with the “Business Rules Framework”. Maybe I shouldn’t use it at all to avoid confusions, and say just “calculation framework, or engine”.

With “rule based” I mean essentially fully configurable. There is another reason why I used the term; the function block named “function router” based on a decision matrix. With the decision matrix, which is a parameter of the function router, you decide which functions are to be applied on which data sets. In that sense, you set the rules which functions are to be executed for which data sets.

You could for example configure the framework so that investment performance measurement method M1 is applied for fund group G1, method M2 is applied for fund group G2, and so on.

2. tuncalik says:

Because I worked in the financial services industry as senior consultant with pre-sales support for a couple of years, I have first-hand experience that many fund companies invest hundreds of thousands of dollars for the implementation of some fee calculations for invoice generation and reporting. These are typically expensive, lengthy and tiresome IT projects that can continue for several quarters, in some cases even years. The time frame and costs are typically double or triple of the amounts planned initially. The software solution ultimately developed is in most cases too complex and entangled, accordingly expensive to maintain, because it has grown in an ad-hoc fashion without solid analytical models.

Why is this so? Why do some asset management companies continue to invest hundreds of thousands in fee calculations? Is there no other solution?

Yes, there is another solution. All fee calculation projects (and similar projects in other industries as well) could be completed much faster, better and economical with a complete calculation framework, as explained in the article above, provided that solutions for different areas like calculations, reporting and workflow are separated with well-defined interfaces among them.

I haven’t yet seen a complete calculation framework in the market as explained in the article above. Maybe there are some, of which I am not yet aware. All the solutions I have seen so far under names like calculation engine are not real calculation frameworks based on analytical models. If there was a real calculation engine with well-defined interfaces to reporting and workflow, fund companies wouldn’t need to invest so much in fee calculations.

Even if there is a real calculation engine in the market, well hidden somewhere outside the knowledge and appreciation of potential customers, this doesn’t mean that a better one can’t be produced.

I am currently working on the prototype of the calculation framework, which will be ready for demonstrations within a couple of months. We plan to convert this prototype into a product with some competent business partners from the software industry.

We also have a business idea for this product: XXX Analytics for Business and Science. This will be the name of the company which will develop and sell the product.

The current version of the business idea foresees a tree-phase deployment plan:

1. Establish the product and sales channels, define configuration standards (2-3 years)
2. Set configuration standards, broaden the customer base (2-3 years)
3. Complete solutions for risk and scenario analysis, based on the calculation framework

An initial public offering (IPO) may or may not be realized after the second phase, depending on the size of the customer base, and other factors.

Please don’t hesitate to contact us if you are interested in this business idea as a potential stakeholder; as investor, software developer, analyst or any kind of business partner.

Note that this project needs rational and independent minded investors that are real trend setters; not trend surfers. Innovative and creative marketing strategies will be very important for especially the second phase of the business deployment.

Other key points for XXX Analytics for Business and Science:

• Creative marketing; a distinctive image; not too much respect for conservative values and expectations
• Distinctive HR strategy with core competence defined as follows: Ability to create a pleasant working environment for broad-minded and innovative individuals with interest in science, nature and music; positive selection of ideas and people

Tunç Ali Kütüçüoglu