A Context for Silver Bullets:

Knowledge as the Unifier in Systems Integration

Individual

s
es
si n
u
B

General
Knowledge

Kn
ow
led
ge

depends on

Industry Domain
Knowledge

Universal
logical form

according to
scope

depends on

Enterprise
Knowledge

Exclusion
according to its
operational force

Existential

Business
Practices

includes

Enterprise
Business Unit
Knowledge

Business Knowledge
Extracts

depends on

according to its
operational force

Conditional

Key:

depends on

Business Element
Definition

Business
Purpose

Business
Stipulation

Individual Expert
Knowledge

Contingent
Fact

Prediction

according to its
operational force

is
classified
into

Value
Stipulation

State Rule

Action Rule

William Frank, XTG

Itzhak Roth, Intelligent Systems Solutions
David Sheer, Charles Schwab & Co.

We are grateful to David Materasso and Joaquin Miller for their work editing this paper and Richard Harkness
for his diagrams and document management work.

Table of Contents
1.

INTRODUCTION........................................................................................................... 1
1.1.
OVERVIEW ................................................................................................................. 1
Topic and Structure........................................................................................................... 1
Why this is Important ........................................................................................................ 1
Approach ........................................................................................................................... 2
1.2.
SOME SPECIAL WARNINGS......................................................................................... 2
1.3.
WHAT IS UNIQUE TO THIS APPROACH ........................................................................ 3

2.

MULTIPLE CLASSIFICATION SCHEMES FOR BUSINESS KNOWLEDGE ... 4

2.1.
2.2.
2.3.

3.

OVERVIEW OF THE OPERATIONAL FORCE DIMENSION ........................... 10

3.1.
3.2.
3.3.
3.4.

4.

DIMENSIONS OF BUSINESS KNOWLEDGE.................................................................... 5

THE ROLE OF LOGICAL FORM .................................................................................... 6
REPRESENTATIONS OF BUSINESS KNOWLEDGE .......................................................... 8
TYPES OF OPERATIONAL FORCE .............................................................................. 10
THE OPERATIONAL FORCE CLASSIFICATION SCHEME .............................................. 13
KNOWLEDGE DEPENDENCIES ................................................................................... 15
KNOWLEDGE DEPENDENCIES, KNOWLEDGE MANAGEMENT, AND AUTOMATION .... 18

DISCUSSION AND REVIEW OF BUSINESS KNOWLEDGE CATEGORIES .. 21

4.1.
4.2.
4.3.
4.4.

BUSINESS KNOWLEDGE TYPES AND AUTOMATED SYSTEM ORGANIZATION ............ 21

INTEGRATING BUSINESS RULES VIEWPOINTS .......................................................... 23
SUMMARY OF CLASSIFICATIONS .............................................................................. 23
USING THESE RESULTS ............................................................................................ 25

1. Introduction
1.1.
Overview
Topic and Structure
This document explains the separate roles of different kinds of automated components in
the context of the ability of information systems to manage and use all the different kinds
of human knowledge.
Business rules are types of business knowledge. By showing the entire landscape of
business knowledge, we can show all the things that business rules are not as well as all
the things that business rules are.
We believe that by providing a set of definitions and distinctions for all the types of
business knowledge, we can help to better organize and coordinate the work of analysts
and system designers. The first three chapters explain our approach, and the fourth
chapter discusses its applications. The long last chapter details the approach and applies
it most closely to those various kinds of knowledge people have called business rules.

Why this is Important

In large business enterprises, there are frequently many separate and uncoordinated ITfocused automation and business improvement initiatives. These include:
Business Process Management
Enterprise Application Integration
Six Sigma
Business Rules
Knowledge Maps
Reuse
Ontology
XML messaging standards
Enterprise Data Modeling
Metadata Repository Development
Business Knowledge Management
Systems Development Methodology
System Component Definitions
Any human or automated system design in the context of any of the above
initiatives.
All of these initiatives deal with business knowledge, whether attempting to better
manage it, to clarify it, to disseminate it, or to better utilize it.
Without a common understanding of what is business knowledge, and how the different
types of business knowledge are related, all of these groups can very quickly start to work

at cross purposes, arriving at conclusions that, at worst, are contradictory or, at best, need
to be reconciled.

Approach
This is particularly true of a common understanding of what are business rules. Yet the
term business rules today has so many connotations, with so many competing (and
useful, yet sometimes even orthogonal) definitions, that we believe it is counterproductive to propose a specific definition for this term.
So, rather than starting with a definition of business rules (as most frameworks do), we
believe a better approach is to start by presenting a clear business knowledge framework,
onto which all the various connotations of the term business rules can be mapped,
understood, and usefully applied. By allowing the various uses of the term business
rules to remain, we can improve mutual understanding, in which each party to the
discussion can translate his or her meaning for the term to the aspect of the meaning that
some other party is focused on.
This, in turn, is the best approach to enable all of the above business initiatives to co-exist
and to be well coordinated, with the best chance to avoid the redundant, inconsistent, and
consequently often divisive situations that frequently arise in large enterprise, with
multiple groups each striving to make the enterprise more cohesive. It is the best
approach simply because people will not agree to all use the same term in the same way
they have different needs and perspectives, and there are not enough terms to go around.
In addition, even within the narrower, very technical area of business rules
implementation, there are many different and competing schemes and technologies.

