Real-Time Reporting
Most Eagle clients design data workflow to follow a daily cycle:
Once markets close and regular-hours trading ends, the daily accounting update cycle sees trades updating positions, prices applied to create market values and reference and analytical data updated. Accounts are reconciled and submitted for automated and manual error checking.
When this activity is complete, end-of-day processing such as entity builds commences, with performance measurement calculations usually coming last. Further data QA and approvals take place.
With all warehouse contents in a validated state, clients build their Mart and use it to deliver enriched information during the ensuing business day.
In an ideal world, there would be no reason to make further changes to data values updated as of past completed business days. However, this is not the case in the real world. Vendor data corrections impact previously loaded security information. Late trades and trade reversal/re-entry activity affect accounting data values in the open accounting period.
It is physically possible to use Process Manager to build a workflow that automatically detects every such intra-day data change and updates the Mart accordingly soon afterward. However, such a “real-time” Mart is likely to produce undesirable results, primarily for two reasons:
A real-time approach may allot insufficient time for data QA, especially when the consumer is a client of the firm. Proper evaluation of updated information must allow for at least the possibility of human intervention in exception-management mode. It is unlikely that this type of discipline can be applied to high-frequency intra-day changes.
If updates take place on a continuous random basis, there is no “snapshot stability” of information. Unstable data is likely to lead to more questions of how recent or how clean the numbers on the page or screen are.
Two approaches to incorporation of data changes are considered best practices:
Batch each day’s corrections and accounting restatements during the day, and evaluate those using standard data QA procedures. As part of the overnight Mart build, incorporate these changes into selective required rebuilds of the Mart for all past dates affected.
Take the same approach, but do so at one or two regular times during the day as well as at end of day.
Both of these approaches allow for proper data validation and promote a stable Mart whose “vintage” can be understood by users, while keeping reportable information quite current with ongoing changes to securities and accounting.
Eagle Information Delivery Buildouts Should Incorporate Data Mart
If you are an Eagle client in the process of building your information delivery solution, we recommend you use Data Mart. Data Mart is at the core of Eagle’s information delivery strategy. As Eagle develops and integrates additional tools for information delivery and portfolio analysis, Data Mart is the default data source for them. For example:
Third-party reporting tools and applications can source from Data Mart, because the Mart is an open database platform.
Data Mart offers a simplification of reporting configuration relative to prior tools.
The Data Mart achieves efficiencies as a “write once, read many” information resource.
Eagle Portal is closely integrated with Data Mart.
Eagle Mart, Eagle’s platform for delivering standard out-of-box reporting, performance and Portal content is based on Data Mart.
Data sources outside the Eagle warehouse can often be integrated with Data Mart tables to provide a more comprehensive view of the firm.
Note that Eagle’s Advanced reporting solution based on the Active reports platform can use Data Mart as its source, as can Classic Portal that precedes the new user interface Eagle Portal (V11.0 and later).
Using Data Mart if You Implemented Before Eagle Data Mart
If you built your information delivery around Eagle before Data Mart, you have the same reasons as implementing clients to use Data Mart. New information delivery initiatives would do well to source from Data Mart.
A more complex question is whether to convert existing reporting to Data Mart. This involves a unique cost/benefit calculation facing each company. Some key considerations are:
Conversion is easier/harder if existing reports have less/more program logic beyond just displaying values of field attributes.
All meta data (field attributes, date rules, source rules, range rules and dictionaries) is reusable in configuration of Data Mart.
Conversion to Data Mart can be done for a part of the report suite, such as a new type of information delivery.
Add Comment