By no means is this a book about SBVR.  Rather, it is about the core and critical concepts necessary to understand how  to define an enterprise repository of declarative knowledge covering business.  The unfortunately reality is that the work necessarily suffers from legacy concepts and perspectives, but this is a statement of fact and practicality rather than a negative assessment.  Essentially, my problem with much of the increasingly mainstream marketing and practicing of business rules is precisely the term “rule”.  Nonetheless, since the mainstream audience is pre-occupied with the word “rules” rather than the word “knowledge”, Ron’s book is – again – right on the money for practitioners who want to achieve the benefits of separating models and knowledge from implementations in order to increase the agility of systems and more closely align IT with business needs (all of which he discusses in Chapters 2 and 3).

This edition clearly benefits from the progress in the field and reflects current enterprise objectives that have progressed into the mainstream since Ron began practicing and writing many years ago.  Veterans will quickly recognize and benefit from the simple clarity that Ron brings to the subject.

The critical topics that Ron addresses are the core concepts underlying modeling and linguistics that allow non-technical business analysts (even, perhaps, subject matter experts) to capture unambiguous statements of business definitions, requirements, policies and other “rules” in English sentences that are suitable for presentation to and verification by stakeholders.  In addition, in the event knowledge-level standards like SBVR evolve and are adopted by technology (e.g., business rule) vendors, managing such statements will directly impact the operational behavior of business processes, especially where they involve automated decisions, policy enforcement and other forms of governance requiring enforcement.

Although Ron and I have come to a shared view on knowledge capture and management, we have followed different paths.  Ron’s concern is primarily capture.  Mine extends to and necessarily emphasizes implementation and execution.  Nonetheless, our perspectives on modeling and capture are extremely aligned.  Ron’s writing on what he calls “terms” and “wordings” are right on the money.

We have independently arrived at a point where we believe that linguistic expression of business knowledge is much more important (and valuable) than rule-based expressions suitable for execution by rule engines.  In effect, Ron argues and I agree that the knowledge is much more important, durable, and valuable than its executable form or expression.  As a result, I could not more emphatically introduce Ron’s coverage of how to express models and logic in English.

By the end of Chapter 1, Ron defines what he calls a vocabulary and why  managing  vocabulary is a requirement for managing business knowledge (including definitions, requirements, and policies).   Ron’s writing on nouns and verbs and how they form the backbone of expression for business knowledge is seminal and accessible to novice and expert practitioner alike.

As more or an artificial intelligence practitioner, I might quibble with the omissions of mass nouns, such as money or time, from his discussion, but these topics will not be missed by anyone but the most forward-looking strategist.   Similarly, the limitation of current standards to wordings involving verbs eliminates coverage of adjectival phrases and results in too many wordings involving the verb “has”, at least in my opinion.  For example, wordings like “a person has an age” seem arcane, perhaps technical, to me.  Nonetheless, even though my work supports such “phrasings”, most of its users still use “has” phrasings!  Perhaps this is because I have not taken the time and expended the effort to clarify the concepts that Ron covers so well.  In short, Ron’s writing is right on target for practitioners given the current state of the art (and standards).  And I can think of no other expert or author who has reduced current practice to such an accessible form.

Chapter 4 clearly explains and motivates the use of sentences as the independent units of business knowledge.  Ron does a good job of introducing the notion of roles as the components linked together within predicates using verbs.  This is fairly abstract material, so I don’t blame him for avoiding too much depth on the semantics of roles.  Fortunately, other materials, such as the SBVR standard itself, cover these details in greater depth.  So again, the content seems right on for someone entering the field and focused on linguistic modeling, capture and management rather than more formal “semantics”. 

Ron clearly separates statements defining and relating concepts from requirements.  Not only does he present the material linguistically, he reinforces it with clear graphical presentations of the corresponding models.   Personally, I prefer to mix certain requirements with definitions, as in “a person has exactly one mother”,  but this would complicate the graphical presentations.  He also addresses common linguistics, such as passive voice and using verbs (i.e., participles) as adjectives, which I have found to be important concepts that must be brought to practitioners’ attention.  Otherwise, the models become unnecessarily complex or the resulting sentences seem cumbersome, if not stilted.

In places the formality of SBVR shows through.  For example, “a person must not lease a vehicle the person owns”.  This reflects linguistic limitations of available tools.  This phrasing reflects “necessity” within the underlying logical formalism of SBVR.  In addition, the reiteration of “the person” begs for natural language processing that would understand pronouns, such as “(s)he”.  Having said that, this is clearly a higher level statement than can currently be understood and implement by most business rule management systems (BRMS), however.  As such, it demonstrates the power of Ron’s approach and motivates (given most commercial offerings) the separation of capture and management of business knowledge from its expression in business process management systems (BPMS) or BRMS.

Having encountered the notion of logical necessity in the preceding example, it is worth pointing to Ron’s discussion in Chapter 10.  Externalizing business knowledge from systems requires certain architectures for information systems.  For example, the prohibition of a person leasing a vehicle that (s)he owns requires some action not stated here.  In effect,  a violation of requirements must be anticipated in the runtime architecture.  There are various approaches to this, including runtime exceptions.   Ron demonstrates this approach in Chapter 10 and, if the system incorporates workflow for resolution, he advocates using the end-user accessible form of business knowledge for explanation (in his discussion of guidance within Chapter 2).  More advanced approaches, such as meta-reasoning, and detailed architectural approaches are appropriately left out of this work on capture and management.

Interestingly, in Chapter 7, Ron suggests that business rules should not be expressed within an if-then syntax.  Obviously, this clearly separates Ron’s methodology from the production rule focus of most commercial BRMS.  It also exposes a gap between SBVR and operational systems.  Ron discusses behavioral rules within the chapter but the gap between requirement and behavior remains unfilled.  This is my most significant concern for the logical approach to knowledge management.   Without a framework by which declarative knowledge can bridge to imperative action, the logical approach falls short of operational relevance.  This is reflected, in my practical viewpoint, by the lack of operational deployment of SBVR. 

The principal  challenge remaining for SBVR is to cross the gap from expression into operation.  Aside from linguistic limitations, this is my primary concern for the formal logic approach to knowledge capture and management.   The ideas Ron covers so well are necessary for long-term success in automating managed knowledge, but they are not enough.   Unfortunately, most of the business rule vendors do not adequately address the necessary capabilities that Ron’s methodology and toolsets handle.  This leaves us with a continuing need for business rule engineers to bridge the gap, manually.

Mark’s suggestions include establishing standard upper ontologies for:

1. Time & dates
2. Monetary amount
3. Location
4. Unit of measure
5. Quantities, cardinalities, and ratios
6. Arithmetic operations

I will skip operations for now since they are not taxonomic concepts but functional relationships involving such concepts.  I believe the post on CEP and BPM covered time in adequate detail and the post on Siebel’s handling of foreign exchange covered the currency exchange aspects of money.  It only touched on the more general concept of amounts that I will focus on here.

The remaining concepts are common to almost every application conceivable.  They are some of the most primitive, domain-independent concepts of a critical and practical upper ontology.  They include:

1. Time
2. Amounts
3. Numbers
4. Location

Notice that money is not listed, nor are units of measure.  For more details, read on and consider the sections on “units as constants” and “much versus many” here.

