How does one model dependency between rules?

Oscar - This is a challenge as the dependency between rules typically results when one rule sets the value of an attribute or causes the value of an attribute to be changed and the result of settng or changing the attribute value enables another rule to fire.  The most effective way to model this situation is through the use of UML Object models and notes that describe the state of the objects before the rules execute and the state of the objects after the rules have executed.

Is there any certification provided by ILOG for BRE?

Oscar - Yes, ILOG offers three levels of rule certification.  You can learn about these at the ILOG website.  www.ilog.com.

by Oscar Chappel

There are several books currently in publication that describe the importance of term-fact modeling when developing business rule systems.  These include Tony Morgan’s book, Business Rules and Information Systems, Ronald Ross’ book, Principles of the Business Rule Approach, and Barbara von Halle’s book, Business Rules Applied.  One of the key points made by all of the authors mentioned is that business knowledge is at the center of business rule systems.

Business knowledge is expressed using words and phrases that make sense to the business people.^[1] Facts build on the terms and express the things that business people know about their business.  Rules use facts to help control business operations to make sure that business is being performed the way the business people want business to be performed.  Terms form the foundation upon which business facts are built.  Business rules are built on top of business facts.  Business rules use business facts and interact with one another to guide business operations.

Figure 1.  Term, Fact, and Rule Pyramid.

The work that results in successful business rule discovery, analysis, modeling, and implementation all starts with term and fact identification and term-fact modeling.  This article focuses on the analysis and modeling techniques that I have used over the years^[2] in order to complete successful term-fact modeling and lead to efficient, successful business rule applications.

As Ron Ross points out, business terms are words and phrases that have meaning to business people in the context where those terms are used.  Facts are combinations of business terms that describe what business people know about their business.  So where do terms and facts come from?  How are terms and facts identified?  How do we model terms and facts in order to effectively use them in business rule applications?  What are the deliverables from term fact modeling?  This article will provide some answers to these questions.

Before going further, I want to say a quick word about ambiguity.  Use Cases and the scenarios based on those Use Cases are usually expressed using natural language and consequently they can be ambiguous.  Humans have the natural ability to interpret Use Case descriptions and scenarios and to ‘fill in the gaps’ caused by ambiguity.  Computers, on the other hand, deal in precision.  Computers cannot ‘fill in the gaps’ the way humans can.  Term-fact modeling provides the means to eliminate ambiguity from Use Case descriptions, scenarios, and business rules so the computer needn’t ‘fill in the gaps’.  Figure 2 represents a view of the role that term-fact modeling plays in introducing precision into the business rule discovery and analysis process.^[3]

Figure 2.  Term-Fact Modeling Creates Precision.

Answering the Questions

Where do terms and facts come from?

Use Case analysis is one of the primary ways that terms and facts are identified.  Use Cases contain a narrative describing the situations under which a particular aspect of an automated system is used.  The narrative is packed with business terms and facts.  In addition, the narrative often identifies decision points — places in the Use Case where at least one business rule must be enforced.  A Use Case is usually accompanied by a diagram that identifies the human or non-human actors, with the names of the Use Case and any extended or included Use Cases   Use Cases are supported by scenarios.  These scenarios are useful for fact identification as they capture the business users’ knowledge about business processes and decisions, and the situations that can cause decisions to change.

Terms and facts can be extracted from documentation such as business policies, standard operating procedures, governmental regulations, contracts, and other printed materials.  Terms and facts can also be extracted from a business’ current software applications and database definitions.  This approach is the least favorable because it usually results in the acquisition of terms and facts as seen by the IT technicians who implemented the software solutions and may not represent the actual vocabulary and knowledge of the business people and business processes.

How are terms and facts identified?

Terms can represent different things in the business context.  The things that a term can represent include:

• Abstract Business Concepts — Business Object Class
• Concrete Business Things — Business Object Class
• Characteristics — Attribute/Data Member
• Behaviors — Method

