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

Posts Tagged ‘business agility’

Benefits: What Problems Does the Business Rule Approach Address?

Read to the end for an interesting note about this post. 1. Ad hoc rules: Most businesses have no logical approach for defining their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike. The larger the organization, the bigger the problem. Also, since many business rules involve monetary transactions (for example, whether a customer should be given a discount, and if so, how much), this problem can also directly affect the bottom line.

Business rule solution: A structured approach helps you think through rules before the fact.

2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?

Business rule solution: A clear set of concepts provides a foundation on which rules can be directly based.

3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.

Business rule solution: A way to manage business rules provides direct accessibility.

4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners for ever more complex products or services. How can businesses massively differentiate between business parties and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?

Business rule solution: A rule-based approach featuring rapid development and deployment of rules supports differentiation.

5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the Internet age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?

Business rule solution: Real-time delivery of business logic to knowledge workers as errors actually occur creates a seamless, never-ending, self-training environment.

6. Knowledge walking out the door: By and large, baby boomers created much of the operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads—and nowhere else. What will happen when they retire? On a smaller scale, people with vital operational knowledge walk out the door almost every day.

Business rule solution: A systematic way of capturing, documenting, and retaining the business rules prevents the loss of knowledge when people leave.

~~~~~~~~~~ Excerpted from Principles of the Business Rule Approach, by Ronald G. Ross, AddisonWesley, 2003, pp. xx-xxii. Note: This list of benefits was written a dozen years ago. It seems the more things change, the more they stay the same for business rules. About the only thing I would alter today is to add the following buzzwords for the respective benefits.

1. Consistency & Complexity 

3. Business Agility & Compliance

4. Customization & Personalization

6. Knowledge Retention

 www.BRSolutions.com

Continue Reading

The New Litmus Test for Business Agility

The point of knowledge (POK) is a real place. POK is where know-how – business rules – are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen. When you start to fully understand business rules, a whole lot of other pieces of the puzzle fall right into place.  You arrive at smart architectures, which gives you smart knowledge management and smart processes. In smart architecture, business systems become knowledge companions, enabling never-ending, on-the-job training.  Flash points of knowledge – real-time evaluation of business rules – enables dynamic processes and personalized, just-in-time delivery of up-to-date guidance. A smart architecture is one equipped to address the formidable challenges facing businesses today – the accelerating rate of change, massive customization, and products and services that are ever richer in knowledge.  Effective engineering of the POK is the new litmus test for agility. The question you should be asking: How do you get your company to the point of knowledge? ~~~~~~~~~~~~~~~~ Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php www.BRSolutions.com  

Continue Reading

Point-of-Knowledge Architecture: True Business Agility, Incremental Development, In-Line Training, and Real-Time Compliance

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php Let me use an example to sketch the workings of business rules in smart architecture based on points of knowledge[1].  Refer to the Figure to visualize how the system works.

Aside: I have been using this same slide since 1994(!).

Suppose you have a process or procedure that can be performed to take a customer order.
  • An order is received.  Some kind of event occurs in the system.  It doesn’t really matter too much what kind of event this is; let’s just say the system becomes aware of the new order.
  • The event is a flash point — one or more business rules pertain to it.  One is:  A customer that has placed an order must have an assigned agent.
  • We want real-time compliance with business policy, so this business rule is evaluated immediately for the order.  Again, it doesn’t much matter what component in the system does this evaluation; let’s just say some component, service, or platform can do it.
  • Suppose the customer placing the order does not have an assigned agent.  The system should detect a fault, a violation of the business rule.  In other words, the system should become aware that the business rule is not satisfied by this new state of affairs.
  • The system should respond immediately to the fault.  In lieu of any smarter response, at the very least it should respond with an appropriate message to someone, perhaps to the order-taker (assuming that worker is authorized and capable).