1.2.

Some Special Warnings

Unfortunately, almost every word referring to special human skills has been taken over
by some specialist group and given a new special definition, including the word
knowledge. For example, it has become fashionable to distinguish between
knowledge and information in a special way, to carve out a place for knowledge
management as a new kind of discipline distinct from data management. But if facts in a
database are true, and known to the system, then they are one kind of knowledge
(knowing that, or knowledge of facts) , according to normal usage, while knowledge
managers are actually concerned with another kind of knowledge (knowing how, or
knowledge of practice).
But this paper is not about words, it is about a way to understand how to fit all kinds of
automated systems together. So, if you have some reason to reserve one of the words
used here for some very special purpose, just choose another word to mean the general
capacity of people to have true beliefs of any kind.
In particular, the paper concentrates on placing business rules in the continuum of all
business knowledge. Our work shows that there are many kinds of knowledge that
business rules specialists group together as business rules, and that these things are best

supported by different kinds of automated capabilities, that then should be integrated to

work together to support the entire needs of an enterprise.
To a man with a hammer, everything looks like a nail.
The tools of software technology are so flexible that every advocate of a particular kind
of tool can show you that whatever you are talking about is really one of the kinds of
things that he deals with. Our approach is the very opposite: it is to emphasize
distinctions some might find subtle, for the purpose of making sure that the very best
tools is used for each purpose.

1.3.

What is Unique to this Approach

Our approach is radically different from most work on business rules and even more
different from other work on knowledge management. Our approach allows us to relate
all of these definitions, schemes, and techniques to each other, so that we can integrate
them all as required, without being locked in to any one1.
Technology vendors define business rules in the context of the particular functions they
might perform in certain automated systems. But business rules are a special kind of
business knowledge, so we place them in the context of how people use them when they
do business, and only then do we use that understanding to determine how best to
incorporate rules into automated systems.
Business rules experts, on the other hand, do provide us with more general ways of
defining and classifying business rules, but they each provide only a single way. They
say this is what a business rule, is, and here are its types. But stipulating some
particular definition of business rule or classification scheme for business rules will never
stand the test of time. People change their definitions and classifications over time and
across different problems to suit their needs. To be able to manage these changes, we
need a framework into which all the changes can be fit.
The definitions and distinctions set forth in this document provide us with a way of
organizing and coordinating the efforts of the many groups concerned in some way with
designing the work of knowledge workers, when these efforts might otherwise be at
cross-purposes.

Our solution depends on multi-faceted classifications. This is largely the work of Ruben Prieto-Diaz and
Haim Kilov, and has become a standard part of the Object Management Groups Unified Modeling
language.

2. Multiple Classification Schemes for Business

Knowledge
Like anything else, the same business knowledge can be classified in many different
ways, each way most useful to some particular purpose.
In general, people are only interested in looking at things in the way it is useful to them,
at that particular time. For example, a sales person might want to classify customers by
how much business they do, while a risk person might want to classify the same
customers by their credit-worthiness, and a general manager by the risk-adjusted
profitability of the customer.
For our purpose, however, we want to reconcile and integrate the business knowledge
interests of many different people.
To do so, we propose a business knowledge framework that identifies several distinct
classification schemes for business knowledge. Each of these classification schemes
permits us to define a set of classifiers that are mutually exclusive and exhaustive over
the entire domain of things to be classified2. In other words, every item in the domain is
viewed, identified and classified once and only once within that classification scheme.
But each of these classification schemes covers the same domain, the entire space of
business knowledge. So, by identifying multiple such classification schemes, every item
of business knowledge is viewed, identified and classified in multiple ways, but once and
only once per classification scheme.
Since each of these classification schemes is a different, although complete view of the
subject domain, we refer to each scheme as a dimension of a multi-faceted classification
system. Existing systems for classifying business rules do not use a multi-faceted
approach, nor do they place rules in the broader space of business knowledge.
In the remaining sections of this chapter, we first identify the multiple dimensions for
classifying business knowledge. We then examine one of these more closely, the
Logical Form dimension, because this is the one that is usually used by existing
business rule classification systems.
We then close this chapter with general observations about representations of knowledge,
because this further underscores why Logical Form is inadequate as the primary
classifier for business rules, much less the only one. This will lead us to the subject of
the next chapter, the Operational Force dimension, which we believe is the better
context for understanding business rules.

A set of classifiers like this is called a partition of the space.

2.1.

Dimensions of Business Knowledge

We propose four classification schemes, or dimensions, of business knowledge. These

