Search ::     [ Advanced ]
Username:   Password: Auto login next time?  

AttainingEdge : World Class Training For Critical Business Innovations

Corticon RulesWorld

RuleXpress: The business tool for expressing and communication business rules.

 

 

 

 

     ROSS ARCHIVES ...
untitled

What Is a Business Rule?

by Ronald G. Ross

Excerpted from Chapter 7, Business Rule Concepts:  Getting to the Point of Knowledge (Third Edition), by Ronald G. Ross (August 2009). ISBN 0-941049-07-8   http://www.brsolutions.com/b_concepts.php

A business rule[1] is simply a rule that is under business jurisdiction.  Under business jurisdiction is taken to mean that the business can enact, revise, and discontinue their business rules as they see fit.  If a rule is not under business jurisdiction in that sense, then it is not a business rule.  For example, the 'law' of gravity is obviously not a business rule.  Neither are the 'rules' of mathematics.

The more basic question is the real-world, non-IT meaning of rule.  Clearly, rule carries the sense of guide for conduct or action, both in everyday life and in business.  One way or another, this sense of rule can be found in most, if not all, authoritative dictionaries.

If a rule is to serve as a guide for conduct or action, it must also provide the actual criteria for judging or evaluating that conduct or action.  In other words, a rule serves as a criterion for making decisions.  A business definition of rule therefore encompasses the sense of criteria as given by authoritative dictionaries.

A rule always tends to remove a degree of freedom.  If there were no rules, there would be complete freedom — i.e., anarchy.  If some guidance is given but does not tend to remove some degree of freedom, it still might be useful, but it is not a rule per se.  Such guidance is called an advice.

Figure 1 presents an overall categorization of guidance from the perspective of business people.  All rules are either behavioral (also called operative) or definitional (also called structural).

Figure 1.  Categorization of business guidance.

Practicable Business Rules