Also note that cardinalities and ratios are simply numbers.  Consider, for now, an amount as a number and unity of measure.  I’m treating amounts and numbers as quantities.  That is, a quantity is either a number or an amount.  Taking this view, the order of ontological development could be expressed as:

1. Time
2. Numbers
3. Units of Measure
4. Amounts
5. Quantities

As we will discuss below and as I have discussed previously, however, units of measure are amounts, so the preceding is tautological.  Moreover, modeling quantities after modeling amounts (which includes or requires modeling numbers) is so trivial that is not worth mentioning.  Therefore, the order and focus I recommend is:

1. Numbers
2. Amounts

And in modeling amounts, we will model “stuff” like time, money, and distance.

Amounts before time

An ontology that covers time also needs amounts.  For example, what separates one point in time (or a date) from another point in time (or another date)?  The difference is an amount of time.  In other words, we will not model time well without first understanding (and subsequently modeling) what an amount is. 

But to model an amount, one needs to model stuff.  And to discuss an amount, one needs to be able to state how much stuff some stuff is.  That is, one needs to say that an amount of stuff is a number of reference amounts of stuff.  For example, the amount of time it takes to read this second can be measured by a number of seconds.  Of course, a second is also an amount of time.  But it is an amount that we all understand so we can use it as a reference.  None of us really knows how much an inch is, but we know enough about it that we now a twenty five inch newborn would be pretty long.

Authority could not model stuff.  Its concepts were implemented only to handle concepts labeled by common count nouns and instances of such concepts.  Any new concept had to be one of the following:

There was no way to model “steel” or “water” or any other mass noun.  As we will discuss, we cheated our way out of this by modeling:

• an amount of money
• an amount of time (or a duration)
• an amount of length (or distance)

Essentially, an amount is a count noun.  Its plural is “amounts” and a particular bunch of some stuff is an amount.  An amount of any kind of stuff can be measured using a number and a unit of the same kind of stuff.  The same is true for the word “unit”.  These words are known as “partitive” nouns.  Using them with a mass noun produce as noun phrases that is a count noun.  See the section titled “monthly partitions” in the post about events and time for more on partitives.

Numbers before amounts

The point here is simply to point out that it won’t do much good to measure amounts until we also model numbers, because without numbers we cannot specify how much of some kind of stuff (e.g., time or money) we are talking about!

So the upper ontology should be developed in the following order:

1. Numbers
2. Amounts
3. Time

Note that location has been dropped for now.  The next section explains why we recommend modeling distance as part of amounts but deferring location.  If you want to get on to what amounts are (including what kinds of stuff there is), please skip ahead.

Time and distance before location

Modeling time is much simpler in practice than modeling position since we all share the same time but have different perspectives on even the same position.  For example, in modeling location, we will need to model position.  Modeling position will require modeling systems of coordinates in up to three dimensions.  This will require defining what a dimension is and, when used in a system of coordinates, how positions are defined along that dimension.  With peculiar exceptions, such as longitude and latitude, coordinate systems have at least one dimension along which position is measured by distance.  In Cartesian coordinates, position is specified by distance from the origin in all dimensions.  In two or three dimensions, one or two of the dimensions may be specified by an angle.  In cylindrical coordinates, one of the dimensions is angular and the other two are Cartesian.  In spherical coordinates, two dimensions are specified by angle.

We have not even begun to model perspectives (each involving a coordinate system and point of origin) or motion (which requires time) which seem so natural to consider as one models location.  In addition, we have not modeled geography, including hemispheres or continents.  Without geography, we cannot adequately progress to political geography, especially countries (at least not by location, we may model them for currencies, perhaps within continent and by neighbor).

For example, Cartesian coordinates, position is measured by distance from the origin in all dimensions.  Geographic position requires only two, but it also requires a notion of angle and the reference points for Greenwich (which relates geo-position to Universal Time) and the equator.  Of course, we may also need to model a sphere, which will require modeling circles, which will turn out to be required simply to model angles.

All these issues will need to be addressed in a robust upper ontology, but we can skirt the issue for now by realizing that the amount of space between two positions is similar to the amount of time between two points in time.  More specifically, the length of a line between two points in space is a distance, just as the length the line between two points in time is its duration.

We can model distance as an amount, just as we can model duration as an amount.  Each has reference amounts, such as meters and seconds.  And as we will discuss, we can compose them into area, volume, and speed.  But without direction, which requires a much of the modeling discussed above, we cannot fully model velocity or acceleration.

Amounts are stuff

An amount of money is money.  An amount of time is time.  An amount of distance is distance.  Each kind of stuff has units of measure.  Currencies are the units of money.  Good units of time are seconds, days, lunar months, and solar years.  Good units of distance are inches and meters. 

Money, aside from currency and exchange issues discussed elsewhere, is a mass noun.  Most people find it peculiar to talk about “monies”, unless they are referring to amounts of money.  The same is true for time.  Of course, words are also ambiguous.  When we say “what time is it” we are referring to a time of day, not time itself.  When we refer to ‘a number of times”, we are referring to a number, not time itself.

• What is the difference between an amount of money and money itself?
• What is the difference between an amount of time and time itself?

The difference is that mass nouns refer to something that is not measurable or countable but to the stuff itself.  You cannot measure time, but you can measure an amount of time.

It turns out that the difference between stuff and amounts of stuff is beyond the capabilities of most products today.  For example, my previous work tries to avoid modeling mass nouns by, as Mark suggests above, modeling amounts of stuff (e.g., “monetary amounts”). 

The trick is that putting “amount of “in front of whatever kind of stuff, produces a count noun!  Then, even if we think everything is an object, we can handle mass nouns.  For example, we already discussed how this works in Authority above.  If we are using OWL, we can introduce “an amount of money” or “a monetary amount” as a kind of thing.

The fact that most knowledge representations do not address mass nouns well, if at all, may be surprising.  What is even more surprising is how poorly most knowledge representations handle.  The fact that RDF and OWL do not address them explicitly is stunning.  The fact that OMG is considering how to address this in SBVR or its object definition meta-model (ODM) is tremendous!^[2]

On Numbers

For most computer people, numbers are either integers or real numbers.  There are several other relevant kinds of numbers, however.  For the best overview and surfing, I recommend Wolfram’s Math World.  A good taxonomy of numbers should include the integers and the real numbers, the later including fractions (rational numbers).  It may also be useful to model the natural or positive integers (and the disjoint negatives, perhaps), but I would probably avoid modeling complex numbers, even though I’m a “retired” physicist.  Too many years in business, I guess.

This really isn’t enough on numbers, though.  Modeling a percent(age) is important, as are ratios in general.  Ratios can be modeled as fractions.  Like fractions they have denominators and numerators, each of which is, in general, a quantity.  If the units of the denominator and the numerator are the same (including non-existent) then the result is unit-less.  That is, the result will be a number.

A decibel is also a number, as is a Richter magnitude.  Each is a logarithm of a ratio between some metric of power, energy or intensity over a reference metric.  Any logarithm results in a unit-less number, of course.

In my experience, percentages are more important than fractions or ratios and logarithmic units are rarely used.  This may simply amount to an admission of too much financial services work since my days as a scientist!

Another angle

Modeling angles can be avoided in most cases, but problems like Halo’s attempts to pass the physics AP test will certainly require it!  Any significant effort to model location, including other than Cartesian coordinates will also require an understanding of angle.