are:
Subject Matter:
o To classify by subject matter, you identify the thing(s) in the world that
this business knowledge is telling you about.
Scope of Application:
o To classify by scope of application, you identify how broadly this
knowledge applies.
Logical Form:
o To classify by logical form, you identify the internal structure of a
statement.
Operational Force:
o To classify by operational force, you identify how a person who
understands a statement would be expected to use it.
Each of these classifications is orthogonal, in the sense that any piece of knowledge can
be classified simultaneously and separately along each dimension, as is illustrated in
Figure 1.
Note that in this figure, there is no category called Business Rule. This is because so
many specialists use the term Business Rule so differently. If we tried to impose a
single specific meaning onto the term business rule, we would simply be entering yet
another definition into a field that is already too fraught with contention.
Instead, we propose a set of precise technical terms, onto which we can map all the
different valid uses of this term.
Note especially that there are many other ways of classifying business rules, each of
which is the most important for some purpose, and which we do not discuss in this paper.
For example, rules have life cycle phases, in terms of which they might be proposed,
operational, or retired, for example. These classifications schemes also require
specification before they can be effectively used.

Subject Matter

Individual
Expert

Portfolio
Management

Scope of
Application
& Control

Business
Unit
Enterprise
Knowledge

Financial
Accounting

General
Knowledge

General
Knowledge

Conditional

Business
Element
Definitions

Business
Purposes

Business
Stipulations

Contingent
Facts

Predictions

Integrated
Business
Practices

Operational
Force

Universal
Exclusion
Existential

Logical Form

Figure 1 Dimensions of Knowledge

2.2.

The Role of Logical Form

Because it is comprised of classifiers that can sharply distinguish rule-like statements,

such as If then, Always, Never, and There exists exactly one, the
Logical Form dimension is the one usually featured in business rule classification
schemes.
But the logical form of a given statement, in particular a rule-like statement, is largely
orthogonal to its force. Yet the force of a statement is what really makes a statement a
rule; not its logical form.
The logical form of a statement, in and of itself, does not determine whether a statement
expresses a business stipulation; or whether it expresses how a given community uses a
term; or whether it expresses a general fact that has been observed.
For example, consider the form of statement:
Every X is a Y.
This same form can be used in statements with the following distinct operational forces:
Every agent of the company identifies him or herself as such at the
beginning of any communication with external parties a Business
Stipulation

Every account has at least one balance a part of a Business Element

Definition
Every drop in interest rates of 10% or more is followed by an
increase in stock price within 6 months a Prediction.
Some people have asserted that a business rule is the explicit or implicit presence of a
must or a may in the statement. But note that every one of the statements above may
be re-written with a must.
Every agent of the company must identify him or herself as such at
the beginning of any communication with external parties
Every account must have at least one balance
Every drop in interest rates of 10% must be followed by an increase in
stock price within 6 months.
This word must does not make all of the above rules in the same sense of the word
rule. In the first case, the must means s required by company policy, in the second
case must means is part of the very meaning of the words account and balance, and
in the third case must means follows from the principles of market economics.
Furthermore, the same thing can generally be said using many different logical forms.
For example, here are some different ways of expressing the same stipulation3 in the form
of a rule-like statement:
Never have burning materials present while pumping gasoline.
Always have no burning materials present while pumping gas.
If pumping gas, do not have burning materials present.
At all times while pumping gas, no burning materials may be present.
At no times while gas is being pumped may burning materials be present.
Although all three of these statements express the same stipulation, each has a distinct
logical form and, largely for that reason, not all three are equally easy to understand and
to work with.
OF course, logical form is also an essential part of business rules engineering.
Knowledge management does become easier when we all use the same way of saying the
same thing. So, whereas logical form is not the best way to distinguish the force of what
3

Note that even in this orthogonal classification, kinds of knowledge are always used together, and closely
related. For example, this stipulation is based on the prediction: if burning material is present while
pumping gas, an explosion is likely, and the purpose: Explosions are undesirable.

is said logical form is critically important for developing standards for representing (i.e.,
expressing) these rules4 and other kinds of business knowledge.

2.3.

Representations of Business Knowledge

The four dimensions of business knowledge provide a comprehensive, multi-faceted

system for classifying the knowledge itself. Yet it is also often important to classify the
formal ways that it is possible to represent (i.e., express) that knowledge, as distinct from
the knowledge so represented. With a formal or semi-formal approach to managing
knowledge, the manager will stipulate the logical forms that should be used when
representing that knowledge for a particular purpose, making it easier for people to
recognize the kind of knowledge being expressed and especially easier to automate the
management and application of the knowledge.
For example, in a textbook, knowledge is usually represented in free-form. This makes
it easier for people to get the unified, big picture of the subject matter while also
understanding each detailed text. At the other extreme, in the tables of a relational
database, knowledge is represented in a fully structured way5. Even the structures are
structured, and the knowledge of how it is structured is stored elsewhere (in the schema
specifications). This makes it impossible for people to read and understand the stored
knowledge details, whereas it is a perfect representation of knowledge for computers.
In between, the representation of knowledge in laws and procedure manuals is more
structured than in most textbooks, but less so than in databases.
Work in rules management requires that the business rules and related kinds of
knowledge be sufficiently structured so that it is relatively easy to translate the
knowledge into forms that can be used by a computer. Our focus is to identify
representations of knowledge that are first easiest for people to fully understand, and then
easiest for people to accurately translate into representations that computers will fully
understand.
How about these levels of formality as per Uschold and King:
Highly Informal: Expressed Loosely in natural language. e.g. definitions taken from
glossaries, manuals or other forms of documentation.
Structural Informal: Expressed in Restricted and Structured form of natural
language to increase clarity and reduce ambiguity. e.g. express the content using
preset expressions that are part of the target ontology language.
Semi Formal: Expressed in an artificial formally defined language. e.g. use
typographical notation to identify parts of the definition, operators and relations.
As in the Business Rules Groups Rule Speak.
Note that we are referring to the individual facts in the database as knowledge, that is, using the word
knowledge in the ordinary sense that people have always found it useful, so that if it was 30 degrees
centigrade in berlin yesterday, and you know it, then that is knowledge that you have. Not in the narrow
sense of knowledge engineers in which only the knowledge not yet well managed by automated systems
is called knowledge.
4
5