Facts describe what business people know about their business.  Facts can describe what business people know about the business objects used in their business.  Facts provide clarity to understanding abstract business concepts and describe concrete business things; they describe constraints associated with characteristics, such as size limits, thresholds, etc.  Facts often describe the relationships between business concepts and things.

A Use Case narrative is typically full of facts and terms.  A narrative identifies the actors who gain some form of benefit from the Use Case.  The Actors may be humans or automated systems.  The narrative will typically begin with a business event, e.g., “A prospective customer requests an insurance quote.”  The narrative then usually describes a series of activities that are to be performed by an automated system in order to generate the required benefit from that system.  The activities will all contain business terms and facts.

Use Case Analysis is the software design activity that enables term and fact identification.  During Use Case Analysis, it is often helpful to ask some simple questions to get a better explanation of the meaning of a term in the business context — questions like:

• “What is <term>?”
• “What does <term> look like?”
• “Is <term> similar to other < term>?”

The answers to these questions are facts.  They describe what business people know about their business and they will allow you to decide if <term> is best represented as a business object class, as a characteristic of a business object class, as a behavior of a business object class, or as relationships between business object classes.

How do we model terms and facts in order to effectively use them in business rule applications?

Two standards that are maintained by the Object Management Group (OMG) provide extremely useful guidance for the performance of term-fact modeling:  the Model Driven Architecture (MDA) and the Meta Object Facility (MOF).

The MDA emphasizes the creation of computation independent models (CIM), platform independent models (PIM), and platform specific models (PSM) in order to guide application development.  Business terms and facts are stated in natural language and are by definition totally independent of any computing platform.  CIM and PIM are platform independent models of the business domain and are therefore the most important models supporting business term-fact modeling.

The MOF provides the conceptual guidance necessary to actually construct meaningful term-fact models.  The MOF is platform independent and therefore encourages the development of PIM.  For example, the MOF allows the use of inheritance to create hierarchies of classes.  The MOF allows multiple inheritance to facilitate a clearer understanding of the business domain semantics.  The MOF describes three relationships that are essential in term-fact modeling:  Generalization, Association, and Aggregation.

Generalization is the relationship that facilitates creation of class hierarchies.  The colloquial term for generalization is ‘is-a’.  Generalization encourages the abstraction of common characteristics and behaviors to the highest logical levels of a class hierarchy.  Generalization enables the modeler to describe abstract business concepts and concrete business things.  Any time the question “what is <term>?” can be answered with the response “<term> is other < term>” the answer may indicate that the generalization relationship should be explored.  At a minimum, the answer indicates that two terms are synonymous and indicates that some common term must be established to avoid ambiguity among the business users and to eliminate ambiguity in computer applications.

Association is used to describe relationships between pairs of classes.  Associations can be navigable in one direction, from one class to another, or bi-directional.  Association is often colloquially called ‘uses’.  Association indicates what one class ‘knows’ about another class.  The concept that classes ‘know’ about other classes is fundamental to modeling facts.  Navigability also indicates that one class may delegate work to another class.  Association can be used to indicate that one class may delegate work to another class.

Aggregation is used to describe the situation where one class has components that are other classes.  The colloquial terms for aggregation are ‘has-a’ and ‘part-of’.  Like association, aggregation is navigable in one direction or bi-directionally.  Navigability of an aggregation relationship indicates that one class may know that another class is a part of itself or a class may know that it is a part of another class.  The decision of the need to provide navigability in an aggregation relationship is guided by ‘what makes sense’.  For example, it may make sense that an automobile ‘knows’ that a particular engine is a component but it may not make sense that an engine ‘knows’ that it is a component of a particular automobile — the reason, engines are removed from and replaced in automobiles all the time.  The automobile can delegate work to the engine however the engine can not delegate work to the automobile.

The MOF describes a feature called cardinality.  Cardinality can be used to express the number of class instances (objects) that participate in an association or aggregation relationship with other class instances.  When used in conjunction with association and aggregation, cardinality provides an added dimension for expressing constraints.

The Unified Modeling Language (UML) provides excellent tools to perform term-fact modeling.  The UML is based on the MOF; therefore it provides generalization, association, and aggregation as well as allowing specification of cardinalities.  The UML also offers the Object Constraint Language (OCL), which can be used to enrich model semantics.