An angle is measured as the numerator of fraction where the denominator is implicit.  For example, when measuring in radians, the denominator is the 2 pi radians in a full circle.

Perhaps it would be better to add “angle” as one of the primitive types of stuff, like distance?  What do you think?

Kinds of stuff

The International System of Units designates the following most “base units”:

Note that these are physical units.  Money is important, too. 

Note that a mole is actually a count, not a kind of stuff.  One mole is Avogadro’s number of molecules of some kind of matter. 

Dropping moles (since they are not a kind of stuff) and adding money gives the base units that we provided in Authority.  With the exception that Dr. Novak kept moles, this we took an approach similar to his approach in this 1995 paper, at least on what stuff is.  We did not have all the concerns about single step unit conversion that he addressed.

This is count is sometimes more useful than than mass in chemistry.  The mass of a mole of a substance is its atomic mass, which is a function (primarily) of the number of neutrons and protons in each molecule.  Moles are used primarily in chemistry to describe or control how many of various kinds of molecules are available to react with each other.

Base units

In addition to the SI units listed above, it is nice to add things like inches and ounces and their multiples, feet, yards, miles and pounds and tons.  You also want the common divisions and multiples of the SI units, like minutes and hours.  Days, months and years are also handy, of course, but these are not strict multiples of seconds.  See our prior post on events and processes needing a good ontology of time. 

The upper ontology should also include degrees Celsius and Fahrenheit, because these are somewhat common.  Degrees Kelvin is less relevant to most, as are units of luminosity and charge.  Note that in Authority, I took the liberty of disagreeing with the Bureau International des Poids et Mesures.  Charge, which was the SI base unit before they changed it to current in 1961, strikes this physicist as the better primitive, since current also requires the notion of time and is therefore less primitive.  In any case, neither coulombs nor amperes are terribly relevant to most.

Weight: one minute

Practically speaking, the difference between weight and mass can be ignored if gravity can be assumed constant at the earth’s surface and location will always remain close to the earth’s surface.  Nonetheless, weight is a force not a mass and it can be modeled properly.  More importantly, any inability to do so with semantic accuracy is a serious issue!

Composing derived units

Given the following kinds of stuff and some reference amounts for each that we call units, we can describe almost all of a person’s everyday world:

• Money (e.g., dollars and cents)
• Time (e.g., seconds, minutes, hours, days, weeks, months, and years)
• Distance (e.g., inches, feet, yards, miles and meters, including mm, cm, km)
• Mass or weight (e.g., tons, pounds, ounces or grams, including mg, kg)

For example:

• Speed is distance over time, as in a mile per hour or a meter per second.
• Area is distances times distance, as in a square meter or an acre. 
• Volume is distance cubed, as in a cubic meter, a liter or a gallon or an ounce.
• Acceleration is distance over time over time or distance over time squared, as in meters per second per second or G, which is a constant approximating the acceleration of a mass at the earth’s surface due to gravity.
• Weight is a force, which is mass times acceleration.  A kilogram on the earth’s surface weighs (i.e., exerts a force downward) of approximately 2.2 pounds.  A Newton is a kilogram accelerating at one meter per second per second.
• Energy or work is force times distance, as in a joule, which is a Newton meter.
• Power is work over time, as in a Watt, which is a joule per second.
• Current is charge over time, as in an ampere, which is a coulomb per second.

We compose new kinds of stuff very simply:

• Multiple or divide one kind of stuff by another.

Manipulating amounts is much trickier.  That’s what Novak’s 1995 paper was all about.

Working with amounts

A long time ago (on the first page of this post!), Mark Linehan listed arithmetic operations as necessary in what he is reluctant to call an upper ontology.  I am not so reluctant but he is on the money about arithmetic operations.

Readers of this blog will recall some discussion about adding amounts of money using Siebel’s model of money (which includes currencies, inflation, and exchange rates) from that article.  In general:

• An amount of stuff plus another amount of the same kind of stuff equals a total amount of the same stuff.
• A total amount of stuff minus an amount of the same kind of stuff yields another amount of the same stuff.

So the upper ontology on amounts needs a relation that handles this.  It needs to support inferences, such as:

• A second plus a minute is 61 seconds.
• A kilometer plus a mile is (5,280 plus 3,280.8399) feet.
• 212°F minus 100°C is 0°C or 32°F
• A second plus a mile is a problem.

It will be interesting to see how OWL, RIF and OMG come out on this.  Some of the standards may land up being revised deeply to address these issues. 

Composing amounts

We have already discussed that distance over time is speed.  What happens if we multiply an amount of speed by an amount of time?  For example:

• How much is 100 kilometers an hour times 90 seconds?
• How much is one mile per day times a month?
• How many acres in a square kilometer?
• How much is minimum wage for a week?

The infrastructure required for this kind of reasoning is critical if an ontology for amounts is to be broadly useful.  Novak’s paper is the tip of the iceberg.  Authority does much of this well, but we need vendors and/or the W3C and OMG to bring the semantic web and MDA stack up to snuff. 

The efforts at OMG on such ontologies are a great step in that direction.

Ask them the question that drives CEP people crazy!

Last fall, at the RuleML conference in Orlando, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.  

1. Apparently, the broader OMG feels the same need for “event semantics” we discussed in Florida.
2. In addition, BPMN users indicate that too many event types complicate process modeling.
3. Finally, Bruce Silver dives a little deeper in two recent posts, one which responds to the authors of the BPMN survey and the other discussing whether BPMN will actually become portable, among other things, including events.

For me, the Great BPMN Debate boils down to two things:

1. Whether BPMN has too many features
2. That BPMN is missing semantics

I like BPMN.  I wound not want to sacrifice much.  But as a customer, I would think interchange is critical.  Regrettably, Mr. Silver points out some problems serializing to XPDL and other issues with vendor coverage.  We are a ways from effective standards for rules or BPM, it appears.  By effective, I mean standards supported by vendors that actually facilitate interchange between vendors.

1. XPDL may not be enough for BPM.
2. Rule vendors at the Business Rules Forum openly agreed that PRR is too low level for effective interchange given all their value-added (which I do not question)
3. RIF will be much better than PRR but it will still not facilitate effective interchange between BRMS vendors
4. SBVR has little traction and no effective implementation (yet)

One problem with all these standards, and even the web ontology language (OWL), is that they lack a common ontology.  That is, they are syntax lacking shared semantics.  Until they share some semantics, integrating or interchanging between them will remain imprecise , unproductive, and overly technical.  Everything but technical rules and models (e.g., vocabulary) will remain locked in.

BPMN is overwhelmed by events

Just reading Mr. Silvers post, you find start and end events, throwing and catching events, intermediate events, exclusive events, timer, message, error and terminate events.  And there are more.  Too many, BPMN users agree, according to the survey cited above.

How many different kinds of events are there (or should there be)?  For now, I’m going with 2.

What is an event?

Ask any complex event processing (CEP) vendor!  It will drive them crazy or you will get a long-winded answer. Or, like me, they might say that it is something that happens or occurs.

At first, most people think of events as occurring at a point in time.  After some discussion, however, most people agree that events are things that we view as occurring instantaneously, even if they take a day, such as last year’s 4^th of July picnic, which we might also call an occasion.  Events, like the lights going on or a starting gun firing, might indeed be effectively instantaneous, in which case we would not call them occasions.

