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, http://www.brsolutions.com/bbs
The instances of many operational business things have a life in that they can reach milestones or change states in some manner important to the business. Business rules offer a powerful tool for practitioners to understand and orchestrate business things with life – for examples, cases. Pattern questions pertaining to business models of milestones or states assist not only in capturing related business rules, but also in discussing and resolving related business issues with business stakeholders. This discussion presents a targeted set of pattern questions to assist in that regard and illustrates them with practical examples.
When an operational business event happens in day-to-day business activity, an instance of an operational business thing – for example a case – 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 rules1 can be captured from business milestone (or state) models using the pattern questions presented and illustrated below.
- Any business rule that must be satisfied for an instance of an operational business thing – for example a case – 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 that 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.
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.
- 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 path (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 11-2 serves to illustrate additional pattern questions useful in capturing business rules from business milestone models.
- 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!
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.
- 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.
2The 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.