Rigorously Formal: Meticulously defined terms with formal semantics, theorems

and proofs of such properties as soundness and completeness. e.g. Ontology
languages as KIF, DAML+OIL, or OWL have the property and mostly the tools to
determine soundness and completeness.

Not all levels of formality should be used and not all knowledge can be expressed in all
levels of formality. As for the database example the tables are machine readable but the
knowledge is in the schema which is not.

3. Overview of the Operational Force Dimension

The operational force dimension classifies knowledge by how that knowledge must be
represented, managed, and applied.
To illustrate this, lets look at two of the operational force classifiers: contingent
(business) facts and business stipulations. An example of a contingent business fact is
that some particular client has some particular combined net asset value; an example of a
business stipulation is that all clients are assigned exactly one relationship manager.
This contingent business fact is discovered, represented, stored, and changed in a way
that is entirely different from how the same is done for this business stipulation. The
contingent business fact is managed as data in a database, while the business stipulation
is managed as a rule in a rules base, or in a logical data model or physical data schema, or
in some other business model.
Yet contingent business facts and business stipulations have a critical relationship to each
other. Every contingent business fact will describe what the state of the business actually
is, while a related business rule would describe what that same state of the business
actually ought to be. While they both can speak to the same business state, one speaks to
what is, while the other speaks to what ought to be. Therefore, it is possible for them to
be inconsistent with each other, even though both the fact is true and the rule is in force.
For example, there may be a rule in force that states that every employee must have
exactly one employee ID. But there might be a system error that causes one employee to
have two employee IDs (so the fact actually is that an employee has two employee IDs).
The rule is in force, and the fact is true, and yet what they say about the state of the
business is contradictory. Since they are both representations (expressions) of valid and
true business knowledge, and yet they may say contradictory things, we want to look
elsewhere for what differentiates them.
What actually makes the rule and the fact different is not what they say about the
business, but the force of what they say to the listener.

3.1.

Types of Operational Force

Business rules stand out clearly and distinctly from other kinds of business knowledge
when business knowledge is differentiated along the operational force dimension.
The types of operational force (i.e., classifiers) within the operational force dimension
are:
Business Element Definitions
o The givens or presuppositions of the business.

10

 Business Purposes
o The shoulds or desired states of the business.
Business Stipulations
o The musts or required states and actions of the business.
Contingent Facts
o The dids or circumstantial facts about the business.
Predictions
o The usuallys or observed generalizations of the business.
Integrated Business Practices
o The can dos or practical knowledge of the business.
These types are differentiated in more detail in the following table.
Main
Category
Business
Element
Definition

Subtype

Definition

Business
Purpose

Business
Stipulation

Describes a given of the

business.
Describes a concept that is in
industry-wide or corporate
enterprise-wide use, having a
value-free, generally accepted
industry-wide or corporate
enterprise-wide definition.
May describe a fact that is
true by generally accepted
definition.
Describes what the leadership
of the business desires one or
more things to become.
Describes one or more things
that the leadership of the
business desires to have
happen.
Describes the higher-level
would likes of the business.
Describes the way the
leadership of the business
requires things to be, or
requires things to happen.
Describes the higher-level
musts of the business.

11

Examples and
Specializations of this
Concept
Definitions of
account, position,
posting;
E.g., Every posting is
to an account, and
affects an account
position.

Vision
Goal
Strategy
Tactic
Plan

Value
Stipulation

State Rule

Expresses the conditions that

impart a particular value onto
the things that meet those
conditions.
Expresses the actions or
business results that are
required or desired because
some thing has that value.
Specifies the required or
proscribed states of the
business

Action Rule

Contingent
Fact

Specifies the actions that are

required to be performed
under specific circumstances.

Expresses a fact that happens

to be true at a certain time.
The actual was or actual
is of the business.

Expresses a generalization
based on experience that
guides expectations more or
less reliably.
Includes expressions of
expectation that are 100%
reliable. (reliable or certain? Is
there anything that is 100%
reliable or certain?)

Prediction

12

Inclusion rule for a

Gold Client category
gold client is a client
who does more than
$1MM in business.
Stipulation that The
Gold Client Discount
Percentage is 9%.
Every client must be
assigned exactly one
relationship manager.
Only open accounts
can have Gold
Features added to
them.
A relationship
manager is assigned to
a prospect as soon as
the prospect submits
adequate contact
information.
Client Tom Murphy
does not have a
relationship manager
assigned to him.
This company has no
clients in
Saskatchewan.
Clients are pleased
when they are
addressed by their
names.
If you reboot your
PC, it usually starts
working again.