There is more to the difference between occasions and instantaneous events, however.

What occurs or happens?

Is an event an occurrence or something that occurs?  The difference is  similar to the difference between days, such as Friday versus March 14, 2008.  One is what BPMN would call an event type and the other is an event.  Well, not exactly, I doubt BPM folks would be happy thinking of a day as an event.  Perhaps they would prefer that the start or end of each Friday was a type of an event and that the start of this Friday (i.e., today) was a specific instance of the “start of a Friday” event type.

For those who read about understanding time, the difference between event types and events is similar to the difference between specific and recurring times.  The semantics of introducing different types for starting and ending events is troublesome, however.  Especially if how they are different is not specified semantically.

Generally, for all X, I do not like X “types”. When we talk with friends other than colleagues, using the word “type” confuses them.  When talking to non-technical folks, instead of saying “event types”, why not just say “events”?  Come to think about it, why don’t we talk about process types?  (I’m sure someone thinks BPMN needs them!)

When is a process not an event?

Most people would agree that things happen.  Most people would also agree that events happen.  The word “occur” is interchangeable with “happen” here.  Do you agree that processes, like events, also occur or happen?

If specific instances of events are occurrences of “event types”, what is a specific instance of a process?

If celebrating the 4^th of July is a process and last year’s 4^th of July picnic was an event, could an instance of a process be an event?  Or, is every instance of an event type an occurrence of a process?

Yes and No.  Yes, but, for all X, I do not like X “instances”, for the same reason that I do not like X “types”.  In other words, yes, occurrences of processes can be viewed as events.

But no, some events are not processes.  For example, the start of a process can be viewed as an event, as BPMN views it, but the start of a process is not necessarily a process in and of itself.  We could recurse into philosophy on this one, I guess, but at some level, the beginning of an explosion stops being interesting from a process perspective.

Avoiding philosophy as much as possible while remaining semantic:

1. Occurrences of processes “are” (can be viewed as) events.
2. Events occur instantaneously or over an interval of time.
   • That is, events occur at a point in time or they have a duration.
   • In other words, an event is either instantaneous or durative.
3. Durative events are occurrences of processes.
4. Instantaneous events occur at the beginning or end of processes.

Ontologically, a process is disjoint from an instantaneous event but both are events.

Getting this right is important, not only for helping CEP cross the chasm, but also for integrating BPMS with BRMS.  Whether or not they agree with me, OMG and others need to answer the question:

Are processes and event different and, if so, how?

In his post, James agrees with the Butler Group’s statement:

Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.

I have several problems with this statement:

1. I don’t think it’s the most important aspect.
2. I don’t think the possibility of re-use is being realized.
3. I  think current tools’ facilitation of re-use is limited.

The most important aspect of a repository is the reuse of knowledge, not just rules.  The types of knowledge that are most easily reused are:

1. the vocabulary (e.g., nouns, verbs and adjectives) and what they mean in the domain
2. the taxonomy of concepts and how they are refered to using (primarily) nouns and adjectives
3. the ontology of concepts, which is the taxonomy plus relationships between concepts, and how they are referenced using nouns, verbs and adjectives
4. the definitions of derived concepts in terms of formulas or equations or constraints that define the truth without respect to process, state, or event
5. the rules that specify behavior, regulation, governance, or policy

And their re-use decreases in the same order.  Industry specific standards, like ACORD or MISMO of FIX or XBRL, for example, stop at 2 or 3.  Logical formalism address 4 but are used more rarely than business rules.  The SBVR standard, although it stands for the semantics of business vocabulary and rules, actually stops at 4.  It’s rules are logical definitions and constraints, not business rules that take action, resulting in state transitions, data modifications, or other side-effects.

The use of SBVR or simply ontology is quite limited in today’s BRMS/BPM markets.  There is simply too little emphasis on separating semantic models and business vocabularies using logic and ontology.  Most BRMS/BPM platforms are fixated on behavior and process, rather than truth and knowledge. 

Sure, clever enterprise architects and systems analyts can engineer rules so that they are useful in more than one application, but this is not the typical result of a business rules application.  I do agree that encapsulating decisions within services is a more viable way of realizing re-use, but that is an architectural result (i.e., an SOA benefit), not a benefit of a rules repository.

I have blogged repeatedly (see the requirements category, for example) about the limitations of current tools with regard to vocabulary, separating ontology from implementation, and managing definitions and functional requirements in the natural form.  Current BRMS tools are generally limited to an if-then mentality that makes them inadequate for managing knowledge.  If-then metaphors force knowledge to be expressed and organized relative to how it is used.  This fundamentally and inherently limits its reusability.

Just to drive this home, if you are technically inclined, take a look at the standard developed by the vendors, PRR.  It will become immediately apparent that their focus is on rules at the operational rather than the knowledge level.  RIF, on the other hand, evolved from the logic community to address the requirements of the semantic web.  In this regard it is much more like SBVR.  It makes up for its vocabularly weaknesses with much more ontological and logical strength.  Nonetheless, RIF, like SBVR, is more at level 4 than level 5. 

Another way of looking at this is that the models more than the rules are interchangeable.  This misses that logical rules are very reusable, but it is in accordance with the 80/20 rule.  In BPM, for example, the model is shared across processes.  With decision management, the model should also be shared across decisions.  The easiest rules to share across decisions are those that are true, not those that determine what to do.  

Practically speaking, put rules that determine what to do in a services that share what is true. 

[ratings]

Consider these words from Forrester:

One might argue that Word documents, email, phone calls, and stakeholder meetings alone are adequate for managing rules. In fact, that is the methodology currently used for most projects in a large number of IT shops. However, this informal, ad hoc approach doesn’t ensure rigorous rules definition that is communicated and understood by all parties. More importantly, it doesn’t lend itself to managing the inevitable rules changes that will occur throughout the life of the project. The goal must be to embrace and manage change, not to prevent it. ^[2]

But note that Forrester used the word “requirements” everywhere I used “rules” above!

The fact is, BRMS vendors target business analysts, promising that they can capture and maintain rules externalized from application infrastructure. But BRMS vendors do not support capturing and maintaining requirements.

A better vision would unify rules with requirements in a single framework of understanding and within a single management tool. Otherwise, rules will remain downstream from functional requirements and use cases in the development process. Consequently, business rule management systems (BRMS) would always be at least one step removed from business analysis – and, therefore, end users.^[3]

Until BRMS vendors do support requirements, business analysts will continue to use word processors, spreadsheets, or requirements management software. And for the most part, they will do so instead of – rather than in addition to – using a BRMS.

There are many thoughts on how to elicit business rules and requirements.^{[4][5][6][7][8]} 

Surprisingly, there is substantial confusion on the relationships between rules and requirements.

For example, some have written: ^[9]

1. rules are not requirements^[10]
2. rules cannot be managed using requirements tools
3. rules must reference requirements which must not reference rules

A distinction should be made between functional and non-functional requirements (as in ISO 9126^[11] and according to NASA^[12]). When we use rules we are most concerned with functional requirements.^[13] The positions stated above seem to reflect a perspective: that rules are an implementation of functional requirements.^[14] For example, that rules exist to clarify how to comply with requirements or how to behave when requirements are not satisfied (e.g., during a business process^[15]).