What are the deliverables from term-fact modeling?

Term-fact modeling is performed to capture the business semantics in a way that enables development of rule-based systems.  The first deliverable of the term-fact modeling process is a collection of platform independent models that can be converted into platform specific models for the application that is being developed.  Platform independent models are crucial because they represent the business in its simplest form.

The first and most important deliverable of term-fact modeling is the definition of the terms that are important in the business domain.  In most cases term definitions are provided in a business glossary.  A complete business glossary is not necessary in order to move to the next deliverable, however.  The business glossary template in Table 1 is useful for defining business terms and provides a mechanism to describe the term’s business use, for example, a term might represent an abstract concept, a concrete thing, an attribute, or a behavior.  The description often contains facts that are important to completing the term-fact modeling.  The description can also be looked upon as a statement of a business requirement.  The description can lead to other facts that are not explicitly stated but that must be captured in order to properly represent the business environment.  For example, the description of the various Customer terms in Table 1 was extracted from The Enterprise Ontology.^[4]

Table 1. Business Glossary Template

Term	Description	Business Use
Actual Customer	The role of a Legal Entity agreeing to exchange the Sale Price for a Product in a Sale.	Concept, Role
Potential Customer	Any Legal Entity who may become an Actual Customer.	Concept
Customer	Any Legal Entity that may be an Actual Customer or a Potential Customer.	Concept

The various Customer descriptions in Table 1 provide additional business terms that must be added to the glossary.  The description of an Actual Customer contains additional facts that must be extracted, captured, and modeled.  For example, the fact ‘A Product is offered for Sale at a Sale Price‘ indicates that every Product has a Sale Price.  One must dig a bit deeper into the Enterprise Ontology to find that a Product is a generalization used to describe a Good, a Service, or a Currency.

Following the development of the Glossary of Business Terms, a semantic network can be developed.  In the semantic network, terms are represented by nodes and the relationships between the terms are represented by labeled arcs.  The labels on the arcs represent relationships between the terms.  Semantic networks can become quite complex and involved.  Figure 3 is the semantic network that describes the fact ‘A Legal Entity may perform a Customer Role ‘ and Figure 4 represents an example of a simple semantic network that generalizes the Customer description from Table 1 and represents the fact ‘Any Legal Entity may purchase any Product‘.

Figure 3.  Entity and Customer Role Semantic Network.

Figure 4.  Example Simple Semantic Network.

Further research into the Enterprise Ontology leads to the identification of the Entity concept.  An Entity is something that may perform Roles in the business domain.  Entity, Legal Entity, Role, and Product can be represented as a Class in the Object-Oriented Analysis and Design paradigm.  These classes can be diagramed using the Unified Modeling Language as demonstrated in Figure 5, a platform independent UML class diagram.  This class diagram represents a conceptual view of the relationships between Entity, Legal Entity, Role, Customer Role, and Product The platform independent model is the third deliverable of the term-fact modeling process.

Figure 5.  UML Class Diagram.

The third term-fact modeling deliverable is the logical model that is developed by expanding the conceptual model.  The logical model is often developed in conjunction with a data modeler or a data base administrator.  The logical model can be represented with a fully-attributed UML class model or it may be represented with an Entity Relation diagram.

By taking advantage of tools such as the Eclipse Modeling Framework (EMF), the logical model can be used to generate Java source code.  The Java source code generated forms the nucleus for the Business Object Model (BOM) source code that is essential to development of effective business rule systems.

Drive the Ambiguity out of Business Rule Systems

Ambiguity is the nemesis of all computer applications but is especially bad for business rule applications.  Ambiguity is rampant in all business domains.  Ambiguity exists because business policies, regulations, laws, and other documents are written in natural language.  People can manage the ambiguity and thrive in an environment where ambiguity rules.  Computer systems, especially rule-based systems falter and crash in such an environment.

