When it comes to implementing an accounting system, an organisation has three basic choices: buy an ‘off the shelf’ system, build one themselves ‘from scratch’ or compromise and build one themselves using proven infrastructure from an established vendor. Here we argue, from experience, that the latter approach gives an unbeatable combination of flexibility, cost and low development risk. Furthermore a business rule management system (BRMS) is a very potent implementation vehicle for an accounting system.

An accounting system is a mandatory element of any financial institution’s back office. Over the past ten years we’ve have helped to build five of them. We’ve seen systems built from the ground up (in C++ and Java with a Sybase back end) and systems based on ‘off the shelf’ accounting packages. But by far the most successful approach is building an accounting system based on a business rule management system (BRMS). This approach is so successful because:

1. It eliminates the key disadvantages of most accounting packages:

  • Flexibility: many packages impose a strict model of accounting on your enterprise (e.g. they insist on handling valuations internally, have a fixed approach to notionals processing or exception handling, or oblige you to use a specific ERP or general ledger). Integrating these constraints into your architecture can be a big hidden expense. With BRMS support you can implement your accounting precisely the way you need it and integrate with a wide variety of (standards based) systems.
  • Avoid Vendor Tie In: although offering more of the accounting solution ‘out of the box’, vendor solutions are designed to make you dependent on them. Frequently they have proprietary configuration systems which need to be customised and tuned to the specifics of your environment. Typically these configurations do not follow any open standards. Within months you will be overrun with expensive vendor consultants, introducing bespoke elements into their product, building your dependency on them. BRMS based solutions are more open: the business intellectual property remains with you and you can change vendor if you are not satisfied.
  • Business Visibility and Access: many packages do not express accounting policies in a business friendly format. They use ETL or imperative coding languages which are inappropriate for direct use by business SMEs. However accounting policies are business assets, to be expressed, shared and reviewed in a business medium, not buried within a technical language. BRMS frequently have thin clients and express accounting logic using the business vocabulary of your organisation – so all a business SME needs to review the accounting schema of their business is an internet browser. Even complex accounting logic can be directly represented in business friendly terms.
  • Governance: many packages have poor support for managed version control or a full governance service. BRMSs are much stronger at supporting this functionality: they can directly support workflow associated with changing the accounting schemas include review and testing. Further they can act as a focussed hub for collaboration between business and IT teams within a company.
  • Agility: if the accounting schema is expressed in business terms, complete separate from the underlying technical representation, then many small but necessary changes can be done without intermediating them through IT teams, thereby saving a great deal of time and money. This approach also avoids much of the errors introduced by translation of requirements from the business domain into the technical domain. BRMS introduce business oriented testing facilities which also reduce the need for IT involvement at every step.
  • Traceability. Few accounting packages can support genuine linkage between the accounting schema and the business documentation supporting it, or allow the impact of a proposed change to be assessed. In contrast BRMS support connections between business rules and supporting documentation and permit the dependencies between rules and the environment to be analysed. In addition the entire ruleset may be searched for the use of a specific business condition or action if the semantics need to be altered.
  • Testibility: few accounting packages permit business users to design their own regression test suite and perform output differencing and KPI measurement on test runs. Such a facility is supported by most BRMS and this offers the ability to compare the (business or technical) performance of different accounting policies or data. This greatly enhances the productivity of testing, allowing errors to be discovered early and supporting business users in experimenting with different accounting policies.

2. It mitigates most of the dangers of a totally bespoke approach:

  • Lower Development Risk: the BRMS provides a reliable, tried and tested, commercial-quality vehicle for shared, version controlled, collaborative, business-oriented development of an accounting policy – meaning that you don’t have to develop it yourself (or do without). The presence of a BRMS in your architecture leaves you free to concentrate on developing accounting schema and integrating your accounting engine with your existing back office components.
  • Lower Performance Risk: the BRMS platform offers proven performance benefits over processing in raw Java. Sophisticated rule eligibility algorithms ensure that that it is easier to achieve performant applications using rules than it is to code the same logic in raw Java.
  • Lower Quality Risk: using BRMS one can automatically detect inconsistencies in accounting policies (for example gaps, overlaps or contradictions in business rules) that are much harder to detect in a bespoke system. It can report such anomalies and suggest and coordinate resolutions.
  • Lower Cost of Ownership: A BRMS can be applied to many problems other than accounting – they are business domain agnostic. This means the associated license and maintenance costs can be amortised over many projects, making the total cost of ownership for each lower than a bespoke accounting solution.
  • Lower Risk of Key Man Dependency: If an accounting engine (or any other software system) is built upon a commercial vendor product, then knowledge of that product will be a commodity that can be bought on the marketplace and it will lower your dependency on key people within your organisation who might otherwise have to design and implement bespoke infrastructure.

3. It conveys many of the unique advantages of BRMS:

  • Building Enterprise Consistency: The business vocabulary used to represent your accounting policy can be shared with (or sourced from) other business rule applications, promoting a cross-project consistency in the terminology used. The vocabulary itself can be directly managed and controlled by the business using Business Vocabulary Management Systems.
  • Delegation: the precision of business rules allows the management of well-defined rule sets to be delegated to other business units.

These experiences demonstrate that the ‘part-build part-buy’ tradeoff offered by business rules infrastructure is a powerful middle road between the inflexibility and integration woes of a off-the-shelf system and the development costs of a completely custom made system. Our white paper ‘The Advantages of Implementing Accounting Systems Using BRMS’ has more details.

Useful? Please share: