When I was in elementary school, one of my classmates worked assiduously to find ways to get around the rules. Regardless of the situation, my friend was obsessed with doing things his own way while still operating within the boundaries of the classroom rules of conduct. Of course, sometimes he could not figure out the right "hook" and would get himself into hot water. I am sure you have met people like this. Whether figuring out how to laze around at the workplace without getting caught, driving in the breakdown lane during a traffic jam or acting as a corporate tax attorney looking for ways to exploit loopholes, there is some inherent drive to get around the rules.
It would not be unreasonable to state that most organizations are driven by a set of business policies designed to effect achievement of specific business objectives. These policies may be stated explicitly in some form of business directives, run books or memos; or, they may be implicitly understood by all staff members. In government situations, policies may be stated in regulations, legislation or perhaps even interpretive judicial documents. As information professionals, we recognize the value of explicitly stated business policies because these policies typically encompass the business rules that influence both information architecture and system design. In fact, business rule engineers relish documented business policies because they are rich in the business terminology that feeds business rule automation; and those of you who regularly read my columns are well aware of my attachment to formal rule frameworks and their use for automating system implementation. I am a firm believer in the value of being able to document rules at a relatively high level while making the rules actionable and self-documenting.
A rule-based system is defined by a set of system states, along with a set of transitions dictating how the system moves from one state to another based on a set of inputs. All of the rules of the system define system states, describe what inputs are expected or describe what transitions are effected by those inputs. It is can be very enlightening to read through documents with an eye toward what we might call "rule harvesting." Sometimes, the text dictates constraints on the system; other times, there are directives associated with identifying specific events and corresponding actions triggered by those events. In any case, the text will typically define business terms used throughout the set of policies, which helps drive any modeling activity and provides input to a meta data repository. Well-described policies perhaps even dictate exactly how the system would be implemented, surely a sign that a rule- based system is appropriate! Even applications that are not well-documented are still run by policies and their associated business rules. In most situations, being able to figure out the rules provides valuable input into how the application is to be built.
The one downside to rule-directed systems is associated with folks such as my childhood friend. Whenever a system is governed by rules, there are likely to be people trying to get around those rules. These people can be the source of either fraud or evasion, which we might call "defector behavior." As a classic example, a number of years ago, the details of the rules associated with the way that telephone tones directed how phone calls were logged and subsequently billed were published in an internal telephone company journal. These details were leaked externally, and some enterprising people designed an electronic device that simulated those tones. In turn, individuals were able to build a box and use it to make telephone calls without having to pay for them! As a side note, applications within the telecommunications industry have traditionally been fertile ground for defector behavior consider how we are plagued today by computer viruses propagated via security holes in e-mail and browsers.
Some organizations try to address rule evasion through the introduction of data analyses to ferret out defector behavior. In many industries (including telecommunications, insurance and accounting), data mining is used to look for behavior that might indicate fraud. The implication I draw from this situation is that when implementing a rule-directed system, we are not careful enough in analyzing the system states and their corresponding transitions for completeness. We must ask questions such as, "Are there any system states from which there are no outbound transitions?" and "Is it possible to see inputs in some system states that introduce unexpected behavior?" I am not trying to be naive a comprehensive system analysis will not prevent defectors from trying to evade the rules. However, as a matter of good practice, an analysis of the state machinery of your application should expose situations where defectors may be able to derive some advantage. Once these have been found, steps may be taken to patch up the holes. Finding these loopholes won't solve the overall problem, but why leave the back doors wide open?
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access