What do legal contracts and computer security specifications have in common?  You might not think too much, but actually both are often based on a common assumption -- namely, that rights must be specified explicitly.  In other words, nothing is permitted unless explicitly authorized.  This assumption is just the opposite of the one usually assumed for business rules -- namely, that nothing is prohibited unless explicitly forbidden.

The world of legal contracts assumes the possibility of malfeasance, breach of trust, non-performance, etc. -- in other words, the worst possible outcomes.  Similarly, the world of computer security specifications assumes the possibility of hacking, identity theft, sabotage, etc. -- also worst-case scenarios.  In both cases, the underlying assumption is a bleak one.  Let's call this the dark world.  In a dark world, everything that is not permitted is forbidden.

The world of business, in contrast, generally assumes success, whether in financial terms or otherwise -- in other words, the best possible outcome.  Only in certain cases might business goals conflict, or levels of risk be unacceptable.  In these and only these cases do we need protection -- i.e., business rules of the 'normal' sort.  Let's call this the light world.  In a light world, everything that is not forbidden is permitted.

With this in mind, let's revisit the business rule mantra:  Rules build on facts, and facts build on terms.  Normally in the business rule approach we start off assuming that all facts are unconstrained.  In other words, there is no rule unless we say there is a rule.  In a dark world, just the opposite is true -- there is no permission unless we say there is permission.  In other words, we start off assuming that all facts are constrained, then any authorization we might specify un-constrains them (some).

Now for the bottom-line question:  Should authorizations be considered business rules?  The answer should be obvious -- of course.  They simply come from a different world.

# # #