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

To understand Microsoft Dynamics 365 (formerly Dynamics CRM), 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. This post introduces some of the key terms and how these concepts are important for planning your implementation. While Dynamics 365 is 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. 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 uniquely identified domains, users, security groups, and subscriptions.  Your tenant has a domain name of .onmicrosoft.com such as acme.onmicrosoft.com.  User accounts belong to a tenant, and subscriptions are assigned to user accoun

Replacing Microsoft InfoPath with Power Apps

Source:  https://powerapps.microsoft.com/en-us/infopath/ Microsoft has offered a number of forms automation products over the years, and the most long running was InfoPath which was released as part of Office 2003.  InfoPath is a powerful and flexible product that stores user data in XML while offering form features such as rules, data validation, scripting, and integration with SharePoint.  The popularity of SharePoint resulted in many organizations standardizing on InfoPath for forms, especially internal forms which are hosted on an intranet such as employee reviews, leave and payment requests, and human resources forms. Microsoft has discontinued InfoPath, with mainstream support ending July 13th, 2021, and extended support ending July 14th, 2026. Microsoft has named Power Apps as the successor to InfoPath .  Power Apps has much in common with InfoPath.  Both products include integration with SharePoint.  Both are geared toward the citizen developer and do not require advan

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 Power Apps Portal and shifted to the Power Apps 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