Problem
A client had a nightly screening job with an elaborate calculation model buried in source code. Based on daily market conditions for a group of monitored companies, a nightly batch job would gather the latest market data to serve as the inputs to this calculation model. One by one the job would process each company, determine dozens of output results, and write them into a database table for further processing downstream.
End users always wanted to know more about the calculation model, and there were continuous discussions about how to improve it in a myriad of ways. But the developers of the overall solution were swamped with numerous projects, and they made and released changes as they could.
Solution
When the developers learned of ClearFactr, they realized they could use both the Web App and the API to vastly improve everyone’s experiences. The overall solution looks like this, with entirely new components in blue.

Breaking down the system diagram, we see the following:
- For any given market day’s analysis of any given company, the entire system is still driven by the Nightly Batch Job assembling the inputs to the model from the various Market Data sources.
- The calculation model itself was easily moved out of custom code and replaced with a ClearFactr model. This model underwent rigorous testing to ensure that it could replicate the output results of the original source-code model, for all companies, for a wide variety of market data input sets.
- The orchestration mechanism in the night job was easily modified to build a large parameter set for use by ClearFactr’s evaluateCells endpoint. Then the job simply made a single REST-API call using this new ClearFactr model.
- The nighty job would gather all of the results back from ClearFactr to write them into a separate database table that would drive another custom application having a UI component. Users can then select a company/situation of interest and with one click, they are sent to a web browser where ClearFactr is launched, pre-loaded with the inputs and results from its latest model run. Then can then further experiment with the output there in a way that cannot break the valuation model itself.
Key Results and Benefits
- For the first time, the end-users were able to review individual company/situation model results in a rich, familiar, highly-functional interface. They could use the capabilities of ClearFactr itself to learn exactly how the model worked, and how it could possibly be improved over time. They could run standalone sensitivity analyses to further changes on key input variables to see when certain conditions would trigger. Based on all of this, they were empowered to take additional actions with their own stakeholders downstream, armed with better data.
- The developers no longer needed to maintain the model themselves in source code. They could use the Engagement tools of ClearFactr to see how users were interacting with the model, who was building scenarios and of what kinds, giving them concrete information how to follow up with particular people. Their overall time spent on this particular system dropped, freeing them up to spend more time on other things.
- Auditors and observers of the entire process could see who was making any changes to the model, what they changed, and when.
- The overall runtime speed of the nightly batch job was largely unchanged. Interestingly, developers found that the calculation time spent within ClearFactr was shorter than the transit times of sending inputs and receiving results to/from the model.
- Importantly, note that a single instance of the ClearFactr model drives both the API interactions and the Web App interactions. This is critical, because it assures that neither type of interaction can fall out of sync with the other one.