Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Business Rule Manifesto FAQs Added to BRCommunity.com

I am pleased to announce that a comprehensive set of authoritative FAQs about the Business Rules Manifesto has been added to BRcommunity.com: http://www.brcommunity.com/brm.php The Manifesto is celebrating its 10th anniversary this year – and remains as powerful and as vibrant to today’s business challenges as ever. I will be covering a good many of its insights in my Sunday tutorial, Business Rules: The Why and the What, at this year’s Business Rules Forum conference, part of BBC2012 (Oct. 28 – Nov. 2, Ft. Lauderdale, FL): http://www.buildingbusinesscapability.com/ The FAQs explain in-depth how the Manifesto relates to a great many pressing issues on today’s business agenda, including …
    • Requirements
    • Business Processes
    • Business Analysis
    • Business Agility
    • Enterprise Architecture
    • Zachman Framework  
    • Knowledge Retention
    • Events
    • Enforcement
The new BRCommunity Insider also provides insight into the general positioning and structure of the Manifesto, as well as point-by-point clarification of individual Principles. The Manifesto is just 2-pages and free. It has now been translated into some 15 languages: http://www.businessrulesgroup.org/brmanifesto.htm The Manifesto is a rare thing in our field – a timeless work that seems more and more prescient which each passing year.

Continue Reading

Business Model vs. System Model – Very, Very Different … Do You Get the Difference?!

You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf ~~~~~~~~~~~~~~~~~~~ business model:  a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people

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-worldBusiness 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 competent

Discussion:  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/bbs

Continue Reading 1 Comment

“Business Rules Are Too Unstructured to Stand Alone.” Au Contraire!!

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.

Continue Reading

‘Rules of Record’ … Why ‘System of Record’ Isn’t Enough

Business computing today is characterized by a tangled web of interfaces and data movement from system to system, from source to sink. Knowing the official ‘systems of record’ is basic for resolving discrepancies and demonstrating compliance. But that’s merely a start. What your business really needs today is to know the rules of record. A focus on business rules, rule management, and decision management makes that possible. This post explains. First a little background. If every piece of data in the organization had a single, clear home, identifying official versions would be easy. But in today’s world, operational data is extracted, merged, massaged, re-platformed, and reported many times over, often obscuring original sources. Identifying a ‘system of record’ establishes which source is official for each element (or chunk) of data. In other words, it gives you physical traceability back to source.[1] That’s a first and very basic step for compliance. What physical traceability doesn’t do is explain why that source may have a different value from the copy of the data you’re actually seeing. You might call that difference semantic drift (although that term probably dignifies what often is just plain sloppiness about the meaning and use of data). Since you can’t be sure what rules were applied to create the official version, you can’t easily do a delta on what you’re actually seeing. In other words, you have no semantic traceability back to source. From a compliance point of view, knowing the rules for source data is paramount. Of course, if those rules never changed, you might be able to reconstruct them at an acceptable price when and as needed for compliance. But today, change — at an ever faster pace — is the name of the game. Add massive personalization and customization to the mix and you quickly reach an impossible threshold of complexity and expense. The solution is simply never putting yourself in a position of having to reconstruct rules. Rather, you want to manage rules in such way to keep them ‘on the record’ — i.e., to maintain rules of record for each operational business decision your company makes. Impossible? Not at all. That’s exactly what business rules, rule management, and decision management is all about. There is proven technology to support it.[2] All you need to do is change how you look at the problem. References [1] For additional background on ‘system of record’ see: http://en.wikipedia.org/wiki/System_of_record http://www.yourwindow.to/information-security/gl_systemofrecord.htm [2] For example, Raden and Taylor write, “Logging rules as they execute to create a record of how a decision was made is a common requirement of decision services. They can be managed like a typical logging requirement, except that using business rules makes it easier. Using business rules also makes it possible to use the logged information in both customer-facing and regulatory conversations, because the rules are more user-friendly.” James Taylor and Neil Raden, Smart (Enough) Systems: How to Deliver Competitive Advantage by Automating Hidden Decisions, Prentice-Hall (June 2007), ISBN: 0132347962, p. 358. ~~~~~~~~~~~~~~~~~~ The original version of this post appeared as: “‘Rules of Record’ ~ Why ‘System of Record’ Isn’t Enough,” Business Rules Journal, Vol. 9, No. 1 (Jan. 2008) http://www.BRCommunity.com/a2008/b385.html

Continue Reading

The End of Words?

Will we ever stop needing words to write business rules? No. So long as businesses sign written agreements, follow regulations, verbalize business policies, capture product/service know-how, write guidelines and instructions, etc., we will need words and RuleSpeak-like sentences[1]. Businesses will always need traceability to prove compliance, fidelity with business intent, and validity of reasoning, and those are all things ultimately only words and sentences can do.


