An Approach to Legacy System Analysis

Understanding tabulating system principles can be very powerful in analyzing legacy systems, even though card readers have not been used extensively for perhaps 40 years or more. In this post I’ll describe an approach I would take to replace a large bank’s customer deposit system. You can watch the video here.

Daily Financial Cycle

First, let’s be clear about what the daily financial cycle looks like at almost all large banks, with their major customer facing systems.

The majority of the day the systems are processing on-line transactions. But at night, a series of quite predictable steps occurs.

• First, detailed customer posting to customer balances is done
• Second, a stage that might be characterized by finishing the customer posting, and inter-system communication and posting of other transactions happens
• Third, the General Ledger processes are performed, creating the enterprise (rather than the customer) views
• Last, there is a space allocated for a safety margin, in case anything goes wrong to recover before the next day’s work begins.

Let’s drill in on the first two processes of this nightly flow, the detailed customer posting and the post processes.

>>> Related Posts: The Daily Financial Cycle <<<

Tabulating System Entry Point

If the system is old enough (perhaps more than 40 years or so), the detailed customer posting and the steps right after it may well be the oldest parts of the system. This is because these may have been the first parts of the system created.

Tabulating systems meant that all transactions created through the day were simply queued for this nightly process as there was no real-time processing. They were all batched up. It was during the detailed customer posting and subsequent process that the computer programs read these transactions, edited them, applied them to balances, and produced daily reports of positions for use the next day.

This fact means that the most critical part of the business processes were likely done in these spaces. It also means though that all the complexity of the on-line systems can be set aside for this analysis. To begin with, simply think of the on-line system as someone recording each transaction on a punch card, and nothing more.

>>> Related Post: Tabulating Systems <<<

Detailed Customer Posting

The major work of the detailed customer posting process is to update customer balances with the effect of any transactions taken during the day. This is done so that the workload for future days can ignore the transactions, and just use the balance. It makes the system very efficient.

Note that often even today whenever a customer balance is needed throughout the day, the day’s transactions to that point are simply accumulated with the balance from the night before to create a temporary balance, sometimes called “memo posting.” This isn’t too inefficient because the number of transactions in any one day is always limited, so the work to be done doesn’t cost much. The importance of the control process we’ll discuss next is why those balances aren’t simply stored at that time.

>>> Related Post: Eliminate Posting Processes <<<

Also note that, as shown below, even in today’s systems there is a clear cut-off of transactions which are to be posted. Any transaction that happens after the start of this process is queued, waiting for the completion of the detailed customer posting.

Control Processes

At the end of the posting process, a key control process is performed, ensuring that everything went right in the posting process. The net effect of all the transactions is accumulated, and compared to the net change in the balances.

This is critical because the transactions won’t be used after this point; only the balances. So ensuring that the balances have been updated correctly is vital.

>>> Related Post: Video of Historical Control Processes <<<

When the test is complete and all the balances have been updated, the Detailed Customer Posting process is complete.

General Ledger Feeds

At this point, it is safe to produce the General Ledger feeds for later processing by the General Ledger. These are typically aggregated feeds, summarizing out customer details to make journal entries from the transactions. Often a control balance record is also made, giving the ending position for the customer accounts, again perhaps summarized.

Why aggregation of these transactions? Because there was never enough compute capacity to produce the enterprise view with all the customer details in it. It takes multiple hours to do the customer balance postings, and each customer facing system does this process in parallel with all the other customer facing systems. But the small window remaining in the daily financial cycle before opening for business the next day, and the requirement to know the enterprise view of things prior to doing that, mandated that data had to be aggregated to get processed in time.

The processes that create these journal entries have come to be called Accounting Rules Engines.

>>> Related Posts: Accounting and Business Rules <<<

New Day Started

After the control processes have successfully concluded, the system can mark all the existing transactions in the database as posted, or in many cases actually archive them in historical partitions. This then clears the transaction area of the system for the next day’s transactions

The system is then set to the next day for processing, and the door which closed off any transactions from being entered into the database is opened.

>>> Related Post: Timing of the Daily Financial Cycle <<<

Queued Transaction Updates

In some cases, there may be a program which applies the queued transactions to the database in bulk. This application can be an important asset for starting to understand how the system works.

In addition to this process being one of the oldest parts of the system, it is also fairly simple, because it does not have to manage all the complexity of on-line, concurrent transaction processing. It doesn’t need to deal with message queues, locking, inquiry and other types of functions.

Update Cycle Heat Map

Using this process in a test environment, a team can load into the queue a particularly kind of transaction, and run this process to update the database. They can compare the database before and after these updates, and note what changed.

These changes can be documented, and new transactions can then be loaded and tested similarly. The heat map that is developed begins to show visually related transactions, and critical elements of the database.

This document will also start to show how the system can be broken down and portions of it implemented over time. Portions of the database will be defined for new transactions, and intersections with the legacy database will be developed at critical points (likely the posting processes).

Admittedly, this analysis does not include all types of activity of the system; but it forms the beginning point of analysis. Transaction updates are the most critical part of the system. Like the bow of the ship cutting the path through the ocean, this critical analysis provides insight into the direction all the other activity will have to follow.

Conclusion

Following this process can increase the confidence of the team in understanding the legacy system. To rebuild a system, all the knowledge about what the system did (not necessarily how it did it) must be working knowledge in people’s heads. Those that built these systems, and those that enhanced them, had this knowledge in their heads when they did that.

It took courage to automate these systems to begin with, perhaps initially with the batch components. It took courage to enhance them, like adding on-line processing to them. It will require courage to replace and extend them to the next set of functions that are required.

But new functionality to further increase the efficiencies of our financial and business systems are needed; the companies that take on and are successful in these tasks will be able to capture those opportunities.

>>> Related Post: The Coming Social Commerce Platform <<<

This is another episode of Coding with Kip, the technical sub-series of Conversations with Kip, the best financial system vlog there is. Literally learn more–about ledgers and financial systems–at LedgerLearning.com.

Watch the series in order at the Coding with Kip Playlist