Components and Business Rules: Do They Connect?

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross

This column originally appeared in the Jan./Feb. 1998 issue of the Data Base Newsletter.

If you just want to know my answer, here it is:  I don't think so.  If you want to why, read on.

I recently spoke at DCI's Database and Client/Server World in Chicago, which was all abuzz about components.  Clearly, components are The Newest Thing in software development.

I must say I did not go in really expecting a clear answer.  After all, components are largely a software engineering concept, and by and large, that community is not plugged into the IS view of business rules (i.e., terms, facts, and rules).  I did, however, expect at least a common definition or understanding of the concept of components.  Maybe that was naive.

What I essentially found was a flea market of ideas -- lots and lots of variety, but not too many real bargains even at flea market prices.  And alas, despite universal lip service to "the business," I find that the programming mentality is still very much alive and well in our industry today.  These are some of the same folks who brought us objects as the ultimate solution, and before that, structured techniques, and before that, modular programming.  Actually, that last one was a very good idea.  In some ways, components simply bring us full circle.

Be that as it may, let's not waste time on the muddle.  Instead, let me focus on the best of what I heard, which was offered by Grady Booch of Rational Software (and UML fame).  For my money, he gave the clearest vision of components, and developed the related concepts quite well.

But what he said about business rules did not compute for me.  Here's what he said:  "If you componentize a business rule, that becomes a replacement part."  That is a nice sentiment -- yes, business rules should be re-usable in that sense -- but what does "componentize" mean?  Let's look a little deeper.

The definition he offered for component was as follows.  "A component is a non-trivial, nearly independent, and replaceable part of a system that fulfills a clear function and that can be used in assembling a well-defined architecture."  No problem there.

But there was more.  He went on, "A component conforms to and provides the physical realization of a set of interfaces that specify some logical abstraction."  Let's leave aside the part about "physical realization."  (At one point, he described a component per se as a "bag of bits."  There are reasons for that.)  Let's also leave aside the part about "logical abstraction."  (There is nothing wrong with that.)  The important point is "set of interfaces," which he said should be "well-defined."

Consider the following typical business rule, stated declaratively (as all business rules should be):  A group must not include any non-union members if it includes any union members, and vice versa.  Before I get to the issue of interfaces, let me digress and ask a different question.  Is this sample rule big enough to be a component?  (Business rules must be atomic so they can be independently changeable.)  Booch didn't talk much about the size of components, except to say that they are generally larger than objects, but smaller than whole applications.  I sense a probable disconnect right there.

What about "interfaces"?  If the business rule is a component, then it must have a set of interfaces.  But what would it be? Unless the interface is the state of persistent data (i.e., the database), I am at a loss.  A rule should simply wake up -- i.e., fire based on appropriate events and conditions.  Nothing needs to ask it to, so why would it need an interface?  I may be missing something, but the ideas just don't connect.

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "Components and Business Rules: Do They Connect?" (Jan./Feb. 1998)

About our Contributor:

Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS 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 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 where he serves as Co-Chair. 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. Find Ron's blog on For more information about Ron visit Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.