- Databasing Your Rules
- What Is a Business Rule?
- Business Rules and the "Flow"
- Business Rules and the "Know"
- Why Business Rule Methodology Is Different
- Analysis Paralysis
This chapter is from the book
This chapter is from the book
This chapter is from the book
Why Business Rule Methodology Is Different
What It Means to Mean Business
Outwardly, the business rule approach produces many of the same deliverables as any other approach to building business systems—screens, processes, data, controls, and so on. In other words, the end result is almost sure to include some automated components. So why is the business rule approach any different from other system development methodologies? This section explains why.
The goal for development is to ensure a more adaptable business. This goal produces three imperatives.
Business Rule Systems Imperative 1: A Business Model
Application components must be seamlessly integrated into the business. Such integration requires a blueprint, a top-down business model covering the full business capacity within scope.
To say that a business rule project aims toward producing application software misses the point. The real objective is to produce a full business capacity that covers all the factors or abstractions12 listed in Table 13–4.
Table 13-4 The Factors of a Full Business Capacity
| Business Aspect | Business Component | Business Model Deliverablea | IT Component |
| Knowing | Terms and facts | Fact Model | Data |
| Transforming | Business processes | Business Process Models | Processes |
| Connecting | Business links | Business Connectivity Map | Machine links |
| Interacting | Roles and work products | Organizational Work Model | Human interfaces |
| Staging | Time frames and milestones | Business Milestones | States |
| Guiding | Business goals and tactics | Policy Charter | Rules |
To support this first imperative, a complete top-down business model should be developed involving key business-side workers and managers. By the way, complete here means the model addresses all the key business questions but not system or implementation questions.
With the right people and the right approach, this business model can be developed in a matter of weeks and requires relatively modest amounts of time from the business-side participants. And (this may come as a surprise), we find that these business-side participants almost always actually enjoy the process. I think that is simply because they find the process so relevant and valuable. To sum this point up in a word, we find they finally feel they can take ownership.13
Business Rule Systems Imperative 2: The Best Business Solution
The business needs the very best business solution possible. "Best" must be demonstrated, so a battle plan must be developed up front in which each key element of the solution is motivated from a business perspective.
A business capacity will be of little value if it addresses the wrong business goals. The key question is why a particular form of the business capacity is the right one for the company.
Traditional approaches for building application systems have not done a very good job of answering that key question. In the 1980s, information engineering, for example, sought to answer it by involving sponsors and key managers directly in producing deliverables. As you can imagine, this was very expensive and time-consuming. Worse, it did not even really work. Today, most projects are still managed based on cost. Money is important, of course—but it is not a substitute for knowing why.
The business rule approach offers a fresh approach. Briefly, the central idea is that achieving business goals14 always involves a particular set of business risks and inherent conflicts and tradeoffs. Business tactics and core business rules are formulated to address these risks, conflicts, and tradeoffs.15
Rather than involving sponsors and key managers in data or process deliverables, the business rule approach gets those people directly focused on developing these crucial elements of the business solution. I will have more to say about the deliverable that makes this possible momentarily.
Business Rule Systems Imperative 3: High-Impact Sponsorship
Project sponsor(s) must have maximum leverage for controlling a project with a minimum investment of their time.
As mentioned above, a critical success factor for projects is to enable sponsors to manage projects by business benefit rather than primarily by cost. This is achieved by a coordinated focus on the motivation for the key elements of the business solution, including core business rules.
High-impact sponsorship has additional advantages, including the following.
Sponsors can have a clear, concise, and continuing understanding of how the business goals are being transformed into a complete design for the desired business capacity, including (but not limited to) the automated components.
Sponsors can detect easily and early in the project life cycle that the project is failing to meet the original business goals so they can take timely action as necessary.
What enables sponsors to monitor a project without lengthy participation in the development of deliverables? The answer is the Policy Charter.16
A Policy Charter outlines the business tactics proposed to meet the business goals. The business motivation for each element of these business tactics is established. This battle plan offers the sponsors a direct view of how the needs of the targeted business capacity are being addressed. It also permits the following.
Assessment of business-side feasibility
Examination of business risks and how they will be addressed
Explanation of any divergence or shortfall that might have occurred in meeting the original business motivation
Exploration of specific reengineering opportunities for the business process
Acquisition of rapid and highly focused feedback
A page from one recent project's Policy Charter is presented in Figure 13–1. This segment (which represents about 15 percent of the entire deliverable) is presented in graphic form.17 We find graphic presentation (as opposed to a purely textual format) enables better communication and discussion among business-side team members and sponsors.
)
Figure 13–1 Sample Policy Charter (segment)
This sample Policy Charter segment concerns a business capacity involving an insurance claim process whose reengineering featured automated handheld pads to estimate repair costs for damaged autos. The elements shown in the segment include business goals, tactics, risks, and core business rules linked in appropriate manner. Note the prominent role of core business rules in addressing business risks.
If any part of a draft Policy Charter is unacceptable, unworkable, or incomplete, sponsors can immediately take appropriate action with minimal loss of time and resources relative to the project as a whole. Such early intervention will be much less costly than during later phases of the project during which technical design, construction, and testing occur.
Our experience is that with the right people and the right approach, a Policy Charter can often be developed in a matter of days. Also, we find that sponsors almost always enjoy their participation in the process. We recognize this is partly because the process takes so little of their time. However, we again find it also comes down to a sense of ownership.