MMG Insurance is a premier regional property/casualty company, with an A (Excellent) financial strength rating from A.M. Best.  We proudly partner with more than 2,500 licensed Independent Agents in over 400 agency locations throughout Maine, New Hampshire, Vermont, Pennsylvania, and Virginia to offer exceptional service to our customers.  MMG is headquartered in Presque Isle, Maine, with regional offices in Concord, New Hampshire and Allentown, Pennsylvania.  Our commitment to technology is a key part of our high-tech/high-touch business model and is an integral support to our nationally-recognized ease-of-doing-business and exceptional-customer-service initiatives.

MMG adopted a business rules approach in an Enterprise Architecture environment in 2010.  Two important factors in this decision were the goal of improving business agility and the goal of developing a common language and understanding between business domains and information systems.  Our approach to standards and patterns has been a critical piece of this approach.

The Motivation for Standards

We sometimes get a few funny looks when talking about standards and business agility at the same time.  If this seems counter-intuitive, perhaps a quick look at the motivation for standards will help.  We have found that standards are a key enabler of business agility for the following reasons.

Accountability and Ownership.

When accountability and ownership are clear, decisions are made faster.  We use standards to help ensure that accountability and ownership are clear.  Accountability and ownership are key enablers for our goal of engaging the right people at the right time.  When accountability and ownership are not clear, we witness one of two ineffective approaches.

1. Involve absolutely everyone who might have knowledge. 
   This approach ensures the necessary people are somewhere in the group.  However, all the additional input invariably leads to confusion and slows down decision making.
   
   
2. Move along with a minimal set of decision makers. 
   In this approach, key stakeholders are often missed.  This results in late feedback and often in rework.  It also sets up a group for more difficult stakeholder interactions if the stakeholders feel they were circumvented.

When a group is clear about accountability and ownership, they can quickly make the decisions they are empowered to make, and engage stakeholders at the right time.  Stakeholders may feel their time is being used wisely when only the decisions they need to be a part of are brought to them.  The team may feel more empowered to make certain decisions, and clarity helps establish confidence.

Communication.

Meaningful communication about business rules — or any important business topic — occurs when different groups have a shared understanding of business rules and concepts.  We use standards as an enabler for meaningful communication.  We recognize that meaningful communication is difficult to achieve.  Unfortunately, a typical view of communication and what we aim to achieve through meaningful communication are often very different things.  In a typical communication in which someone expresses "I understand what you mean", they often mean this:

I listened to what you just said.  I have interpreted what you just said, using my own glossary of definitions for the words you used.  Additionally, I have used my unique cultural background and past experiences to filter what you have said and make it meaningful to me.  I have also filtered what you said to apply meaning based on how I envision what you said being relevant to me in the business context I am familiar with.

The one thing that we can be fairly certain of is that the other person has interpreted what you said differently.  Therefore, standards are necessary to enable meaningful communication. 

A structured business vocabulary that is clear and accessible to all parties is a necessary building block for meaningful communication.  This vocabulary must be clear of technical jargon that alienates business consumers.  Motivation, comments, and examples are also key components to add clarity to a structured business vocabulary.

Corporate Memory.

We sometimes struggle to fully anticipate the needs of the future decision makers of our business capabilities.  Which rules do they need easy access to, and which rules are acceptable if we have to engage developers and SMEs to re-discover?  These questions aren't always easy to answer.  However, knowing what needs to be available to the people who will operate, maintain, and make future business decisions about business capabilities is a critical component in identifying the needs of all stakeholders. 

When these needs are identified, additional care must be applied in ensuring durability of communication for these stakeholders.  In the midst of a project, context is often well known.  When someone needs to know information a year after the project is over, context may not be as readily apparent.  Standards are a key component in ensuring durability of communication for stakeholders who need access to corporate memory over longer periods of time.

Retrospectives and Iterative Improvement.

Standards give teams concrete discussion points concerning what's working and what could be better.  If a technique is working and we want to aggressively repeat that technique, making a standard helps create clarity and visibility.  Standards that aren't working are easy for teams to spot and change in retrospective meetings.

There are additional reasons that standards are important, but hopefully some of the major reasons to consider standards as an enabler of business agility have been clarified.  We'd like to share some of our standards in the areas of rule statements and governance.  We do not believe these standards are appropriate for every organization.  Each organization is unique.  Hopefully these standards will provide a point of comparison for your own standards or even identify an area in which you may be wishing to develop standards for your organization.

The Importance of a Shared Understanding

