Business Analysis with Business Rules

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(!).

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?  You'll find success at that level of alignment fruitful (and challenging) enough(!).

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!

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.

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.

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.

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.

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.

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!

Authors :

Ronald G. Ross is recognized internationally as the ‘father of business rules.’ He is Co-founder and Principal of Business Rule Solutions, LLC, where he is active in consulting services, publications, the Proteus® methodology, and RuleSpeak®. Mr. Ross serves as Executive Editor of BRCommunity.com and as Chair of the Business Rules Forum Conference. He is the author of eight professional books, most recently Business Rule Concepts (2009). Mr. Ross speaks and gives popular public seminars across the globe. His blog: http://www.ronross.info/blog/

Gladys S.W. Lam is a world-renowned authority on business analysis and applied business rule techniques. She is Co-founder and Principal of Business Rule Solutions, LLC, the most recognized company world-wide for business rule methodology, consulting services, and training. Ms. Lam serves as Publisher of BRCommunity.com and as Executive Director of the Building Business Capabilities Conference. She is a recognized expert on project management and is highly active in consulting, mentoring, and training.