Business Knowledge — Packaged in a Policy Charter
Policy Charter as a Deliverable

by Gladys S.W. Lam

How can the business close the gap between the business and IT?  How can it capture the basic business knowledge needed to build effective systems?  How can it justify its core business rules?  In the following article, Ms. Lam discusses Business Tactics Capture, a means to answer these questions.  The resulting deliverable is a Policy Charter, a crucial new component in the business rule approach.

A bank executive with too many frustrating experiences with IS was heard to ask recently, "Are we really confident that IS can build the system in time for our product release?"  These days, more and more corporate executives, project sponsors, and business users are asking similar questions.  "Can IS produce?"  "Will IS produce what we need?"  "Are we spending too many resources on this IS project?"  "Why are we being asked to make these technical decisions?"  "What is IS building, anyway?"

The business community's primary responsibility lies with planning, managing, and operating the business.  They are trained and skilled in creating visions for future growth of the business, in developing strategies to implement change, and in streamlining operations to maximize efficiency.  They think profit and loss.  They think customer service.  They think operations and logistics.  They talk business talk.  In other words, they are focused on the business — and rightly so.

Now consider what IS demands these poor business people do.  During the IE (Information Engineering) era, executives and senior management were asked to get together for months to develop an ISP (Information Strategy Plan).  They were asked to sit in a room for days on end to define "customer," "employee," "facility," etc. with no clue about why and how this would help them achieve their business objectives.  Today, executives and project sponsors still are given three-inch thick binders of business analysis reports, conceptual systems designs, and technical design reports, and then they are asked to "sign-off."  Are the executives and the project sponsors really expected to read these reports?!

On the other hand, IS cannot be expected to build systems on its own.  It needs business expertise.  As John Zachman says, the system is the business.

The biggest challenge for IS today is simply how to get the business community more involved:  How to be proactive instead of reactive to the business?  How do we bridge IS with the business community?  What do senior executives or sponsors need from IS to show that it is building what they really need?

IS has other challenges as well.  Systems are getting more complex.  Users are demanding faster response.  Technology is changing constantly.  Where should IS concentrate?  The answer must be:  the business.

Systems development lacks an approach to capture, implement, and manage the basic knowledge of the business.  The knowledge of the business is the thinking and the culture behind the business that drives the business forward.  It is not workflow or data requirements.  The knowledge of the business is imbedded in the tactics used to drive the business, in the policies enforced by the business, the risk tolerance of the business, and the rules implemented by the business.

Business Tactics Capture fills the "missing link" in systems development.  Based on the business rule approach, Business Tactics Capture provides a systematic method to extract and manage business knowledge.  It allows communications at the business level.  It outlines a simple way to extract and to document business knowledge to show what it is and why it exists.  It produces a condensed, readable deliverable called the Policy Charter, which allows the business community to understand the most essential elements of the business.  This provides the basis for developing meaningful workflow and data requirements.  Producing the Policy Charter, therefore, should be one of the very first steps in systems development.

The remainder of this article focuses on how Business Tactics Capture should be conducted, and what results can be anticipated based on actual application of the technique by Business Rule Solutions, LLC.  The discussion begins with a closer examination of the Policy Charter deliverable.

The Policy Charter

There are three business roles in defining the business knowledge represented in the Policy Charter — the sponsor, the owner, and the worker.

• Sponsor.  This is a person "in control."  His/her role is to review, confirm, and approve the business knowledge.

• Owner.  This is a person who specifies what the business needs.  His/her role is to develop the business knowledge.

• Worker.  This is a person who must work with the business knowledge.  His/her role is to translate the business knowledge into more concrete specifications that can be used to create models to implement.

During requirements development, the IS team must work with the Owner(s) to develop or capture the business knowledge within project scope.  The critical deliverable is the Policy Charter, which documents the motivation for tactics and business policies.  The Policy Charter contains the following components.

Business Objectives

A business objective identifies what the business needs to achieve on an on-going basis.  It provides the justification for why things should happen in the business.  Objectives can make all the difference in the world in developing the specific business knowledge of a business.  As an example, consider the potential differences resulting from the objectives "to make a profit" vs. "to be non-profit."

Tactics

The success of a business depends heavily on the foresight exhibited within its business tactics.  A tactic is a course of action or means that may be employed to achieve some desired end.  For example, in order to compete in the marketplace, Microsoft decided to generalize its products for the hardware platform.  Apple decided to have customized hardware.  Different tactics — very different results!

Policies

Business policies are ways to implement the tactics.  They are specific or quantified statements that give guidance to action or decisions.  An in-depth understanding of a business' strategies and culture can be gained by examining its business policies.  A bank with the policy "a borrower must be 21 or older" is more conservative than a bank with the policy "a borrower can be any age as long as his/her income can support the loan payment."  The policy ".5% more interest to an account holder that is 10 or under" shows a bank that seeks to attract young clientele and that may have a long-term vision in planning.

Risks

Risks are undesirable outcomes that may arise as a result of a course of action (i.e., putting a tactic or a policy into practice).  Implementing the policy "a car loan borrower must be at least 25 years old" may introduce the risk of losing business from responsible college graduates who need a car loan.  Adopting tactics and policies creates risks.  The business' level of tolerance to risks dictates the next level in tactic and/or policy development.

