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

Breaking the Rules: Breach Questions

What should happen when a business rule is broken[1]? As discussed in this post, Business Analysts should answer three questions:
    1. How strictly should the business rule be enforced?
    2. What message is appropriate?
    3. What response is needed?
Developing a friendly, secure business solution requires overt answers to these questions for at least a subset of business rules. (As explained later, defaults can be assumed for the others.) It should also be possible to easily change or evolve the answers (including defaults) after deployment of the business rules, thus permitting the business capability to become incrementally smarter. The goal is context-dependent, pinpoint reaction to breaches in real-time.  Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation. Breach Question 1.  Enforcement Level How strictly should a behavioral rule[2] be enforced? Example …

Business Rule:  A service representative must not be assigned to good customers in more than 3 states or provinces.

Ask:  How strictly should this business rule be enforced?

Enforcement Level:  Override by pre-authorized actor

Table 1 lists the most common enforcement levels for behavioral rules.[3] Table 1Common Enforcement Levels for Behavioral Rules
Enforcement Level Description
strictly enforced Violations are disallowed in all cases – achieving some newstate successfully is always prevented.
override by pre-authorized actor The behavioral rule is enforced, but an actor with proper before-the-fact authorization may override it.
override with explanation The behavioral rule may be overridden simply by providing an explanation.
guideline Suggested, but not enforced.
  Be sure not to overlook the last enforcement level Table 1.  A business rule that is actively evaluated, but not enforced, is (literally) a guideline. Guidelines are business rules too! Breach Question 2.  Guidance Message What message should be returned when a breach of a business rule occurs? When a business rule is breached, somebody, often a business actor directly engaged in a business process, needs to know about it.  The breach means the work being conducted has strayed outside the boundaries of what the business deems acceptable or desirable.  From a business perspective an error has been made, so some error message should go out.  What should that error message say? As a default, we like to say that the business rule statement is the error message.  From a business point of view, that equivalence must always be true – what else are business rules about?! Rather than saying ‘error message’ (which sounds technical) or ‘violation message’ (which sounds harsh, especially for guidelines), we say guidance message. Generally, guidance messages should be as friendly and as helpful as possible.  For example, guidance messages can be written in a more personal, informative style. More explanation or suggestions can be appended or substituted as desired.  Perhaps a link to other media (e.g., a how-to video) can be provided.  Sometimes the best guidance message takes the form of some icon or signal (e.g., a warning light turning to yellow or red).  Guidance messages frequently need to be specific to the circumstances in which a breach occurs (e.g., what role or user produced it). In all cases, guidance messages should be made available only to people who are qualified and capable. Breach Question 3.  Breach Response Does the breach response for a business rule need to be more selective, rigorous, or comprehensive than simply a message? Example …

Business Rule: A cursory review of a received engineering design must be conducted within 5 business days of the date received.

Ask:  What breach response is appropriate for this business rule?

Breach Response:  The received engineering design must be brought to the attention of the manager of the department by the morning of the next business day.

Breach responses can take any of the following forms:
    • business rule (as illustrated above), or set of business rules
    • processes or procedures
    • sanctions or penalties
    • operational business decisions
    • special notifications, displays or instructions
Multiple breach responses might be desirable for a business rule. They might also need to be specific to the circumstances in which a breach occurs (e.g., what particular part of a process is being performed). Usually, breach responses serve to increase user-friendliness. In cases of potential fraud or malicious business behavior, however, breach responses should be much more aggressive. Defaults Natural defaults for the three breach questions are listed in Table 2. Table 2.  Defaults for the Breach Questions
Breach Question Default
enforcement level strictly enforced
guidance message the business rule statement itself
breach response none
 
[1]Fundamental to business analysis with business rules is the assumption that breaches of business rules can be detected.  If you can’t detect breaches, how can you run the business?! To say it differently, if you can’t detect breaches of a business rule, but you can still run the business, perhaps you don’t need the business rule at all(!).
[2]This breach question applies only to behavioral rules. Since definitional rules must always be true, they are in essence strictly enforced.
[3]Table 12-1 of Business Rule Concepts, 3rd Ed. (Chapter 12) discusses additional enforcement levels.  It also provides tips for designing procedures with business rules.

Continue Reading 3 Comments

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

Business Model vs. System Model: eCommerce

In yesterday’s post I talked about the difference between business models and system models: http://goo.gl/CMMPi  To make a long story short, business models talk directly about real-world things (as business people do); systems models talk about surrogates for real-world things (as system designers do). Not the same thing! Some people argue that the separation between business model and system model blurs in eCommerce. Does it?  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 those ePersons.

Continue Reading

What’s the Difference Between Business Requirements and Functional Requirements?


We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3 Hope to see you there! Naturally, we’ll be talking a lot about business requirements. Are business requirements the same as functional requirements? No! Functional Requirement vs. Business Requirement Wikipedia describes a functional requirement as … “a requirement that defines a function of a software system … what a system is supposed to accomplish” [emphasis added] We define a business requirement as … “something called for or demanded by a business model that a system model must support” That’s a big difference! Appreciating the importance of the difference, however, requires clear understanding of the distinction between business model and system model. Business Model  We define a business model as follows[1]a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people We stress that business people talk about real-world things! And why should we ask them to do any differently?! 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 to-be 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 (concept models), business milestone models, and Q-Charts (for decision analysis). Any business model is always subject both individually and collectively to the business rules specified for it(!) We believe business rules are key to creating effective business requirements. System Model We define a system model as follows … a model that provides a design for an automatable system that is computationally competent 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.  That idea is actually his, not ours. Zachman describes a system model, in contrast to a business model, as comprising “… 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 or business objects 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.
  • etc.
