Skip to main content

Ten Truths of Business Rule Complexity




In order to automate business processes, you need to understand the underlying business rules of your organization.  Analysis of business rules is time consuming, and complex business rules add to the time and expense of software development.

Based on my experience in developing business solutions, I would like to offer the following observations to help organizations understand how business rule complexity affects them.
  1. If you think your business rule is simple, you are not thinking hard enough.  Many business rules seem simple but turn out to be complex on closer examination.  For instance, you may have a rule that a contact person may be listed only once in your Customer Relationship Management (CRM) system.  If each contact may be associated with only one account (or company) record, what can you do when a person acts in a different role for different organizations.  For instance, I can be listed as a customer of the phone company as the primary contact for my company as well as for my home phone number.  Even something that seems simple such as a company name or DUNS number can be complicated.  Some companies have one or more DBA names as well as official company names. A large company can have multiple DUNS numbers and it would not be obvious which is the correct one. 
  2. Automation involves simplification. If you built a model of the world which faithfully represented all the complexity of the world, you would have created another world as complex as the one you were modeling.  One of the purposes of a model is to simplify.  The trick is to find out which simplifications produce business benefits and which ones are not possible.
  3. Complexity alone does not determine the level of effort for automating a business rule. Some complex business rules are simple to implement and some simple business rules are hard to implement.  A complex business rule which operates on easily determined and unambiguous data can a quick programming task, while "fuzzy" logic in a business rule can be challenging to automate. 
  4. Counting the number of business rules does not directly yield a cost estimate. This is a corollary of the previous point.  Neither the number nor complexity of business rules are the sole determinants of cost.  
  5. Look out for exceptions. It's not the rules that will cause the greatest problems, it's the exceptions.  In many cases, you don't find out the exceptions until it's too late, when users are testing a new system.
  6. Words are important in defining business rules. Like law, business requirements analysis requires strict attention to linguistic details.  People at your organization may use different words to refer to the same thing, causing confusion and ambiguity in your system.  You may need to create a glossary and conduct training for users to understand the meaning of business terms terms such as account, contact prospect, customer, lead, order, purchase order, and quote. Most businesses have their own terms of art and acronyms which are important for their business rules.
  7. There is no limit to business analysis.  Unless you constrain business analysis by time or budget, you could keep going on virtually forever documenting requirements and processes without embarking on building your system.  Try to avoid analysis paralysis. 
  8. There is no pleasing everyone. Documenting business processes will highlight divergences and disagreements among people who perform their jobs in different ways.  This process may help foster greater consistency but it also may raise debates and power struggles in order to reach a consensus. 
  9. Consider an iterative approach. Automated systems and business rules affect one another, and changing one will affect the other.  You may be disappointed with the results if you try to complete your business process re-engineering in one iteration, because you may not be able to predict all the impacts of your changes in how people work.  If you allow for feedback and multiple iterations, you are like to arrive at a better solution in the long run.  
  10. Some processes should not be automated. The most common goals for automation are to improve productivity and reduce errors.  Some business processes may have so many exceptions that they are no longer fruitful to automate.  Leave room for human judgment in your automation if you are having trouble forcing the software to make all the decisions. The most successful systems use computing where it works best and trust humans in the scenarios where they can contribute most. 
In short, understanding business rules is essential to most business software development projects. Implementing new software is an excellent opportunity for business process engineering. By keeping tradeoffs around complexity in mind you can arrive at a more successful implementation and a better performing organization. 

Popular posts from this blog

Power Apps Portal: The Successor to Microsoft Dynamics Portal

In case you have been reviewing Microsoft's new pricing for its Dynamics products which was released this month and have been unable to find Dynamics Portal, it has been rebranded as PowerApps Portal and shifted to the PowerApps side of the Microsoft product family.


Rebranding the portal product underscores the importance of app scenarios involving external users such as customers and suppliers.  It also provides a simpler interface than Dynamics 365 for occasional users.

The new portal pricing is based on the number of unique users who log into the portal each month (for authenticated users) and on the number of page views for anonymous users.  "A login provides an external authenticated user access to a single portal for up to 24 hours. Multiple logins during the 24-hour period count as 1 billable login. Internal users can be licensed either by the PowerApps per app or per users plans, or a qualifying Dynamics 365 subscription."

Pricing starts at $200/mo. for 100 dail…

5 Best Things about the Unified Interface for Microsoft Dynamics 365

The latest version of Microsoft Dynamics 365 moves most of the core functionality of sales and customer service to a new user interface - The Unified Interface client.  This user interface is not completely new as it was gradually introduced for the Hub features such as the Customer Service Hub in recent versions of the product.

The new interface is quite different from the previous interface which was used from Dynamics CRM 2013 to 2018 with a few incremental changes. 

This is the Unified Interface, using a form from InfoStrat's Grants Manager Plus Solution.



Here is the same record shown in the previous interface which Microsoft calls Classic.



Here are the top 5 features that I like best about the Unified Interface:

Better menus and navigation. The sitemap on the left is more helpful than the classic menus for larger, more complex solution. Lefthand menu shortcuts are a great use of space and help users access the most popular areas. Better subgrids.  Subgrids are important for en…

ScreenMeet Remote Support Tool for Dynamics 365 Customer Service

I met Lou Guercia when he was president and CEO of Scribe Software, the leading CRM integration tool.  Scribe was acquired by TIBCO Software in 2018.  I recently reconnected with Lou and learned about ScreenMeet, the company he joined as chief operating officer.   The following is a description of the product provided by ScreenMeet:

ScreenMeet is a cloud-based remote support tool designed to integrate with Dynamics 365 Customer Service. By enabling customer service and IT support organizations to address critical technical issues directly from their CRM or ticketing platform, it streamlines the process and provides a fully browser-based support experience.

You can also use ScreenMeet with other CRM products or even on its own without a CRM.

Here is a short video demo of ScreenMeet with Dynamics integration:


ScreenMeet - Cloud-based Remote Support Integrated with Dynamics 365 Customer Support Once integrated with a Dynamics 365 CS organization, the ScreenMeet widget appears on Case pa…