Business
Practices

Expresses knowledge that

combines and integrates many
other kinds of knowledge and
experience, and that is applied
to a complex job function.
Business Process?

The prescripts for

successfully
identifying and
converting prospective
customers.
The prescripts for
successfully cross-sell
to existing customers
The prescripts for
successfully designing
and launching a new
product.

Table 1 Summary of Kinds of Business Knowledge

Note that one of the common simplifications in the business rules community is to not
distinquish between logical inference rules and prediction rules. Predictive rules are rules
that derive from experience scientific rules. If you touch a hot stove, you will burn
your hand, water freezes at 32 degrees farenheit. These predictions are usually translated
as inference rules. (There is also a deeper distinction between a rule and a conditional
assertion, that we will ignore for now). But other inference rules, such as if something
is square, then it has four sides, represent a VERY DIFFERENT kind of knowledge. This
is definition and not inference rule. Namely, knowledge of the meanings of words, rather
than knowledge of repeatable experiences.
In addition, note that there are logical relationships BETWEEN these kinds of
knowledge. For example, an prediction rule such as Clients are pleased when they are
addressed by their names is likely to LEAD TO a business stipulation, Address Clients
by their names.

3.2.

The Operational Force Classification Scheme

The most careful business rule analysts often map only value stipulations and state rules
to their specification of the term business rules. Others also include business element
definitions or action rules to this mapping. Still others also add predictions to their scope
of business rules. We believe, however, that a closer analysis of the operational force
classification scheme results in a more rigorous mapping
The Operational Force Discriminator
There is one concept that can serve to associate any kind of business knowledge to one
and only one of the above operational force classifiers. We call this concept the
operational force discriminator.
What uniquely discriminates any business knowledge is how a person to whom that
knowledge has been successfully communicated is expected to use that knowledge.

13

For example, when a business stipulation has been successfully communicated to you,
you know that, if it pertains to you, you are expected to follow it and maybe also spot
violations.
When the definition of a business element has been successfully communicated to you,
you know that definition, and you will be expected to use that knowledge to understand
what others say to you when they use the term for that business element, and you will be
expected to use that term correctly when you communicate to others, so that they will
understand you.
When you know a contingent fact, you are expected to use that knowledge (information?)
to determine what stipulations might apply to these circumstances, and what predictions
you might be able to make on the basis of this fact.
This, then, is what we mean by the operational force classifier. When classifying
business knowledge by operational force, you are discriminating business knowledge by
associating it with how that knowledge is expected to be used if it is fully understood.
Application to All Communication
The operational force discriminator extends beyond the communication of business
knowledge. It can be applied to all kinds of communications between people and
between the computing systems that people use as their agents6.
For example, an instruction from a client to execute a certain transaction; a question from
a manager; and a declaration of an action (I hereby revoke this clients credit line) have
different kinds of operational force: instruction, question, and declaration7.
None of these communications is essentially business knowledge. Rather, the person to
whom an instruction has been successfully communicated is expected to follow that
instruction; the person who successfully receives a question is expected to answer that
question; and the person who successfully receives a declaration is expected to draw any
relevant inference from that declaration and to take appropriate action.
Inherent to the communication of an instruction, a question, or a declaration is an
expectation of how the person who has successfully received that communication is
expected to use it. That is, they each have operational force. But they are not essentially
types of business knowledge8.
Some readers might be saying to themselves: Why all this blab about how people understand each other,
we are interested in computers. Well, that is exactly why we have to understand people better, to build
automated systems that will work better with people.
7
Some people will recognize this as an application of the theory of speech acts, one of the most
fundamental discoveries of linguistics. This theory shows how every time we express ourselves, we are
performing some kind of action, and there is an implicit performative such as command, statement,
question, that can all be applied to the same proposition, such as Tom be working., resulting in Tom
work!, Tom is working, is Tom working? See Searle in references.
8
Of course, knowing that each of these communications took place is business knowledge (knowledge of a
contingent fact), and may result in other kinds of business knowledge (such as knowledge that a certain
6

14

So, whereas all communications may have operational force, not all communications that
have operational force are kinds of business knowledge.
Nevertheless, although our ultimate goal is to facilitate common understanding between
people and between computing systems, the scope of all communications is too broad.
The scope of business knowledge communication is broad enough, and a good place to
start, in order to facilitate communications between business units, lower costs, and
improve performance.
Identifying the Operational Force of a Statement
Because the operational force of a statement depends on the intention of the
communicator, we cannot tell the force of a statement merely by looking at its logical
form.
Rather, we must look at the context of the communication to understand how the
recipients of the communication are expected to use the knowledge thus imparted.
For example, what determines that an assertion is a business stipulation is that its authors
have the authority to direct the activities of some others, and that they are using this
assertion for the purpose of directing those activities.
In most contexts, a statement such as We have no clients in Canada might simply be
the expression of an observed fact. For example, when the person who makes this
statement is asked by a sales manager to determine in what North American countries the
company has clients. But in certain contexts, a business stipulation might reasonably (and
correctly) be inferred from this very same statement. For example, when the head of sales
makes this statement in the context of telling a salesman that he has made a serious
mistake by pursuing a sales lead in Canada.

3.3.

Knowledge Dependencies

In this section, we look at dependencies within the Scope of Knowledge dimension and
dependencies within the Operational Force dimension.
The first dependency, among the classifiers within Scope of Knowledge, is self-evident:
detailed, specialized knowledge about some specific subject is dependent on prerequisite
knowledge of a wider subject of which the specific subject is a subset.
The second dependency, among the classifiers within Operational Force, is more
interesting. It requires us to map the operational force classifiers to sub-types in a
framework of broader categories of general knowledge. Since these broader categories
business stipulation is now in force). But that knowledge is separate from the operation force of the
communication itself, which is not to impart knowledge in the listener, but rather to engender some other
behavior.

