incremental design: developing a system through repeated cycles (iteratively) and in smaller portions at a time (incrementally)
Business rules are unsurpassed for step-by-step enhancement of deployed know-how in business capabilities over time (incremental design). The Business Rules Manifesto[1] puts it this way: “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.” That’s exactly what you need for know-how retention and to move pragmatically toward the know-how economy. Support for incremental design with business rules is quite straightforward. For example, a decision task might start off manual (performed by humans). As time and resources permit, decision rules for handling the simplest cases can be captured and encoded, removing these cases from the manual workload. Perhaps you start supporting a modest 20% of all cases. The only required changes to the system to support additional cases are to specify:(1) What new cases are covered (by providing appropriate selection criteria).
(2) What new outcome(s) are needed (if any) for the new cases covered.
(3) What new (encoded) decision rules should be used for the new cases.
At a subsequent time, you ramp up to 50% of all cases, then perhaps 80%. You may never get to 100% – nobody is talking about taking humans completely out of the loop for every operational business decision(!). The net result is simply applying human resources where best suited, the really hard cases.Discussion: Even the words used for the building blocks of business models (e.g., the vocabulary used to develop structured business vocabularies) must be natural for business people – again, real-world. Business people talk about real-world things!
A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms. Developing a business solution using a future-form business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding.
Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (fact models), business milestone models, and Q-Charts (for decision analysis). The term business model is also used collectively to designate all the business models for a particular business capability. A business model is always subject both individually and collectively to the business rules specified for it.
system model: a model that provides a design for an automatable system that is computationally competentDiscussion: For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things. These real-world things are as the business leads see or define them.
A system model in contrast comprises “… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.” Surrogates include data entities in place of real-world things; GUIs and use cases in place of face-to-face, real-world communication; network nodes in place of real-world locations; system events rather than operational business events; and so on.
Does the separation between business model and system model blur in eCommerce? No. If business leads see or define ePersons (for example) as real-world, then real-world they are. To ensure you have a winning business solution, the ePersons should be defined and shaped within a business model. Afterwards comes design of a computationally-competent system model so you can conduct actual business with the ePersons. [John Zachman, informal communication, June 2011] ~~~~~~~~~~~~~~~~~~ Excerpted from 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, http://www.brsolutions.com/bbs1. First, is there a systematic reason to believe we are underestimating risk and or consequences? That’s a matter of data and analytical methods, and there are lots of people trying to find out. We know that when disaster models are misused, like the financial models, they will tell us garbage with results that may shock us. Again, where’s the news in that. Don’t misuse the models and put into place precautions against doing so.
2. Second, even if the data suggest we need fatter tails (long-standing procedures exist to do that), there’s a policy/greed question. Will finance and insurance companies put enough in their reserves to reflect the risks they face? Or, as a matter of policy, lack of regulation, competitive market pressures, and self-deception, will they simply close their eyes, cross their fingers, and discount cognitively what low risk means, e.g. non-zero risk?
Reminding us of rare, high consequence events is fine. Calling them “Black Swans” doesn’t add anything substantively, although it’s an effective metaphor. But the greatest contribution is in answering the latter two questions I’ve posed. ~~~~~~~~~~~~~~~ Have a look at my recent posts on Black Swans, strategy, and business rules … Search on “Black Swans”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.What in your current IT requirements methodology ensures you will get consistent results for each business rule across all these processes, procedures, and use cases?
Unfortunately, the answer today is almost always nothing. In the past, business rules have seldom been treated as a first-class citizen. No wonder legacy systems often act in such unexpected and inconsistent ways(!). Organizations today need business operation systems where business governance, not simply information, is the central concern. Business rules should be seen as one of the starting points for creating system models – not something designers eventually work down to in use cases. That’s the tail wagging the dog. By unifying each business rule (single-sourcing), and faithfully supporting all its flash points wherever they occur, Business Analysts can ensure consistent results across all processes, procedures, and use cases. Is there really any other way?! ~~~~~~~~~~~~~~~~~~~ Excerpted 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, 2011, 304 pp,http://www.brsolutions.com/bbs