If you are developing ‘requirements’ using use cases, you are actually designing a system (creating a system model), not defining business requirements(!). We believe a focus on use cases with no prior business model puts your project at grave risk.
[1]Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, 2011, 304 pp.http://www.brsolutions.com/bbs
 

Continue Reading

Understanding Strategy as a Key Business Analysis Tool: It’s Not Business Process!

John Matthias recently wrote this about our new book, Building Business Solutions: Business Analysis with Business Rules[1]:

“I especially liked the discussion about the mission and goals. I still see business process analysis in organizations I visit where the goals are not articulated well, and the results are not useful. (I’ve done it myself.) It’s easy to get lost among the trees, unaware of the contours of the forest or what direction you’re going.”

Indeed! That’s why we came up with the Policy Charter, which is the deliverable in our approach that lays out the elements of strategy and their motivation.  A Policy Charter is all about business goals, business risks, and business policies. It’s not about business process! [2] How do you distinguish between good business strategy and bad business strategy? Noted strategy expert Richard Rumelt distinguishes the good and bad as follows.[3] Good Business Strategy Rumelt, p. 20: “good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests.  Strategy is at least as much about what an organization does not do as it is about what it does.” Rumelt, p. 243: “good strategy is, in the end, a hypothesis about what will work.  Not a wild theory, but an educated judgment.  And there isn’t anyone more educated about your [business] than the group in [the] room.”  Bad Business Strategy Rumelt, p. 32: Bad strategy “… is not simply the absence of good strategy.  It grows out of specific misconceptions and leadership dysfunctions.  To detect a bad strategy, look for …
  • Failure to face the challenge. When you cannot define the challenge, you cannot evaluate a strategy or improve it.
  • Mistaking goals for strategy.  Many bad strategies are just statements of desire rather than plans for overcoming obstacles.”
Rumelt, p. 32: Bad strategy “… is long on goals and short on policy or action. …  It uses high-sounding words and phrases to hide [its] failings.”  He means (and says) fluff. The Three Skills of Good Business Strategy What do you need to be successful with strategy? Rumelt (p. 268) says: “… you must cultivate three essential skills or habits.
  • First, you must have a variety of tools for fighting your own myopia and for guiding you own attention.
  • Second, you must develop the ability to question your own judgment.  If your reasoning cannot withstand a vigorous attack, your strategy cannot be expected to stand in the face of real competition.
  • Third, you must cultivate the habit of making and recording judgments so that you can improve.”
Good stuff!


[2] The standard for organizing business strategy is provided by the Business Motivation Model (BMM). See www.BusinessRulesGroup.org
[3] Rumelt, Richard [2011].  Good Strategy Bad Strategy:  The Difference and Why It Matters.  New York, NY:  Crown Publishing, a division of Random House Inc.

Continue Reading 1 Comment

Harvesting Business Rules??

guest post by Cecilia Pearce Are we actually harvesting the business rules? To harvest something you are required to go to a designated area to gather the crop or fruit. ‘Harvesting’ implies you ‘grew’ the business rules with deliberate purpose – cultivated special ground, keep it watered and weeded, watched over it as it matured. This is not what we are doing when ‘gathering’ business rules. We are required to go seek these business rules in documents, people’s heads, and programming code. We are required to sift through loads of information to find the business rules. Similar to what the prospectors did during the gold rush era in the past. I believe that ‘mining’ or ‘panning’ for business rules may be a more appropriate term to use when gathering business rules.

Continue Reading 15 Comments

Creating a Business Model: Walk the Walls!

In running facilitated sessions, we like to create each kind of business model on a different wall.  We find that the physical act of walking or shifting focus from one wall to another helps participants rapidly grasp and remember what each wall represents.  It also helps business leads and Business Analysts identify disconnects and gaps in the business solution more readily. We call this walking the walls. Our definition:  managing complexity in developing a business model by figuratively, and as much as possible literally, addressing each primitive as a separate concern (i.e., on a different wall)  In physically walking the walks, we usually put business process model(s) on the left wall and the structured business vocabulary (concept model) on the right wall.  On the front wall we put reminders about the strategy for the business solution (Policy Charter) and on the back wall we capture business rules.   Aside: Business rules go on the back wall to help resist the temptation of wordsmithing, which is better done offline.  In an ideal world, there would be one surface for each of the six primitives of the Zachman Architecture Framework.  (Alas the ceiling and floor are hard to use.)  Business rules, serving as integration relationships, would occupy the 3D space between the six surfaces (even harder to use!).  Our approach approximates the notions well enough in practice.

Continue Reading

Batting 1000 on Amazon: Our New Book “Building Business Solutions: Business Analysis with Business Rules” Hits Eight 5-Star Reviews (of 8) on Amazon

Our new book has been extremely well received this far – very gratifying. See the Amazon reviews: http://goo.gl/8lk4u and more comments: http://www.brsolutions.com/b_building_business_solutions_reviewers.php Two reviewers, George McGeachie and Maria Amuchastegui, made same criticism, both giving the book a 5-star rating anyway. So let me clarify. George McGeachie wrote: “The point about business rules and deployment is made on page 9, where you say that requirements evolve before deployment, and business rules evolve after deployment. In reality, I would expect business rules to evolve alongside requirements, and continue evolving after deployment.” We were trying to make a simple point. This time the point was perhaps expressed too simply. A full expression of what we meant to say would be: “A great many business rules exist before requirements, some business rules evolve alongside requirements. Unlike requirements, however, business rules continue to evolve after deployment – sometimes quite rapidly.” Elsewhere in the book we express the idea that your business would need its business rules even if it had no software at all. I think that implies many (probably most) business rules do exist prior to requirements. But thanks George and Maria – point taken.

Continue Reading 1 Comment