(1) a body of methods, rules, and postulates employed by a discipline,(2) a particular procedure or set of procedures, or (3) the analysis of the principles or procedures of inquiry in a particular field.

There are two senses of the term 'methodology above'.  The second definition and and one half of the third definition describe a way of going about something, the activities required to meet an objective using certain guidelines, incorporating a set of preferred procedures that have proven effective over the course of long, sometimes hard experience.

The other sense of 'methodology' refers to the "principles" and "methods, rules, and postulates", in other words the tools and methods one employs to solve a problem or answer an inquiry.  It might be regarded as a slip of terminology, since it seems to be using the word 'methodology' for the real meaning, that is 'methods'.  Nonetheless, the sense of 'methodology' as method is probably the most common sense of the word when it is being used.         

Slippage and fuzziness of terminology is very common in all human endeavors and has lead many people astray over the millennia.  An insistence on rigorous definition of terms is a major benefit of the business rules approach and is almost like the heartbeat of rules-based systems.

A clear standout among the excellence is Barbara Von Halle's "Business Rules Applied", which may deserve the title as the 'Bible of Business Rules'.  The approach it outlines will be used extensively in this and later chapters on rule based systems.

The GUIDE methodology is the result of a collaboration between most of the big names in business rules, Barbara Von Halle among them.  It includes good, concise definitions and basic descriptions for terms, facts, assertions, conditions, actions and derivations, the various types of each modeling entity, their origin, how to express them, etc.  Details of the GUIDE model will be described in the section for Rule Based Systems.  

A key concept is that business rules are "one cohesive body of rules, enforced consistently across all relevant areas of business activity" - they are enterprise business rules.  Another key concept is the use of sophisticated tools to formulate, validate, and manage business rules and to help business people verify complex interactions between rules for completeness and consistency.   

For a high-level summary definition, see the Business Rules Manifesto.

Business rule methodology has become a big field.  The principles have been covered so well in so many articles, books and white papers that it would be redundant and somewhat futile to 'reinvent the wheel' yet again.  It is also somewhat beyond the technical focus of this site. 

From a technical standpoint, perhaps the most important concept is that "formal logics", such as predicate logic, which is fundamentally important to expressing well-formed rules in business terms that both people and computers can understand.  Rules are stated in a form that computers can understand and enforce across the entire enterprise.

Instead of programming logic, business logic rules the roost, but that may not be the big bargain it appears to be at first.  Complexity doesn't go away - it shifts to a different arena, the business community.  Instead of being buried in program code, the complex rules that govern the business express themselves in the complexity of the business rules that must be managed by business people, albeit in a far more visible and controllable form than program code. 

The prime directive is "make it simple".  The usual formulation is "keep it simple", but this form of the directive says if it isn't simple then make it it simple.  Needless to say, it is much easier said than done.  

Another powerful concept is "Subjects Before Objects".  The distinction is a sort of meta-rule about how to go about modeling rule-based systems.  One can think of it as warning to technically-inclined folk who love to jump in and start doing object-oriented computer stuff without 'wasting time' over system requirements.  Sophisticated object-oriented design paradigms are useful for software engineers - they are virtually useless for everyday people solving everyday problems.         

The formulation of rules, and knowledge in general, starts with subjects.  In the business world, the subjects are business subjects.   If one wanted to create a knowledge base about sport, the subjects would be about sports.  The process of forming rules and knowledge may be similar for business subjects and sports subjects, but the essential nature and complexity of the subjects are very different.    

In any case, the all-important first step of identifying and defining subjects should involve only a piece of paper ( maybe a word processor ), simple natural language assertions about the subject domain and maybe a few drawings to assist clear expression.  The definition of requirements should be stripped of object concepts, abstruse modeling notations and all the paraphernalia of software engineering.  Maybe a few specialized symbols can be allowed, such as squares for data and circles for actions, or visa versa.  In other words, nothing fancy.  An uninitiated person should be able to read through a document discussing the subjects and be able to get a basic sense of what it's all about.

Another power concept is Subject Lifecycles.  Once one identifies subjects, one explores the lifecycle of the subject, such a Customer lifecycle, Product lifecycle, Order lifecycle, etc..  Anything subject that has a series of stages or fixed sequence of 'status codes' has a lifecycle and is of extreme interest to modelers.  They tend to be the the motor that drives big transaction processing systems over a wide range of industries.          

A concept that is too often neglected is understand the impact of what you are proposing and expect to have plentiful opportunities to demonstrate patience.   Many technically-driven business rules initiatives get stalled by the sudden impact of a common set of business definitions on the corporate culture.  It can take a company a year or two to absorb and understand all the enterprise-level business issues raised by a reasonably thorough business rules analysis.  Consequently, the technical side of the initiative can 'hang fire' for several years while the business community adjusts itself to the new vision.

The business factors driving technology to support knowledge discovery are mostly business rather than computer or technical.  Often, marketing or research organizations are the prime users of powerful multi-dimensional analysis and data mining tools and a host of statistical analysis packages.  Tools sets are usually packaged with sophisticated analytic database back-ends, something like community data marts for researchers or specialized knowledge workers. 

The technology is capable of sifting through large amounts of data to extract patterns of information the data, for instance, that the color green is more popular this season.  It also can be used to extract 'after the fact' information that lead to new business rules, for instance the fact that 35% of orders shipped Fridays arrive late to the customer, compared to 7% the other days of the week.  Data mining tools facilitate themselves very well to rule and knowledge discovery in corporate situations and may well be usable in data-rich environments such as the Semantic Web. 

A great 'subject' modeling tool is CRC cards, a very informal and flexible approach to object oriented modeling.  CRC stands for "Class, Responsibilities, and Collaborators".  It can be built with 3 X 5 index cards ( word processors are also allowed ).  A collection of a few dozen cards shows the responsibilities and interaction between the 'classes'. 

The word 'classes' sounds like objects so we will use the word 'subjects'.  Instead of CRC cards, it will be SRC cards, standing for "Subjects, Responsibilities, and Collaborators".  SRC cards are created through scenarios, revealing requirements that model the major entities, relationships and behaviors of a system in an intuitive, notation-free way. 

There are many excellent, tools, methods and methodologies that are not part of the core of business rule methodologies.  Some have a rule-based flavor, others have an entirely different approach to modeling that can be adapted for the purposes of business rules, notably the Zachman Framework, which was developed long before the advent of the business rules.  These tools and methods will be explored in greater depth in the section for conceptual modeling.