Black Swans, Business Rules, and Strategy: What Every Business Analyst Needs to Know
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?!Tags: black swans, business analysis, business risks, business strategy, Policy Charter, risks, strategy, Taleb
Ronald G. Ross
Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.
Terry Roach
| #
Hi Ron,
This is a subject that my team and I spend our time working on as business architects at a regulatory agency in Australia. Our agency is charged with the job of monitoring the institutions in our financial services industry to identify and mitigate risk of failure. Risk Assessment and Response is the name of our core business process.
Unfortunately the view that ‘it’s impossible to determine risk…’ doesn’t wash in our business. We exist for the sole purpose of determining and preempting future risk, which is actually like setting yourself up for failure because no one ever knows about risks that have been mitigated, only the black swans you miss.
The approach we take is to monitor for risk factors that are indicative of future risk and develop preventative responses. Of course it’s not an exact science, but as you say, we believe that a rules based approach works very well for this modelling this type of business problem.
The way we have approached modelling risk in our business architecture is through a state-based model. We envisage and model an enterprise as a state-of-affairs. We decouple ALL business logic from our structural (state patterns) and dynamic (state transitions) models and maintain it in a governance repository made up of three categories of rules (Entitlements, Conditions and Assertions).
To monitor risk, we create Outcome models which are State Patterns for business attributes in the lifecycle of a particular Resource. For example a Risk Assessment (Resource) would follow a life-cycle of Outcome states that might include Created, Reviewed, Responded, Mitigated. Each Outcome can be uniquely depicted by a specific pattern for instantiated attributes of the Resource when it has obtained a particular state.
Three types of Rule logic are applied to the states of these attributes. The first type is the logic which calculates proposed state transitions in instantiating the attributes for a Resource instance. In other words the formulas for calculating what the various risk values would be for attributes such as the Risk Probability and Risk Impact of a particular Risk Factor.
The second type of logic we then apply, identifies where state values have violated Post-Conditional constraints. In other words we identify where risks exist by examining whether any attribute values fall outside of acceptable ranges.
The third type of logic we apply is to determine an appropriate response. In other words the flow logic to define what activities need to occur to address the situation appropriately.
There is a fourth type of logic which I haven’t coved in this scenario, which is to verify the entitlements of the roles participating in the interaction. Like Outcomes, Roles are modelled as state patterns on the attributes of the party attempting to execute an activity and Entitlement rules hold the logic for evaluating the states of those attributes.
It’s much easier to explain with a picture!
The point is that whilst we can’t tell the future, we can be certain it does hold risks. We’re unlikely to ever be infallible in the face of uncertainty. Black swans will occur so we better accept that and get on with being vigilant for the risks we can anticipate and preparing the best possible responses for both risk mitigation and risk recovery.
PS I have to confess to being a disciple of your work, since the BRG manifesto and give you credit for much of the thinking underpinning our business architecture framework. One day I hope to get the opportunity to demonstrate it to you.
Regards
Terry
Ronald G. Ross
| #
Terry, Outstanding response. (And very kind. Thank you.)