The old ledger paradigm in accounting software design is slowly giving way to components that deliver specific business functionality to support the needs of different industries.
When you think of accounting software, do you picture a suite of modules that are interfaced or integrated? This image is a carryover from the days of manual bookkeeping, when individual books were maintained to record accounting items in multicolumn ledgers. Even modern client/server accounting software is largely organized in the same fashion and users of accounting systems have become comfortable with their electronic ledgers.
However, some would say we have become too comfortable with the ledger paradigm and it is time for a new way of designing, deploying and using accounting software. In fact, although it is not obvious to most users, we are in a period of transition in terms of accounting software design.
The move to client/server accounting was initiated in the early 1990s. Client/server encouraged vendors to partition their applications into client and server components. Today, the influence of the Web is pushing many accounting systems to adopt a new browser/server architecture. This is forcing vendors to break their applications down a step further into separate "applets" that can be deployed individually or in combination inside a Web browser. As we move into the next century, we can expect yet another transition to component accounting, based on applications being delivered as so-called business objects choreographed by a sophisticated workflow engine.
Alternate Views of Accounting Architecture
There are at least three high-level ways of viewing the architecture of an accounting system (see Accounting Architecture Views):
- Ledger-centric, in which functionality is divided into ledger modules that are interfaced or integrated to deliver an application suite.
- Service-centric, in which accounting systems are constructed through the integration of multi-vendor modules that each deliver a specific service to users.
- Process-centric, in which functionality is delivered to support the automation of specific business processes or the job performed by classes of user.
Today, almost all accounting software is ledger-centric. Some vendors have moved toward a service architecture by surrounding their core accounting functionality with third-party "service" modules that provide complementary functions such as reporting, workflow, imaging, electronic commerce and so forth. And a few vendors, mostly those with a strong workflow orientation, are delivering their software functionality in assemblies designed specifically to support "best practices" for automating business processes such as procurement and fulfillment.
All of these approaches fail to deliver true component accounting, which requires that the software be constructed from discrete lower-level functional components. These components are designed to deliver specific business functionality and to operate collaboratively within a particular operational framework supporting the needs of different types of businesses. Component accounting software demands application characteristics such as the following:
- Design (business objects): Designing the software as discrete functional components (usually termed "business objects") that represent real-world people, places and things, such as employees and customers, companies and departments, orders and invoices.
- Delivery (user- or process-centric): Delivering business objects in the form of "assemblies" or "frameworks" that reflect either a user's job (such as the purchasing manager or accounts payable clerk), map onto a generic business process (such as shipping, receiving, payment processing or month-end reporting), or offer a solution for a specific type of business (such as banking or insurance).
- Deployment (location independent): Business objects may be physically deployed on desktop PCs (clients) or in local or remote repositories (servers); the actual business object code may be physically stored inside a database and utilized by applications through the use of special "object request brokers" — software that tracks, locates and delivers business objects to applications that need to use their functions.
Fundamental to the concept of component accounting is the delivery of the software functionality in the form of business objects. Business objects are software "black boxes" that include both the data that "belongs" to the object and the programs (called "methods") used to maintain and manipulate the data. The object data can only be managed through use of its methods. This is good news for accounting applications because it ensures that the accounting data can only be accessed by authorized users and used in ways that the system designer intended. Also, the object's data could be stored in any form in any location, since it is the responsibility of the object to manage its own data. This may mean that document images, such as a scanned invoice, may be stored in an object database whereas the text and numbers data are stored in a relational database. While users would normally interact with a business object through a visual interface such as data-entry and query forms, other objects and applications would normally interact with the object by working directly with its methods non-visually.
The complexity of the data, range of methods and visual forms associated with a business object determines its relative sophistication. A business object for currency conversion might only manage data such as currency codes and exchange rates, have a few methods to handle the input of source amounts to convert and the output of target converted amounts, and provide a couple of simple tabular forms for the user to maintain currency codes and rates. However, a business object such as an invoice would be much more sophisticated (see "An Invoice Business Object").
Business objects are themselves composed of combinations of lower-level components called system classes. The vendor delivers a framework of system classes that can then be used to build a wide range of business objects. For example, a framework might include system classes for an invoice header, address and line item. These can then be combined into an invoice business object and this object in turn used as the basis for a more specialized version of the invoice such as a project billing or a credit note. This delivers advantages both to developers and users of component accounting.
For developers, once they have built a core set of system classes (no trivial task) they can then start to combine classes into objects or inherit from existing objects to create new ones. So the rollout of new functionality may be faster than using traditional programming methods. Also, as ancestor objects are changed, the changes "ripple through" to all objects that depend on that ancestor, which helps to ensure fewer software bugs and better overall consistency in the application.
For users, fewer bugs and greater consistency in terms of the look and feel of the application and the way it works are always a benefit. But the real benefit comes from the fact that applications built from business objects are more likely to offer greater flexibility in the ways that functions can be assembled around business processes and user tasks. This will allow system functionality to be deployed in "assemble-to-fit" combinations that could reduce both acquisition and implementation costs and reduce learning curves because only the functionality needed, not whole modules, are being installed.
Managing the collaboration of business objects internal and external to an accounting application is the role of a workflow services layer. The workflow engine is used to respond to calls from an application to load a specific business object to support a user request or activate the next step in a business process. The workflow engine is responsible for managing the integrity of the transaction data passed between objects, such as between the requisition, purchase order, vendor invoice and payment business objects. The workflow engine must monitor a wide range of system, application and business events that impact individual business objects or business processes. The workflow engine will be responsible for passing data to and from external applications or managing the integrity of connections to Web services such as electronic commerce, credit checking, exchange rate or tax rate download. Currently, workflow is regarded as an add-on to accounting applications and deliverable only in high-end accounting suites. But in the component accounting future, workflow services will be an essential infrastructure layer just like print, network or database services are today.
Back to Reality
Despite the promise of component accounting, few vendors have actually tackled the mammoth task of redesigning their application as a framework of system classes and business objects. One of the few that has is Consist International Inc., whose new Obvius General Ledger takes the deep functionality of its legacy mainframe accounting system and transforms it into a leading-edge component accounting system. Others who have taken the object route include IBM AS/400 accounting vendors such as System Software Associates (SSA) and Infinium Software, both of whom were early to market and met with resistance to their new object-oriented accounting systems. Early workflow accounting pioneers such as Computron and Geac SmartStream (formerly Dun & Bradstreet Software) have also had difficulty getting mass acceptance of their process-centric vision. They, and other vendors, are actively pursuing the delivery of application functionality as a series of "best practice" workflows that can be quickly installed and adapted to specific business needs to make their sophisticated workflow capabilities easier to implement.
Market leader SAP has been active in exposing interface methods (called business application programming interfaces or BAPIs) for third-party software to access data in its R/3 suite. Currently SAP is only just modularizing its mammoth R/3 suite and it will be some time before it can deliver the functionality in the form of components. Meanwhile, industry giant IBM has been working on its project "San Francisco" for some years to deliver industry-specific frameworks of collaborating business objects, but has yet to make any significant market impact with its deliverables.
Despite the relatively minor market impact to date of these visionary products, my discussions with vendors confirm that component accounting is definitely the next big thing in accounting software design. Once again, Microsoft technologies such as variants of COM (component object model), ActiveX and Message Server are likely to figure prominently in the vendors' plans to componentize their suites, as is compliance with CORBA (common object request broker architecture). True component accounting is unlikely to surface in force before the year 2000, but when it does it promises to dramatically change the way accounting software is built, delivered, deployed and used.