|
untitled
Four Useful Constructs for Developing a Structured Business Vocabulary
Special-Purpose Elements of Structure for Fact Models
by Ronald G. Ross
To express business rules and other forms of business communication at scale, you need both noun concepts and verb concepts.[1] The result is a structured business vocabulary, often represented as a graphical fact model. The verb concepts (fact types) distinguish fact models from other kinds of structural models (e.g., data models and class diagrams).
The business meaning (semantic shape) of the verb concepts lies completely with the wordings supplied for them by business workers and business analysts. Such verb concepts have no implicit or prefabricated meaning of any kind. They are business-defined elements of structure.
Other important elements of structure come in handy, pre-defined semantic shapes, as provided by SBVR. This discussion illustrates use of four of these shapes, as presented in Table 1. These special-purpose connections between noun concepts extend the reach and precision of the fact model significantly. Before I get too deeply into that, however, I should give a quick note about the term instance.
About the Term Instance
At this point in the discussion, I will start taking a few liberties with the SBVR concept of instance. In SBVR, instances are always in the real world, not in a model. For example, you can't put the real country Canada into a model. Wouldn't exactly fit(!). In a fact model, you can include only concepts (like the one that stands for Canada) and facts (things you assert are true about Canada).
If you're used to thinking about instances being organized within or by a model (e.g., to be stored in a database), however, that gets a little confusing. So in this discussion, I will use the term instance a bit more loosely. Just remember, when business people talk about real-world things, they're not talking about instances in a model(!). |
Table 1. Special-Purpose Elements of Structure.
Special-Purpose Element of Structure |
General Form |
Example |
Use in a Sample Business Rule Statement |
categorization |
(Class of thing1) is a category of (class of thing2). |
'Corporate customer' is a category of 'customer'. |
A customer is always considered corporate if the customer is not an individual person. |
property |
(thing1) has
(thing2) |
order has date taken
order has date promised
|
An order's date promised must be at least 24 hours after the order's date taken. |
composition
(whole–part or
partitive structure) |
(whole) is composed of (parts)
(part) is included in (whole)
|
chair is composed of:
|
A chair may be ordered without armrests. |
classification |
(Instance) is classified as a (class of thing). |
Canada is classified as a country.
Canadian dollar is classified as a currency.
|
An order may be priced using the currency 'Canadian dollar' only if the customer placing the order is located in Canada. |
1. Categories and Categorizations
A category is a class of things whose meaning is more restrictive than, but otherwise compliant with, some other class of things. For example, male is a category of person. Each male is always a person, but not every person is a male. A male can have properties that would not apply to any person who is not a male. In general, a category represents a kind, or variation, within a more general concept.
Representing one class of things to be a category of another class of things is called categorization. Figure 1 illustrates several categories (using heavy lines).

