Related Links

Web Seminars

A few weeks ago I was in a department store and found some expensive dinnerware that was on a half price sale. I also noticed that some of the items were priced quite differently to the advertised 50 percent discount. Several were much cheaper than this, while a few others were actually 10 times more expensive than the regular price. In addition I had two personal discounts that I could apply to any purchase. After picking out the dinnerware items that were the best buy, I went to the checkout. The mispricing and my personal discounts layered on top of the special sale were more than the terminal could handle. "But don't worry," said the sales clerk, "I can get round it." Indeed she could. I watched as she used a series of manual overrides and what she called "special ways of doing things" to input a long series of transactions. The clerk warned me that my receipt would look a bit odd, but the final figure was the cost that I had calculated. That was what I paid, and I walked away happy.

What is "Gaming the System?"

This incident reminded me of something all IT professionals have come across at some point, which is "gaming the system." This can roughly be defined as using a computerized system to process data or yield a result for which the system was not designed. Users, especially system operators, usually engage in this kind of behavior to get their work done in what they would call a more efficient or effective manner. Occasionally, there may be more sinister motives, but I have never personally encountered instances of fraud, although we all know that it can occur. Whatever the motives, gaming the system deeply offends the sensibilities of most IT professionals. The reason is that IT professionals spend a lot of time and effort getting the logic of systems right. Whether using traditional programming or business rules engines, IT professionals strive to get what they consider to be the correct set of business rules implemented in a system. When users game the system it seems as if all this hard work is being repudiated.

Users rarely advertise that they are doing things with a computer system for which it was never intended, and it is my guess that IT professionals only hear about a small fraction of what is actually going on. Perhaps for traditional systems development projects this situation can be tolerated. However, there are a couple of important considerations for business rule projects that need to be thought about.

Auditability

One of the greatest advantages of the business rule approach - at least in theory - is that it is possible to understand the origin of data values derived through executing business rules. In systems where program code is handcrafted, programmers may have to spend an inordinate amount of time combing through source code to figure out what got executed in order to populate a particular data value. By contrast, the business rules approach offers the promise that the rules that led to the population of a particular data value can be shown in a report. This ability to audit derived data has other advantages. In many circumstances, e.g., in special regulatory or legal environments, it may be necessary to prove that a certain set of business rules were used to derive data. Therefore, if a system can be "gamed," the capacity for auditability may be diminished, and one of the most important benefits of the business rules approach may be lost.

One of the ways to protect auditability is to design databases so that data derived through business rules is distinct from data that is updated manually or via handcrafted program code. This tends to spawn additional columns in databases, which is disliked by many IT professionals, but it is really a very small price to pay. More protection can be given by forcing users to state why they are doing certain things when processing transactions in unusual ways. This meta data can be stored and can be an invaluable aid to auditing data

Why Play Games?

While IT professionals dislike users playing games with systems, they tend to avoid asking why such things happen. A major reason is that a system may not satisfy the requirements of users because the nature of a business changes. Users have become so inured to having IT ignore their requests or provide solutions in overly long time frames, that they often look first to gaming the system as a way to accommodate new requirements. Yet, the business rules approach holds the promise of being able to quickly change computerized environments to cope with changed circumstances. Being able to deliver on this promise is another question, however. If there are not sufficient feedback loops between the users and IT (or whoever is responsible for updating business rules) then the business rules approach is unlikely to deliver. Similarly, if an organization implements a business rules approach within an IT bureaucracy that has been established to manage the traditional systems development approach, the full potential of the business rules approach is unlikely to be realized.

Hopefully, these obstacles can be overcome. We must also hope that the culture of gaming the system is not so entrenched in information management that it impedes the progress of the business rules approach.

Malcolm Chisholm, Ph.D. has over 25 years of experience in enterprise information management and data management and has worked in a wide range of sectors. He specializes in setting up and developing enterprise information management units, master data management, and business rules. His experience includes the financial, manufacturing, government, and pharmaceutical industries. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and Definition in Information Management. He writes numerous articles and is a frequent presenter on these topics at industry events. Chisholm runs the websites http://www.bizrulesengine.com, http://www.refdataportal.com and http://www.data-definition.com. Chisholm is the winner of the 2011 DAMA International Achievement Award.