15

have their own dependencies among themselves, our operational force classifiers, as subtypes, also evidence these dependencies.
Dependencies within the Scope of Knowledge dimension
Obviously, more specialized knowledge depends on more general knowledge.
For example, in order to understand and try to meet any special individual needs of
foreign clients, you must have general knowledge of that part of the world where your
client lives and works, with respect to their culture, their families, jobs, homes, and
leisure pastimes.
It is impossible to obtain and understand this more specific knowledge without first
obtaining and understanding the more general knowledge.
Dependencies within the Operational Force dimension
The highest level of operational force classifications for knowledge in general as follows:
Semantic knowledge
o Knowledge that comes only from understanding the meaning of terms
Normative knowledge
o Knowledge of what people want, independent of what they get
Empirical knowledge
o Knowledge of what objectively exists, based on observations
Integrated knowledge
o Knowledge required to accomplish a complex goal
These categories of general knowledge have dependencies among themselves. The figure
below shows these dependencies.
In addition, however, since business knowledge is a subset of (and therefore a part of)
general (i.e., all) knowledge, we can map all the types of business knowledge to these
categories of general (i.e., all) knowledge.
For example, semantic knowledge encompasses the meanings of all terms, including such
general terms9 as person, family and house. But this also includes, as a subcategory, business element definitions, e.g., the meanings of finance-specific terms, such
as account and balance And of course knowing these meanings goes beyond
dictionary definitions: knowing meaning means knowing how to use a term properly,
which includes relationships to other terms, context rules, etc.

Formal specifications of the meaning of these more general concepts is sometimes called an upper
ontology, and is of course essential when a computer is expected to handle tasks requiring judgment by
itself. However, we intend to focus on the more easily automated management of business-specific
knowledge.
9

16

Normative knowledge encompasses all knowledge of right and wrong. But all such
knowledge includes, as a sub-category, business stipulations whose domain is a single
business community.
So, since normative knowledge depends on semantic knowledge, it follows that business
stipulations depend on business element definitions.
When we place all of our operational force classifiers for business knowledge in the
broader context of the categories of general knowledge (i.e., of all knowledge), we get the
following complete picture of dependencies:

Normative Knowledge
Business
Purpose

Business
Stipulations
Value
Stipulation

Semantic
Knowledge

Empirical
Knowledge

Business
Element
Definitions

Contingent
Facts

Predictions

State Rules
Integrated
Knowledge

Action Rules

Business
Practice
Knowledge

Key:
depends on

Figure 2 Dependencies Between Kinds of Knowledge Based on Operational Force

This figure clearly illustrates how business element definitions, as a sub-category of

semantic knowledge, are the root of all other business knowledge.
Business purpose and business stipulations, as sub-categories of normative knowledge,
are largely independent of contingent business facts and business predictions, which are
sub-categories of empirical knowledge. While it is true that empirical knowledge is
required in order to be able to apply normative knowledge, this is not a knowledge
dependency; it is some other kind of dependency outside of our present scope.
And, finally, business practice knowledge, as a sub-category of integrated knowledge,
depends on all the other types of business knowledge, integrating all these other types in
order to make good use of them.

17