The Policy Charter can be written in plain business language.  The policies can be summarized in a few pages.  This is very important in retaining the Sponsor's focus and interest.  These summary pages provide the sponsor (and other business users) with a fast and clear understanding of the business area within project scope.  Once approved, the policies in the Policy Charter can be used by the worker(s) to translate the business knowledge into specifications and models that can be implemented.  The implemented knowledge represents the "gut" of the future system.

Business Tactics Capture

How can the Policy Charter be produced?  The discussion below sketches an approach, and indicates what is required to be successful.

Step 1:  Define the business objectives within project scope.
Ask:  What business effects does this area try to achieve?

Step 2:  Define tactics to satisfy the objectives.
Ask:  What needs to be done to meet each objective?

Step 3:  Define risks caused by tactics.
Ask:  What are the risks if we take this course of action?

Step 4:  Define further tactics / policies that will address the risks.
Ask:  What can we do to minimize the risks?

Step 5:  Repeat steps 3, 4 until the risks become acceptable risks.
Ask:  Can the business accept the risk?

Step 6: Develop policies for tactics that need to be made more concrete.
Ask: Can each tactic be clarified by one or more policies? If not, develop appropriate policies.

The statements captured in the above six steps must be short, crisp, and precise.  When complete, the Policy Charter defines the game plan of the business.  It keeps the focus squarely on the business.  It is not workflow or data — those come later.  It is not long justifications or benefit statements about why something happens.  It is simply the business knowledge captured in a structured and concise form that can be understood easily.  An example is given in the box opposite.

This example shows a small excerpt from the business tactics used in Hugh-Mongus Auto Collision Repair in order to maintain a good partnership with suppliers.  It shows how IS can capture the knowledge of the business in a structured and precise manner.  These business knowledge specifications are developed with the owner(s) of the business area.  The best approach is to use structured facilitated sessions to explore different tactics, risks, and policies.

Once stabilized, the Policy Charter can be submitted as a deliverable to the sponsor(s) for review.  Unlike deliverables prescribed by other system development methodologies, the Policy Charter is related strictly to the business.  Sponsors who understandably show little interest in traditional systems development deliverables will be very interested in the Policy Charter.  In the example above, the sponsor may ask crucial business questions, such as "how much would electronic fund transfer cost?" "how much would we advance to the supplier per month?" or "why don't we collect interest on advances?"  These business issues should be resolved before other systems development activity starts.

Once approved, the Policy Charter provides IS with the business game plan, which it can use as a starting point for developing other deliverables.  All these other deliverables should follow the guidance of the game plan.  The Hugh-Mongus excerpt, for example, suggests two potential workflows — one to handle electronic funds transfer and another to handle advance payment.  It also suggests some data requirements (i.e., payment, supplier, bank accounts, etc.).

In a system development project, all deliverables must follow the constraints put forward by the game plan.  The automatable policies must be translated to implementable rules for system implementation.  The ideal implementation platform is for these core business rules to be implemented in a rule engine in which they can stay truly independent of process and the database.

Conclusion

The business rule approach is exciting because it provides the opportunity to satisfy both IS and the business.  Business Tactics Capture, with its focus on business knowledge, provides the critical link between IS and the business community.  The deliverable of Business Tactics Capture is the Policy Charter.

Business Tactics Capture represents a new communication channel between IS and the business community.  This opens up endless opportunities for IS to put technology more in-line with the business, and to capture business knowledge.  This corrects approaches to IT in which there has been little or no business involvement.  It also brings us closer to John Zachman's vision that the system is the business.

The Policy Charter is business-friendly.  It provides the business community with a short, structured, and concise document that expresses the business essentials of an IS project.  This gives the project sponsor(s) the understanding necessary to control, manage, and make decisions about the project as other, more detailed deliverables subsequently are developed.

Under Business Tactics Capture, policies that previously might have been ignored or put together crudely now can be developed and captured methodically.  An executive or a project sponsor, who is not at all interested in other types of deliverables, is naturally quite interested in the business policies that the system will implement and support.

That interest is really the bottom line.  You can work for days on a clear definition of ORDER, but will it provoke any real interest?  Not likely.  How about a slick GUI screen design?  You may get some momentary oohs-and-aahs, but that's probably the end of it.  On the other hand, if the business community reads a policy defined as "an order must not be over $1,000," this is sure to produce rapid-fire questions.  Now!  That crucial business connection between IS and the business finally has been established.

©1998, Gladys S.W. Lam

Gladys S.W. Lam is an expert IT project manager, consultant, and seminar leader. She has extensive experience in various business contexts, including BPR, strategic IT planning, and managing and implementing information systems. She works closely with companies in developing Business Rule solutions.

Ms. Lam has gained a reputation for fostering positive professional relationships with principal and support staff in projects. Her wide business and technical knowledge is invaluable in achieving consensus among project participants. She has also developed an impressive track record of completing projects on time and within budget. She is committed to achieving quality results within available resources.