Term-fact modeling is the most effective tool for driving ambiguity out of business rule applications.  When used in conjunction with the Model Driven Architecture, the Meta Object Facility, and tools such as the Eclipse Modeling Framework, term-fact modeling extends the analysts’ capabilities, enabling the analyst to specify/discover business rules, discover the business concepts, characteristics, behaviors, and interactions, model these discoveries, and finally generate source code that forms the foundation for business rule systems.

References

[1]  Principles of the Business Rule Approach, Ronald G. Ross, Addison-Wesley, 2003.  

[2]  This article describes, in general, the approach to term-fact modeling that ILOG applies in its analysis and modeling techniques.  ILOG has developed the ILOG Solution Implementation Standard (ISIS) methodology in order to provide our clients a repeatable process that they can use to develop business rule applications.  ISIS is an extension of the Rational Unified Process (RUP) and as such, it places great emphasis on the performance of Use Case analysis, iterative, phased development, and visual modeling.  ISIS and the RUP also emphasize Use Case based scenario definition to support software system design, development, and testing.  Use Cases and Scenarios are the first and one of the best sources for gathering terms and facts.  Other sources for terms and facts include written documentation, such as business policies, standard operating procedures, contracts, etc., as well as business experts, and currently operating software systems and data models/databases.  

[3]  based on ILOG’s approach  

[4]  The Enterprise Ontology, Mike Uschold, Martin King, Stuart Moralee and Yannis Zorgios, AIAI, The University of Edinburgh, 1997.  

Here is an article that I wrote for publication in the Business Rule Community web site in 2003. I thought some of you might find it interesting.

Keeping Business Rules Separate from their Enforcement

by Oscar Chappel

Article 4.5 of The Business Rules Manifesto states “A rule is distinct from any enforcement defined for it. A rule and its enforcement are separate concerns.”^[1]

This article from The Business Rules Manifesto raises a very important question. “What is the difference between a business rule and its enforcement?” It seems that it is difficult to get strong agreement on exactly what represents a business rule. I have found that it is even more difficult to reach agreement on the definition of a business rule’s enforcement.

When I think of a business rule, I think of the many possible definitions that Ron Ross published in The Principles of the Business Rule Approach.^[2] Ron provided 10 different definitions on pages 183 and 184. These definitions range from the very simple “…[A]n explicit statement of a constraint that exists within a business’s ontology” to the very complex “…[A] statement that defines or constrains some aspect of the business … [which is] intended to assert business structure, or to control or influence the behavior of the business. [A business rule] can not be broken down or decomposed further into more detailed business rules…. [I]f reduced any further, there would be a loss of important information about the business.” Regardless of the definition used, it is very difficult to explain exactly what a business rule really is. It seems that we should be able to agree that business rules describe the way business people want their business to operate.

Business rules are stated in many different ways but always using natural language. They can be stated in business procedure manuals, where they are often stated in terms of business policies. They can be stated in government regulations and manuals such as the Hospital Prospective Payment System Manual from the Centers for Medicare and Medicaid Services, CMS. They can be stated in business contracts where they are represented by the terms and conditions of the contract. They can be stated in service level agreements. They can be ‘common knowledge’ among the business executives, management, and staff, “this is the way we always do it.” Regardless of the source for the business rules, little attention is given to the enforcement of those rules. What is to be done if the business rule is violated? This example from the health care domain is illustrative.

Table 1. Excerpt from VMS-CORF Medicare Billing Highlights

Additional Occurrence Codes & Dates:
	Code 11		Reported with the date of onset of symptoms/illness only if physical, occupational and/or speech language therapy revenue codes 42X, 43X, 44X are billed.
	Code 35		Reported with the date treatment started for physical therapy at the billing provider in the current plan of treatment and only if revenue code 42X is billed.
	Code 44		Reported with the date treatment started for occupational therapy at the billing provider in the current plan of treatment and only if revenue code 43X is billed.
	Code 45		Reported with the date treatment started for speech language pathology at the billing provider in the current plan of treatment and only if revenue code 44X is billed.

These business rules leave the enforcement up to the reader’s imagination. The enforcement rules are missing. What actions should be taken, by whom, and when, when these business rules are violated?

