We can agree that 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 rearranged, or the criteria used to make decisions changes. This is what business process management systems (BPMSs) 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 of a BPMS stems from identifying these stable patterns of change and supporting them with structures — activities, decisions, and the definition of their order — that allow for change.
THE DATABASE ANALOGY
To illustrate the point of stable change, consider database management systems (DBMSs) as an analogy. A database embodies a model/structure of an organization’s ongoing 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, occurring only if the business of the organization changes significantly or the organization enters a new business.
Further, databases are not just containers; they are rule enforcers.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." This 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 and used primarily when a new occurrence of something, such as 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 ordered.
This solution using code has caused even more problems than the examples described previously, 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 decision making, only to then see the business rules change enough that the results produced by the code were no longer valid and had to be extended by manual workarounds. 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; thus the backlog started to grow seemingly exponentially.
Next Time: Supporting Business Rules; will Brute Force work?
No comments:
Post a Comment