Why business rules? Why are they worth the trouble? Early in this chapter, we looked at the business value of business rules. We showed how business rules are used as software requirements, how they can be directly executed, and how they are used for communications, training and learning, and managing com- pliance. But now that we have examined business rules in some detail, we can say more.
Capturing business rules simplifies business process models. When the rules around decisions are modeling separately, outside the business process, the busi- ness process becomes simpler. We saw an example of this in Figures 6.26 and 6.28, where we modeled the decision rules for when to seat parties and when they should wait, removing that logic from the business process. The resulting business process was simpler, and hence more valuable.
Business rule models provide greater agility. Today many organizations want the ability to change faster when they need to, to quickly react to changes in the business environment: market opportunities and threats, or new laws and reg- ulations. With a business rule model, many of the desired changes are implemen- ted as new business rules. Other desired changes are implemented as changes to existing business rules. Business rule models separate the part of the business that naturally changes the quickest—the rules—from everything else that changes slower.
Business rules are also useful in the modernization of legacy applications.
Most organizations have legacy software: applications written 10, 25, or even 40 years ago. These legacy applications cannot be retired; they perform important business functions. But they were created using technologies that are now either obsolete or are simply too expensive to maintain. There is a great interest in mod- ernizing these applications.
180 CHAPTER 6 Business Rule Models
Legacy modernization is risky. When a new application is written to replace the old, it’s easy to overlook important business logic encapsulated in the legacy code. The new application is missing the hard-won knowledge that the old one accumulated over its lifetime. The result is a brand-new application that is worse than the legacy application because it is missing business rules. Many legacy mod- ernization efforts fail for just this reason.
Business rules mitigate this risk. The legacy modernizer examines the legacy code—typically with tools for just this purpose. He mines the code for the busi- ness rules encapsulated within it. Then he models those business rules. Either the business rules become requirements for the new application, or they are exe- cuted directly.
Business rules are useful and valuable, but not widely practiced today. We expect this to change. We expect business rules to go mainstream. In the future, every company and every government agency will model its business rules.
Business rules guide behavior. Operative business rules guide behavior by stating what is obligatory, what is prohibited, or what is permitted only under certain conditions. Structural business rules guide behavior by defin- ing what is necessary, what is impossible, or what is possible only under certain conditions. Operative business rules can be violated. Violations are prevented through enforcement.
Business rules are precise—precise enough to be directly enforceable. If someone knows a rule and sees relevant behavior, that individual can deter- mine whether the behavior violates the rule. Business policies are the less precise and more abstract cousins of business rules. Business rules are often derived from business policies.
Business rules are richly connected to other business model elements.
Business rules govern strategies. Business rules support the achievement of goals. Business rules are established by organizations. And most important, business rules guide business processes and the gateways and activities within those processes.
Business rules are the last of the four business modeling disciplines. In Chapters 7–9, we explain how to create a business model. There are some techniques to creating a good business model—techniques that are common to all four disciplines. Chapter 7 describes the techniques for creating a good model.
CHAPTER
Creating a Good Model
7
There is no simple formula for creating a good business model. In fact there are lots of ways to fail—many different methods of creating a bad model.
These bad modeling methods cross all four model disciplines. For example, one can build an overly complex motivation model, an overly complex orga- nizational model, an overly complex process model, or an overly complex rules model. Similarly, model elements can be given bad names in any of the four model disciplines. Creating a good model involves avoiding all the paths of failure. This chapter explains the different paths of failures and some techniques for avoiding those paths.
Business modeling can deliver significant value. As we described in Chapter 1, there are eight different kinds of purposes that a business model can achieve.
Often a business model will accomplish several of these purposes at the same time.
But in some organizations, business modeling has a bad reputation. “We tried that ten years ago,” the old timers say. “There was a team of business modelers on the fifth floor. Lots of models were built, but nothing useful happened.” The old timers described how the models became increasingly elaborate and complex until no one could understand them. “Finally, we axed the group.”
So why is there a discrepancy between the promise of business modeling and the actual experience of business modeling? What gave business modeling its bad reputation in some organizations?
Leo Tolstoy begins his epic novel Anna Karenina with the sentence, “All happy families are alike; every unhappy family is unhappy in its own way.” By this he means that to achieve happiness a family must avoid a host of dangers: alcohol abuse, infidelity, overspending, depression, and so on. An unhappy family of drunks is different from an unhappy family of spendthrifts. But the happy families have avoided all the dangers and for that reason are somewhat alike.
Business modeling is like the situation Tolstoy describes. There are many dan- gers to business modeling. Each danger can contribute to a bad reputation for business modeling. These dangers include model value destruction, scope
183
failures, straight-through modeling, creeping complexity, ugly models, and incom- petent modelers. Only by avoiding all these dangers can business modeling succeed.
Fortunately it is possible to avoid all these dangers. With some careful attention and governance, you can build a good model rather than a bad one.