Predictable Change in Business Processes

Business Processes change a lot, but a little analysis of the nature of these changes reveals that they are of the same type(s): activities are added or removed, or the order of the activities is re-arranged, or the criteria used in decisions changes. This is what Business Process Management Systems (BPMS) were created for: defining activities, decisions, and their order in a business process, with the ability to change the process in common ways without requiring an IT project. The power and simplicity of a BPMS is about identifying these predictable patterns of change, and supporting it with structures — Activities, Decisions and the definition of their order —- that allow for change.

The Database Analogy

Consider Database Management Systems (DBMS) as an analogy to illustrate the point of predictable change. A database embodies a model/structure of an organization’s on-going data needs, patterns of entities/objects and their relationships, what Database Analysts know as the ‘schema’. With this stable structure, new occurrences of data are added as needed through application systems; the need to add new data item definitions to a database is very infrequent, only if the business of the organization changes significantly, or if the organization enters a new business.

Further, databases are not just containers, they are rule enforcers; consider the entity-relationship diagram that is used to define most databases. The optionality and cardinality defined for relationships are rules, such as an Order must have at least one Item being Ordered but can have many Items being Ordered as well; that is what any business person will tell you is true about an Order, so a database can be used to enforce these rules.

This enforcement is good, but it is also limited; database rules, especially optionality, are cut and dried; they cannot implement conditional situations, such as a relationship is mandatory only when x=y. For example, an Order must be related to a Credit Approval IF the Payment Method is Credit Card. When the business presented this kind of situation to IT, the ‘data edit’ was born. As you might expect by this point, this response was implemented in code, used primarily when a new occurrence of something, like an Order, is created by an application system. It has also been known as the ‘input edit’, the ‘screen edit’, and the ‘field edit’; a special case is the ‘cross-edit’, where the value of one data attribute is constrained by the values of another. For example, a discount for an Order can be greater than 25% only if a certain type of Item is being ordered.

This solution using code has caused even more problems than the examples described above, because ‘data edits’ are a technical IT term for Business Rules, and what I have learned is that Business Rules change even more often than the Business Processes that use them for guidance. Working in insurance, and then lending, I have often seen code that implemented underwriting business rules to automate decisions, only to then see them need to be extended by manual workarounds when the rules changed and the results produced by the code were no longer valid. So, the systems that implemented the data edits in program code were subject to even more requests for change, along with the requests to change processes; the backlog started to grow seemingly exponentially.

Many organizations tried to solve this problem with brute force: add more resources, run more projects, outsource what could not be done internally. Other (fewer) organizations saw the diminishing returns that approach, and started evaluating the problem laterally[1]; they determined that data definition and then process definition captured a lot of what business is about, and automating their management was of benefit, but neither included “the set of rules that determine how a business operates — that is, rules that prevent, cause, or suggest things to happen.”[2]