Excerpted with permission from Building Business Solutions:  Business Analysis with Business Rules (2nd Ed.), by Ronald G. Ross with Gladys S.W. Lam, Business Rule Solutions, LLC, 2015, 308 pp.  URL:.  http://www.brsolutions.com/bbs

When an operational business event happens in day-to-day business activity, an instance of an operational business thing can enter a new state.  We call the initial point in that state a business milestone.  Achieving a business milestone means that every relevant business rule has just then been satisfied for that instance.  Many business rules^[1] can be captured from business milestone (or state) models using the pattern questions presented and illustrated below.

Pattern Question for Milestone Imperatives

Pattern Question M1:  Milestone Imperatives
	What criteria must be met for an instance of an operational business thing to achieve a business milestone?
Ask specifically:
	What criteria must be met for an order to be deemed credit-checked?  What criteria must be met for an order to be deemed shipped?
Sample business rule specifying a milestone imperative:
	A credit-checked order must be verified by at least 3 references.
Sample business rule specifying a milestone imperative:
	A shipped order must be assigned to a carrier.

Comments: 

• Any business rule that must be satisfied for an instance of an operational business thing to achieve a business milestone is called a milestone imperative.  This first pattern question is basic to externalizing business rules from business process models in an organized and intelligible way.


• If a milestone imperative is meant to be applied only when a business milestone is first achieved, not continuously thereafter for the state, the business rule must be written that way.  Event-specific applicability is never the default.  In RuleSpeak®, the keyword when is used for that purpose.  Example:  Suppose the business intends the first business rule above to be applied only at the business milestone, not thereafter.  In that case the business rule should be written:  A credit-checked order must be verified by at least 3 references when the order is credit-checked.


• Models of business milestones or states can take a variety of forms. In Figure 1, states are represented in a concept model using unary verb concepts.^[2]  The associated state names (e.g., credit-checked order, shipped order, etc.) can be used directly in capturing milestone imperatives.


• Only the happy life of order is represented in Figure 1. (A happy life is a life consisting of states through which instances progress and complete successfully from the business's point of view.)  Each state is dependent on the previous state having been achieved.  An implication is that any business rule that applies to credit-checked orders also applies to filled orders, shipped orders, etc.  A business rule should be associated with the first (earliest) state in the happy life to which the business rule applies.

Pattern Question for Spontaneous Behavior

Pattern Question M2:  Spontaneous Behavior
	Does satisfying some criteria enable an instance of an operational business thing to achieve a new business milestone spontaneously?
Ask specifically:
	If the right circumstances arise, is an order immediately deemed completed?
Sample business rule specifying spontaneous behavior:
	A shipped order paid-in-full must be considered completed.

Comment:  The business milestone completed is spontaneously achieved if an order is both shipped and paid-in-full.  Whether an order is paid-in-full might be derived by a set of computational business rules.  Be careful about conflicts that might arise if other business rules (milestone imperatives) pertaining to invoiced and completed orders are not satisfied.

Pattern Question for Suspense Criteria

Pattern Question M3:  Suspense Criteria
	Is there a time limit for how long an instance of an operational business thing can remain in the same state?
Ask specifically:
	How long can an order be shipped without being invoiced?
Sample business rule specifying a suspense criterion:
	An order may be shipped but not invoiced at most for only a week.

Comments: 

• Sometimes an instance of an operational business thing gets hung up at a state.  A business rule specifying a suspense criterion indicates how long is too long for the business to stand idly by (i.e., tolerate the instance remaining there).


• If a suspense criterion involves a happy life (as above), two states are usually referenced (e.g., shipped and invoiced), not just one.  Caution should be exercised in specifying a suspense criterion that references just one state.  The business often needs to talk about, or to write business rules about, whatever it is that hasn't been accomplished.

Figure 2 serves to illustrate additional pattern questions useful in capturing business rules from business milestone models.

Pattern Question for Prohibited Antecedents

Pattern Question M4:  Prohibited Antecedents
	Does achieving a business milestone require that some other state(s) not be achieved?  Does achieving a business milestone preclude some other state(s) from being achieved?
Ask specifically:
	Is there a state that precludes an order from being cancelled?
Sample business rule specifying a prohibited antecedent:
	A cancelled order must not have been shipped.

Comments: 

• The state shipped must not be antecedent to (have been achieved before) the business milestone cancelled for any given order.


• Severely unhappy states (such as cancelled) should be modeled outside the happy life.  Otherwise, anomalies (e.g., conflicts) among the business rules almost always result.


• Be sure not to embed constraints about prohibited antecedents in any business process model.  Such business rules apply to all business activity and, like all business rules, might change.  Single-source them!

Pattern Question for Interruptions in Life

Pattern Question M5:  Interruptions in Life
	Is achievement of a business milestone in a happy life precluded by some prior sub-state?
Ask specifically:
	Can an order be credit-checked if it is rejected?  Can an order be filled if it is back-ordered?
Sample business rule specifying an interruption in life:
	An order may be credit-checked only if not rejected.
Sample business rule specifying an interruption in life:
	An order may be filled only if not back-ordered.

Comment:  These business rules enforce possible interruptions in the life of individual orders.  An interruption in the life of an operational business thing is not permanent unless a business rule in its life pattern makes it so.  For example, unless specified otherwise, once an order is un-rejected it can then move forward.  Once an order is un-back-ordered it too can move forward.

Pattern Question for Afterlife

Pattern Question M6:  Afterlife
	Are there any time limits on how long an instance of an operational business thing must or must not be retained once some terminal business milestone is achieved?
Ask specifically:
	How long must a completed order be retained?
Sample business rule specifying a retention criterion:
	A completed order must be retained for 7 years.

Comments: 

• The business rule above is meant to ensure the business will not 'forget' about a completed order for at least 7 years.  The motivation might be that some external tax authority requires organizations to keep business records for at least that long.


• Be sure that the motivation for such a business rule arises from the business, and is not simply a choice made by IT in designing or optimizing a system.

Next month's discussion focuses on pattern questions specifically for organizations, including roles, responsibilities, interactions, and work products.

For further information, please visit BRSolutions.com     

References

[1]  All business rule statements in this discussion are expressed using RuleSpeak®.  The RuleSpeak guidelines for expressing business rules in structured natural language are free on www.RuleSpeak.com.  

[2]  The diagram snippets of concept models in this discussion follow the BRS ConceptSpeak™ conventions.  Refer to:  Business Rule Concepts, by Ronald G. Ross, 4th ed., 2013.  

# # #