Before discussing our cornerstone business rule standard, it's important to have a shared understanding of the value of a common language.  The assumption that people speak the same language is pretty common.  We have used the following test in multiple scenarios and have yet to find a case where everyone had a common understanding.  It has even held true in several rooms full of insurance professionals where there is a vested interest in a common understanding.

Without reading ahead, take a minute to write down your definition of a 'vehicle'.  Then, for each of the pictures below, decide if it should be considered a 'vehicle' according to your definition.

In a room full of people, it's amazing to view the different perceptions for each of these possible instances.  By the time we ask for feedback on the golf cart, we consistently see that differences in definitions emerge.  For a point of comparison, our definition of 'vehicle' is "a manufactured carrier of goods or passengers."

It's common to assume we conceptualize things the same way but, unfortunately, this simply isn't true.  The assumption that we walk around with the same inherent understanding of what things are is dangerous.  It might sometimes be true, but it will inevitably lead to misunderstandings and lack of clarity on important concepts and business rules.  In recognition of the need for clarity, our cornerstone business rule standard is:

Business Rules must be based on a structured business vocabulary.

We use concept modeling to create our structured business vocabulary.  There are other methodologies that can be used to achieve the same result.  The particular methodology employed is not the most crucial aspect in our opinion.  We believe the crucial aspects are that organizations recognize the value of a defined, structured business vocabulary and have a methodology to create and maintain this in a consistent manner.  Here's a small snippet of a concept model we use that is relevant to the vehicle example above.

Figure 1.  Concept Model Snippet from the Vehicle Example  

We base many of our business rule standards on RuleSpeak^[1] and, more specifically, SBVR (Semantics of Business Vocabulary and Business Rules).^[2]  A lot of really smart people have done really good thinking in this area.  Whether you choose to utilize these standards or others, it's good to know what's available and build from there.

One of the reasons we chose SBVR is that it conforms most closely with how our business rules are naturally conveyed by our SMEs.  We have considered "if, then" syntax and BDD (Behavior Driven Development) style "given, when, then" syntax, but SBVR seems to be the most natural fit for business rule statements.  Additionally, our general rulebook system, RuleXpress, has built-in support for SBVR patterns.  This provides us with an easy and automated approach to governance.  We strive to use these standards and patterns to promote clarity and consistency.  However, we don't force a statement into a pattern if doing so will make it unclear to the business consumers.  If there is competition between the pattern and clarity, clarity wins.

Some Patterns Used in Business Rule Statements

So without further ado, here are some of the patterns we use in our business rule statements.

Derived Calculations.  Used to specify a term that must be calculated in a certain way.

Construct as:  term + "must be computed as" + calculation formula.

Example:

Numeric Comparisons.  Used to specify how a term must relate to some threshold or some other term.

Construct as:  term + comparison phrase + threshold or term.

Example:

Use of a Decision Table.  Used to specify that a decision table is used as a reference for the rule.

Construct as:  term + "must be as in 'x' table" + additional rule statement parts.

Example:

Considerations.  Used to specify considerations for a business rule.  When a decision table is used, the considerations specify the information that must be provided in order to get a unique answer from the decision table.

Construct as:  term + "for a given x, y" + additional rule statement parts.

Example:

Scope.  Used to specify business rule scope.

Construct as:  term + additional rule statement parts + "if" + scoping statement.

Example:

Single Instance of Reference Data.  Used to specify that a term must be a specific value and that no inputs are necessary to determine this single value.

Construct as:  term + "must be" + value.

Example:

Multiplicity.  Used to specify a certain number of a concept that another concept must have.

Construct as:  term + multiplicity comparison + term.

Example:

Identified Using.  Used to specify that a concept must be able to be uniquely identified by a concept or set of concepts.

Construct as term + "must be identified by" + term.  Alternatively, to construct with focus on the identifier, term + "must identify" + term.

Example:

Permissive Restriction.  Used to specify that something is only allowed in certain circumstances.

Construct as:  term + "may" + condition + "only if" + condition.

Example:

Some Anti-Patterns

In addition to the patterns above, there are several standards we attempt to follow in order to keep business rules clear, simple, and decoupled.  We drew inspiration for these standards from The Business Rules Manifesto.^[3]  The principle we follow is that each business rule should be a fully-formed atomic statement. 

Our standards help us identify some anti-patterns, where we could keep things clean, simple, and decoupled when we know what patterns we wish to avoid.  Two of our most common anti-patterns are as follows:

