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

Key Concepts for Microsoft Dynamics 365: Tenant, Instance, App and Solution

Updated 8/15/2022 To understand Microsoft Dynamics 365 (formerly Dynamics CRM) and Power Apps, you need to learn some new terms and concepts that may be a bit different from what you know from databases and solutions that are hosted on premises.  These concepts also apply to Power Apps.  The main difference is that with Power Apps you are not starting with a Microsoft app but more of a blank canvas for your custom apps.  This post introduces some key terms and how these concepts are important for planning your implementation. While Dynamics 365 is still available on premises, it is most commonly deployed on the Microsoft cloud.  This blog post discusses only cloud implementations. Microsoft has multiple clouds such as commercial and government community clouds in several countries. We start with a Microsoft tenant .  A tenant is the account you create in the Microsoft Online Services environment (such as Office 365) when you sign up for a subscription. A tenant contains uni

Understanding Dynamics 365 and Office 365 Admin Roles

Managing Dynamics 365 instances If you run Microsoft Dynamics 365 (formerly Dynamics CRM) in the Microsoft cloud, you need to understand how your Dynamics instances relate to Office 365 and choose which of your administrators receives which roles and permissions to manage Dynamics 365. In on premises deployments, your network administrator would create and delete user accounts.  The Dynamics 365 admin would then assign permissions to users in Dynamics 365. This post explains three administrator roles: Office 365 Global Administrator Dynamics 365 System Administrator Dynamics 365 Service Administrator You may think that the Dynamics 365 system administrator would have power to do all the actions needed to manage Dynamics 365, but this is not the case. What's different in Microsoft cloud deployments is that licenses and user accounts are managed in Office 365 by an Office 365 Global Administrator.  This role is analogous to a network administrator for an on premises

My Favorite Microsoft Power Apps Bloggers and their Blogs

  by James Townsend Updated 7/5/2022 Microsoft Power Apps is one of my favorite subjects, and I enjoy reading blog posts from members of this thriving technical community.  Here are some of my favorite bloggers and their blogs: The Official Microsoft Power Apps Blog   I have to start with the official Microsoft Power Apps blog.  It has many contributors, largely Microsoft program manager, including frequent posters Denise Moran ,  Greg Lindhorst , Kartik Kanakasabesan , and  Adrian Orth .  This is the place to go for product announcements, updates and technical how-to for a broad range of Power Apps topics.  April Dunnam April Dunnam was formerly focused on SharePoint and now devoting herself to Power Platform.  April offers highly understandable explanations of Power Platform, Dataverse and other top Power Apps topics. She joined Microsoft in late 2019 and has a thriving YouTube channel .  Carl De Souza Power Apps Blog and eBook This is one of the most extensive and best organized blo