A large consulting company recently conducted an assessment of the IT development approach followed by one of our clients that uses our approach for business analysis with business rules. The consulting company judged the approach highly effective because the approach is ‘componentized’ (their description). 

The consulting company meant that business rules are viewed as a component; business processes are viewed as a component; business vocabulary is viewed as a component; etc. ‘Componentized’ may or may not be the right description, but the consulting company hit upon an important point.

Most IT methodologies for requirements development today make no attempt to examine the fundamental questions what, how, where, who, when, and why individually and selectively.  That omission is odd to say the least.  Those six questions are ones all of us ask and answer every day in real life.  The six question words are very basic to our language.

Instead, most methodologies today are centric.  They are process-centric or data-centric or user-story-centric or sometimes even rule-centric or decision-centric.  A centric approach requires force-fitting some or all elements of a solution into a single mold that distorts and submerges other elements.  Worse, a centric approach does little to avoid elements being neglected or omitted altogether.

Business problems are inherently complex and multi-faceted, as are their solutions. So we make every effort to ensure our approach to business analysis is well-factored and balanced – that is, non-centric – right from the start.

A non-centric approach doesn’t make developing winning business solutions harder, just the opposite. By addressing business complexity head on – as naturally factored in the real world – top-quality business solutions are far easier to attain.  Experience proves it time and time again.

~~~~~~~~~~~~

Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015

Get the book: http://www.brsolutions.com/b_building_business_solutions.php

Get the training: Instructor-led, online, interactive training: April 4-6, 2017 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php

©Business Rule Solutions, LLC 2016. www.BRSolutions.com

Let’s put you on the hot spot. You are forced to agree or disagree with the following statement, and defend your answer. What would you say?

Deep subject matter expertise is irrelevant for a business analyst, especially in agile business analysis.

Here’s how I answer: I disagree. How about you?

My reasoning: Actually I agree that deep subject matter expertise is generally irrelevant for a business analyst. Where I disagree (strongly) is that it’s especially true for agile business analysis.

Agile business analysis is no silver bullet. It doesn’t imbue you with magical powers to learn faster. Failing faster to learn faster is simply churn. There’s no end to it.

We’re missing the big picture. Exploring ‘deep subject matter expertise’ you’re not familiar with is a matter of having the right architectural tools to probe knowledge. It’s that deep operational business knowledge that makes subject areas hard.

So you simply need the right architectural techniques to map the knowledge of a domain explicitly. You need to be able to ask probing questions about the domain intelligently without wasting SMEs’ time.

The architectural techniques you need are true business rules and concept modeling (structured business vocabulary). By the way, business rules and concept models can be made to work equally well for both agile and waterfall – and anything in between.

~~~~~~~~~~~~~~~~~~~~~~

Mark Your Calendar: The annual Building Business Capability (BBC) conference is November 6-10, 2017 at the Loews Royal Pacific Resort, Orlando, FL. The BBC is the place to be for professional excellence!

Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Let’s stand back and think for a moment about the future of your business and its approach to business analysis. What’s really important? My elevator pitch would comprise the following insights.

Insight 1. Order-of-magnitude improvements in business agility are possible … and proven.

Every year for the past 15 years at the Business Rules & Decisions Forum Conference[1], we’ve heard one case study after another about how companies have dramatically improved business agility. Time and time again they report having reduced the cycle time of deploying changes to business rules by an order of magnitude or more. Extensive applied experience exists in the field – such initiatives are not at the bleeding edge.

What’s actually required? Two things: Some new techniques and vision. Are we to be forever prisoners of legacy? Only if we let ourselves.

Insight 2. Doing more of the same, just faster, won’t get you there.

You’ll never get to agile business via agile programming and development. Not ever.

A requirements development and design methodology should result in high-quality systems that are inexpensive to maintain and cost-effective to enhance. How well is yours really doing that in that regard?

Insight 3. It’s not about working harder, just smarter.