Don't couple 2 business rules together.

Coupled:

• A vehicle must have exactly one VIN if it is a private passenger vehicle; otherwise a serial number.

Uncoupled:

• A private passenger vehicle must have exactly one VIN.
• A vehicle must have exactly one serial number if it is not a private passenger vehicle.

Enforcement actions should be their own business rule.

Coupled:

• If a vehicle does not have a vehicle model year, a message must indicate a vehicle model year is required.

Separate enforcement action:

• A vehicle must have exactly one vehicle model year.

Upon violation of this rule, a separate business rule –

• A message must indicate a vehicle model year is required.

Since we have a common need to respond to a business rule violation with some form of communication, we handle these common responses with a business rule violation message property in our general rulebook, RuleXpress.  In the example above, we'd capture the message language "A vehicle year is required." in the violation message property.  

Decoupling an enforcement action from the business rule that is violated provides a lot of extra flexibility.  What if we don't want to respond to all violations the same way?  For example, do we want to respond differently to someone who has violated the business rule three times instead of just once?  The base rule will stay the same, but the enforcement actions may vary.

General Standards Applied in the Area of Governance

In addition to the specific business rule standards above, we have some general standards that we apply in the area of governance.  These standards apply specifically to the business rules and terms that have a stakeholder need to be captured long term as part of our corporate memory.  Business rules that meet these criteria are defined using enterprise class terminology.  This means that the terminology and verb concepts used to construct the business rules have been agreed upon by all business domains and there is a single, clear definition that is understood across the enterprise. 

These business rules are captured in our general rulebook and published so that they are easily available to any consumer.  So our cornerstone standard here is:

Business rules that are crucial to our corporate memory must be defined using enterprise terminology and stored in a general rulebook.

With this building block in mind, here are some of the standards we apply to promote clarity and consistency in our general rulebook:

Capture comments, motivation, and examples.

Usage:  All of these elements are crucial to a common understanding of terms and business rules.  Sometimes, knowing how you arrived at an agreed understanding adds more clarity than the final business rule or definition.  Examples are a critical element for a rapid understanding of terms and business rules.

Example:

Capture business domain ownership.

Usage:  Each of our terms and business rules is owned by a business domain.  Capturing this ownership helps consumers understand who they need to speak to if they have questions about impacts when changes are being considered.  It clarifies accountability.

Capture SMEs.

Usage:  SMEs (Subject Matter Experts) are captured for each term and business rule.  Knowing who was involved in the original discussion is often useful when future questions arise, or if a consumer discovers they need additional clarity.

Conduct business architecture peer reviews.

Business architecture, including terms and business rules, is peer reviewed.  A business analyst peer reviews another business analyst's work.^[4]  We have found that this process adds value in the following four ways:

• Catch your own mistakes: 
  By describing our own work to someone else, we often catch our own errors.  The act of describing the work creates an opportunity to self-identify and correct any items that need improvement.
  
  
• Create a learning opportunity: 
  A learning opportunity can be created for both the analyst describing the work and for the analyst doing the peer review.  Each person gets an opportunity to hear how another person approaches the work, and incorporate this into their own approach when it adds value.
  
  
• Identify and evolve standards: 
  When analysts realize we have a common, repeating need that is being addressed in disparate manners, we can discuss if business value would be created by having a standard to address the need in a consistent manner.  If we have standards that are no longer working or need to change, these can be identified in a similar way.  Regular discussions about how our approach could deliver additional business value help us evolve.
  
  
• Ensure standards adherence: 
  A peer review helps to ensure that the standards we have agreed upon are actually followed.  A simple question like "Did we consider this?" usually does the trick.  Extra care needs to be exercised in this area to ensure that communication is friendly and helpful.  In order to achieve the desired benefits, the peer reviews need to be viewed by participants as a valuable learning opportunity that helps provide stakeholders business value.

In Conclusion

Hopefully some of these examples have shed light on areas we have found of value.  This is not an exhaustive list, but it covers many of our most important standards.  We attempt to keep a small number of standards that are high value.  If they cannot be easily remembered and applied, they won't have the desired impact.  We have found that using a few standards effectively improves clarity and business agility.  They are a critical component of our business rule approach.

References

[1]  www.RuleSpeak.com  

[2]  www.omg.org/spec/SBVR/1.1/  

[3]  www.businessrulesgroup.org/brmanifesto.htm  

[4]  Please note that our definition of 'business analyst' is anyone who does business analysis, regardless of role or title.  

# # #