The traditional approach to dealing with the missing enforcement rules is to bury the business logic in application software, stored procedures, database constraints, and other application source code, essentially hiding the enforcement rules from the business people and the software developers. Over time, the rules become increasingly unmanageable and costly to maintain. Any change in business rule or policies results in a software change project that can take months to complete and cost the business in both dollars and lost revenues. This scenario is the reason for the renewed interest in business rule systems.

It is no wonder that it is difficult to achieve consensus on the meaning of Enforcement Rules. When I think of the enforcement for business rules I think of software that has a base of knowledge, facts, business policies, and, yes, business rules that express ‘what should be’ in the business environment. I think of objects that represent this knowledge, that are stored in some form of fact repository, most probably a relational data base. I think of a persistence service that facilitates the insertion and extraction of these fact objects. I think of interfaces that allow business people to create these fact objects using natural language. I think of objects that are created by a business application to represent ‘what is’ at the point in time enforcement rules are expected to be employed. I think of a few, well-organized, logical enforcement rules that match the objects representing ‘what is’ to the objects that represent ‘what should be’. I think of business rule systems that help a business run smoothly by enforcing the business rules and policies. I think of economic solutions that empower the business people to control their business.

The business rule community seems to suffer from a handicap when we attempt to codify the enforcement rules for business rules. We are constrained by the things we know, our past experiences, and the habits we have developed over years of embedding business logic within business applications. We see business rules as “if … then … else” branching control statements like those we would write in COBOL, Java, C, C++, C#, or any other programming language, and we write business rules in this style believing it a good way to enforce the business experts’ visions of the way the businesses should operate. Our rule systems become bloated and begin to perform poorly. We struggle to find ways to process thousands, tens of thousands, even hundreds of thousands of rules rather than finding a way to reduce the number of rules while simultaneously achieving the desired result.

Over a period of nearly two decades I have had the opportunity to learn about both rules and object-oriented technologies and to apply the things I have learned in several industries including defense, insurance, manufacturing, entertainment, finance, and health care. Over the years, I have observed that an understanding of object-oriented programming technologies and predicate logic is invaluable in implementing successful business rule applications. I have learned that a rule engine is, first and foremost, an optimized pattern matching algorithm. I have learned that the pattern matching algorithm must test at least one of the conditions of each and every rule in a rule set to determine if the rule conditions should be tested further and if the rule can become a candidate for firing. I have learned that the more rules I provide the rule engine, the longer it takes to process those rules. I have learned that objects embody business facts, ‘what should be’ and business observations, ‘what is’. I have learned that Classes can implement predicates, methods that return a Boolean value and that these predicates can be used in the conditions of enforcement rules. I have learned that good enforcement rules provide patterns that enable a rule engine to efficiently compare ‘what is’ to ‘what should be’ and to recommend the appropriate actions when ‘what is’ is not ‘what should be’. I have learned that good enforcement rules can be reused across multiple industries when the business knowledge and policies are represented in a consistent manner. I have learned that good rule engine implementations will replace variables in rules with business objects and create ‘virtual’ rules that can replace the thousands, tens of thousands, even hundreds of thousands of rules that can cause poor performance.

Using the health care examples in Table 1 we can develop the following business rules.

Revenue Code 42X requires Occurrence Code 11.

Revenue Code 43X requires Occurrence Code 11.

Revenue Code 44X requires Occurrence Code 11.

Revenue Code 42X requires Occurrence Code 35.

Revenue Code 43X requires Occurrence Code 44.

Revenue Code 44X requires Occurrence Code 45.

These business rules are not enforcement rules, they do not describe the actions to take when the rules are violated. These rules tell us ‘what should be’ when a Revenue Code with a value in the range 420 to 429 occurs on a health care claim. But they do not tell us what to do when ‘what is’ — i.e., the codes reported on an actual claim — doesn’t match ‘what should be’. The usual approach is to reject a claim that violates the business rule and to provide a message explaining the cause for the rejection.