Most of us are frankly already working about as hard as we can. That’s not the problem. Rather, it’s about working smarter – and producing more effective business solutions. For that you need (true) business architecture.[2] It includes business strategy, business processes and business rules, and business vocabulary (concept model).[3]

Insight 4. It’s about building business capability, not better business software (though that will happen).

Quick Quiz: Which of the following is/are directly about software?

• Business rules.
• Business architecture.
• Business strategy.
• Business processes.
• Business vocabulary.

None of them! Of course you can use software to manage and implement any of them, but that’s a very different matter. If they’re not about software, then what? Architecting real solutions for real business challenges. Building business-oriented, business-based business capability. Any business software solution that doesn’t base itself today on these new fundamentals will be LOD – legacy on delivery. It’s time we move beyond instant legacy. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com  

The Question: I asked for feedback on LinkedIn about using agile for target business problems focusing on an area subject to regulations, contract terms & conditions, agreement/deal provisions, business policies, etc. (Sound like your area?) The best reply I got back …       Guest Post by Sujatha Ramesh Sr. Manager, Business Solutions at LearningMate “In highly regulated environments, documented evidence of decisions, impact and approvals are a necessity. Agile practices discourage maintaining extensive documenting, relying on ‘sitting next to the team and explaining’ instead. You will generate precious little proof of what transpired and the decisions taken in doing so.”

A Business Analyst recently said, “Business Rules themselves tend to be too unstructured to stand alone “. Au contraire! Well-expressed business rules are discrete, specific, and context-independent. Think about laws, regulations, contracts, agreements, deals, policies, etc. as common sources for business rules. Business rules are interpretations that make those things practicable. Those things can certainly stand alone. So can the interpretations. The test of ‘practicable’ (the term used in relevant standards) is ‘Can a worker who is authorized and capable know what to do or not to do as a result of reading it?’ Business rules must be well-structured to pass that test. More broadly, ‘practicable’ means ready to deploy into the business for workers to follow, or to pass over to IT as part of requirements in building systems – either way with the same results. Practicable business rules are encoded know-how of the business, vital operational IP. They are explicit, not tacit, so they can be retained, managed and re-used. Business rule management is the most practical means around for meaningful knowledge retention.

