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!

# # #