Someone sent me a private email asking about the origins of the name of my blog. So, here it is ... 

I originally started working on rules and expert systems a long time ago in a galaxy far, far away - in fact, it was Intel Architecture Labs, under a very smart leader named Hans Witt (Hans is now part of Haley).  I went through lots of different directions over the following years, including time at Cisco working on networking SLAs, firewall and configuration rules, etc.  And, I spent time in the DMTF and IETF authoring policy models and RFCs (take a look at RFCs 3060, 3198 and 3670).  But, in spite of all the low-level, siloed work, I kept believing that policies and rules were motivated by the business and its needs (and not specific technologies). And, I kept believing that we were missing the most important user/customer of policy - the business. I ended up at Microsoft focusing on business - working to capture a business' goals and ways of doing business (corporate policies, management directives, processes, vocabularies) as formal, analyzable definitions that could then be acted upon by existing infrastructures. The goal of the work is to go from a business' "natural language" to artifacts that can be refined in model-driven infrastructures.

There are certainly lots of tools and standards in the business process, business modeling space - but only for the educated professional. :-)  For example, there are business process diagrams that can be expressed in BPMN (Business Process Modeling Notation), collaboration, activity and use case diagrams captured in UML (Unified Modeling Language), tool-specific definitions of "interactions" or "communications" (usually saved in some proprietary XML), data models focused at a conceptual, implementation-independent level (perhaps captured as UML objects) or a specific database's definitions rendered as entity-relationship diagrams, and on and on.  Then, you can capture rules as UML's OCL (Object Constraint Language). Or, you have the "business rules" approaches.  There are many of these tools around - but they are again geared to the educated professional (dare I say, programmer?) and usually targeted at a single, backing rules engine. 

None of this is really accessible to or usable by a business person. I was told by several of my customers that business people use three tools - documents and emails (written word with some pictures and graphics) and spreadsheets.  Period, end of story. So, none of the complex diagrams or acronyms really help in this space.  But, there are some options that go in the right direction. Ron Ross advocates writing rules in a clear, precise manner - "RuleSpeak" (http://www.brsolutions.com/p_rulespeak.php). If we have this, should we be able to formally analyze the vocabularies and rules, and then transform them to UML and many other encodings?  Yes!  And, could we share this data and interoperate based on standards such as SBVR, the Semantics of Business Vocabulary and Business Rules from OMG (http://www.omg.org/spec/SBVR/1.0/)?  Yes!  Cool, "policy-based business".

From another angle, Forrester wrote an interesting piece in  May 2008, under the title, "How the Convergence of Business Rules, BPM and BI Will Drive Business Optimization".  That report has a great graphic that business policies drive processes and rules, which in turn consume and generate data. Forrester says "Enterprises are run by policies".  I take that as validation of the "policy-based business". :-)

Andrea