What exactly should the error message say? Obviously, the message can include all sorts of ‘help’.  But the most important thing it should say is what kind of fault has occurred from the business perspective.  So it could start off by literally saying, “A customer that has placed an order must have an assigned agent.”  We say the business rule statement is an error message (or better, a guidance message). That’s a system putting on a smart face, a knowledge-friendly face, at the very point of knowledge.  But it’s a two-way street.  By flashing business rules in real-time, you have an environment perfectly suited to rapidly identifying opportunities to evolve and improve business practices.  The know-how gets meaningful mindshare.  That’s a ticket to continuous improvement and true business agility.

Smarter and Smarter Responses

Is it enough for the system simply to return a guidance message and stop there?  Can’t it do more?  Of course. For the order-taking scenario, a friendly system would immediately offer the user a means to correct the fault (again assuming the user is authorized and capable).  Specifically, the system should offer the user another procedure, pulled up instantaneously, to assign an appropriate agent.  If successful, the user could then move on with processing the order. This smart approach knits procedures together just-in-time based on the flash points of business rules.  It dynamically supports highly-variable patterns of work, always giving pinpoint responses to business events (not system events).  In short, it’s exactly the right approach for process models any time that applying know-how is key — which these days, is just about always! The Business Rules Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) says this:  “Rules define the boundary between acceptable and unacceptable business activity.”  If you want dynamic processes, you must know exactly where that boundary lies, and how to respond to breaches (at flash points) in real time. Is that as smart as processes can get?  Not yet.  Over time, the business rules for assigning appropriate agents might become well enough understood to be captured and made available to the system.  Then when a fault occurs, the system can evaluate the business rules to assign an agent automatically.  At that point, all this decision-making gets tucked very neatly under the covers.  Even if the business rules you can capture are sufficient for only routine assignments, you’re still way ahead in the game. Smart architecture based on business rules is unsurpassed for incremental design, where improvement:
  • Focuses on real business know-how, not just better GUIs or dialogs.
  • Continues vigorously after deployment, not just during development.
  • Occurs at a natural business pace, not constrained to software release cycles.
The Manifesto says 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 knowledge retention, as well as to move pragmatically toward the knowledge economy.  Business rules give you true agility.

Continue Reading 1 Comment

What Role for Business Rules in *Business Agility*? 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 #5 Question: How do business rules support business agility? Think of business rules as expressing business practices. These practices can cover a wide range of business concerns, including the composition of products, the customization of services for individual customers, operational hand-offs with suppliers, implementation of regulatory constraints, and so forth. Historically, rules have been embedded (hard-coded) in processes, in many different places and often inconsistently. There is no easy traceability for any given rule. Changing rules inevitably requires IT intervention, along with the associated cost and delay. From a business perspective, the resulting business support is simply not agile. Business rules support business agility by providing pinpoint means to evaluate and modify business practices. Rules are expressed and managed independently of processes (a.k.a. rule independence). By that means they can be consolidated (single-sourced) and evolved more rapidly and reliability. From a platform point of view, the Manifesto says it 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.

Clearly some platforms are far better than others in this regard. The quality of their support for rules should be a critical factor in selection and design. Unfortunately, many organizations are trapped as much by legacy platforms as by legacy systems. True business agility requires migration to new platforms as quickly and easily as possible. For example, a central concern of many organizations these days is mobile computing and social media – capabilities not even on the horizon ten years ago when the Manifesto was written. There’s no end to platform innovation in sight – and companies will always want to get on-board faster and faster. Is there any way of doing so without knowing your business rules? No! So the Manifesto recommends …

10.3. Business rules should be organized and stored in such a way that they can be readily redeployed to new hardware/software platforms.

Always remember that business rules are what you need to run your business, not to design systems, at least directly. There will never be a future platform for which you do not need to know your business rules.  