These business rules have additional problems. For example, the use of the X to signify a ‘wild card’ would lead the uninitiated to believe that a Revenue Code with a value 426 would be a valid code. This is, in fact, not the case. The Revenue Codes in the 42X range can actually take on valid values of 420 to 424 and 429. So Revenue Code 42X does not mean the continuous interval 420 through 429. The same holds true for the Revenue Codes with values in the 43X and 44X ranges.

There are many approaches to writing the enforcement rules for the business rules stated above. Among the most common, is writing one rule similar to these:

IF a Claim contains Revenue Code 420 to 424 or Revenue Code 429 and
		The Claim doesn’t contain Occurrence Code 11
	THEN Reject the Claim with message “Revenue Code 420 to 424 or Revenue Code 249 requires Occurrence Code 11.”

IF a Claim contains Revenue Code 420 to 424 or Revenue Code 429 and
		The Claim doesn’t contain Occurrence Code 35
	THEN Reject the Claim with message “Revenue Code 420 to 424 or Revenue Code 249 requires Occurrence Code 35.”

There will be a total of six such rules, one for each of the Revenue Code value sets. This doesn’t appear to be too large a challenge, but when one considers that there are currently more than 890 revenue codes that interact with other codes — e.g., Value Codes, HCPCS Codes and so on — the number of rules can quickly become unmanageable. This example illustrates how claim clearing houses end up with tens of thousands of health care claim edit rules.

Change is continuous in the health care industry. So imagine what happens when the format for Revenue Code values changes to a four digit format containing a leading zero, as happened in 2000. Now all the rules must be changed to insert a leading zero for all Revenue Code values. If a new Revenue Code with value 0426 is implemented a new condition (”or Revenue Code 0426″) could be added to the current rules. Alternatively, completely new rules might be written to account for the new facts: “Revenue Code 0426 requires Occurrence Code 11″ and “Revenue Code 0426 requires Occurrence Code 35.” Either way, the maintenance headaches, costs, and delays begin to mount.

A more efficient alternative lies in the exploitation of object technologies and unification, a technique that causes variables to be instantiated in rules, much like dynamic, parameterized SQL. Using these approaches one might create relationships between the various codes and enable the codes to ‘know’ about and find effective relationships. One might use a model similar to that in Figure 1. From this model, one might write a single enforcement rule similar to this:

IF a Claim contains a Reported Code and
		the Reported Code requires a Required Code and
		not Claim contains Required Code
	then create error message “Reported Code requires Required Code.”

where Claim, Reported Code, and Required Code are all variables that will be instantiated through unification as the rule is evaluated by an inference engine.

When supported with a ‘knowledge base’ of fact objects that implement the model in Figure 1, the single rule described above can be used to replace hundreds of ‘one-off’ rules. The rule is reusable because it can be applied equally well to the health care and warranty claim processing domains. In fact, this one rule can be applied in any domain where there is a proliferation of codes that are involved in relationships with other codes.

Business rules and their enforcement can and must be separated in order to achieve the results that business people demand from their rule based applications. This task requires a thorough understanding of object-oriented and rule engine technologies, and predicate logic. Business experts must be pressed to describe the actions that must be taken when ‘what is’ doesn’t match ‘what should be’. Thorough analysis, the application of the principles of object-oriented technologies, the use of predicate logic, and a good understanding of rule engine operating characteristics can relieve rule bloat and enable businesses to achieve the advantages of business rule applications.

References

[1] The Business Rules Group, Business Rules Manifesto ~ The Principles of Rule Independence (Ver. 1.2), January 2003. Available at www.BusinessRulesGroup.org (in English as well as translations to other languages).

[2] Ronald G. Ross, Principles of the Business Rule Approach, Boston, MA: Addison-Wesley, 2003.

We rather glossed over the issues of modeling in the September 24 Webinar on Rule Discovery, but they really are fundamental to the process of developing a business rule application. I’m going to spend some time going into a little bit of depth to the kind of models that you need on the business side, and why I think the UML versions of these models are the best and easiest to work with.

