Business Analysis with Business Rules

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross
Gladys S.W.  Lam
Gladys S.W. Lam Co-Founder & Principal, Business Rule Solutions, LLC , Publisher, Business Rules Journal and Executive Director, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Gladys S.W. Lam
Excerpted with permission from Building Business Solutions:  Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October 2011, 304 pp.  URL:http://www.brsolutions.com/bbs

Continuous change is a central fact of life for business these days.  The techniques you use for business analysis must be based on the assumption that business rules will change, often quite rapidly.  The best business solution is one that caters to such change, always doing so in the manner friendliest to business people and Business Analysts.

What other issues should techniques for business analysis be addressing these days?  In addition to continuous change:

  • Capturing, managing, and retaining business know-how.
  • Enabling more effective business governance.
  • Making compliance (with business rules what else?!) more effortless.

None of these challenges is well served by the kinds of information systems we’ve built in the past.  We need to engineer a new kind — business operation systems.

The challenge is not about fixing software engineering practices.  It’s about changing them fundamentally.  We think it’s way past time they were.  Current practices probably miss as much as 90% of everything important in running the business(!).

What a Business Rule Is

A business rule is a criterion used to guide operational business behavior, shape operational business judgments, or make operational business decisions.  Business rules are only indirectly about system design or behavior.  Your business would need its business rules even if it had no software.

Alignment

Everyone asks:  How do you close the gap between the business and IT?  We think that’s the wrong question.  You want to do that, sure.  But the question as posed more or less implies the solution will be organizational, whether by new styles of interaction, better project management, restructuring, or other means.

Instead, we think the key to an effective solution is architecture.  Use the right architectural approach and the organizational issues will take care of themselves (one way or another).  So we ask:  How do you align business operations with business strategy?

To be frank, most Business Analysts lack the standing in their organizations to pull off enterprise-level solutions.  We hope that situation changes (and over time, we believe it will).  Experience suggests taking smaller steps is wise.  (We didn’t say small steps, just smaller). 

So we right-size the question to the more achievable, smaller-scale equivalent:  How do you align business capabilities with strategies for solving business problems?  Success at that level of alignment fruitful (and challenging) enough(!).

What a Business Capability Is

A business capability is not an application system, database, set of use cases, enterprise architecture, or any other IT artifact.  Its design and implementation might depend on some or all of those things, but that’s a different matter.

Instead, a business capability is created as a business solution to an operational business problem.  That solution and the problem it addresses have a scope (definite boundaries) that can be identified in terms of what business items make it up.  The business solution is initially developed and expressed as a business strategy — what we call a Policy Charter.

The business model you create in business analysis is the business architecture for the business capability, a blueprint enabling business people and Business Analysts to engage in a business discussion about what needs to be created, managed, operated, changed, and discontinued.  Developing a business solution using a business model does not necessarily imply software development, but if software development does ensue (and it usually does), the business model provides a solid grounding.

Our definition of business capability comes down to this:  What the business must know and be able to do to execute business strategy.

You'll notice we keep repeating business as a modifier (business solution, business problem, business capability, business model, business strategy, business rules, and so on).  We do it in practice too.  It’s a reminder that our focus is always on business things, not system or IT things.  When we say business, we mean business.

Basic Principles for Business Analysis

You can see already we’re very careful about how (and when) to ask questions.  How you ask questions makes all the difference in the world.  Question the questions!

Basic Principle for Business Analysis: Always seek to ask the right question in the right way of the right people at the right time.

In creating a business model we also take great care never to use ITspeak in talking with business people.  IT terminology provides an easy and understandable reason for business people to drop out of business discussions.  A business model is always about real-world things, represented using terms that business people would naturally use.

Basic Principle for Business Analysis: Use no term in talking with business people about the business they wouldn’t use naturally.

Avoiding all ITspeak is hard.  Many familiar terms assume development of software systems.  Two examples: use case and data model.  Both terms originated from IT and imply a system.  In developing business models you don’t need those terms(!).

Here’s a related point.  ‘Users’ exist only if you’re thinking about building an IT system.  We avoid the term.  In the business context, business people are not ‘users’, they are the central actors in the day-to-day drama of business activity.  Anyway, everybody is a ‘user’ of some system these days, so ‘user’ doesn’t much discriminate anything.

Basic Principle for Business Analysis: Never say ‘user’.

Now we confess that last one is hard.  It takes practice.  We still slip up once in a while ourselves.

Change Deployment Hell

A business manager at a very large health care organization recently confided to us that making a change to business rules of even moderate complexity took their organization 400 person-days over a 4-month period.  That’s staggering.  How could it be sustainable?  Their organization, like many today, is living in change deployment hell.

The manager went on to observe that a subtle stagnation had crept into the staff’s very way of thinking about the business.  He noted that they often don’t even consider business innovations they know from experience to be difficult for the existing systems to handle.  He wondered out loud whether they could even think through any real business innovation effectively any more.  The bottom line:  They needed a new approach, not more of the same.

By the way, the people at this organization were hard-working and very engaged in their activities — they did want to deliver good quality.  That wasn’t the problem.  Indeed, we find most people in our field to be very professional and to have the best of motivations.

We can do better than that, smarter than that — we can and we should.  Ask yourself this fundamental question:  Do you really want to continue embedding the business rules you need to run the business in application programs?!

We would assume you don’t.  You want pragmatic, proven approaches for identifying and externalizing business rules from all other artifacts produced in business or system analysis.  In short, we treat business rules as a first-class citizen.  We think everybody should.

Can you really engineer business rules separately from requirements for application software?  Absolutely.  It’s a proven fact.

Business Rules vs. Requirements