Figure 1. Illustration of categories.
The following categorizations are illustrated by Figure 1.
- Both sales representative and engineer are recognized as categories of a more general concept employee. Note the property employee name is indicated for employee. Since all sales representatives and engineers can have names — indeed, any employee can — the name property is indicated only for employee. Remember that all sales representatives and engineers are employees in this business, so the name property pertains as a matter of course to both representative and engineer. It does not need to be re-specified for them; inheritance of the property is assumed. On the other hand, commission rates apparently pertain only to sales representatives — not to all employees (e.g., not to engineers) — since commission rate is indicated only for sale representative.
- Product has three categories — military, corporate, and consumer — forming a group. This group of categories is organized on the basis of a categorization scheme named orientation — more about that later. Note that (as always for categories) military, corporate, and consumer must be products. Indeed, unless everyone reading the diagram is thoroughly familiar with categorization, better labels would probably be military product, corporate product, and consumer product. The boxes represent that anyway, but these revised labels would emphasize the point.
Any category can have categories; any category of a category can have categories, and so on. Multiple levels of categorization are not uncommon in fact models. Indeed, such refinement or narrowing of meaning as you go 'deeper' yields a high degree of precision or selectivity for making statements about the business (e.g., giving business rules). For example, a business rule might be expressed for software engineers, a potential category of engineer, which does not apply either to other kinds of engineers or to employees in general.
2. Properties
The Merriam-Webster Unabridged Dictionary defines 'property' as a quality or trait belonging to a person or thing. Figure 1 indicates employee name to be a property of employee, and commission rate to be a property of sales representative. A thin line is used to attach each to the appropriate box (noun concept). Exactly what does the thin line represent?
The thin line does not indicate that every member of a class of things actually has an instance of the property, only that it can. If each member of a class of things must have an instance of the property, an explicit business rule is required (e.g., An employee must have an employee name.).
The thin line is actually a shorthand for a binary fact type. The wording for this binary fact type defaults to (thing1) has (thing2). The important word here is has. The verb to have is very general — not specific or descriptive at all. Has makes very poor wording for fact types not specified as properties. For properties, on the other hand, a has default is often convenient.
Can properties be worded using verbs other than has? Yes. For example, the commission rate property of sales representative might be worded sales representative is compensated at commission rate.
The property shown at the end of the line is often actually a role of some other noun concept. For example:
- Suppose commission rates are always percentages (in this business). Then the commission rate property of sales representative actually represents the fact type worded sales representative is compensated at [commission rate] percentage.
- Similarly, the employee name property of employee might actually represent the fact type worded employee has [employee name] name.
Note on Notation
Why bother with a graphical shorthand for properties? The answer has to do with scaling up. If you were to treat all properties as 'regular' fact types, the fact model would become hopelessly cluttered with connections having to do with such things as numbers, names, dates, units of measure, and much more. Such connections are of secondary importance to the business. Avoid that! |
Figure 1 actually includes several other properties, as follows.
- Two properties for the objectification[2] briefing have been indicated using a single thin line (another shorthand to reduce clutter).
- Orientation, which can be seen just above the crossbar for the categorization of product, is also a property, albeit a special kind. Orientation is the name of the categorization scheme used to organize the three kinds of product. Since orientation is a property of product; we can say product has orientation. (That's like saying person has gender, meaning male and female.) Is it required that every product fall into at least one of the three categories: military, government, or consumer? In other words, must every product have an orientation? (Or perhaps exactly one?) Don't assume so — that would require some explicit business rule(s).
3. Compositions — Whole–Part (Partitive) Structures
Many things in the real world are composites, made up of several other kinds of thing. For example, an automobile (simplistically) is composed of an engine, a body, and wheels. A mechanical pencil is made up of a barrel, a lead-advance mechanism, pencil lead, and eraser.[3] An address (simplistically) is made up of a street number, a street, an apartment number, a city, a state/province, a country, and a zip code / postal code.
Sorting out the terminology and composition of such whole–part structures is often quite useful. Before looking at a graphical example, let's address some relevant questions:
- Is every instance of the whole in a whole–part structure required to have at least one instance of each part? No. For example, not every address has an apartment number. If every instance of the whole is required to have some part(s), an explicit business rule must be given.
- Can an instance of a whole have more than one instance of a kind of part? Yes. An automobile must have at least three wheels (a business rule). But use caution here. A whole–part structure usually works best where there is only one, or a small number, of each part.
- Can the specification of a whole–part structure indicate only one kind of part? Yes. However, exercise common sense! For example, is it really useful to consider the fact type worded order includes line item to be a whole-part structure? We do not favor that practice.
- Can a part itself be a whole composed of other parts? Yes. Multiple levels of composition are possible.
- Can both the whole and the parts be selectively involved in fact types on their own? Yes.
- Can an instance of a part exist independently from an instance of the whole? Yes (unless business rules disallow it). A wheel, for example, can be removed from an automobile.
- Can an instance of a part be in more than one instance of a whole at the same time? Yes (again, unless business rules disallow it). A power source, for example, can be part of more than one circuit.
Figure 2 illustrates a composition of briefing using a tree structure of thin lines to indicate the parts. The wording for this fact type, not shown explicitly, is assumed to be: briefing is composed of: introduction, main body, conclusion. In other words, tell 'em what you're gonna to tell 'em, tell 'em, and tell 'em what you told 'em.

Figure 2. Example of a composition (whole-part structure).
4. Classifications
A central focus in fact modeling is on identifying, defining, and naming the classes of things important to basic business operations. Most often the business cannot possibly know in advance what all the instances will be of a class of things. For example, most businesses cannot predict all their future customers.
For certain classes of things, however, the business can identify or prescribe in advance some or all of the instances, especially for those classes where the instances are relatively stable. For example, we know all the European countries at the present time. Moreover, the business will need to pre-define instances when it has some business rule(s) that pertain selectively to them — for example: A shipment may be made only to the European countries United Kingdom or The Netherlands.
Representing the connection between an instance and its particular class of things is called classification.[4] Figure 3 illustrates. The line with the double-wavy hatch mark indicates a classification connection from the class of things European country to some of its instances.
Note on Notation
The double-wavy hatch mark indicates that a meta level is crossed. To avoid clutter, we recommend ample use of neighborhoods[5] to depict instance-level terminology. |

Figure 3. Example of classification.
Some additional examples of classifications:
- Health care: All recognized health services — e.g., consultation, office visit, hospital admission, surgery, and so on.
- Ship inspection: All recognized parts of a ship — e.g., bulkhead, hatch cover, railing, deck, and so on.
These examples were chosen deliberately to illustrate that classifications can be multi-level. For example, the instances bulkhead, hatch cover, etc. of the class of things ship part type might themselves be viewed as classes of things with respect to specific bulkheads, hatch covers, etc. These specific bulkheads, hatch covers, etc. probably have serial numbers and would be found on a given ship or in a given shipyard. Business rules might be targeted toward any of these levels.
References
[1] I discussed verbalization in my November 2009 column. See: http://www.BRCommunity.com/a2009/b506.html
[2] Refer to the discussion of verbalization in my November 2009 column. See: http://www.BRCommunity.com/a2009/b506.html
[3] From [ISO-704] International Organization for Standardization (ISO). Terminology work — Principles and Methods. English ed.:
ISO (2000), p. 9. 
[4] Classification is termed assortment in Semantics of Business Vocabulary and Business Rules (SBVR), v1.0. Object Management Group (Jan. 2008). 
[5] A neighborhood is a page or tab in a large graphical fact model that generally concentrates on categories, properties, and instances for just one or several core concepts. 
| standard citation for this article: |
| Ronald G. Ross, "Four Useful Constructs for Developing a Structured Business Vocabulary: Special-Purpose Elements of Structure for Fact Models," Business Rules Journal, Vol. 11, No. 6
(Jun. 2010), URL: http://www.BRCommunity.com/a2010/b538.html |
|
|
about
. . .
RONALD
G. ROSS |
Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC,
where he actively develops and applies the IPSpeak™ methodology including RuleSpeak®,
DecisionSpeak™ and TableSpeak™.
Ron is recognized internationally as the "father of business rules." He is the author of ten professional
books including the groundbreaking first book on business rules The Business Rule Book in 1994.
His newest are:
Ron serves as Executive Editor of BRCommunity.com and its flagship publication,
Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have
heard him speak; many more have attended his seminars and read his books.
Ron has served as Chair of the annual International Business Rules &
Decisions Forum conference since 1997., now part of the Building Business Capability (BBC) conference. He was a charter member of the Business Rules Group (BRG) in the 1980s,
and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.
Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology.
For more information about Mr. Ross, visit www.RonRoss.info, which hosts his blog. Tweets: @Ronald_G_Ross
|
|
|
May 2013
Re-Cycling Shut-Down
Let's Face It — Some Rules Are Just Silly!
By Ronald G. Ross
April 2013
Tabulation of Lists in RuleSpeak® — Using "The Following" Clause
By Ronald G. Ross
March 2013
Requirements are Rules: True or False?
By Ronald G. Ross
February 2013
Breaking the Rules: Breach Questions
By Ronald G. Ross
January 2013
Business Rules, Business Processes, and Business Agility: Basic Principles — Celebrating the 10th Anniversary of the Business Rules Manifesto (Part 3)
By Ronald G. Ross
December 2012
Business Rules, Business Processes, and Business Agility: Basic Principles — Celebrating the 10th Anniversary of the Business Rules Manifesto (Part 2)
By Ronald G. Ross
November 2012
Strategy for Business Solutions: Part 3: Adjusting and Fine-Tuning a Strategy
By Ronald G. Ross with Gladys S.W. Lam
October 2012
Strategy for Business Solutions: Part 2 — Business Mission and Business Goals
By Ronald G. Ross with Gladys S.W. Lam
October 2012
Big-P Process is Dead; Long Live Configuration Agility!
By Ronald G. Ross
September 2012
Strategy for Business Solutions: Part 1 — The Policy Charter
By Ronald G. Ross with Gladys S.W. Lam
August 2012
Business Rules, Requirements, and Business Analysis: Basic Principles — Celebrating the 10th Anniversary of the Business Rules Manifesto
By Ronald G. Ross
July 2012
Strategy-Based Metrics for Measuring Business Performance
By Ronald G. Ross with Gladys S.W. Lam
June 2012
How Business Processes, Strategy, and Business Policies Relate
By: Ronald G. Ross
May 2012
Business Processes: Better with Business Rules
By: Ronald G. Ross
April 2012
Business Policies, Business Rules, and Rulebook Management: Let Us Be Well-Governed
By: Ronald G. Ross
March 2012
What's Really Needed to Align Business and IT Part 2: Strategy for a Business Solution
By: Ronald G. Ross
February 2012
What's Really Needed to Align Business and IT Part 1: Creating True Business Solutions
By: Ronald G. Ross
January 2012
Concept Model vs. Fact Model vs. Conceptual Data Model; Just a Matter of Semantics?
By: Ronald G. Ross
December 2011
Business Rules: Basic Principles
By: Ronald G. Ross with Gladys S.W. Lam
November 2011
Know-How Models: How Business Rules, Decisions, and Events Relate in True-to-Life Business Models
October 2011
Business Analysis with Business Rules
By: Ronald G. Ross with Gladys S.W. Lam
September 2011
How Business Processes and Business Rules Relate
August 2011
Decision Analysis (Part 3): Defining Scope
July 2011
Decision Analysis (Part 2): The Basic Elements of Operational Business Decisions
June 2011
Decision Analysis (Part 1): What Kind of Decisions?
May 2011
How Long Will Your Fact Model Last? — The Power of Structured Business Vocabularies
April 2011
More on the If-Then Format for Expressing Business Rules: Questions and Answers
March 2011
Operational Business Decisions
Whose Decisions Are They Anyway?
February 2011
The Anatomy of Decisions
The Business-Rule View
January 2011
Why Rulebook Management? Because Software Requirements and Business Rules Simply Aren't the Same!
December 2010
Introducing Question Charts (Q-Charts™) for Analyzing Operational Business Decisions: A New Technique for Getting at Business Rules
November 2010
Agility Based on Business Rules
It's Just Common Sense
October 2010
Five Tests for What Is a Business Rule?
September 2010
Can a Business Rule Be Enforced Differently in Different Contexts?
August 2010
How Far Can You Take Decisioning?
July 2010
Business Rules vs. System Design Choices
June 2010
Four Useful Constructs for Developing a Structured Business Vocabulary: Special-Purpose Elements of Structure for Fact Models
May 2010
Eight Things You Need to Know About Fact Types Bringing Verbs into Structured Business Vocabulary
April 2010
Business Vocabulary: The Most Basic Requirement of All
March 2010
What Is a Business Rule?
February 2010
CRUD in Business Rules: Accident-Prone Decision Logic
January 2010
The Point of Knowledge
December 2009
When is an Exception Really an Exception? The Business Rule Principles of Accommodation and Wholeness
November 2009
Verb-ish Models for Verbalization: Give Us Back Our Verbs!
October 2009
From Rulebook Management to Business Governance: Where Business Rules Fit
September 2009
What You Need to Know About Rulebook Management
August 2009
When Is a Door Not a Door? ~ Basic Ideas of the Business Rules Paradigm
July 2009
General Rulebook Systems (GRBS): What's the General Idea?
June 2009
Becoming Strategy-Driven: The Policy Charter
May 2009
Product Quality and a Longer-Term View: A 'Simple' Matter of Business Policies
April 2009
RuleSpeak® Sentence Forms: Specifying Natural-Language Business Rules in English
March 2009
The Rulebook: To Play Ball You Need Rules
February 2009
Extreme Business Agility (Part 6): A Manifesto-in-Progress on the Semantic Re-Engineering of Products
January 2009
Extreme Business Agility (Part 5): The Optimal Edge of Business Performance
December 2008
Extreme Business Agility (Part 4): Change Deployment Hell
November 2008
Extreme Business Agility ~ Part 3: Examples of Non-Agile vs. Agile Business Capabilities
October 2008
Extreme Business Agility ~ Part 2: A Semantic Approach to Re-Engineering Your Company's Products
September 2008
Extreme Business Agility — Part 1: A Value Chain for Re-Engineering Your Company’s Products
August 2008
My Son, Business Rule Analyst — Governance and Compliance Through Young Eyes
July 2008
Rules vs. Processes (Again) — Part 2: Now for Events
June 2008
Rules vs. Processes (Again) — Part 1: There’s Simply No Need for Confusion
May 2008
Legacy Modernization, Semantics, and the Knowledge Economy ~ Have You Connected the Dots Yet?!
April 2008
The Emergence of SBVR and the True Meaning of ‘Semantics’: Why You Should Care (a Lot!) ~ Part 2
March 2008
The Emergence of SBVR and the True Meaning of ‘Semantics’: Why You Should Care (a Lot!) ~ Part 1
February 2008
The Phoenix Strategy ~ A Lower-Risk Approach to Rejuvenating Systems and Legacy Modernization
January 2008
'Rules of Record' Why 'System of Record' Isn't Enough
December 2007
The Decision Center: A Center of Excellence for Coordinating Business Rules and Other Process 'Smarts'
November 2007
The Latency of Decisions ~ New Ideas on the ROI of Business Rules
October 2007
Legacy Systems -- Poorly Engineered or Over-Engineered? New Insights about Business Rules and Enterprise Decisioning
September 2007
The Value of Decisions ~ New Ideas on the ROI of Business Rules
August 2007
A Case of Dueling Manifestos? Business Rules and Enterprise Decision Management
July 2007
What's Wrong with If-Then Syntax For Expressing Business Rules ~ One Size Doesn't Fit All
June 2007
Are IT Terms Fundamental to Every Business? Not!
May 2007
Are all Rules Business Rules? Not!
April 2007
Are Software Requirements Rules? Not!
March 2007
Are Integrity Constraints Business Rules? Not!
February 2007
From Rule Management to Business Governance, Part 4: Governance Engineers and the Chief Governance Officer (CGO)
January 2007
From Rule Management to Business Governance, Part 3: Re-Engineering the Governance Process
December 2006
From Rule Management to Business Governance, Part 2: Governance and How it Relates to Business Rules
November 2006
From Rule Management to Business Governance, Part 1: Governance and How it Relates to Business Rules
October 2006
Rules and Processes: Examples Showing How They Relate
September 2006
The Meaning of Things: Definitions, Intensions, Rules, and Extensions
August 2006
Re-Vitalize, Don't Just Re-platform! ~ Three Tests for Whether Your Company 'Gets It' with Respect to Re-Platforming Business IP
July 2006
The Dirty Secrets About Your Company's Business IP That Nobody Wants to Talk About
June 2006
A Personal Insurance Saga ~ The Economics of Business Rules
May 2006
Concepts, Definitions, and Rules: RuleSpeak® Practices
April 2006
The RuleSpeak® Business Rule Notation
March 2006
How Rules and Processes Relate ~ Part 6. Point-of-Knowledge Architecture (POKA)
February 2006
How Rules and Processes Relate ~ Part 5. Scripts -- Rule-Friendly Process Models
January 2006
How Rules and Processes Relate ~ Part 4. Business Processes vs. System Processes
December 2005
How Rules and Processes Relate ~ Part 3. Three Best Practices for Designing Business Processes with Rules
November 2005
How Rules and Processes Relate ~ Part 2. Business Processes
October 2005
How Rules and Processes Relate ~ Part 1. The Challenges
September 2005
Rule Quality ~ The Route to Trustworthy Business Logic
August 2005
Decision Tables, Part 2 ~ The Route to Completeness
July 2005
Decision Tables, Part 1 ~ The Route to Consolidated Business Logic
June 2005
Rule Reduction ~ The Route to Atomic Business Rules
May 2005
Essence Definitions and Business Rules ~ Developing Stable Anchor Points for Operational Knowledge
April 2005
Can You Violate Structural Rules? (part 3) ~ The Difference Between Breaking Rules and 'Breaking' Knowledge
March 2005
Can You Violate Structural Rules? (Part 2) ~ The Difference Between How to Compute and How to Behave
February 2005
Can You Violate Structural Rules? (Part 1) ~ The Difference Between Violations and Bad Decisions
Janauary 2005
Business Rules and Knowledge Workers ~ Getting to the 'Point of Knowledge'
December 2004
Can a Definition be Violated? ~ Definitions and Business Rules
November 2004
Rustling Up Good Definitions ~ There's a Lot Less and a Lot More to It
October
2004
Clarifying
Clarifications ~ Universal 'And' to the Rescue
September
2004
Relearning
the Basics of Communicating ~ Business Semantics and Business Rules
August
2004
The
Light World vs. the Dark World ~ Business Rules for Authorization
July
2004
Best-Fit
Decision Points ~ How They Fit into the Business Rule Approach
June
2004
What
Rule Independence Means to System Models ~ Less
and More than You Think!
May
2004
The
Semantics Lexicon ~ Terms For The Business Rules / Smart Process
April
2004
Don't
Reinvent Rule Engines!
March
2004
Rules
And Compliance Tactics
February
2004
Tracing
the Path of Rule Reduction
December
2003
Do
Rules Decompose To Processes Or Vice Versa?
November
2003
Should
You Encapsulate Knowledge in Modeling Real-World Things?
October
2003
Business
Rules, Encapsulation, and Models of the Real World
September
2003
Business
vs. Environment in Business Models
August
2003
Requirement
Statement vs. Rule Statement
July
2003
Rules
as Constraints: On or By the System
Design?
June
2003
Rules
Reveal Events -- Not Actions
May
2003
Actions
Are Not Rules (and Vice Versa)
April
2003
The
Definitions of 'Business Rule' and 'Rule'
March
2003
Business
Problems Addressed by the Business Rule Approach
January
2003
About
the Business Rules Manifesto ~ The Business Rule Message in a Nutshell
November
2002
Business
Rules for the Company's Provisioning Processes ~ There’s a Lot More to
Reference Data than Just Data!
September
2002
The
Terminator -- I'll be Back (with Just the Right Term)
July
2002
What
Does it Mean to be Business-Driven? (Part 2)
May
2002
What
Does it Mean to be Business-Driven? (Part 1)
March
2002
A
Telltale E-mail Trail: The Case for
In-Line Business Rule Analysis
January
2002
Managing
M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (part 2)
November
2001
Managing
M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (part 1)
September
2001
The
BRS Rule Classification Scheme
July
2001
Minding
Your P's and Q's
May
2001
RuleSpeak"!
-- Templates And Guidelines For Business Rules
March
2001
Business
Rules In Business Processes ~ Title Rules For Process And Rules For
Product/Service
January
2001
What
Is Rule Management About?
November
2000
Let's
Make a Deal: A Killer App for Business Rules
September
2000
The
Re's Of Business Rules
July
2000
What
Are Fact Models And Why Do You Need Them? (Part 2)
May
2000
What
Are Fact Models And Why Do You Need Them? (Part 1)
March 2000
What
is a 'Business Rule'?
January
2000
Current
Thoughts On Expressing Business Rules
November
1999
The
Fin de Siegle Legacy Mindset
September
1999
Analysis
Paralysis Just May Save Your Life
July
1999
If
We Had Started Coding Already...
May
1999
Your
Core Business Processes Need a Rule Engine
March
1999
Who
or What is a True Business Analyst?
January
1999
Four
Things Wrong with the Way We Develop Information Systems
November/December 1998
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross
September/October 1998
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross
May/June 1998
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross
March/April 1998
Business Rules as Customer Interface
By Ronald G. Ross
January/February 1998
Components and Business Rules: Do They Connect?
By Ronald G. Ross
November/December 1997
The Policy Charter: A Small-Sized Picture of the Big Picture
By Ronald G. Ross
September/October 1997
Implementing
Application Packages: Is There A Better Way?
By
Ronald G. Ross
July/August 1997
'Why'
is Why Business Rule Methodology is Different
By
Ronald G. Ross
May/June 1997
Never-ending
On-the-Job Training
By
Ronald G. Ross
September/October 1996
Re-Usability
in the Business Rule Approach
By
Ronald G. Ross
March/April 1996
The
Newest Idea In Business Rules: Rules Normalize!
By
Ronald G. Ross
January/February 1996
An
Open Letter to DBMS Vendors: We Need Active Database Systems
By
Ronald G. Ross
May/June 1995
The
Greatest Irony Of The Information Age: Business Rules
By
Ronald G. Ross
November/December 1995
Business
Rules:
Knowledge For Knowledge Workers
By
Ronald G. Ross
March/April 1994
"Play
Ball!"
By
Ronald G. Ross
November/December 1988
The
History Of Steam-Powered Ships
By
Ronald G. Ross
January/February 1994
"Business
Rules, At What Cost?"
By
Ronald G. Ross
May/June 1994
Business
Rules: Birth of a Movement
By
Ronald G. Ross
July/August 1991
Why
I Like the Zachman Framework Architecture"
By
Ronald G. Ross
March/April 1997
Business
Process Re-Engineering
By
Ronald G. Ross
|