3.4.
Knowledge Dependencies, Knowledge Management,
and Automation
To recognize these knowledge dependencies is very important for effective knowledge
management and successful automation.
For example, if we were try to build a system to collect empirical facts (i.e., to build a
typical database system) without first specifying the meanings of the terms by which
these empirical facts are expressed (and making the associated business element
definitions formally known, once and only once, to the database system and formally
managed by that system), we would have to sneak those definitions, un-vetted and unvalidated by the business community, into the database. (So true)
This is in fact how many systems are still being built today. Business element definitions
keep getting build and re-built into one database system after another, because the prerequisite step of formally defining and managing these definitions was not done first.
And this is where most of the costs and errors in systems originate.
In the following sub-sections, we look at how a computer would have to manage the
knowledge it needs to perform business functions as well as people. The purpose of this
exploration is to determine how to use computers to help people manage knowledge as
effectively as possible.
In order for a computer to be able to perform completely accurately and completely
independently from people, it would have to have complete mastery of all these types of
business knowledge (differentiated by operational force, and dependent on each other),
and it would also have to have mastery of general knowledge of every kind, on which the
business-specific knowledge would also depend. This is not practical. What is practical
is to determine those parts of this mastery are easiest for a computer to achieve.
William,
I identified the following levels of knowledge here applied to the domain of finance. I
think overall it is consistent with what you are talking about but just another dimension:
Knowledge level 0: Common Sense Knowledge (Upper Ontology), e.g. persons and
personal relationships, time and measures etc.
Knowledge level 1: General Financial Knowledge, e.g. money, value and interest, basic
financial reporting, etc.
Knowledge level 2: Specialized Financial Sub-Domain Knowledge. e.g. specialized
vocabularies for banking, investing, accounting, taxes etc.
Knowledge level 3: Specific Financial Sub-Domain Process and Task Knowledge. e.g.
trading, clearing, reporting, etc.
This hierarchy is meaningful also in respect to security and privacy. The lower we go
the deeper we get into proprietary and private knowledge which requires higher
security level.

18

Knowledge Management across Scopes of Application

If a computer were required to perform client relationship management entirely on its
own, it would need to do that as well as a person does.
To do so, it would have to have as much pertinent general knowledge as a person (a
human relationship manager) has. For instance, it would need to know about families
and jobs as well as specific knowledge about investment management. This is not going
to happen anytime soon, because computers today are not very good at independently
using, let alone managing, such general knowledge.
At best, computers can be programmed to use general knowledge tools such as search
engines and to apply that general knowledge to business-specific knowledge content.
Even much industry-domain knowledge is difficult for computers to learn to use
independently. We hire people to do specific things because of the general knowledge
they have, because of what they know about our industry, and because of what they can
learn about our corporate practices and use effectively.
Because it is so difficult to teach computers how to understand and use general
knowledge, the first efforts to do so must focus on the smallest scopes of application, e.g.,
the operations of a specific business unit rather than an entire division or global
enterprise.
Management across Operational Forces
Once we have decided to focus on a particular, and very small, scope of application (e.g.,
a specific business unit) the knowledge of which we want our computer system to
know, learn, and use, we must then categorize that knowledge no longer by scope of
application but by operational force.
And here, we must start by making our computer know, learn, and use the fundamental
type of business knowledge, i.e., the business element definitions, rather than the more
specific, narrower types of knowledge, such as stipulations, predictions, and practices,
which depend on the business elements. It is impossible to know, learn, and use (i.e., to
understand) business stipulations, predictions, and practices without first understanding
business element definitions.
In order to be coherent and universally and consistently understood, every kind of
business specific knowledge must be expressed with a single, consistent vocabulary. It is
impossible to build a knowledge management system or a rule execution environment
without this foundation. Single is desirable but may not be possible or realistic but only
at a very low level and narrow scope. The fact is that we are dealing with many
subcultures and dialects that use different terms for same purpose or same terms for
different purpose. Machine intelligence should be aware of these disparities and use the
knowledge to solve problems.

19

This is true for all kinds of knowledge management and rules management. For instance,
the first step for developing an effective database of contingent facts is to construct a
logical data model to capture the business elements and their relationships.
Similarly, when constructing a set of state rules, the first step is to standardize on the
names of things in the business and to identify those business things that can have states.
Otherwise, the rules system will not work.

20

4. Discussion and Review of Business Knowledge

Categories
4.1.
Business Knowledge Types and Automated System
Organization
One way to better understand the business knowledge types along the operational force
dimension is to relate them to traditional application organization.
In a typical automated system, the way the application works is the joint effect of the
database design (the data model); what is IN the database at a given time (the database
content); the source code; and external inputs.
The following table relates our business knowledge categories to these application system
components.
Main
Category
Business
Element
Definition
Business
Purpose

Subtype

Where it is
Embodied
Data Model

Use Case
Name,
Use-Case
Description

Discussion
Data Modeling does not distinguish between what
is general to a business (business element
definitions) and the rules that the business has
today (value stipulations).
Use case names describe actions in terms of their
purpose.
Use case descriptions describe those same actions
in terms of a process that implements that purpose.
Achieving purposes is sometimes supported with
automated linear programming models

Business
Stipulation
Stipulative Data Model, Data model entities and attributes depict stipulative
Definition Source Code definitions, but do not distinguish them from the
business element definitions that are generally
accepted industry-wide.
Source code was traditionally used for static
values, and is still used for defined formulae, such
as the computation for bond duration.

21

State Rule

Action
Rule

Contingent
Business
Fact
Prediction

Practical
Business
Knowledge

Data Model, State rules are constraints applied to the

Source Code relationships between business elements and the
contingent facts that are allowed to be true about
them at any point in time.
Whether implemented in a data model or in source
code, they are sometimes referred to in this
implementation form - as data integrity
constraints.
Application Use Case descriptions or specifications also
Source
describe the sequence of actions that are to be used
Code,
to accomplish the goal of the use case, and thus
User
include action rules.
Manual,
Operators
Run Book
Database
The database contains all contingent facts, but the
Content
database is also often used for any stipulative
definitions that can be expressed as single values,
rather than as formulae.
Not in
Expert Systems and the like often support
traditional
predictive reasoning. If such heuristics are built
automated
into a traditional automated system, rules of thumb
systems
will sometimes be applied inappropriately.
Combination .
of all the
parts of the
automated
system, but
only when
so leveraged
by the
business
user