In order to realize their marketing promise, BRMS need to advance to include direct support for functional requirements. Ideally, this support will eliminate the need to translate such requirements into rules. At a minimum it should support mapping back and forth between related rules and requirements, perhaps by supporting the OMG mappings between concepts like means (e.g., directives, including policies and rules) and ends (e.g., objectives), as in the Business Motivation Model.^[16]

Supporting relationships between rules and requirements should not require relationships between them, however. Sometimes a policy may exist without a clear underlying requirement. Although theoretically, perhaps, there should be some underlying requirement for every rule, uncovering it may not be productive. Moreover, as discussed below, the distinction between rules and requirements is artificial in many cases.

When integrating rules and requirements into a single framework, care should be taken to support all the natural results of business analysis. In addition to rules and requirements, business analysts also uncover definitions of vocabulary and underlying concepts.

Vocabulary definitions are mostly ontological^[17], such as mapping nouns onto taxonomic concepts or defining what it means when an adjective is used with a noun. This is why I designed Haley Systems’ Authority to manage such vocabulary and ontologies. Regrettably, the software did not yet eliminate the need to translate requirements into rules before it was acquired by Ruleburst. With it, Ruleburst is ahead of other vendors who do not manage ontologies and vocabularies explicitly, but there is still a problem.^[18]

Current BRMS technology is not able to implement requirements directly. Current BRMS need a human to analyze a requirement and translate it into sometimes many rules that use the words “if” and “then” instead of words like “must” that are so common in requirements. This leads rule technologists to say things like, “a rule may reference a requirement” but “a requirement is not a rule”, as cited above.

One would think that OMG standards in rules could be supported by the BRMS vendors who contributed to them. Surprisingly, what SBVR^[19]calls a rule is beyond the capabilities of current BRMS (as also discussed here). For example, most rules technologists would have trouble “coding” the SBVR rule: “each rental car always has exactly one vehicle identification number”. The rules technologist might say that this was a definition, not a rule or requirement.

Business analysts, such as those involved at OMG, are alienated by such discrimination.

And they are right to be alienated. What if a service request provides two VINs? Or zero? Does the statement change from a definition to a requirement or some rules?

Vendor support for requirements (or simply SBVR) rather than just rules involves – at a minimum – generating rules that invoke an exception mechanism when a requirement is violated (as also discussed here). Generating rules that avoid premature exceptions is a significant challenge, however, particularly when information may be missing (including when it is accumulated over time, such as across multiple submissions of web forms).

For example, given the requirement that “an ad on the back page of the New York Times Magazine must be full-page color”, it may be preferable to deduce the (permitted) color or size of a back page ad rather than indicate an exception if the size or color is unspecified. Today’s BRMS do not assist users with such rules nor do they relate them to such requirements. All such translations and any such mappings are strictly manual.

The looming battle in RMS involves the clarification and automated implementation of requirements and less codification of rules.

As you might surmise, I find this area presents some very interesting opportunity…

The line between requirements and rules needs to be clarified. Perhaps it needs to be erased. Consider that not every requirement must use the word “must”. During analysis, for example, a business concept might be similar to the concept of an orphan. A business analyst could capture this as any of “an orphan has no parents”, “a person without parents is an orphan”, “if a person has no parents then the person is an orphan”, “a person is an orphan if the person has no parents”, or “an orphan must have no parents”, among other alternatives. Some of these appear to be definitions, some requirements, and some rules. Yet they are all the same from the standpoint of stakeholders and less technical analysts.

Should software help clarify and unify such typical results of business analysis or should the burden be borne by humans in a waterfall process that distances natural expression of “requirements” from technical definitions and implementing “rules”?

Obviously, I believe the former.

In addition to previous recommendations to manage rules in a BRE-independent manner, I hope the following provides additional help in planning for the integration of requirements, definitions, and rules as the market evolves:

1. Contemplate the extent to which your rule analysts are distinct from your requirements analysts and discern why if that difference is significant.
2. Adopt methodologies that are consistent with best practices in requirements capture, analysis, and management rather than over-emphasizing rule-specific approaches.
3. Understand where rule/requirement convergence and vendor independence is headed. Specifically consider SBVR (e.g., look at the video or document here). To a lesser degree consider PRR and semantic web activity.
4. Consider managing rules and requirements outside a BRMS using requirements management software or as discussed here. Also consider the functionality of requirements management software (e.g., Rational) or BRMS that is not provided by an unassisted word processor or spreadsheet (e.g., as Ruleburst still presents here).

1. Business Rules Management Systems (BRMS) typically produce forward chaining production rules that are interpreted by^[1] a business rules engine (BRE) based on the Rete Algorithm.
2. BRMS typically generate rules that are interpreted by a BRE.

First, dropping the word “production” before “rules” loses information. BRMS do not typically generate rules that are not production rules. Consider, for example, the BRMS vendors involved in the OMG effort produced the Production Rule Representation (PRR) standard. The obvious question is:

• What is different about production rules?

Second, dropping the words “based on the Rete Algorithm” loses information. The dominant rules vendors and open-source engines are all based on the Rete Algorithm.

• Why does the Rete Algorithm matter?

Third, dropping the word “chaining” before “rules” loses information. Chaining refers to the sequential application of rules, as in a chain where each link is the application of one rule and links are tied together by their interaction. But:

• Why does chaining matter?

Fourth, dropping the word “forward” before “chaining” loses information. Forward chaining reacts to information without requiring goals. This begs the question:

• Don’t goals matter?

What is different about production rules?

In a system where rules are not productions, new knowledge must be positioned within the existing knowledge. In the worst case, the cost of adding a new rule is proportional to the existing number of rules. That is, the cost of acquiring new knowledge increases as knowledge accumulates. The ability to improve at constant cost is the basis of agility that comes from using production rules to implement business rules.

The term comes from automata theory, in which the rules that define a formal language are called “productions”. The important thing about productions is that the formal language they define does not depend on their order.

For example, changing the order of rules expressed in Backus Normal Form (BNF) will not change the definition of a language (e.g., Pascal). This is distinct from “if-then-else” statements in procedural languages where order is clearly relevant.

Also consider that the order of logical formula does not matter to a theorem prover.^[2]

Procedural rules (including if-then-else statements in procedural languages and decision trees) are less agile. The effort required to codify them increases as the amount of pre-existing code increases.

The irrelevance of order is the critical ingredient of agility.

Focus on truth. Minimize context.

Why does the Rete Algorithm matter?

The agility of production rules would be less practical if performance degraded as more rules were added. For a practical business rule system, performance must scale less than linearly with respect to the number of rules. That is, if doubling the number of rules always cut performance in half, the applicability of rules might be limited. Ideally, adding a rule would have zero impact on performance.

I’ve written about these topics many times^[3] and there is plenty available on the Web^[4].

Essentially, in Rete, the conditions or antecedents of rules correspond to SQL queries. Rather than check rules by running a sequence of queries against data, however, Rete compiles queries into a pattern matching network through which data flows. Performance of the first approach would clearly be linear in the number of rules (queries). The worst case performance of Rete can also degrade linearly as rules are added, but the expected performance is less since Rete effectively ignores conditions that are not satisfied by data.

Decades or experiments and commercial use have demonstrated that Rete typically scales up with performance that degrades far less than linearly. Here is the technically accurate statement:

The expected performance of the Rete Algorithm is asymptotically independent of the number of rules.

