Everywhere you turn, rules dictate how you work, how you act, how you dress, how you conduct yourself. And as onerous as these personal rules are, rules that control a business can be many times more complex and burdening. Business rules can (and often do) contain contradictions that can make interpreting them difficult.
Wouldn't it be wonderful to create a graphic representation of your business rules so that you could clearly map out what to do in any given circumstance? In IT, we have business process models that lay out business processes in a visual format and data process models that visually depict the processes that operate on the data as it passes through a system. We have entity relationship models and object models that help you visualize how data is stored inside a database. We have systems models and network models and even Web site and Web page models that visually represent these IT components. So why don't we have business rules models?
One explanation might be that rules models extend beyond the scope of traditional IT. All the other models I mentioned relate to business components that fall under the auspices of the IT department. People in IT use the collection of visual tools I listed above to help them understand their universe. Describing a system with a picture is much faster and, in many cases, more accurate than writing it out in thousands of words. If you can't imagine why you'd want to do this, remember that the traditional scope of IT has been significantly blurred. You need to think about the needs of your whole organization.
The concept of a rule model isn't new; business rules engines such as the Eclipse plugin and Fair Isaac's Blaze Advisor have been using rule models to organize the thousands of business rules that typical customers struggle with every day. However, these software packages are expensive and complex to deploy. What about those of us who work with budget and time constraints? What can we do to better organize and formalize the rules and regulations by which we run our businesses?
To address this situation, information system development expert Ronald Ross has been developing a style of modeling called the Fact Model, which is part of his business-rules approach. Because of space limitations, I can't describe Ross's entire methodology (which you can read about in his book Business Rule Concepts: Getting to the Point of Knowledge, Second Edition). However, I can say that one of the fundamental principles of Ross's business rules approach is a structured business vocabulary and a mapping of this vocabulary into a Fact Model.
What's the difference between a rule and a fact? A fact is an unconstrained rule composed of two terms connected by some action verb. A Fact Type, in Ross's methodology, is a non-judgmental, non-constrained sentence (no adjectives, no adverbs). The following two sentences are Fact Types:
customer places order shipment includes item
A term is a basic word or phrase (in English or any human language) that's used in the business; a term has some specific, defined, unique business meaning. A collection of terms about your business constitutes a structured business vocabulary. You should already be storing business terms in a catalog, to which everyone in the company has access. If you don't have a business catalog, consider going to http://www.wikispaces.com and establishing a wiki for your company.
What Constitutes a Rule?
A rule is a fact that has been constrained. By extending the fact customer places order to a customer places at least one order, you've changed a fact to a rule. A business runs on rules. So why would we want to create a Fact Model?
Facts are the basis of rules. Recording facts in a visual format, as the Ross methodology explains, is so simple that you can easily teach business users the technique and let them record what they do and how they do it. Encourage them not to qualify the Fact Types (the nonjudgmental sentences that make up the core of the Fact Model) so that you can get to the core facts. When you review the Fact Models with them, you can fill in the constraints, whatever they might be.
Figure 1, shows a basic Fact Model from which you can derive facts such as a student enrolls in a class, a class is offered by a university, a university offers a class. This simple model tells you much about this business. For one thing, students have to buy their books; books aren't provided for students as part of the class-registration process. This is an inferred business rule that's expressed as a Fact Type.
Isn't This Just a Concept Model?
You might argue that this Fact Model is just another form of conceptual data model, but in fact, there are significant differences between a Fact Model and a conceptual model. The original intent of a conceptual model is that it's a graphical representation of a set of business rules (not facts). However, the various methodologies that you use to render a conceptual model have evolved to produce highly complex drawings that aren't intuitive to a non-database person (i.e., a business user). The conceptual model is step one in the database-design process, so it tends to limit itself to data that will be stored in the database being modeled. Arguably, you could use a package of conceptual models or a master conceptual model comprised of child models to better express the business rules of the company, but conceptual models tend to be limited to expressions of data storage.
In contrast, the Fact Model is a visual representation of a structured business vocabulary. Fact Models document what's happening in the business by using standard and universally accepted business words and statements. The Fact Model is simpler than a conceptual model; the sentences that express the facts don't place constraints on instances of these facts. Realistically, conceptual models are built on constraints—one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N) relationships. Remember, adding a constraint to a fact converts the fact into a rule, so library patron borrows books is a fact and a library patron may borrow a maximum of 6 books at one time is a rule. The Fact Model has no concept of limitation by storage structure; there's no implication that the Fact Model will be converted into anything other than what it is. Creators of Fact Models don't have to be IT people; business users can draw Fact Models without regard to whether they're correctly representing some facet of IT.
Benefits of a Fact Model
So what are the benefits of adopting this Fact Model methodology? Let's take a look at the factors that contribute to a successful blend of IT and business-user benefits.
Business rules are controlled by business users. By exposing business facts to the universe of business users, users can better manage the business rules and business policies. Because users are the business owners, they should be able to set policy.
Rules become a shared resource. No more "hiding" rules and no more guessing what to do in a given circumstance. Because the rules and facts are now a shared resource, anyone in the company can easily read the content and determine the intent of a specific rule.
Application development is faster. This is a terrific benefit for both IT and non-IT business units. When facts and rules are published, developers can quickly, concisely write code and build systems that mirror the intent and purpose of the facts and rules. Testing and production groups have ready access to the data from which they can build metrics for measuring success. The entire company runs more smoothly, unencumbered by a lack of knowledge of the rules.
I can quickly convert a Fact Model into a conceptual model. At last, here's the real reason why I love Fact Models. In my job as a consultant, I usually have to plow through stacks of written documentation and use-case descriptions, study mock-ups of input screens and output reports, and infer from all this written stuff what's important to the business and what's not—and my customers expect me to be able to do this in no time at all. With an accurate Fact Model, I can quickly get my head around the most important components of a company and the critical processes that will make or break it. Then, depending on my design assignment, I can usually convert a Fact Model (or part of it) to a first-draft conceptual model in less time and with greater accuracy than conventional methods. Lower cost to delivery, less time to production, a greater understanding of the critical elements of the business—what's not to like?
Anyone who believes that business analysis and modeling methodologies are static is very much mistaken. New techniques let us better define how a business works and use that understanding to create databases and applications. Business users can participate in developing systems that will make the business run better. Developers can use the output from these techniques to build quicker, better applications. Customers get the benefit of a business that knows what they need and how to get it to them. Sounds like a win-win-win to me!
You can post your thoughts about Fact Models and their potential, on the SQL Server Magazine Database Design forum at http://www.sqlmag.com/go/dbdesign