Table 3 Types of Knowledge as Embodied in Standard Application Designs

Much business knowledge can be found in the documents of a business enterprise, while
some can be found only in the minds of some key business individuals and nowhere else
(e.g., especially, but not exclusively, practical business knowledge).
But abundant business knowledge can be found in the automated systems of a business
enterprise, and some of it nowhere else. In automated systems, this business knowledge
is expressed absolutely accurately and precisely, yet it is expressed in a form that can
only be easily understood by a computer.

22

One of our challenges is to be able to readily (and repeatably) externalize the knowledge
embodied in our databases and source code, instead of having to rediscover it every time
we need to build a new application.

4.2.

Integrating Business Rules Viewpoints

To narrowly define the term business rule or to narrowly specify how to formulate
business rules would not be productive. Each specialist should be able to use the term
business rule in his or her own way, as long as he recognizes that that use is special.
It is not the job of the information engineer to teach business people how to do their jobs,
or how to speak or use (or not use) their own language.
Rather, it is the information engineers job to interpret, organize, and refine the business
knowledge they get, in whatever form the business wants to convey it, and then feed it
back to the business in this reorganized, yet comprehensible form.
Similarly, it is not the job of the analyst to get programmers and database designers to
think about rules beyond the scope of their job, which is to create certain kinds of
technological implementations of rules.
All of this means that it is up to the business analyst to support a broad concept of
business rule that effectively translates business needs into technology solutions.
Historically, it has been hardest for both analysts and business people to resist the song of
technology buzzwords, leading them to couch their work in some one or other ephemeral
implementation technique.
If we continue to do this, our work will continue to be very costly and often short lived.

4.3.

Summary of Classifications

In this chapter, we classified types of business knowledge as business elements in their

own right, according to a few different but related schemes, as depicted in Error!
Reference source not found., below.

23

Individual

ss
ine
s
Bu

General
Knowledge

Kn
ow
led
ge

depends on

Industry Domain
Knowledge

Universal
logical form

according to
scope

depends on

Enterprise
Knowledge

Exclusion
according to its
operational force

Existential

Business
Practices

Enterprise
Business Unit
Knowledge

Business Knowledge
Extracts

includes

depends on

according to its
operational force

Conditional

Business Element
Definition

Key:

depends on

Business
Purpose

Business
Stipulation

Individual Expert
Knowledge

Contingent
Fact

Prediction

according to its
operational force

is
classified
into

Value
Stipulation

State Rule

Action Rule

Figure 3 The Taxonomy of Kinds of Business Knowledge

Our primary focus in this document has been on rules management, so this skews our
diagram toward greater detail only where knowledge is classified according to its
operational force.
There are three important things that this diagram helps us keep in mind:
First, each business knowledge dimension provides us with an independent organization
of knowledge, with each dimensional view better serving a different purpose.
For example,
The operational force dimension creates groups of knowledge that we can manage
using a single engineering technique.
The scope of knowledge dimension creates groups of knowledge that have to be
managed in a coordinated way, for the same stakeholders.

24

The representation dimension creates groups of knowledge according to the

technology that can be used to store the knowledge, and the ease with which it can
be retrieved.
Second, what makes something a business stipulation is its operational force. The fact
that it has rule in its name is incidental (value stipulation; state rule; and action rule are,
all three of them, types of business stipulation, even though only two of them say rule).
Third, rules of inference and rules of thumb refer to business predictions. They are
not the musts of the business, i.e., they do not have the operational force of business
stipulations. The fact that they have rule in their name in some schemes is purely
accidental. Following this logic Id argue that rule of thumbs (new kind of rules?) are
business stipulation since they say that if you see A or B do X it might be based on
some observation that X is the correct action in 80 or 90% of the time and maybe on
some cost benefit analysis which you call prediction but they are still stipulations. As for
inference rules, do we have such rules? or is it that we are applying inference algorithms
on some logical structure (not necessarily rules).

4.4.

Using These Results

In summary, there are three ways to use the knowledge in this paper:
1. Avoid entering yourself into pointless disagreements where the same terms are
being used in different senses.
2. Facilitate better understanding between people whose responsibilities for some
aspect of business knowledge lead them to use different classification schemes.
3. Create, design, and manage human and automated systems in which each type of
business knowledge required for the operation of the system is represented in only
one portion of the system, rather than redundantly and inconsistently, and is
represented in a part of the system that is specialized for knowing how to use
knowledge of that kind.
Each of these ways of using this paper is increasingly ambitious, but these ways are also
incremental. Accomplishing the first goal is required to accomplish the second, and the
second is required for the third.
One thing this paper is not meant to do: to supplant or conflict with any of the useful
existing methods for encoding business rules in particular formal and semi-formal
languages. Instead, this paper is meant to help you to better understand those methods,
and be able to relate different methods to each other.

25