In practice, adding a hundredth or ten thousandth rule will have immeasurable impact.

Rete matters only because it implements unordered rules in an efficient and scalable manner. If you can implement rules without ordering them some other way, great – but consider chaining, too.

Why does chaining matter?

Chaining refers to the sequential application of rules, as in a chain where each link is the application of one rule and links are tied together by their interaction.

Without chaining, inference is impractical.

Chaining is a key distinction between implementing rules using an engine versus in procedural code. A rules engine can string inferences together to reach conclusions involving several steps, where each step is expressed in a rule. Procedural languages provide no support for reaching intermediate conclusions and building further upon them.

Without chaining, a system cannot be intelligent.

Chaining is your greatest source of leverage for semantics and intelligence. By writing statements^[5] that are true you can leverage deduction. Doing so makes all your statements less verbose and more reliable.

Don’t Goals Matter?

Backward chaining involves working backwards from goals to the current state of the world. Therefore, backward chaining requires a goal. Problem solving involves goals.^[6]

Forward chaining involves working forward from the current state of the world. Forward chaining does not require goals. Forward chaining is behavioral and – without goals – strictly reactive.

Unlike artificial intelligence and logical rule systems, PRR and all but one BRE based on the Rete Algorithm are limited to forward chaining.

Forward chaining systems are inherently limited to “if” and “then”. When the “if” is satisfied they want to conclude or execute what comes after the “then”. Which “ifs” are satisfied, is determined or driven by data, of course.

Unfortunately, the data-driven aspect of forward chaining is often confused with the data-driven nature of the Rete Algorithm. The fact that the Rete Algorithm is data driven has nothing to do with whether it can support backward chaining.^[7] The lack of support for goals in the business rules market is the issue, not the Rete Algorithm.

I have previously supported backward chaining using the Rete Algorithm. The details are available on-line^[8], from Haley Systems, or by request. More vendors need to step up their support in this area. The open-source community is actually ahead of most!

Support for backward chaining will allow business to use more logical deduction without as much need to indicate when to perform or how to control inference. Subgoaling will focus inference. This will encourage and facilitate increasingly large and sustainable repositories of knowledge.

Even with improved deductive capabilities using backward chaining, BRMS will remain inadequate for requirements, however.

Why can’t BRMS handle requirements?

In order to support emerging standards from OMG^[9] and W3C^[10], BRMS need to handle logic that is not limited to the “if-then” or “A implies B” form of rules. Such statements include definitions and constraints^[11]; or, more generally, requirements.

Requirements do not fit the “if then” paradigm of today’s business rules systems. They do not pose any challenge to logic systems, however. Current rules technology requires an antecedent. A formula in the predicate calculus does not.^[12]

This results in all sorts of distortions in the business rules market. Worst among them, in my opinion, is the distinction between requirements management and rules management on which I will post shortly.

On the analyst front, they read advice such as the following from Gartner:^[1]

As Gartner has stated, the BRE market is a volatile technology sector, and market trends point to increased consolidation. In recent research, we stated that some consolidation will come from rules-to-rules acquisitions. Recent examples of this include Trilogy/Versata buying Gensym and now, RuleBurst purchasing Haley Systems.

Another form this consolidation will take is application vendors or business process management suite vendors buying much-needed rule technology, as seen in SAP’s recently announced intention to purchase Yasu Technologies. In either case, rule technology will persist, but the vendors selling the technology will often be different.

I agree with Gartner, enterprise app and BPM vendors desperately need rules technology. I also agree with the following analysis from Forrester:^[2]

SAP’s decision to purchase Hyderabad, India-based Yasu Technologies greatly improves its business rules management capabilities. Other large vendors would be wise to follow SAP’s lead in the business rules market. If you look at the big vendors, they’re all going to need this technology. SAP’s competitors are going to have to step up to these requirements also.

It’s encouraging that SAP bought Business Objects and is now buying Yasu. We’re seeing requirements to link business rules and business intelligence or analytics. SAP has told us they have seen these requests, and we’re encouraged that SAP is now acting.”

Unfortunately, Gartner’s concluding advice could have been more constructive:

Prospective BRE customers: Buyer beware – the rule engine market is a volatile sector. Choose your vendors carefully and be prepared to see more BRE acquisitions.

Consolidation is a sign of a maturing market. Gartner is responding to the same fear, uncertainty, and doubt that I first mentioned above. Forrester’s advice has been more specific and constructive:^[3]

I’ve been waiting for consolidation to happen [...] the customers need it.”

Two companies that are particularly appealing targets are Ilog and Corticon. Ilog is one of the market leaders in business rules functionality and market share, but it counts only about $125 million in yearly revenue.

Despite these comments, Gartner agrees that accessible rules technology is the critical ingredient needed for agility and in BPM:^[4]

Business rule technologies are considered essential to BPM systems (BPMS) because they extend the flexibility and agility BPM brings to process management by making complex decisions in the processes transparent, and therefore manageable, to users. According to leading IT research firm, Gartner, in the report “A Business Rule Market Checkup,” November 6, 2007 by David McCoy and Eric Deitert, “By definition a BPMS must include rules technologies.”

Having recently talked directly with most of the potential acquirers in this space before merging with Ruleburst, I think the threat of further consolidation is exaggerated. The smaller vendors are already consumed and the lack of immediate synergies will inhibit eight, certainly nine figure acquisitions for the foreseeable future. Of reputable vendors, only Corticon or the Ruleburst/Haley combination seem viable targets in the short term. I expect most enterprise app and BPM vendors to stick with partnerships or join Oracle in acquiring inexpensive or open-source engines.

Indicators other than consolidation, such as available talent and standards adoption, are lagging in this market. Although I plan to address the inadequacy of emerging standards that I have covered elsewhere^[5], my clients are more immediately concerned with the lack of fungible talent. Adopters too often engage recruiters only to find people with limited experience or consultants with specialty rates and limited availability.

A dearth of talent is a sign of a small or immature market, or both. However, IDC estimates that the business rules market software, excluding service providers, will continue double digit growth to $531M in 2001 from $227M in 2006, during which Fair Isaac grew revenues its by 19% to 24% of the market!^[6] The weak talent pool is due to certain immaturities in the market. Consolidation itself will not address these directly.

In order to motivate people to focus on developing skill and accumulating experience in this market, they have to believe that they will find more or more lucrative work. When the major consulting firms start accumulating and marketing business rules skills, this market will have arrived, whether or not consolidation has run to completion. Expect this to occur as Oracle and SAP roll out their rules capabilities. For Oracle, who is ahead by a year or two, expect this momentum to build out of the public sector.

I agree with Gartner that this will initially play out in Haley’s favor due to Siebel:

RuleBurst and Haley Systems have strong, strategic relationships with large ERP providers (SAP and Oracle/Siebel respectively). Their combined forces will bolster these lucrative partner channels.

Broader momentum will accumulate as Oracle matures rules within Fusion and SAP introduces Yasu to NetWeaver, but then the channel conflicts will play against Ruleburst, as Forrester points out:

SAP already has OEM relationships with two other business rules vendors — ILog and Ruleburst. Likewise, Yasu has OEM relationships with Sun Microsystems, Versata. and Savvion. Customers will have to watch to see what becomes of those relationships.

Expect large SIs to establish a talent draw to serve the Oracle and SAP markets that will develop the talent pool more aggressively by 2009.