In contrast to a business policy, a business rule needs to be practicable.  This means that a person who knows about a business rule could observe a relevant situation (including his or her own behavior) and decide directly whether or not the business was complying with the business rule.  In general, a business policy is not practicable in that sense; a business policy must be interpreted into some more concrete business rule(s) that satisfy its supposed intent.  (That's what the fact type in Figure 1 worded practicable element of guidance is derived from business policy is about.)  For example the following business policy is not practicable:  Safety is our first concern.

Just because business rules are practicable does not imply they are always automatable — many are not.  For instance, consider the business rule:  A hard hat must be worn in a construction site.  Non-automatable rules need to be implemented within user activity.  In many ways, managing non-automatable rules is even more difficult than managing automatable ones.  They definitely have a place in your rulebook.

For a business rule (or an advice) to be practicable assumes that the business vocabulary on which it is based has been adequately developed, and has been made available as appropriate.  Note the fact type in Figure 1 worded practicable element of guidance is based on fact type.  Every business rule (and advice) should be directly based on a structured business vocabulary.  Each business rule (and advice) is expressed using terms and wordings to create statements in building-block fashion.

Meaning vs. Statement

An additional, subtle point is this:  The statement of a business rule is not actually the business rule; the meaning of the statement is the business rule.  That's important because:

  • The very same business rule (or advice) can be expressed by statements in different languages — e.g., French, Mandarin, etc.  It's a global world these days!

  • Even in the same language and the same notation (e.g., RuleSpeak), it's not uncommon to find a business rule (or advice) expressed in different ways by different people.  That's a kind of redundancy you need to be able to discover and sort out.

In short, managing business rules needs to be about managing meaning — semantics — not just statements.

Non-Rules (Advices)

Consider the statement:  A bank account may be held by a person of any age.  Although the statement certainly gives business guidance, it does not directly:

  • Place any obligation or prohibition on business conduct.  Therefore it does not express a behavioral rule.

  • Establish any necessity or impossibility for knowledge about business operations.  Therefore it does not express a definitional rule.

Because the statement removes no degree of freedom, it does not express a rule.  Rather, it expresses something that is a non-rule — a.k.a. an advice.

Is it important then to write the advice down (i.e., capture and manage it)?  Maybe.  Suppose the statement reflects the final resolution of a long-standing debate in the company about how old a person must be to hold a bank account.  Some say 21, others 18, some 12, and some say there should be no age restriction at all.  Finally the issue is resolved in favor of no age restriction.  It's definitely worth writing that down!

Now consider this statement:  An order $1,000 or less may be accepted on credit without a credit check.  This statement of advice is different.  It suggests a business rule that possibly hasn't been captured yet:  An order over $1,000 must not be accepted on credit without a credit check.  Let's assume the business needs this rule and considers it valid.

In that case you should write the business rule down — not the advice — because only the business rule actually removes any degree of freedom.  Just because the advice says an order $1,000 or less may be accepted on credit without a credit check, that does not necessarily mean an order over $1,000 must not.  A statement of advice only says just what it says.

Behavioral Rules

Consider the business rule expressed as:  A gold customer must be allowed access to the warehouse.  Let's assume for now we don't need to consider any exceptions.  Clearly this business rule can be violated.  If a gold customer is denied access to the warehouse, then a violation has occurred.  Presumably, some sanction is associated with such violation — for example, the security guard might be called on the carpet.

Any business rule that can be violated directly is a behavioral rule.  (It doesn't matter whether it is automatable or not.)  Behavioral rules are really people rules.  Basic business operations typically involve significant numbers of behavioral rules.

Behavioral rules always carry the sense of obligation or prohibition.  To reflect that sense, RuleSpeak (www.RuleSpeak.com) prescribes the rule keywords must or only to express behavioral rules.

One way or another, behavioral business rules are always preventative, as the following examples illustrate.

•  Surgical gloves must be worn in performing surgery.
     This business rule is intended to prevent infections.

•  A nurse must visit a patient at least every 2 hours.
     This business rule is intended to prevent inattention to patients.

•  A gold customer must be allowed access to the warehouse.
     This business rule is intended to prevent any denial of access.

Behavioral rules (also called operative rules) enable the business to run (i.e., to operate) its activities in a manner deemed suitable, optimal, or best aligned with its goals.  Behavioral rules deliberately preclude specific possibilities (of operation) that are deemed undesirable, less effective, or potentially harmful.  Behavioral rules remove those degrees of freedom.  Often, sanction is real and immediate if a behavioral rule is broken.

Although the examples of behavioral rules above are not automatable, many can be automated.  Here are some examples:

  • An order over $1,000 must not be accepted on credit without a credit check.

  • A high-risk customer must not place a rush order.

  • An order's date promised must be at least 24 hours after the order's date taken.

Not Automatable?

Be careful about assuming a business rule can't be automated in some way.  Sometimes, given the right technology (and sufficient business motivation) you might be surprised.  Consider the business rule discussed earlier: 
    A person must wear a hard hat in a construction site. 

You could use something like facial recognition software to determine whether a person is wearing a hardhat.  If a person is not wearing one, the response could be to lock a gate the person needs to pass through or to trigger an alarm.  Or put a GPS device on both the person and the hat.  Don't underestimate technology!

Behavioral rules — people rules — are a distinctive feature of the business rules paradigm.  All behavioral rules are business rules — people rules are always under business jurisdiction.

You may have noted that none of the examples of business rule statements given above (or anywhere in these articles) use if-then syntax.  A major reason is that if-then syntax is not well suited for expressing behavioral rules.[2]  See Sidebar.

Behavioral rules have fundamental implications in several areas:

Reasoning.  Since behavioral rules can be broken, they require special care in reasoning (automated or otherwise).  Consider the behavioral rule:  A gold customer must be allowed access to the warehouse.  It cannot be assumed that the business rule has always been faithfully enforced; therefore, it cannot be inferred that in every situation where it was appropriate for a gold customer to be allowed access to the warehouse, the customer actually was allowed such access.  Violations happen.  Reasoning must be carefully restricted in this regard for behavioral rules.

Processes.  Behavioral rules have significant (and perhaps surprising) consequences for modeling processes.  A key question in that regard is how the business selectively responds to violations of any particular business rule (if at all!).  That question, in turn, raises the issue of how strictly each behavioral rule should be enforced — that is, its appropriate level of enforcement

Guidelines

Consider the behavioral rule:  An order over $1,000 must not be accepted on credit without a credit check.  Suppose this behavioral rule is restated with a should instead of a must such that it reads:  An order over $1,000 should not be accepted on credit without a credit check.  Now does it express an advice (non-rule)?

No.  It is still a business rule, only with a lighter sense of prohibition.  What actually changed was its presumed level of enforcement.  Rather than strictly enforced, now the business rule has the sense:  It's a good thing to try to do this, but if you can't there's no sanction.  In other words, now it's simply a guideline (or suggestion, if you prefer).

Should you use should or should not (or similar forms) to express a lightly-enforced behavioral rule?  Not recommended.  In general, it's better to use consistent wording for all behavioral rules (e.g., must or must not).  Remember, the level of enforcement for any given business rule often varies with changes in business practice.  Guidance is one thing; level of enforcement is another — best not to mix the two!  By the way, that's why you don't find guideline in Figure 1.

Two other things about guidelines:

Vocabulary.  A guideline for business operations — just like an advice (non-rule) or any other business rule for the same business — is expressed using the same underlying vocabulary.  Note that in Figure 1 all elements of guidance are based on fact types.  Let's put it this way:  If you have the vocabulary to express your business rules, you already have the vocabulary you need to express any guideline.

Guidance Message.  We say that a business rule statement is the guidance message.  This remains true for guidelines.  A guideline can indeed be violated, but no enforcement action is taken.  Instead, the end user (if authorized) is simply informed.  If you think of business rules simply as hard-and-fast constraints, you're missing an important part of the picture.  In the larger sense, business rules are always about dispensing basic business knowledge in real time.  Guidelines are an important part of that overall scheme.

Definitional Rules

Additional business rules would be relevant to evaluating the behavioral rule:  A gold customer must be allowed access to the warehouse.  Specifically, what criteria should be used for determining whether a particular customer is gold or not?  Here is an example:  A customer is always considered a gold customer if the customer places more than 12 orders during a calendar year.

Such business rules are called definitional rules.  Definitional rules always carry the sense of necessity or impossibility.  To reflect that sense, RuleSpeak prescribes the rule keywords always or never to express a definitional rule.[3]

Let's return to our two business rules.  Suppose a customer appears at the warehouse, but the security guard is unaware of the criteria expressed in the definitional rule, or misapplies that criteria.  Quite possibly the customer will not be given due access.  The error, however, manifests itself as a violation of the behavioral rule, not the definitional rule per se.  Definitional rules can be ill-conceived, misunderstood, or misapplied, but they cannot be directly violated.

Unlike behavioral rules, not all definitional rules are business rules.  The reason is that not all definitional rules are under business jurisdiction.  As mentioned earlier, the 'law' of gravity is obviously not under business jurisdiction.  Neither are the 'rules' of mathematics.

Evaluation of a definitional rule always classifies or computes something using all known facts.  For example:

Classification RuleA customer is always considered a gold customer if the customer places more than 12 orders during a calendar year.

Given any customer, evaluation of this definitional rule indicates whether the customer is or is not gold given all known facts.

Computation RuleThe total price of an order item is always computed as the product unit price times its quantity.

Given any order item, evaluation of this definitional rule indicates the one result for total price that the known facts justify.

During business operations, definitional rules are used to evaluate 'where you are' — that is, the current state of affairs — as the need arises.  For example:

  • Is this customer a gold customer or not?
  • Do we owe this customer a discount on this order?
  • Does this patient have cat scratch fever or something else?

The result reached in each case is only as good as the decision logic given by the business rules.  Poor or misapplied guidance yields poor or inconsistent results.  In that case, some aspect of the knowledge 'breaks down' — it simply does not work properly.

Behavioral rules and definitional rules are fundamentally different.  Disregard for behavioral rules leads to violations and possible sanctions; misapplication of definitional rules leads to miscalculations and off-base conclusions — but only indirectly, if at all, to violations.

If you are concerned about violations, you always need a behavioral rule.  Consider the example of a definitional rule given earlier:  The total price of an order item is always computed as the product unit price times its quantity.  Suppose a salesman decides to give a special volume discount to a personal friend.  Again, the original business rule is merely for computing; it does not prohibit inappropriate conduct.  For that, you would need a separate behavioral rule — for example:  A special volume discount may be given only to high-volume customers.

For sets of definitional rules, you will often want to understand how their evaluation reaches particular results.  More about that in the Sidebar.

Definitional rules (also called structural rules) are about how the business organizes (i.e., structures) its basic knowledge.  They give shape — i.e., structure — to core concepts of the business. 

Definitional Rules and Definitions

Definitional rules clearly contribute to the meaning of concepts.  Obviously definitions do as well.  In practice, can a clear distinction be maintained between definitions and definitional rules?

Yes.  A good definition focuses on the essence of a concept — the core meaning of the concept to the business.  Definitional rules, in contrast, indicate the exact lines of demarcation — that is, the precise 'edges' of the concept.  Establishing these lines of demarcation is how definitional rules remove degrees of freedom.

For example, consider an 'essence' definition of gold customer:  a customer that does a significant amount of business over a sustained period of time.  Now compare that with the associated definitional rule:  A customer is always considered a gold customer if the customer places more than 12 orders during a calendar year.

The definition expresses the fundamental notion about what gold customer means to the business or, more precisely, to business people.  It is unlikely that basic notion will change — in other words, the notion as defined is very stable.  That stability helps maintain continuity of knowledge within a community over time.  It also aids in training newcomers, as well as in communicating with people outside the business area.  In short, definitions should be aimed at people.[4]

The definitional rule, in contrast, gives precise criteria for determining whether a customer is or is not gold — criteria that quite possibly will change over time.  Any aspect of business practice subject to change should be treated as a business rule, not embedded in definitions.

Another difference between definitions and definitional rules is that the latter frequently provide criteria that would not be so obvious from the definition, for example:  A customer is never considered a gold customer if the customer has been incorporated less than a year.

References

[1]  This discussion of business rules is based on, and consistent with, the OMG 2007 standard Semantics of Business Vocabulary and Business Rules (SBVR).  For more about SBVR, see my article, "The Emergence of SBVR and the True Meaning of 'Semantics':  Why You Should Care (a Lot!)," Business Rules Journal, Vol. 9, No. 3 (Mar. 2008), URL:  http://www.BRCommunity.com/a2008/b401.html return to article

[2]  For additional discussion see the author's article "What's Wrong with If-Then Syntax For Expressing Business Rules ~ One Size Doesn't Fit All," Business Rules Journal, Vol. 8, No. 7 (July 2007), URL:  http://www.BRCommunity.com/a2007/b353.html return to article

[3]  Examples of definitional rules in this discussion use the keywords always or never (or permissible variations) for clarity and emphasis.  In current practice, distinguishing behavioral vs. definitional rules via selective keywords is not the greatest concern.  For practical guidelines, refer to www.RuleSpeak.com. return to article

[4]  Aiming definitions toward people is a BRS-recommended best practice.  It is supported but not required by SBVR. return to article



standard citation for this article:

Ronald G. Ross, "What Is a Business Rule?" Business Rules Journal, Vol. 11, No. 3 (Mar. 2010), URL:  http://www.BRCommunity.com/a2010/b525.html  


 about . . .

 RONALD G. ROSS


Ronald G. Ross is recognized internationally as the "father of business rules." He has Chaired the annual Business Rules Forum since 1997. He was a charter member of the Business Rules Group in the 1980s, and an editor of two landmark BRG papers, The Business Motivation Model and the Business Rules Manifesto. He is active in standards development, with core involvement in SBVR.

Mr. Ross is Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is author of eight professional books, including Business Rule Concepts (2009), a just released 3rd edition of his popular, easy-to-read 1998 handbook. Mr. Ross speaks frequently at industry events worldwide.

Mr. Ross is Co-Founder and Principal of Business Rule Solutions, LLC and is actively engaged in consulting, training and research. He co-developed RuleSpeak®. Mr. Ross gives highly regarded public seminars in North America through AttainingEdge and in Europe through IRM-UK.

For additional information about Mr. Ross, please visit his personal website at www.RonRoss.info.

March 2010
What Is a Business Rule?

February 2010
CRUD in Business Rules: Accident-Prone Decision Logic

January 2010
The Point of Knowledge

December 2009
When is an Exception Really an Exception? The Business Rule Principles of Accommodation and Wholeness

November 2009
Verb-ish Models for Verbalization: Give Us Back Our Verbs!

October 2009
From Rulebook Management to Business Governance: Where Business Rules Fit

September 2009
What You Need to Know About Rulebook Management

August 2009
When Is a Door Not a Door? ~ Basic Ideas of the Business Rules Paradigm

July 2009
General Rulebook Systems (GRBS): What's the General Idea?

June 2009
Becoming Strategy-Driven: The Policy Charter

May 2009
Product Quality and a Longer-Term View: A 'Simple' Matter of Business Policies

April 2009
RuleSpeak® Sentence Forms: Specifying Natural-Language Business Rules in English

March 2009
The Rulebook: To Play Ball You Need Rules

February 2009
Extreme Business Agility (Part 6): A Manifesto-in-Progress on the Semantic Re-Engineering of Products

January 2009
Extreme Business Agility (Part 5): The Optimal Edge of Business Performance

December 2008
Extreme Business Agility (Part 4): Change Deployment Hell

November 2008
Extreme Business Agility ~ Part 3: Examples of Non-Agile vs. Agile Business Capabilities

October 2008
Extreme Business Agility ~ Part 2: A Semantic Approach to Re-Engineering Your Company's Products

September 2008
Extreme Business Agility — Part 1: A Value Chain for Re-Engineering Your Company’s Products

August 2008
My Son, Business Rule Analyst — Governance and Compliance Through Young Eyes

July 2008
Rules vs. Processes (Again) — Part 2: Now for Events

June 2008
Rules vs. Processes (Again) — Part 1: There’s Simply No Need for Confusion

May 2008
Legacy Modernization, Semantics, and the Knowledge Economy ~ Have You Connected the Dots Yet?!

April 2008
The Emergence of SBVR and the True Meaning of ‘Semantics’: Why You Should Care (a Lot!) ~ Part 2

March 2008
The Emergence of SBVR and the True Meaning of ‘Semantics’: Why You Should Care (a Lot!) ~ Part 1

February 2008
The Phoenix Strategy ~ A Lower-Risk Approach to Rejuvenating Systems and Legacy Modernization

January 2008
'Rules of Record' Why 'System of Record' Isn't Enough

December 2007
The Decision Center: A Center of Excellence for Coordinating Business Rules and Other Process 'Smarts'

November 2007
The Latency of Decisions ~ New Ideas on the ROI of Business Rules

October 2007
Legacy Systems -- Poorly Engineered or Over-Engineered? New Insights about Business Rules and Enterprise Decisioning

September 2007
The Value of Decisions ~ New Ideas on the ROI of Business Rules

August 2007
A Case of Dueling Manifestos? Business Rules and Enterprise Decision Management

July 2007
What's Wrong with If-Then Syntax For Expressing Business Rules ~ One Size Doesn't Fit All

June 2007
Are IT Terms Fundamental to Every Business? Not!

May 2007
Are all Rules Business Rules? Not!

April 2007
Are Software Requirements Rules? Not!

March 2007
Are Integrity Constraints Business Rules? Not!

February 2007
From Rule Management to Business Governance, Part 4: Governance Engineers and the Chief Governance Officer (CGO)

January 2007
From Rule Management to Business Governance, Part 3: Re-Engineering the Governance Process

December 2006
From Rule Management to Business Governance, Part 2: Governance and How it Relates to Business Rules

November 2006
From Rule Management to Business Governance, Part 1: Governance and How it Relates to Business Rules

October 2006
Rules and Processes: Examples Showing How They Relate

September 2006
The Meaning of Things: Definitions, Intensions, Rules, and Extensions

August 2006
Re-Vitalize, Don't Just Re-platform! ~ Three Tests for Whether Your Company 'Gets It' with Respect to Re-Platforming Business IP

July 2006
The Dirty Secrets About Your Company's Business IP That Nobody Wants to Talk About

June 2006
A Personal Insurance Saga ~ The Economics of Business Rules

May 2006
Concepts, Definitions, and Rules: RuleSpeak® Practices

April 2006
The RuleSpeak® Business Rule Notation

March 2006
How Rules and Processes Relate ~ Part 6. Point-of-Knowledge Architecture (POKA)

February 2006
How Rules and Processes Relate ~ Part 5. Scripts -- Rule-Friendly Process Models

January 2006
How Rules and Processes Relate ~ Part 4. Business Processes vs. System Processes

December 2005
How Rules and Processes Relate ~ Part 3. Three Best Practices for Designing Business Processes with Rules

November 2005
How Rules and Processes Relate ~ Part 2. Business Processes

October 2005
How Rules and Processes Relate ~ Part 1. The Challenges

September 2005
Rule Quality ~ The Route to Trustworthy Business Logic

August 2005
Decision Tables, Part 2 ~ The Route to Completeness

July 2005
Decision Tables, Part 1 ~ The Route to Consolidated Business Logic

June 2005
Rule Reduction ~ The Route to Atomic Business Rules

May 2005
Essence Definitions and Business Rules ~ Developing Stable Anchor Points for Operational Knowledge

April 2005
Can You Violate Structural Rules? (part 3) ~ The Difference Between Breaking Rules and 'Breaking' Knowledge

March 2005
Can You Violate Structural Rules? (Part 2) ~ The Difference Between How to Compute and How to Behave

February 2005
Can You Violate Structural Rules? (Part 1) ~ The Difference Between Violations and Bad Decisions

 

Janauary 2005
Business Rules and Knowledge Workers ~ Getting to the 'Point of Knowledge'

 

December 2004
Can a Definition be Violated? ~ Definitions and Business Rules

 

November 2004
Rustling Up Good Definitions ~ There's a Lot Less and a Lot More to It

 

October 2004 

Clarifying Clarifications ~ Universal 'And' to the Rescue

 

September 2004 

Relearning the Basics of Communicating ~ Business Semantics and Business Rules

 

August 2004 

The Light World vs. the Dark World ~ Business Rules for Authorization

 

July 2004 

Best-Fit Decision Points ~ How They Fit into the Business Rule Approach

 

June 2004 

What Rule Independence Means to System Models ~ Less and More than You Think!

 

May 2004 

The Semantics Lexicon ~ Terms For The Business Rules / Smart Process

 

April 2004 

Don't Reinvent Rule Engines!

 

March 2004 

Rules And Compliance Tactics

 

February 2004 

Tracing the Path of Rule Reduction

 

December 2003

Do Rules Decompose To Processes Or Vice Versa?

 

November 2003

Should You Encapsulate Knowledge in Modeling Real-World Things?

 

October 2003

Business Rules, Encapsulation, and Models of the Real World

 

September 2003

Business vs. Environment in Business Models

 

August 2003

Requirement Statement vs. Rule Statement

 

July 2003

Rules as Constraints:  On or By the System Design?

 

June 2003

Rules Reveal Events -- Not Actions

 

May 2003

Actions Are Not Rules (and Vice Versa)

 

April 2003

The Definitions of 'Business Rule' and 'Rule'

 

March 2003

Business Problems Addressed by the Business Rule Approach

 

January 2003

About the Business Rules Manifesto ~ The Business Rule Message in a Nutshell

 

November 2002

Business Rules for the Company's Provisioning Processes ~ There’s a Lot More to Reference Data than Just Data!

 

September 2002

The Terminator -- I'll be Back (with Just the Right Term)

 

July 2002

What Does it Mean to be Business-Driven? (Part 2)

 

May 2002

What Does it Mean to be Business-Driven? (Part 1)

 

March 2002

A Telltale E-mail Trail:  The Case for In-Line Business Rule Analysis

 

January 2002

Managing M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (part 2)

 

November 2001

Managing M x N Vs. M + N, Market-Driven Economies, and Other eCommerce Issues (part 1)

 

September 2001

The BRS Rule Classification Scheme

 

July 2001

Minding Your P's and Q's

 

May 2001

RuleSpeak"! -- Templates And Guidelines For Business Rules

 

March 2001

Business Rules In Business Processes ~ Title Rules For Process And Rules For Product/Service

 

January 2001

What Is Rule Management About?

 

November 2000

Let's Make a Deal: A Killer App for Business Rules

 

September 2000

The Re's Of Business Rules

 

July 2000

What Are Fact Models And Why Do You Need Them? (Part 2)

 

May 2000

What Are Fact Models And Why Do You Need Them? (Part 1)

 

March 2000

What is a 'Business Rule'?

 

January 2000

Current Thoughts On Expressing Business Rules

 

November 1999

The Fin de Siegle Legacy Mindset
 

September 1999

Analysis Paralysis Just May Save Your Life
 

July 1999

If We Had Started Coding Already...
 

May 1999

Your Core Business Processes Need a Rule Engine
 

March 1999

Who or What is a True Business Analyst?
 

January 1999

Four Things Wrong with the Way We Develop Information Systems

 

 

 

 





[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ] [ Technical Support ]