Introduction:
We often hear people say, “Our processes and business logic are extremely complex; they will be very difficult and expensive to understand and document.” This same thought-process usually prevails whether we’re contracted to re-engineer a process, re-discover an existing process, or create a new process. And, when we ask for existing documentation, we are handed stacks of process charts or told that the documentation is buried in the code. No wonder they think their processes are very complex, there are no views of the processes and business logic that is easy for everyone to understand.
We’re not suggesting that your processes are extremely simple, but would like to demonstrate through this article that they might be a lot less complex than you believe.
To demonstrate this point, look at the two process diagrams in Figure 1, taken from a real project. The “Before” chart is very complicated because the process and business logic (or what you may call business rules) are mixed together. The business logic was embedded in the chart in the little red numbers that adorn many of the chart task boxes.
The “After” diagram is the same process, but using BPMN and separating the business logic. The difference is not the notation, but the fact that we removed the business logic from the process chart.
Figure 1: Before and After Using the Decision Model
With the business logic removed from the process chart, the Decision Model is used to organize the business logic (business rules) into well-formed structures that are predictable, maintainable, and normalized (Business Decisions are denoted in the process chart with the blue octagons). A Decision Model is a structure of business logic that makes business sense, not an arbitrary collection of business rules written in an unstructured natural language.
The Decision Model enabled us to discover that the business logic was incomplete, inconsistent, duplicated, and sometimes wrong. This model also made it possible for us to dramatically reduce the number of rules and discover that many of the rules could be reused.
In the “Before” example, the company had, after a significant amount of effort, abandoned the process diagrams as being too complex and difficult to maintain. After we separated the business logic, we managed to greatly simplify the processes, and more importantly we were able to reduce the total number of processes by a half. And, it turned out that several of the processes, once the logic was removed, could be re-used.
Why Is The Simplification So Dramatic?
Separating the business logic from the process creates this dramatic simplification because the inherent structure of process and business logic is different. Processes are procedural (that is to say that it is a sequence of tasks and events, where the sequence is obligatory) and business logic is declarative (which is to say, sequence is irrelevant.) Trying to depict both in the same process diagram results in an “impedance mismatch”. In other words, we get a diagram that doesn’t depict the underlying truth. It’s a little like using a topological map to determine the population density of a given geography. When we mix the procedural with the declarative it increases complexity, inaccuracy, and becomes difficult to maintain or easily change. The reality is that a process flow chart is not capable of documenting business logic in a rigorous and normalized structure.
Let Us Offer Further Proof:
We recently completed a scoping engagement for a major health insurance provider, who wanted to re-discover the business logic in five separate systems that were independently coded, but nonetheless used (or was thought to be using) the same business rules. The business was concerned that portions of the business logic may be inaccurate or inconsistent between systems, and ultimately wanted to consolidate the business rules into a single application, perhaps on a business rules engine, or as a set of business services.
The client’s major concern was that there were a large number of rules and many of the business rules were very complex. When we started the engagement, the client’s staff (business representatives, business analysts, and technical staff) was also very vocal on one count: the complexity of the business rules, and the complexity of the processes were very high.
The duration of the scoping engagement was two weeks. This included training the clients’ business, analyst, and technical staff on the Decision Model; documenting one of the business processes implemented by each of these applications, identifying two business decisions in each of these processes, mining the business logic within those two business decisions, and documenting them into Decision Models. Once we completed these two business decisions we compared the differences between them in each application to consider their accuracy and consistency. In the last phase we used the scoping project metrics to create an estimate for a full project.
The client had a great team. At the conclusion of training, they had an excellent grasp of the Decision Model. This enabled us to dive head first into rediscovering the four business decisions and their business logic. In fact, as the project progressed, even shy participants were taking leadership roles. Everyone was participating and having a good time.
The team quickly discovered problems in one of the applications where process and decisions had been intermingled. To their surprise, as they separated the business process and business decisions they saw that the logic in the business decisions was significantly simpler than they had originally thought. More pertinently, they discovered that their main processes did not consist of innumerable complex sub-processes, but a relatively few sub-processes that were re-used many times. When the business decisions were removed from the process, each process became much simpler.
Conclusion:
These results were not surprising to us. In fact, they are typical of our experience. For example, one of the authors recently did a process improvement project for a “big four” accounting firms which involved implementing their Independence Policies into a single process across 130+ countries. Their Independence Policy was more than a thousand pages! They had the right to view their independence process and business logic as complex, but once we separated the business logic from the process, it became clearer, less complicated.
By separating your process and business logic into their appropriate, and separate models, you will likely discover that your processes are simpler than you think. John Zachman once said, “It occurs to me that once the underlying structure of a discipline is discovered, friction goes to zero! The processes (methodologies) become predictable and repeatable.” The Decision Model is the underlying structure of business logic, and using it to remove logic from process will help reduce friction to zero.