Let’s be very clear that business rules and requirements are not the same thing.  When you set out to create a software system, business rules can imply requirements — but that’s a different matter.

Here’s a major difference:  Requirements evolve before deployment of a system; business rules evolve after deployment of a system.  That affects everything.

To bring the distinction into perspective, consider data for a moment.  Would you consider actual business data — not the data definitions but the actual data itself — to be part of requirements?  No!

The life cycle of data and the life cycle of requirements are simply not the same.  The life cycle of requirements, no matter what methodology you use, more or less ends with official software release.  For data, in contrast, that’s just the beginning of life.  The data persists.  More importantly it changes over time.  That’s the very essence of doing business.  It’s so obvious we take it for granted.

Real Life Begins at Deployment

The very same is true for business rules.  Official software release is just the beginning of their life.  They persist.  More importantly they change, sometimes rapidly, because a business constantly needs to adjust its business parameters.

Basic Principle for Business Analysis: Always remember the business rules live on.

The distinction between the software development life cycle and the life cycle of business rules is sometimes hard for those in IT to grasp.  Indeed, if you’re looking through the lens of software development methods, you’re almost certain to be confused.  When you look at business rules from the business point of view, however, seeing the distinction is far easier.

Eventually all companies will appreciate the distinction.  Then the need for managing rulebooks as a separate resource (just like databases) will be obvious.  We call that activity rulebook management.  Leading companies are already doing it.

Order-of-Magnitude Improvement in Business Agility

Today’s information systems aren’t agile — even when agile software methods are used to develop them.  Companies need business agility and in most cases, IT simply isn’t delivering it.

We believe you should aim for nothing less than order-of-magnitude improvement in business agility.  Is that possible?  Absolutely!  Here’s a brief case study.

Order-of-Magnitude Improvement:  Case Study

A medium-sized financial services company we visited specializes in detection of credit card fraud.  Suspicious transactions are kicked out to fraud specialists for manual inspection.  These fraud specialists are an expensive and largely non-scalable resource.

Suppose the bad guys pick up and move shop from Idaho to Manhattan.  Transactions deemed suspicious only by zip code suddenly yield a 10x increase in volume.  To keep the volume of kick-outs relatively constant, additional selection criteria (e.g., location of store, type of store, frequency of use, size of transaction, etc.) must be introduced.

Before using business rules, the elapsed time to deploy revised selection criteria was 30-60 days.  By then smart bad guys are already operating somewhere else.  Using business rules, the company decreased the elapsed time to 3-6 days.  Would you say their business had become more agile?  You bet!  That’s an order-of-magnitude improvement.

Summary

Our world is fast-changing, highly-regulated, and knowledge-intensive.  Business operations are highly complex and becoming more so by the day.  Business Analysts didn’t invent the complexity — they are simply the ones who must come to grips with it.

Success requires the right thinking tools to structure the analysis of business complexity.  Business Analysts must be able to bring those tools to the table apply them with business people.

Basic Principle for Business Analysis: Be the master of thinking tools to address business complexity.

Is there any other way?  We don’t see any.  One thing for sure — doing more of the same, just faster, is not going to work.  Existing IT techniques have simply maxed out.  As Kathleen Barret, CEO of the IIBA says, we need to take it to the next level.

We concede the problem is big one.  It’s all around us everywhere we look.  It’s like what an ant crawling up an elephant’s leg can’t see.  The elephant is just too big.  We don’t concede, however, there’s no solution.  We’ve proven there is.  But first you must see the elephant!

# # #

Standard citation for this article:


citations icon
Ronald G. Ross and Gladys S.W. Lam, "Business Analysis with Business Rules" Business Rules Journal, Vol. 12, No. 10, (Oct. 2011)
URL: http://www.brcommunity.com/a2011/b616.html

About our Contributor(s):


Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:


Ron serves as Executive Editor of BRCommunity.com and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on http://www.brsolutions.com/category/blog/. For more information about Ron visit www.RonRoss.info. Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross
Gladys  S.W. Lam
Gladys S.W. Lam Co-Founder & Principal, Business Rule Solutions, LLC , Publisher, Business Rules Journal and Executive Director, Building Business Capability (BBC)

Gladys S.W. Lam is a world-renowned authority on applied business rule techniques. She is Principal and Co-Founder of Business Rule Solutions, LLC (BRSolutions.com), the most recognized company world-wide for business rules and decision analysis. BRS provides methodology, publications, consulting services, and training. Ms. Lam is Co-Creator of IPSpeak, the BRS methodology including RuleSpeak®, DecisionSpeak and TableSpeak. She is Co-Founder of BRCommunity.com, a vertical community for professionals and home of Business Rules Journal. She co-authored Building Business Solutions, an IIBA® sponsored handbook on business analysis with business rules.

Ms. Lam is widely known for her lively, pragmatic style. She speaks internationally at conferences, public seminars and other professional events. She is also Executive Director of Building Business Capability (BBC) Conference, which includes the Business Rules & Decisions Forum and the Business Analysis Forum.

Ms. Lam is a world-renowned expert on business project management, having managed numerous projects that focus on the large-scale capture, analysis and management of business rules. She advises senior management of large companies on organizational issues and on business solutions to business problems. She has extensive experience in related areas, including BPM, structured business strategy, and managing and implementing information systems.

Ms. Lam is most recognized for her ability to identify the source of business issues, and for her effectiveness in developing pragmatic approaches to resolve them. She has gained a world-class reputation for fostering positive professional relationships with principals and support staff in projects. Ms. Lam graduated from the University of British Columbia with a B.S. in Computer Science.

Read All Articles by Gladys S.W. Lam
Subscribe to the eBRJ Newsletter
In The Spotlight
 Jim  Sinur
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.