Part 2: The Business Rule Approach: Changing the Face of IT Methodology

 

The second of a three-part series based on Principles of the Business Rule Approach, the author’s groundbreaking new book from Addison-Wesley (2003). In this second part, the
author examines business rule methodology.

Recently, we were talking to the chief developer at a large client organization about progress on a major reengineering effort there. The project in question targeted one of the
organization’s core business processes. Our concern was whether the project team members could meet a deadline some nine months out for delivering a large-scale prototype. We had just spent
several intensive months developing a comprehensive business model, and they still had several months of system design left to complete.

This chief developer was very sharp—not one to commit to any answer lightly. For the longest while, he said nothing, lost in thought. Finally, eyeing the detailed business diagrams plastered
on the walls all around, he said, “If we had already started coding, I would say we had no chance at all. But since we haven’t started coding yet, I’d say the chances are pretty
good.”

I had to run that by several times in my mind before I caught his meaning. “If we had already started coding, I would say we had no chance at all.”

I knew he thought that the application coding itself was going to be pretty tough. It would involve using a worldwide distribution network, rule engine technology, GUIs, and some significant
middleware.

He was saying that if they had to resolve all the business issues while coding, they would never pull it off in time—or probably ever. However, since the project team was tackling the tough
business issues up front (including specifying the business rules), he thought they had a pretty good chance of completing the code by the target date.

Why Business Rule Methodology Is Different
What It Means to Mean Business

This discussion focuses on the business end of business rule methodology. There is obviously much more to the business rule methodology than I can cover here – for example, how to capture and
express rules in a declarative manner. But there is ample material available on that, and first things first.[1]

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?

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
aspects[2] listed in Table 1. The business model deliverables are those for Proteus, the business rule methodology developed by
Business Rule Solutions, LLC, for business analysis.

Table 1. The Aspects of a Full Business Capacity

 

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.[3]

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 the business capacity in its particular form 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 goals[4] 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.[5]

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.[6]

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 1. This segment (which represents about 15 percent of the entire deliverable) is presented in its original
computer-automated form. We find graphic presentation (as opposed to a purely textual format) enables better communication and discussion among business-side team members and sponsors.

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.

Analysis Paralysis
Preventing the Disease Behind the Symptoms

Many predators hunt based on movement. In fact, even with their keen eyesight, they cannot really see their prey unless the prey itself moves. Consequently, many hunted animals are programmed
literally to freeze with fear. Not a bad thing to do if it saves your life!

Recently, we were asked to perform a postmortem review of a large project that had failed miserably at a major corporation. I will spare you all the unpleasant details—let’s just say
they started the coding phase way too early. The wounds to the business were deep, and in several ways, the company had begun to ooze red ink.

What went wrong? The diagnosis was relatively easy for us to make—no Policy Charter or other means to assess business motivation, and no true top-down business model.

They should have frozen with fear then and there. Instead, they jumped right on into development, loosely following a spiral “methodology” based on the mantra analyze a
little, design a little, code a little, test a little. The company learned the hard way what that mantra means in practice—lots of rework for lots of time! (By the way, on other
projects the company called such rework “maintenance.” Sound familiar?)

Projects spiral out of control all too often. Unfortunately, there are no magic cures—just very expensive and time-consuming ones. Can the company really afford to continue to squander its
resources in this way? We think an ounce of prevention is worth a pound of cure.

Take a hard, early look at projects and learn to read the symptoms before it is too late to prevent the disease. Here are some possibilities.

• Maybe you do not really know what the business problem is. In that case, how will you know if you are developing the right solution?
• Maybe the business problem itself is hard. Will thinking about it in a programming language (or in IT system models) make understanding it easier?
• Maybe you are not getting the right answers from the right people. Then, realistically, how good are your chances of success?
• Maybe there are unresolved differences of opinion on the business side about what form the business solution should take. If left to the programmers, do you think they can code their way to
  some satisfactory resolution?
• Maybe future business directions are hard to predict. Are designers and programmers in a position to make the best strategic choices?

The next time you hear anyone say, “Watch out for analysis paralysis,” take pause. Just freeze—it might save your company’s life (or your own job). Somewhere close by there
is probably a programmer poised to pounce on a keyboard. To stay on the safe path, think business model, Policy Charter, and business rules! Remember, every problem is first and foremost a business
problem!

Excerpted with permission from Principles of the Business Rule Approach, by Ronald G. Ross, Addison-Wesley, Boston, MA, 2003. ISBN: 0-201-78893-4, Available via www.BRSolutions.com – Mention “TDAN.com” for a 10% discount!

For more on details on the steps and tasks of business rule methodology, visit www.BRSolutions.com for free downloads.

[1] For example in the book, Principles of the Business Rule Approach, itself, on www.BRCommunity.com, through our public and in-house seminars, and from other sources.

[2] Those readers familiar with John Zachman’s Architecture Framework will realize that I am referring to its six columns, which
address the interrogatives what, how, where, who, when, and why, respectively. For more information on Zachman’s thinking, refer to collected articles by Zachman found in the Business Rules
Journal, available at http://www.BRCommunity.com.

[3] I use ownership here deliberately. Owner is the term John Zachman uses to describe the perspective of row 2 in his Framework, the row
that has to do with developing an enterprise model (also known as a business model).

[4] I do not mean project goals or project objectives, so to avoid confusion I will continue to say business goal rather than simply
goal.

[5] For in-depth discussion, refer to The BRS Core Business Rule Practitioner’s Guide: Using Business Rules in Developing Business
Strategy. Available via http://www.BRSolutions.com.

[6] For additional discussion, refer to “Business Knowledge—Packaged in a Policy Charter” by Gladys S.W. Lam,
May/June1998. Available via www.BRCommunity.com