Financials Accounting Hub - An incremental implementation approach

This is a high level example of a FAH implementation. I already described this briefly in this post, but never got around sharing my illustrations, which better showcase the approach.

We start with the following architecture:

The purple boxes represent source systems (e.g. billing, mortgages, investments, claims etc.).
Originally both Lines of Business (LOB1 & LOB2) had their own General Ledger solution. At some point in time both Lines of Business migrated to a single General Ledger solution.
As the source systems are connected to the legacy General Ledgers through various point-to-point interfaces, it would have taken too much time and effort to redesign all those solutions at once and point them to the new corporate General Ledger. Therefore the interfaces from the source systems towards the legacy General Ledgers were preserved, and a custom transformation framework was put in place which translates the accounting from the legacy General Ledgers onto the new corporate accounting structure.

Phase 1: introduce FAH in a Journal Pass-through mode:

First FAH is introduced in the architecture by replacing the custom transformation framework. At this stage FAH is only used in a Journal Pass-through mode: the events presented to FAH already contain an accounting key, and FAH simply maps the accounting from the legacy format onto the new chart of accounts.

Phase 2: move towards an event-based accounting architecture.
Now that FAH is part of the application landscape, any newly introduced source system can be connected directly to FAH:

Such a direct connection leverages the true powers of FAH, as you can use the raw transaction information from the source system to have FAH create the accounting entries. In addition FAH will also maintain the audit trail between source events and the General Ledger journals.

Then select one of the existing source systems to connect it directly to FAH:

Over time the non-strategic source systems will become obsolete.
The remaining source systems (and new ones) can be connected directly to FAH.

This leads to a situation where the legacy interface and General Ledger can be switched off and removed:

And the same holds true for the other Line of Business, eventually leading to the following end-state:

So you can use such incremental approach to position FAH within the architecture at low risk and with low effort, while still having all accounting flow through FAH from day 1. Then you can gradually move to an event-based accounting approach, doing so at your own pace, because all variations of journal pass-through and event-based accounting are possible.

In the end-state all accounting rules and logic are stored centrally within FAH's user updatable rules repository, the legacy interfaces and systems can be switched off, and FAH preserves a complete bi-directional audit trail between business events and General Ledger journals.

Cross posted to oraclecs.com