Chapter 22. Order of Operations

When I went to Sacramento, the development center for SAFR, I started on the system test team. I remember finding a problem with the system not many days or perhaps a couple weeks after starting. I went into the on-site project manager Bill Bengston, and described what I had found. I was surprised when he asked what I would suggest to fix it: I was the newest guy. I thought for a moment, and suggested some course of action. Bill considered it, and said, “That sounds good. Why don’t we do that.” I think I then was responsible to communicate to the programmer how to fix the bug. I have thought for years that that inclusive style of leadership demonstrated by Bill was nurtured from the top by Rick.


Our heritage was slightly different than many later start-ups of the internet age. It was based upon consulting work. The way the problem was solved cut across traditional lines of the reporting architecture and the standard commercial software products that had grown up to support it. It was an incredibly ambitious scope.

Because of its development in the consulting world, it didn’t have to appeal to a large number of potential buyers to be commercially viable. By focusing on solving problems for the largest organizations, performance was always kept top of mind. It also had the freedom to pursue whatever technology or processing options needed to solve the problems. Over years and years, the patterns have emerged and been refined based upon the principles McCarthy outlined.

Effectively, the result is a highly tuned compiler, processing language and flow that automates report production processes from the detail, minimizing the intermediate inventories that must be developed.

One other aspect of being successful in the rapid development of reports is, as Rick often says, doing things in the right order. A more technical term for that is controlling the order of operations.

Figure 44. Cross Component Development

The Right Order

To understand what “order of operations means” think of the order in which a building is built. If the simplified steps were (1) design building, (2) procure materials, (3) ship to site, and (4) assemble building almost any building can be built. Consider the implications on the possible size of the building if just the last two steps are reversed. Instead of shipping materials to the site and assembling, we assemble the building and then ship to the site. The scale of possible building is now a mobile home, not a skyscraper.

The same thing would be true of Dell’s manufacturing line. Imagine they first dumped all the raw materials inside the computer case before connecting any of them. The manufacturing process would be very expensive if not impossible.

In a similar way in reporting, the entire input file could be sorted for each particular report before selection of what records are needed for the report is performed. This would be very inefficient as records and attributes would be processed (with potentially significant IO) which then would not be used in the report. Sorting after selection is more efficient.

Another example: In banking, a particularly useful type of balance is an average daily balance. Use of this type of balance eliminates temporary spikes from large but short-lived transactions. The creation of an average daily balance, though, can mean an entire new supply chain of data to balances for specific answers, with a tremendous amount of intermediate report inventory.

However, use of a movement based architecture with control over the order of operations enables average daily balance calculations from the movements at almost the very last step in report production. Doing this simple divide at the appropriate time is the critical difference between being able to produce a greater number of reports to answer more questions from the same data in a timely manner, or not. SQL as a tool does not provide adequate control over the order of operations to enable use of a movement based architecture.

The Next Wave

Most companies have established the ability to produce enterprise level summaries of financial results. Most have taken this further to implement processes such as funds transfer pricing, allocations, and at times multi-currency processing in a patchwork way into that environment. The deadline for implementing IFRS is looming, and will cause additional changes to the environment. But I am convinced that the next wave progression in financial reporting must come by removing layers of accumulated processes to the financial report supply chain. Each additional layer of processing adds to the diseconomies of scale the environment already has. Only by doing the hard work of removing layers, getting back down to and then carrying forward the details—the business events, can the needs for financial reporting be supported in a cost effective manner.

Fortunately, the SAFR projects over the years, and the way the tool has developed, have established a pattern, a method if you will, for doing just that. To understand that method let me describe those projects, the broader team, and the next key mentor in implementation, Jay Poulos.