by Richard K. Roth, Principal, Price Waterhouse LLP
Eric L. Denna, Warnick/Deloitte & Touche Faculty Fellow, Brigham Young University, Marriott School of Management
[More about this time can be read in Balancing Act: A Practical Approach to Business Event Based Insights, Chapter 15. Operational Versus Informational.]Introduction
Through employing events-based concepts in systems architecture, organizations can dramatically increase the value and role their central systems play in accomplishing the business mission. Events-based architectural concepts result in system designs that increase the timeliness and quality of information, as well as expand the scope of business functions addressed by a given set of computer programs. Compared to traditional designs, events-based designs result in systems that are better, faster, and cheaper — from both development and operational standpoints.
The concept of event-driven (or events-based) systems started with taking a broader view of the proper role and scope for accounting systems. So we have used the accounting system problem as the basis for our discussion here. However, the same broader view applied to other application areas leads to the same general conclusions.
Events-based concepts discard the arbitrary limitations that historically have been used to narrowly define accounting. Under an events-based concept, owners of an accounting system become anyone in the organization with a need for information about events captured by the system, not just the accountants. While the accountants continue to be important users of the system, the financial statements and other reports accountants need are viewed as simply another byproduct of capturing and summarizing all the events of importance to the organization. Accountants use what they need to prepare balance sheets and cash flow analyses. Managers use some of the accounting data along with statistics about claims paid or policies issued to determine the number and type of adjusters and agents that should be assigned to various risks or locations.
Moving off the old accounting paradigm and its artifacts of invoices, journal vouchers, general
and subsidiary ledger files, etc., to an events-based approach has the effect of simplifying the system architecture problem for accountants, other users, and system builders alike. The traditional accounting system architecture has invoice and disbursement transactions being recorded in a payables subsystem, billing and cash receipt transactions get posted in a receivables subsystem, inventory receipts and issues get recorded in an inventory subsystem, and everything gets posted twice in the general ledger subsystem. Special functions often have to be developed to record cash receipts that represent previous overpayments of invoices or disbursements that represent refunds of credit balances in customer accounts. The effect of this traditional accounting system architecture is to create the multiple system problems of redundant entry and reconciliation within what appears to be the same system. This is why traditional accounting systems usually seem more complex than a general understanding of the accounting problem would suggest they should be.
By viewing accounting events in the same context as all events, a different architecture is suggested because it becomes impractical to build a new subsystem each time some new event needs to be captured. Information about vehicles inspected, miles of road striped, licenses issued, inventory counted, invoices received, invoices paid, bills issued, and cash deposited take on a similar appearance when viewed in the broader context. An events-based architecture for a system allows events to be summarized, counted, and compared at various levels of detail for various time frames according to the needs of the particular user concerned. Trends in product sales/square foot of floor space is of interest to assortment planners in retail operations. Payroll costs divided by miles of road striped by month would be of interest to a highway maintenance engineer. Warranty claims by product and failure type are of interest to manufacturers. Policy claims by risk with policyholder overlays would be of interest to risk managers and accountants alike.
As these examples illustrate, we can still get the accounting information required for financial accounting purposes from an events-based architecture by comparing various classes of events without having to incur the overhead of developing, operating, maintaining, and (probably most of all) understanding separate subsystems just to keep track of these subtotals for us.
Differences Illustrated
Exhibits I-I through IV have been included to contrast the differences between traditional and events-based system architectures.
Exhibit I-I shows the basic architecture that has been used in accounting systems automation for the last 20 or so years.
Accounting events (which are a subset of all events a business would like to plan for, evaluate or control) are captured by a set of computer programs collectively called a transaction processor. The transaction processor takes a subset of information that was present on the accounting events as they were originally entered and posts the transactions on one or more summary files. The full detail is then posted to history files, which typically are archived or otherwise made relatively inaccessible. Report programs specific to the financial purpose being addressed are developed based on the specifics of information that was posted to the summary files by the transaction processor.
To the extent that the purposes being addressed have been fully provided for in the summary files and report programs, information can be obtained from the system. However, to the extent that detail information is required that was lost during the summary posting process, or was not captured at all because it was considered outside the scope of what accounting events properly should include, these requirements cannot be accommodated by the system and must be addressed by a subsidiary system specially designed for that purpose.
Exhibit I-II shows the extension of this result to the primary purposes that traditionally are included as part of the financial function. Financial reporting functions are provided for in a general ledger subsystem. Inventory control and reporting functions are provided for in an inventory subsystem. Fixed assets are a different type of inventory and are provided for separately again …and so on.
Each subsystem characteristically is designed to accept and process the specific events that are the appropriate subject matter for its corresponding area of the business. Event details are posted to inaccessible history files and specially designed summary files become the basis for narrow focus reporting requirements. Visibility to detail events captured and lost in the history files of one system become further removed in the context of the multiple subsystems of what we refer to as the — Financial Subsystems Paradigm. Each subsystem has its own data structures designed to support its particular purposes and business rules for transaction processing and reporting. Maintaining and understanding these subsystems and their interrelationships becomes an area of specialization in its own right. Systematically ensuring that the various subsystems are in balance is a labor-intensive function that consumes much of the energy invested in accounting activities. The numerous inter-system relationships make flexibility practically un-attainable.
Exhibit I-III illustrates the real impact of inside-the-box thinking relative to the Financial Subsystems Paradigm. The mainstream events that make or break business missions often have financial effects, but there also are other information requirements that are above and beyond what accountants need to accomplish their mission. By defining accounting systems narrowly, the Financial Subsystems Paradigm has left most mainstream business requirements to be addressed by still separate subsystems that capture most of the same events needed by the accountants, but with more detailed information attached.
The separate subsystems also have the same basic architecture of traditional accounting systems which is characterized by a transaction processor that archives detail and posts summary files that feed narrowly defined reporting processes. The result is that parallel systems are required to support accountants and mainstream business requirements which in turn creates increasing layers of reconciliation, flexibility, system maintenance, and data visibility problems. The layers of complexity caused by traditional architecture, coupled with the Financial Subsystems Paradigm, have resulted in a virtually unworkable situation from an enterprise standpoint.
Traditional architecture was fit for the purpose in the world of 20 years ago when the economics of computing power forced designers to archive detail (much like manual accounting systems) and automated systems were few in number, limited in scope and non-strategic in nature. A new paradigm is required as we attack integrated system requirements. The events-based architecture illustrated in Exhibit I-IV is a solution that is attractive both theoretically and practically.
Exhibit I-IV illustrates an architecture where the point of departure is a broad view of the business systems problem.
It views the proper subject matter for a system as all business events that an organization is interested in planning for, evaluating or controlling. Rather than building separate transaction processors to capture, edit and post payroll transactions, general ledger transactions, inventory transactions… and so on, one transaction processor can be designed to capture events according to their respective data structures and apply the respective business rules for editing and posting and reporting in a generalized way. It explicitly recognizes that detail information should be accessible so that information requirements can be accommodated as they are identified over time. In addition, it
recognizes that mainstream information require-ments and financial information requirements should be supported through the same data capture, maintenance, and reporting facility.
Conclusion
The practical result of viewing systems problems in this broader architectural context is a consolidated design for the systems that get built. A consolidated design means fewer programs to write, test, and maintain. Fewer interrelationships must be defined, understood, explained, and reconciled. The sensitivity to requirements defined at the outset is diminished substantially because views of the data captured are not limited by the summary data structures posted by the transaction processors.
A consolidated architecture is better because of its flexibility in accommodating changing requirements. A consolidated architecture is faster due to the reduced development life cycle emanating from the underlying simplicity of the concept. It is also cheaper because redundant functions are eliminated and there are fewer objects to build and maintain in the application portfolio.
Original Images
These are images of the original paper.