Gartner and Forrester agree that the major vendors and customers are demanding this technology and IDC goes further in predicting:

Advances elsewhere in the application development and deployment markets are helping set the stage for even higher BRMS growth as the industry retools its approach to application development around deployment, support of standards, ease of construction, maintainability, and extensibility. Business rules engines are expected to become key development elements of the application infrastructure stack.

In the meantime, secure your consultants for 2008 early!

In addition to consolidation and talent concerns, adopters of business rules technology are (and should be) reasonably concerned with the stability not only of the tools but of the technology. This is also reflected in Gartner’s “volatile technology” comment above. It is also demonstrated in dialogue among knowledge bloggers.^[7][8]

Customers of Haley or Yasu are obviously concerned with future support. These concerns are further exacerbated by comments from Gartner:

RuleBurst has indicated that it will support both products; however, we believe this is only logical as a short-term strategy and expect RuleBurst to move toward a single composite offering. RuleBurst wants and needs Haley Systems’ natural-language technology prowess and market presence, but we believe the most valuable opportunity of the combined entity will come from leveraging RuleBurst’s background in compliance and governance and seeking “can’t live without it” vertical domain relevance (for example, in financial services) through rule templates and frameworks.

RuleBurst remains in a consolidating market; it must quickly articulate a strategy for relevance that extends beyond rule technology.

And from Forrester:

SAP doesn’t sell software for .NET, so does that version go away?

Only SAP knows, but I doubt Yasu will survive in any standalone capacity. The stated objectives are aimed at embedding the technology in NetWeaver.^[9]

Given the synergies already discussed between Haley and Ruleburst discussed elsewhere here and with colleagues^[10], it is absolutely clear that their products will converge. Expect Haley to lag while advancing Ruleburst in 2008. This is also consistent with Gartner’s analysis and Ruleburst’s published comments emphasizing vertical solutions more than technical advances.

Gartner is justified in advising clients to choose their vendors carefully and to anticipate further turmoil. Rather than advise clients to beware high RO and strategic technology adoption, we encourage them to minimize vendor lock-in.

In my most recent post to this blog I suggested the most critical step in avoiding vendor lock-in:

Manage business rules as content that is as independent of implementation details as practical.

As business requirements, regulations and policies are reduced to the level of Yasu rules, for example, they become less portable and vendor or technical turmoil becomes more costly and painful. If you adopt a less knowledge-centric tool, you should at least examine the production rule representation standard^[11]. Porting Yasu to Ilog may be your best – albeit more expensive – option.^[12]

In addition to managing business knowledge not as rules but as content, consider third party technologies, especially standards concerning semantic ontologies^[13] and business vocabularies^[14].

For those using Haley, the management of rules as knowledge content and its separation from implementation details is fairly developed. Take a careful look at how content can be exported to XML^[15]

For those using or considering other vendors, including Oracle’s Fusion, be sure to consider whether knowledge captured can be extracted as in something like KML or any standard, such as OWL, SBVR or, if nothing more, PRR (reference below).

^[1] RuleBurst’s Haley buy will further consolidate BRE sector

^[2] Is SAP-Yasu the start of business rules management consolidation?

^[3] Ibid.

^[4] as quoted in this Ilog press release

^[5] Semantic Standards for Agility

^[6] Worldwide Business Rules Management Systems 2007-2011 Forecast and 2006 Vendor Shares

^[7] See comments to Consolidation Hits the Business Rules Market.

^[8] See comments to More thoughts on RuleBurst and Haley.

^[9] SAP buys BPM vendor to boost NetWeaver

^[10] See comments to More thoughts on RuleBurst and Haley.

^[11] Production Rule Representation (PRR) from OMG

^[12] Implementing two business rule languages using Eclipse and Ilog’s support for PRR

^[13] Web Ontology Language (OWL) from W3C

^[14] Semantics of Business Vocabulary and Rules(SBVR) from OMG

^[15] Knowledge Management Language (KML)

1. Accumulate requisite skills for productive success.
2. Establish methodologies for productive, reliable and repeatable success.
3. Accumulate and reuse content (e.g., definitions, requirements, regulations, and policies) across implementations, departments or divisions.
4. Establish multiple tutorial and reusable reference implementations, including application development, tooling, and integration aspects.
5. Establish centralized or transferable infrastructure, including architectural aspects, tools and repositories that reflect and support established methodologies, reusable content, and reference implementations.
6. Establish criteria, best practices and rationale for various administrative matters, especially change management concerning the life cycles of content (e.g., regulations or policies) and applications (e.g., releases and patches).

I was quickly surprised to find myself struggling to write down recommendations for the skill set required to seed the core staff.  My recommendations were less technical than the client may have expected.   After further consideration, it became clear than any discrepancy in expectations arose from differences in our unvoiced strategic assumptions.  Objectives, such as those listed above, are no substitute for a clearly articulated mission and strategy.  

Some organizations still use rule engines solely as a means of interpreting externalized technical rules so that the behavior applications can change without recompiling or re-linking code or re-booting systems. Generally, anyone using CLIPS, JESS, or Oracle (i.e., as in Fusion or in the database but excluding Siebel) is in this camp, as is anyone using Prolog, RuleML or any of the semantic web rule languages. The same is true for the OMG’s Production Rule Representation (PRR) and will be true for W3C’s Rule Interchange Format (RIF).

Most organizations now adopt rules with a less technical but more business-oriented perspective. They place greater emphasis on the capture and management of business rules by less technical users. Organizations in this camp have inevitably selected one of the commercial vendors of business rules managements systems (BRMS), including Ilog, Fair Isaac’s Blaze Advisor, Haley / Ruleburst / Siebel, Yasu / SAP, Corticon, or Inrule.

The market for rule engines is similar to the market for SQL or Java. It is quite mature. The market for business rule management systems is now in the mainstream. It ranges from early to later majority, depending on the industry and application. Decision-intensive industries tend to be more mature, with more complex areas, such as commercial loans or insurance being less developed than conforming mortgages or personal lines.

As the following graphical summary of Moore’s Crossing the Chasm indicates, people now adopting rules technology for the first time are laggards while those adopting BRMS are pragmatists or conservatives, but not innovators or visionaries. That is, they are driven by tactical needs rather than strategic thinking.

 Our advice concerning skill acquisition and development differs significantly based on my clients’ mix of tactical and strategic objectives. More strategic clients emphasize objectives such as:

1. reducing the effort involved in translating definitions, requirements, regulations and policies as they are understood by the business into technical specifications
2. minimizing the critical path between identifying and deploying dynamic requirements, regulations or policies by eliminating pre-requisites, such as:
3. minimize the impact of change by managing the definitions of vocabulary used in requirements, regulations and policies and how they relates to various implementations in a loosely-coupled manner
4. minimize analytic translation into “if-then” rules from definitions, requirements, regulations and policies as they are naturally provided, expressed, or captured

In other words, more strategic organizations place greater emphasis on the separation of the capture and management of knowledge from its implementation or use at run-time.[1] The merit of such strategies are reflected in the increasing use of words like “semantics”, “vocabulary”, and “ontology” by vendors, analysts, customers and standards bodies, as well as continuing investment in increasingly natural rule languages by vendors.

