There are many different kinds of policies and rules - going from high-level corporate policies on how business is conducted and its information is secured, to extremely low-level rules about how a specific component in a piece of hardware or software operates (for example, garbage collection in the OS must be run at least once every 1min).  Are all of them defined and managed the same way?  I don’t believe so, since the scope of the policies/rules and the definitional environments are very different.  (By the latter, I mean that the policy definers speak different “languages” and use different tooling. For example, business people "program" in tools like Word, Excel and Outlook. :-)

Now, traditional programmers will raise cries of disbelief that business people program in Word.  However, consider a well-written business requirement document - this defines a business process, its data and flow, requirements for validity checking, algorithms for calculations, decision points, etc.  Sounds like a program to me - but we don't capture it as such.  We think of it as unstructured data which has missing information (usually basic assumptions and definitions that the business person thinks too obvious to write down, but that a programmer unfamiliar with the environment misses completely) and errors (unstructured data can't be analyzed). But, what if we could analyze Word docs?  (I will come back to this in later posts.)

Let's go back to talking about types of policies and rules - and interactions between different types and scopes.  Even though policies and rules might be defined in specific, isolated "communities", they do impact each other.  One example is where government-mandated compliance policies may override business processes and rules.  But, this is pretty easy to understand since they are both defined at the "business" level.  Another example where intersection of rules might occur is where an IT policy causes a business application to fail or perform badly.  However, since these are defined by different people in different scopes - you usually don't know about a problem until it happens (too late).  It would be good to know where these overlaps and problems are, before they happen.  Doh! 

So, simulation is vey important - but I think that more is needed. 

Analysis of business definitions and requirements - maybe using existing ontological map/merge techniques (!) - would help to find errors and inconsistencies at the same policy level. (That takes us back to the importance of analyzing Word docs.)  And, the ability to tie rules across levels using KPIs (key performance indicators) and SLOs (service level objectives) is one way to go.  Implementation-specific or monolithic rule structures seem like very bad ideas to me.  Also, a universal policy language (usually based on if-then-else programming constructs) seems wrong to me.  The latter is too deterministic ("a gold customer must get at least a 10% discount on all purchases" is not as deterministic as it appears :-), and it would be crazy to tie policies from high-level to low-level in a single definition.  

Andrea