Let me re-clarify what I am, and am not, saying about business rules and black swans. There’s been some confusion. I did not say that preparing for or responding to black swans is all about business rules. (I’m not that naive!) I did say, however, that business rules “… build robustness to negative [black swans] that occur and being able to exploit positive ones” [Taleb’s words]. My main point is this: If you don’t have ready access to your current business rules (i.e., know what they are in depth), then when a black swan occurs you can’t immediately undertake to respond to negative ones, and exploit positive ones. (See: http://goo.gl/Ny2Cn) A colleague wrote: “For example, Taleb cites 9/11 as an example of a black swan. What business rules would prevent or allow successful response to that?” I make no suggestions about prevention. Hindsight is 20-20. But successful response? You need to quickly review what your current business practices (business rules) are …

• Permissible carry-ons. Box-cutter knives? Immediately banned. Any other sharp items including silverware for meals, banned.
• Access to the cockpit. Special barriers (food cart, steward(ess)) put in a blocking position when a pilot exits the cockpit to use the lavatory. Doors locks reinforced.

We learn as we go. Amounts of liquid over a certain threshold, banned. Shoes must be removed at security. Souvenir ‘blizzard’ globes, banned. You want to roll out these new business rules fast(!). If you don’t know what business rules you already have in place, you simply can’t respond as fast you need to. Make no mistake, most businesses today sadly don’t really know what their current business rules are. That’s what I’m saying!

I’ve gotten a lot of excellent response to yesterday’s post on black swans. Let me summarize yesterday’s points and continue the line of thought.

a. Business rules cannot be used to help protect against unforeseeable events that have not already happened. b. Business analysts can assess unforeseeable events (black swans) and develop business rules to cater for their potential recurrence.

c. If you don’t have ready access to your current business rules (i.e., know what they are in depth), then when a black swan occurs you can’t immediately undertake point b.

Point c is actually where my emphasis lies. The result is that the organization remains vulnerable for recurrence (and copycat malicious attacks) for a much longer period than necessary (or desirable). How long extra? At least days, more likely weeks, sometimes months. What most organizations don’t realize today is that they don’t actually know what their business rules are. Before they can even begin to rethink business practices in-depth they have to send out ‘scouts’ (business analysts and IT professionals) to discover their current business rules (from people’s heads, source code, procedure manuals, documentation, etc., etc.). When the scouts do find the current business practices (business rules), they have to sort through redundancy, inconsistency, gaps and conflicts. That’s simply no way to run a business! There’s no single-sourcing of business rules, no official, authoritative ‘rulebook’, no structured corporate memory. The result is huge loss of time and energy. The problem is so big it’s hard to see. We simply have to face up to the fact that current methodologies produce a crippled business governance process. And yes, the situation *is* that bad! ~~~~~~~~~~~~~~~~~ P.S. To single-source business rules and retain corporate memory about them, we recommend a ‘general rulebook system’. See http://www.brcommunity.com/BBSGlossary.pdf (page 30) for quick explanation.

We preach (and practice) strategy as a key element of business analysis. A key element of strategy is identifying significant business risks. We address such risks in the deliverable we call a Policy Charter. See http://www.brcommunity.com/BBSGlossary.pdf (page 39). Appropriate business policies are developed to protect the company. Sometimes we hear the argument that it’s impossible to determine the risk of some future unknown event. And what’s a rational definition of risk anyway? By “risk” we simply mean what the dictionary (Merriam-Webster Unabridged) means: 1: the possibility of loss, injury, disadvantage, or destruction : CONTINGENCY, DANGER, PERIL, THREAT Yes, the following statement is correct: “It is impossible to determine the risk of some future unknown event.” The operative word in that is unknown. How could anyone argue with that? The implicit reference is to black swans … unpredictable outliers. The only thing business analysts can do to help protect the business against black swans is “… build robustness to negative ones that occur and being able to exploit positive ones.” (Wikipedia on Taleb’s book The Black Swan: The Impact of the Highly Improbable). I maintain that business solutions based on business rules do exactly that. To respond successfully to unforeseen circumstances you must know what your business practices (business rules) are in the first place(!). On the other hand, business people generally do have a good understanding of known business risks. We think it’s crucial to factor that understanding into business analysis. Now who could argue with that?!

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #4 Question: What role should business rules play in business analysis? Business rules are what you need to run the business. You would need them even if you had no systems. So it makes sense that business rules should be captured and expressed in a form that business people and subject matter experts can understand. That way they can ensure that the business rules are correct. If you are designing systems – and that usually is the case – there’s simply no point implementing rules that aren’t correct. So the Manifesto says …

5.1 Business rules should be expressed in such a way that they can be validated for correctness by business people.

Validation and correctness, however, are not the only focus for business analysis with business rules. Another is whether each rule can be justified as being truly productive for the business. Businesses often accrue so many rules over time (include ‘exceptions’ in that!) that their spiraling complexity results in rapidly diminishing return. So the cost-effectiveness of every business rule should be assessed, at least informally. To do so, first you must recognize there is cost associated with each rule. The Manifesto makes that point explicit …

8.2 Rules always cost the business something.

A rule’s true cost, however, might not be exactly what you think – the platform costs may be relatively insignificant. Instead, the principal cost of most rules is organizational. Rules must be documented. They must be taught to new hires. They must be explained to external parties. All these things take time – and time is money. Also note carefully: This overhead doesn’t decrease with each additional rule – it increases. The more rules, the more complexity. The Manifesto in no way suggests that more rules is better. Just the opposite; it emphasizes that a smaller number of good rules is always better. Better to start with a smaller number, then add more as you go. The Manifesto puts it this way …

8.5. An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

It’s simply a myth that you have to know all the rules before designing and building productive business systems. Just the opposite is true. You can deploy a simpler solution initially, then add rules later on as time and insight permits. Fortunately, rule-based systems are extremely good at incremental design – the goal of many an agile project.