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

The DATA Act Driving Grant Management Automation

The Digital Accountability and Transparency Act enacted in May 2014 calls for making spending data available in open, standardized formats to be published online.  It is a continuation of transparency initiatives and lessons learned with experiences such as grants.gov, the 2009 economic stimulus under the Recovery Act and the spending site USASpending.gov.

Government grantees will have significant new administrative responsibilities.  Many organizations that were tracking grants in spreadsheets or documents will have to adopt more sophisticated automated grant management systems such as Microsoft Grants Manager to keep up with reporting rules.

For profit companies will lose some privacy as a result of this law.  Grant recipients will be required to disclose information including officer salaries.

Continued improvements to publishing grant opportunities such as grants.gov may make it easier to find grants. These reforms together are designed to improve the effectiveness of grant prog…

Dynamics 365 for Government Contractors (GovCon) Frequently Asked Questions (FAQ)

One of InfoStrat's most popular solutions is Dynamics 365 for Government Contractors (GovCon).



Here are some answers to frequently asked question on this solution:
Can I add new fields to the solution?  -- Yes, the solution is fully customizable and you can add your own new fields to any form, view or report.Does Dynamics 365 for GovCon work on mobile devices?  -- Yes, Microsoft offers mobile apps for all the most popular platforms including iPhone, iPad, and Android phone and tablets.Does Dynamics 365 connect with bid data systems such as Deltek and Onvia?  -- Some information services, such as Onvia, offer integration with Dynamics 365.  Others require third party solutions such as the InfoStrat integration with Deltek GovWin IQ.What do customers typically customize for their unique requirements? -- Not all contractors follow the same steps in the capture process.  Most clients will tailor the business process to add or remove steps in order to match their sales methodology.  Of…

InfoStrat Joins Microsoft CityNext

This month my company InfoStrat announced its participation in Microsoft CityNext, a global initiative empowering cities, businesses and citizens to re-imagine their futures and cultivate vibrant communities. Through the Microsoft CityNext initiative, Microsoft and InfoStrat will help leaders to do “new with less,” by combining the power of technology with innovative ideas to connect  governments, businesses and citizens with city services that increase efficiencies, reduce costs, foster a more sustainable environment and cultivate communities where people thrive.
In a recent study, IDC named Microsoft the most trusted smart-city vendor. "Whether it's traffic congestion, citizen services, energy efficiency or operating costs, our Microsoft CityNext partners are equipped to tackle whatever problem or priority local governments want to address. Microsoft’s IDC smart-city scores are really a credit to our partners, which leverage our trusted cloud platform, powerful data analytic…