Since the people who tend to do the modeling are usually the IT-based Business Analysts, this post is more or less focused on them. But the best way to do this modeling is almost always using Agile techniques, where the IT gal and the Business guy sit side by side and figure it out!

First of all there are three kinds of models associated with the early requirements/discovery phases of rule based systems. These are the structural models, the functional models and the process models. They answer three different important questions. Structural models describe what the world looks like to the business, Functional models explain which decisions need to be made, and Process models explain how the decisions need to be put together to achieve the business policy. Let’s look at these models one at a time, in that order. Today I’ll look at Structural models.

Structural models are critical. No one can write rules without a way of speaking about those policies. The structural models provide the language that the business will use to talk about the models. That doesn’t just mean the vocabulary, although vocabulary is a part of it. It means the grammar, too. Oscar (my co-blogger) would take it even further, and call the model one representation of an ontology. That is, it’s a system of talking about what exists in your business domain. Ontology seems a little metaphysical to me, so I’ll stick to language, even if it’s not as complete.

A UML model lets you talk about the business in terms of the objects, both physical and conceptual of a business. For example, in the mortgage example we used in the Webinar, we have objects like a House, and a Borrower, physical things, and conceptual things like a contract, or an inspection (an inspection report might be physical!). And you can talk about the relationships between those objects (a borrower is buying a house) in order to create your rules.

The way the UML Class diagram goes together, you can use real world words to define the objects, and their attributes, and you can use real world words to define the relationships. Plus the relationships are easy for business people to understand and to relate to. My experience is that it only takes a few minutes to get the basics of a UML class diagram through to someone who is not familiar.

There are other ways to model structure, but they are all data-centered. And if you want to do them, you’re probably a technical person, and your business folks are getting ready to scream. The problem with data-centered is, unless you are using a seriously object-oriented database, it doesn’t reflect the real world. That’s a hurdle for the business folks to cover. (Cue the scream, now, business folks!) And it is probably represented as an entity-relationship diagram (which is pretty obscure in many ways.) Another hurdle.

Worse yet, your data model might just be a dump of those legacy relational tables with all the key information and no relationships. Those things are hard for DBAs to get through, much less the people making your business decisions.

Plus data models are, well modeling data, not modeling the world. For business folks, you need to model the world. Their world! This seems obvious, but it’s really, really important. They need to really get it, if they are going to take over the responsibility for the rules – and they are, aren’t they? That is the great advantage of the BRMS paradigm!

OK, so your data will still be in a database, and you’ll need to map between the models. But using a class or object model for your structural description will make the whole process of getting the rules to reflect the business much easier. And as an added bonus, if you are using JRules, your model will translate seamlessly to the BOM (and in many implementations, the XOM, too!) So your architect won’t get all huffy on you!

Welcome to the new ILOG Business Rule Analysis and Design Blog. We have so many great Blogs here at ILOG, but they only rarely address the concerns of the business person trying to implement some kind of Business Rules, or the IT based business analyst trying to set up a business rule management system so that their business can take over. And isn’t that the whole goal of the BRMS space?

So this blog is for you, if you want to know how to turn your business knowledge into business rules! Let us know what you want to talk about, and what you need to know!

The first Blog posts will be related to a series of free Webinars that ILOG is providing on Business Discovery, Modeling, and Analysis issues. The Blogs and the Webinars are designed to each stand on their own without the other, but you’ll get even more out of both if you get both - they dovetail. So be sure to check it out.

The first Webinar, at 10 PST/1EST is about organizing Rule Discovery, and it will talk about how to approach the process of figuring out what information needs to be in the rules, and getting that information. The starting point for a lot of this discovery process is found in the models of the knowledge that many organizations begin working on during the requirements phase of a project. During the Webinar you’ll learn how to create and use a Rule Discovery Roadmap. And during the next few weeks, I’m going to talk about these various models that feed this roadmap, and help you organize your information.

If we’re all lucky, we’ll get Oscar Chappel, my fellow blogger, to hold forth for a post or two on Ontologies, which he knows very well.

So we look forward to you joining us for the Webinars and the Blogs!

See ya!

Julie