A Monthly Article from our Speakers
Current Article of the month
Business Analysis with Business Rules: It’s All About the Business
by Ronald Ross
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. 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.
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. 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(!).
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 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. An example: use case, a term that originated from IT and implies 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. And that’s the we always chose to view them!