[1] See www.RuleSpeak.com for free guidelines.

Continue Reading

Business Rules and Enforcement: One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #10 Question: How does the Manifesto view the issue of business rule enforcement? Principle 4.6 of the Manifesto states …

Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

Why? Separation of rule specification from enforcement concerns[2] ensures that …
  • The true business intent of the rule itself can be directly validated. Enforcement concerns do not mix things up.
  • The greatest degree of business agility is achieved. Changes to enforcement specifications and changes to the rule itself can be made independently.
  • The highest degree of re-use is supported. The same rule can be subject to different enforcement specifications at different points of application.
Specifying rules independently of responsibility for enforcement is taken to mean all the following.
  • Who. If responsibility for enforcing the rule is given to some role in the organization, that role should not be mentioned in the statement of the business rule.
  • Where. If responsibility for enforcing the rule is assigned to some component of the technical architecture, that component of the technical architecture should not be mentioned in the statement of the business rule.
  • When. In general, every business rule applies to multiple events (flash points). However, those events should not be mentioned in the statement of the business rule.
  • How. If capability for enforcing the rule is laid out in some process or procedure, that process or procedure should not be mentioned in the statement of the business rule.


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.
[2] For discussion of enforcement specifications, see Breaking the Rules: Breach Questions http://goo.gl/MFxtN

Continue Reading

Your Current Requirements Approach: A Very Big Question Mark

Each business rule usually produces multiple flash points.  Don’t know what a flash point is? I think you should! See a brief explanation: http://goo.gl/pl9sT. Why is this insight so important?  The two or more events where any given business rule needs to be evaluated are almost certain to occur within at least two, and possibly many, different processes, procedures, or use cases.  Yet for all these different processes, procedures, and use cases there is only a single business rule. Now ask yourself this (the very big question): 

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  

Continue Reading

What Role for Business Rules in *Business Analysis*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th 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.  


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading

What Role for Business Rules in *Requirements*? One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #2 Question: How do business rules fit with requirements? Rules are all around us in the real world – in the games we play, in the laws and regulations of society, in the limits we set for our children – everywhere. Yet for whatever reason, rules are seldom featured in requirements and IT methodologies. That’s very strange if you think about it. So the very first point of the Manifesto aims to correct that omission, and by doing so, to bring better balance to requirements …  

1.1 Rules are a first-class citizen of the requirements world.

This first point does not suggest that business rules are more important than other requirements – for example, process models – but rather, co-equal. How can you organize or model any kind of activity without knowing the rules?! That understanding leads to the second point of the Manifesto

1.2 Rules are essential for, and a discrete part of, business models and technology models.

The “discrete part of” in this statement is crucial. It means that rules should not be embedded in other deliverables – for example, use cases – so that the rules can be written once and then applied everywhere (single-sourcing). It also means the rules can be validated directly with business people and subject matter experts. The result is better requirements – and better communication. Another result is rule independence. The rules can now evolve independently of other architectural components, often much faster. By not hard-coding rules into application programs, much more agile business solutions can be achieved. The Manifesto makes the point this way …  

6.1 A business rules application is intentionally built to accommodate continuous change in business rules.  The platform on which the application runs should support such continuous change.

 


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.

Continue Reading 1 Comment

Requirements Management and the Business Motivation Model

Guest post by Cecilia Pearce ~~~~~~~~~~~ I have just completed the “Business Analysis with Business Rules: From Strategy to Requirements” on-line training session given by Ron Ross and Gladys Lam.[1] This approach has additional benefits where requirements are concerned. During the session, it became evident that some of the requirements processes defined by BABOK® – Requirements Elicitation, Prioritization and Traceability – may be simplified when following the Business Motivation Model (BMM)[2] approach. The BMM approach emphasizes starting with strategy for addressing the business problem. Being top-down and structured, it ensures that defined requirements are based on the business goals identified for the organisation. Since the source of the requirements is therefore known, their prioritization is simplified. Requirements linked directly to the goals will have a higher priority, whereas other requirements, depending how linked to the goals, may be allocated a lower priority. Traceability of requirements also benefits from the BMM approach. The requirements are already associated with the goals, possible business risks are identified, and relationships are traced to business processes, business milestones, and key performance indicators. The requirements elicitation process is just another benefit of the BMM approach. Requirements are defined with the goals in mind. The Policy Charter[3], a deliverable in the style of the BMM, illustrates the goals in more manageable segments and links the requirements directly to the identified goals. It allows the business stakeholders to ‘see’ their end result more clearly and understand what steps are required to get there.
[2] BMM is the strategy standard originally developed by the Business Rules Group, and subsequently adopted by OMG. See http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf.
[3] Business Rule Solutions’ Policy Charter was a basis for the BMM, and is consistent with the standard.
 

Continue Reading