Continuing improvements in natural language understanding will maximize the benefits of knowledge management and facilitate further use beyond technical staff by achieving these strategic objectives. Additional metaphors, such as decision trees or tables, spreadsheets or form-based templates are also useful, of course, but they are inherently less agile, require more setup and impose limits on either the user community or system functionality or both. Interestingly, to the extent that mixed metaphors are appropriate, users interpret each of them using natural language! That is, they “read” structured expressions, such as decision tables, as sentences.

For the simple reason that people already communicate and understand using their own natural language which can easily express any statement (e.g., of policy), the ability to elicit or harvest and manage unambiguous, grammatical sentences is among the principal skill requirements for staff in a center of excellence.

Proficient ability to elicit sentences requires certain strong oral communication and interpersonal skills. In addition, written communication skills are also critical in order to validate elicited understanding with the source or other parties. The reduction of elicited or harvested knowledge to writing is obviously necessary and critical if that knowledge is to be shared and managed over time.

The closer captured knowledge is to sentences the easier it will be to automate. Content that cannot be reduced from a paragraph to independent sentences requires more effort. Any interdependency among sentences in a paragraph or any context to a paragraph must be made explicit in order to automate (i.e., implement) the paragraph. Fortunately, most of this structure corresponds to the flowchart typically captured using business process management (BPM) tools.

A skilled member of the center of excellence staff should therefore also be able to capture and confirm business processes. Any programmatic tendencies should be suppressed, however. The essential objective is to find truth rather than to invent flows. Also, from a knowledge management perspective, confirming a complex business process is impractical. Furthermore, perhaps paradoxically, a business process with a complex flow chart is most likely poorly understood. Apparently complex business processes typically result from failing to isolate the statements that govern decisions and actions from the process flow. This is precisely the benefit of externalizing rules and it is these externalized, natural language statements that we aim to manage as knowledge.

The deep objective of staff should be to uncover truth more than flow. This should be reflected in their skill set. Mathematicians and philosophers are ideal candidates in that they are highly trained in seeking and contemplating the implications of truth. The same holds for pure scientists in mathematically rigorous fields, such as physicists. Each of these disciplines emphasizes truth without emphasizing process. Communication skills may be a challenge in some cases, but not typically with philosophers since they use natural language intensively. Lewis Carroll would probably excel as a “knowledge engineer”! Regrettably, computer scientists tend to pursue sequence more than truth. This is especially true for programmers but less so for data modelers or theoreticians.

In order to introduce rules engines into the enterprise architecture, the center of excellence will certainly need programmers, but the level of effort required is measured in man months, not years. It takes very little coding to integrate a rules engine. Once the engine is integrated the change should be external (i.e., to the rules). On the other hand, if a rules engine is being used without a BRMS then programming skill will be needed to codify the rules themselves. In this case you should consider the use of a tool like RuleTrack to capture, formalize and manage the relevant knowledge. We agree with RuleXpress that neither Word nor Excel support the work effectively.

Consultants are particularly effective for such work. Since you don’t need programming skill full-time, year-round, why not let a consultant accept responsibility? Certainly they should be productive! And if you are manually translating managed knowledge into technical rules, consultants should offer predictable costs and responsiveness with extremely low risk or variability. A consultant should be willing, for example, to give a fixed price and timeframe for translating a collection of grammatical sentences that use a defined vocabulary which maps to an object or data model in technical rules. In the limit, the billed time per rule might not exceed 15 minutes but should not exceed an hour in any case. Whether consultants or staff, you might require at least two such people available full-time in order to handle any crisis with some redundancy.

Once again the key skill to be developed and retained in the center for excellence is the interpersonal and communication skills to clarify knowledge and establish consensus where appropriate. In addition to the innate pursuit of knowledge and truth, the skill of listening is critical to elicitation. If rules are to be harvested rather than elicited, listening may seem less important at first, but clarifying conversations with stakeholders and subject matter experts are inevitable. Whether elicited or harvested, it is critical to validate knowledge by confirming its ramifications.

The validation of knowledge usually proceeds through several phases. As knowledge is being acquired, ramifications are derived by mental inference and considered. Such ramifications often lead to inconsistency, usually as a result of imperfect knowledge (i.e., a misunderstanding). As scenarios are considered and the body of acquired knowledge grows and matures, scenarios may naturally become more detailed “use cases” for application development. Eventually, as many scenarios of varying detail accumulate, they may become a substantial body of test cases and be used within a technical architecture to test versions of knowledge bases, such as before releasing them into production.

Scenarios can be extremely useful in acquiring knowledge, whether by clarifying the ramifications of policy among stakeholders or extracting further knowledge from subject matter experts through protocol analysis. The mental skill of simulation, the ability to recognize inconsistencies, and the social skill to discuss ramifications in hypothetical scenarios productively are all important. In addition to listening, one of the key social graces required to elicit and validate knowledge is considerate patience. It is all too easy (and common) for those eliciting or clarifying knowledge, like children, to impetuously ask “why”. Finally, it is important to remain dispassionate. It is also too easy to become confident in one’s accumulating knowledge to the point of professing as an expert or out of insecurity when stakeholders’ or subject matter experts’ questions should indicate missing knowledge or a misunderstanding.

Now, finally, I can summarize the characteristics that my experience indicates are most important for success – and, therefore, development within a center of excellence:

1. a controlled passion for knowledge and truth
2. extraordinary attentiveness and listening skills
3. excellent oral and written communication skills
4. powerful mental simulation and problem solving skills
5. a mature and secure sense of self, especially when incorrect or not in authority
6. the absence of tendency to see the world from the perspective of a tool or technique, especially procedurally but not strictly in terms of rules, either

Of course, there are specific skills aside from personal traits, many of them somewhat obvious. Experience documenting requirements, regulations, and policies with subject matter experts or stakeholders is great but it is much better if that experience includes personally and iteratively reviewing the resulting documents with them. Experience defining data models and class taxonomies is also helpful in defining and managing vocabulary and ontologies, but care should be taken to avoid technologist who place too much emphasis on any one technical perspective, whether process centric, object- or service-oriented or rule-based. Experience with the rule engine or language to be used is clearly nice to have, but it is not needed in large quantities. The same is true for any particular BRMS.

Additional skill requirements arise from tool limitations. For example, requirements often use the modal verbs “must” or “shall”. No BRMS currently supports automating such statements. In addition, I know of only one BRMS that supports statements that use the word “unless”, which is also quite natural and common in my experience. There are also few rule engines that can compute quantifiers such as “only”, aggregates such as “average”, or superlatives such as “minimum” or “most recent”.

Each of these limitations requires manual translation from the more naturally acquired and managed form. Most systems, for example, will require sentences that negative disjunctions (e.g., use the word “neither”) or that have exceptions (e.g., use the word “unless”) to be converted into a collection of if-then rules, as in disjunctive normal form (DNF). For practical reasons, therefore, the staff should be familiar with formal logic, especially first-order logic (i.e., predicate calculus) and relational algebra (as in SQL).

The only thing remaining is to map business vocabulary to implementation details.  Such tasks require an analytically skilled member of the technical staff who is comfortable relating object or data models to definitions of business vocabulary, such as an enterprise architect.  Such tasks may involve defining a model to be used internally by a rule engine in addition to mapping to services or models that exist in the enterprise infrastructure.  This activity is evolutionary and low bandwidth except when first mapping a vocabulary to an implementation or when a technical model is substantially revised.