[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

Business Agility vs. Agile in Software Development: Not Related!

Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing.  All artificial (IT-based) production-freeze dates for deployment disappear and the software release cycle becomes irrelevant.  The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. We define business agility as follows: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense Agile in software development is an IT development method featuring rapid iteration and prototyping.  Agile methods and business agility have nothing to do with each other.  Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls.  Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually.  But the ‘flexibility’ is just an illusion.  The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come.  It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions.  It makes apple-to-apple financial comparisons virtually impossible.  And it always costs a lot in ‘maintenance’.  There are simply no magic bullets for building business solutions! ~~~~~~~~~~~~~~~ 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 1 Comment

Externalizing Semantics from Business Processes … Why the Procedural Approach is a Flawed Paradigm for the Knowledge Economy

For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly. But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters. True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today. Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules. ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

Continue Reading

Why Doesn’t the ‘Knowledge Management’ Community Get it?

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the first one: Why is it that people discussing ‘knowledge management’ seem to have so little understanding of the core know-how actually needed to run (and change) day-to-day business activity? Core operational know-how consists of business vocabulary, business policies, and business rules. That ‘knowledge’ is currently locked away in IT applications and platforms (or in people’s heads) where it is virtually immune to change. That’s a boon to service providers and IT departments, but a bane to business agility. What business really needs today is agile governance … but few seem to be talking about that. P.S. Social media won’t help much here. You simply have to ‘do’ business rules.

Continue Reading 5 Comments

The Debate Continues … Business Rules in Zachman 3.0 … and the Upcoming Business Architecture Summit at BBC2011

At the Business Architecture Summit in Ft. Lauderdale (BBC2011 – Oct 31 – Nov 4) I will be joining John Zachman and Roger Burlton for one of our rabble-raising 3Amigo sessions. The session is only an hour long, so I’m sure there will be some fast talking(!). One of the first questions I want John to address is: “Where are the business rules in Zachman 3.0?” The following recent exchange represents my current understanding on the matter. I plan to come back on the record after the event to say what I got right and what I got wrong. Question: Can rules address more than one primitive (column) in the Framework? My Answer: Yes, atomic rules can address multiple primitives – e.g., An accounting must be given by the CFO in Delaware on March 15, 2012. (By ‘atomic’ I mean ‘can’t be reduced into two or more rules without losing meaning.’) In this rule you have a thing (‘accounting’), a person (the CFO), a place (Delaware), and a date (March 15, 2012). So even atomic rules are composites, not primitives. Question: Does rules not being a primitive mean that business rules shouldn’t be treated as a first-class citizen? My Answer: What ‘first-class citizen’ has always meant in the Business Rule Manifesto (http://www.businessrulesgroup.org/brmanifesto.htm) and elsewhere is that business rules shouldn’t be subordinate to other kinds of requirements for system design in general, and to what I call ‘Big-P’ processes in particular. Big-P processes are not primitive (think ‘input-process-output’), but rather they amalgamate (think ‘mash-up’) some or even all the other primitives. In other words, Big-P processes are also composite. Composites are about the configuration of the enterprise at any point in time. Business rules are one candidate for that capacity. I believe business rules are a far better choice in that regard than Big-P processes (think ‘business agility’). In any case, business rules being a composite in no way diminishes their importance. The enterprise is not built on primitives alone. If you had only primitives, there would be no configuration, and literally no enterprise.

Continue Reading 1 Comment

What is Agile? … Or Rather, What is It We Really Want to Be ‘Agile’?

This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php ~~~~~~~~~~~~~~~~~ Agile in software development is an IT development method featuring rapid iteration and prototyping. Agile software methods and business agility have nothing to do with each other. Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls. Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually. But the ‘flexibility’ is just an illusion. The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come. It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions. It makes apple-to-apple financial comparisons virtually impossible. And it always costs a lot in ‘maintenance’. There are simply no magic bullets for building business solutions. Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing. All artificial (IT-based) production freeze dates for deployment disappear and the software release cycle becomes irrelevant. The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. So the answer to my question is that business should be agile. Here then is our definition of business agility: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense.

Continue Reading 2 Comments