|Eclipse Software, Inc.||Adapting the Framework|
|ESI Home||Architecture||Glossary||Links||Contact Us||Site Info|
The Functional Framework component of the Architecture embodies the data, metadata, and processing rules that support financial securities transaction management. Those discussions are in the context of a comprehensive implementation of all the components.
In practice, completely new development of a system is much less common than extending or adapting an existing system. On this page we address how to adapt components of the Framework within the context of existing systems.
This is doable because the Framework is as much a conceptual model as a concrete implementation. We look to extend the benefits of the conceptual model to other implementations.
For a discussion of how to expand the capabilities from within the Architecture, see Extending the Framework.
In general the database is the most difficult part of a system to change. If you have that option, you can simply use the material on this site as a guide (the Framework presented here has been implemented almost exactly as presented).
For the remainder of this discussion we will assume the database is fixed, and we will look for other avenues for exploiting the Framework. In addition, non-database adaptations have the following characteristics:
The crucial preparation is to be able to map your current transaction stores, positions, and balances to those described in the Framework. This enables all the adaptations given below. Effectively we are implementing the Adapter design pattern (see [Wiki:Adapter]).
We are particularly concerned with the Register and Positions and Balances entities. The Association is used less frequently as it directs none of the Processing Rules or Positions and Balances updates. It will be used primarily for reporting.
For both entities described below, we need mappings both from the existing system to the Framework model, and from the Framework model to the existing system.
Within the Framework, all transactions and events are recorded in a single data store, the Register. Mapping an existing step will usually require the following steps:
A similar process must be followed for the positions and balances. It is usually simpler than the Register mapping, where there can be quite a bit of variability in representing cancellations/corrections and settlement activity. This process will normally involve the following steps:
It is important that all mappings be consistent with those used for the Register. It will be useful to get in the habit at this point of building the mappings on a table-driven foundation.
The adaptations that follow are presented in order from the easiest to the most complicated to implement. More importantly, each one builds naturally on those presented earlier.
Once the mappings have been built, the first step is to produce a function/view that takes a set of parameters (e.g., date range, account type), collects the source data, and creates an output in the Framework model.
The output can be in any form (e.g., result set, file, temp table), with a pipe architecture that can then convert to other formats (e.g., XML).
This output can be used immediately as the basis for user reporting.
The model view can be used to verify/reconcile the current databases, without impacting the existing structures directly.
There are a number of reconciliations that can be implemented immediately:
Once those reconciliations are in place, you can create shadow versions of the accruals: trading P&L, dividends, and coupon interest. The output of those accruals can be compared to that created within the existing system.
Though we are considering only adaptations that don't modify the existing database, we can proceed to replace existing processing that does update the existing data structures.
The reasons for doing this are that the Framework model is generally easier to implement (once the mappings have been done) and reconciliation is built in.
The logic for updating the existing positions and balances can be replaced with Framework-based updates through the following steps:
You can use a similar approach for the trading P&L, interest, and dividend processing. Translate into the Framework model, use the algorithms given in the Processing Rules to determine the required updates, and map back into the structures of the existing system.
One of reasons for the flexibility, extensibility, and transparency of the Architecture is the use of metadata structures in the Knowledge Base to control as much of the processing as possible.
This approach can be applied to any existing system by modifying hard-coded processing to be metadata-based.
Though we have said that we are focused on adaptations that do not modify the existing database, the steps given above provide a means for an incremental approach to migrating to a Framework-based architecture. It is possible to replace part of the existing transaction structures with ones that are Register- and Association-based. Likewise it is possible to replace portions of the Positions and Balances structures with those from the Framework.
The only other modification to the work done earlier is to replace the mappings with ones that are more direct.
Copyright 2005-2018, Eclipse Software, Inc (ESI). E-mail: WebSite@eclipsesoftware.biz.