Announcing: The Business Agility Manifesto released Sept 8, 2017 by John Zachman, Roger Burlton and myself. Have a look! https://busagilitymanifesto.org/  

The 3 of us will formally introduce the Manifesto for the first time at the Building Business Capability (BBC) conference Nov. 6-10 in Orlando, FL. Be there to hear all about it and to discuss! http://www.buildingbusinesscapability.com/

Mining business rules from legacy code raises big challenges. They’re often implemented in arcane, highly procedural languages. The person or team who wrote the code is often long gone (or perhaps in India). Bringing them back into a form that business people and business analysts can understand is hard.

To illustrate, here is an as-coded example from a major bank:

For Primary Borrower or any Guarantor, IF [Processing Date – Credit Bureau File Since Date] is < 12 months AND the total # of Type Code of ‘R’ and ‘O’ trade lines is 3 or less AND the total # of ‘I’ and ‘M’ trade lines is zero AND the Industry Code = OC, ON, OZ, DC, DV, DM, DZ, Then result is Refer.

Obviously most business workers are not going to understand that specification or be able to validate what it says. Actually, this example is well above average in readability – most coding languages are even farther removed from daily business parlance. If you want to have real conversations with business partners, core business knowledge needs to be expressed in structured natural language (e.g., in RuleSpeak^®), making careful use of common business vocabulary.

The example above is interesting for another reason. Note the outcome of the specification, the portion after the then, is “Refer”, meaning that the matter in question cannot be resolved. This specification actually does nothing but kick work back out to a human!

A specification that simply escalates a case to a human is not a true business rule at all. Rather, it’s an acknowledgement the actual business rule(s) still haven’t been captured and encoded. That knowledge lingers in somebody’s head (hopefully!).

Our broad experience in reverse-engineering business rules has exposed us to harsh reality: No silver bullets. Once business rules have been encoded procedurally, semantics are lost that cannot be resurrected automatically. You’ve made a bargain with the devil.

~~~~~~~~~~~~~~~~

Read more: http://www.brcommunity.com/articles.php?id=b904

I want to share with you the most intelligent thing I’ve ever heard a manager say on the fly. I’ll give some background first. In one way or another, the situation that evoked what she said may seem quite familiar to you. A few years ago Gladys and I were invited to conduct a one-week facilitated session for a national taxation authority. The objective was to reverse-engineer business rules from a very complex spreadsheet. The manager told us everyone was deathly afraid to touch it because no one understood how it worked. You could never tell what impact making a change would have. Used by many of their systems and embedded in various websites, the spreadsheet was mission-critical. She was finally biting the bullet and assembling some of her best staff to re-engineer it. Everyone knew the spreadsheet by its nickname, Al’s Spreadsheet. It dated to the 1970s when it was implemented under the first generation of automated spreadsheets. Notorious in the organization for more than a generation, it was devilishly convoluted. One of these days I might hold a contest for the world’s most complex spreadsheet. I’ve actually told this story many times around the world, and the audiences’ reaction is inevitably the same – perhaps the same as yours reading this. “No, Al’s Spreadsheet couldn’t possibly be the world’s most complex spreadsheet because my company has the world’s worst!” Around the globe there is extensive core operational business knowledge running businesses day-to-day that is highly inaccessible. Just putting your fingers on it, much less revising it, consumes vast amounts of vital resources. We live in a service provider’s dreamscape. It makes you wonder how brittle (read not agile) many companies’ operations really are today. To return to the story, by mid-week we’d achieved only limited success in deciphering the spreadsheet. Progress was painfully slow. Lapsing momentarily into frustration, an idea popped into my head.  I blurted out, “Hey, why don’t we just go ask Al what this thing really does?!” I assure you my intention was not to provide comic relief. To my chagrin that’s exactly what happened. The whole room erupted into laughter. When the hysteria finally subsided, someone patiently explained to me (barely keeping a straight face) that nobody actually knew who Al was – or indeed, whether Al had actually ever even existed. If so he had long since parted ways with the organization, fading away as all workers sooner or later do into the mists of time. That’s when the manager said the thing that I found so memorable. Looking at no one in particular and staring vaguely into the far distance she said, “No organization should ever depend on absent brains.”. Exactly! To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand. Operational business knowledge can be either tacit or explicit (read ‘accessible’). The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’. You make operational business knowledge explicit by expressing it as business rules. So make sure when you lose your Al, he doesn’t walk out the door with the day-to-day knowledge you need to run your business. Encode it as business rules!

When my older son graduated from college, he worked as an intern for a professional sports team.  At the end of his very first day of work he called me, puzzled.  “I asked them what my responsibilities were,” he related, “and they said, ‘We need you to know what we are supposed to be doing’.”  After a long pause he went on, “I wanted to ask them why they didn’t already know what they were supposed to be doing, but I didn’t think that would be such a great idea my very first day there.” Let’s see whether at some level that situation sounds familiar to you.  It turns out his area of responsibility had to do with ensuring operational compliance with corporate sponsorship agreements.  The sponsorships are quite expensive.  You might think these agreements would be relatively simple, but of course, there’s no such thing as a truly simple business.  A sponsorship contract:

• Outlines a complex configuration of promotional and other benefits, some automatable and some not, all usually tailored specifically for the individual sponsor.
• Is loaded with obligations, decision criteria, and computation formula (read ‘business rules’) to govern the sponsorship relationship.
• Is amended frequently, both formally and informally (via hand-shake), owing to the dynamic nature of the sponsors’ marketing needs.

To continue the story of my son’s first day, they gave him a stack of contracts and amendments, operational schedules, and invoices and told him to see if they all matched.  Of course they didn’t.  Not by a mile. By the end of the first week, my son had become fairly fluent in the organization’s governance problems.  (Ah, young minds!)  The contracts and schedules were all produced by different people at different times.  Some of the schedules were hand-done and some automated.  But even the ones that were automated often didn’t match the contracts.  The invoices were automated, but in many cases they too bore little resemblance to the contracts.  The IT people were not much help either.  “They seem to speak a different language,” my son reported naively.  Bottom line:  A number of the sponsors were becoming quite annoyed — not a good thing for a mediocre team in a mid-sized market. But there was still more.  The sales reps were, shall we say, quite creative in what they offered the sponsors.  Their terminology, which often found its way into the contracts, was highly idiosyncratic.  Yet they were talking about the same shared resources (e.g., banner boards in the stadium) that had to be coordinated real-time across many sponsors.  They seemed oblivious to some of the company’s rules — even though some, quite literally, were dictated by physics (e.g., a banner board can only say one thing at a time; there is only so much time during a game, etc.). By the way, my son went to one of the team’s games his first week at work.  The team lost.  Attendance was poor.  Sponsors were unhappy.  “I think it’s going to be a season,” he said. After a moment of reflection he added, “You know what really worries me is that I am going to figure all this out, then walk right out the door with all that knowledge.  They’ll be right back where they started.  Doesn’t seem to me like a very good way to run a business.” Welcome, my son, to the reality of business rule mismanagement in the 21^st century!

What business problems do business rules address?  My take: 1. Ad hoc rules: Most businesses have no organized approach for specifying 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.

Business rule solution: Business rules ensure consistency in customer experience and provably on-target results for demonstrating compliance.

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 structured business vocabulary 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: An organized approach for managing business rules yields order-of-magnitude improvements in productivity and business agility.

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

Business rule solution: Business rules support highly scalable customization and personalization and provide a structural solution for managing complexity.

5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the digital 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 rules to knowledge workers creates a seamless, never-ending, self-training environment.

6. Knowledge walking out the door: By and large, baby boomers created much of the basic 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. Now they are retiring. 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 managing business rules enables pragmatic knowledge retention.

~~~~~~~~~~

Many or most IT methodologies remain essentially in the Dark Ages with respect to knowledge management. They seem to focus blindly on pumping out code faster and faster. We may be living in a knowledge economy, but we’re sure not acting like it. When I say knowledge management I don’t mean what probably comes to mind. I’m not talking about fuzzy text in vast e-mail archives or tacit knowledge in people’s heads. I’m talking about explicit business rules. Business rules (done correctly) represent knowledge – core operational knowledge. Many companies today are in peril of losing or outsourcing that knowledge. Who’s to blame? Business managers for not ‘getting it’ of course. But that’s just where the buck stops. Ultimately practitioners are to blame. They’re not making core operational knowledge tangible to their managers. How you make that kind of knowledge ‘real’? True business-side rulebook management[1] (which is not the kind BRMS offer).[2] That’s no longer optional either. In a knowledge economy your company simply can’t afford to lose its business rules! ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Knowledge worker is a term bandied about in discussion of business process management (BPM). Is it synonymous with white-collar worker, or different? How do you use the term? I ask because there’s significant new and significant interest in automating new areas of white-collar work so as to render it more consistent, traceable and scalable. That requires capturing and encoding the know-how as business rules and on a broader scale, engineering and automating operational business decisions. Knowledge is a very far-ranging term, and there are many forms of knowledge beyond day-to-day operations of a business. Does it confuse the issue to call white-collar workers “knowledge workers”? Is knowledge worker perhaps a broader term than white-collar worker? Which term works best in your organization? Here is some background information from Wikipedia. I confess I have never heard the term gold collar before, but it seems to me there’s an important potential difference there. White-Collar Worker

A white-collar worker is a person who performs professional, managerial, or administrative work. Typically, white-collar work is performed in an office or cubicle. Other types of work are those of a blue-collar worker, whose job requires manual labor and a pink-collar worker, whose labor is related to customer interaction, entertainment, sales, or other service oriented work. Many occupations blend blue, white and/or pink (service) industry categorizations.

Knowledge Worker

Knowledge workers are workers whose main capital is knowledge. … What differentiates knowledge work from other forms of work is its primary task of “non-routine” problem solving that requires a combination of convergent, divergent, and creative thinking.

Knowledge workers are employees who have a deep background in education and experience and are considered people who “think for a living.” They include software developers, doctors, lawyers, inventors, teachers, nurses, financial analysts and architects. As businesses increase their dependence on information technology, the number of fields in which knowledge workers must operate has expanded dramatically.

Even though they sometimes are called “gold collars”, because of their high salaries, as well as because of their relative independence in controlling the process of their own work, current research shows that they are also more prone to burnout, and very close normative control from organizations they work for, unlike regular workers.

www.BRSolutions.com

I’ve been writing a lot recently about the knowledge economy and what makes a business smart. Let me dig a little deeper. The kind of knowledge I’m talking about might be better described as know-how.

know-how:  accumulated practical skill or expertness …  especially:  technical knowledge, ability, skill, or expertness of this sort[1]

Know-how that you can encode and retain is represented by business rules and the structured business vocabularies (concept models) on which the business rules are based.  Know-how is a subset, a small one probably, of knowledge.  Briefly, knowledge can range from practical to theoretical, from certain to probabilistic, and from frequently applicable to infrequently applicable.  At the risk of saying the obvious, you can’t run the day-to-day operations of a business on knowledge that is theoretical, probabilistic, or infrequently applicable.  In short, business rules are about know-how management, a strictly limited subset of knowledge management. Like knowledge, know-how can be either tacit (in people’s heads) or explicit.  The classic test for when knowledge is tacit is ‘lose the person, lose the knowledge’.  Obviously you want to retain know-how. As a senior manager recently put it, “No organization should depend on absent brains.”

know-how retention:  expressing know-how explicitly in a form understandable by business people and business analysts, and managing the know-how, such that it is always available for future reference or use (by those capable and authorized)

The over-time infrastructure needed to retain know-how is provided by a general rulebook system (GRBS).  It’s what rule management should really be all about. ~~~~~~~~~~~~~~~~~~~~~~~ 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

Excerpted from Business Rule Concepts: Getting to the Point of Knowledge (4^th ed, 2013), by Ronald G. Ross, 162 pp, http://www.brsolutions.com/b_concepts.php For me the point of knowledge (POK) is a real place.  POK is where elements of operational business know-how — business rules — are developed, applied, assessed, re-used, and ultimately retired.  In other words, POK is where business rules happen.  Knowledge is power, so  you can also think about POK as point of empowerment. POK corresponds to point of sale (POS) in the world of commerce.  POK and POS are similar in several ways:

• In both, something is exchanged.  In POS, it’s goods.  In POK, it’s operational business know-how (from here on I’ll just say know-how).
• In the world of commerce, we often say that consumer and supplier are parties in point-of-sale events.  Each of us is a consumer in some point-of-sale events, and many of us act as suppliers in others.  The same is true for POK.  Each of us is a consumer of know-how in some POK events, and many of us act as suppliers in others.  Sometimes we switch roles within minutes or even seconds.
• A well-engineered experience at the point of sale has obvious benefits both for the consumer — a positive buying experience — and for the business of the supplier — real-time intelligence about sales volume, cash flow, buying trends, inventory depletion, consumer profiles, etc.  A well-engineered experience at the POK likewise has obvious benefits.  For the consumer, it means a positive learning experience.  For the business of the supplier, the benefits include real-time intelligence about the ‘hit’ rate of business rules, patterns of evolving consumer (and supplier) behavior, emergence of compliance risks, etc.

The consumer/supplier experience at  the POK is crucial to worker productivity and job satisfaction.  In no small measure, optimizing this experience is the real challenge in POK engineering.  It must  be deliberate.  After all, what’s exchanged  at the POK is know-how — something you can’t carry around in your hands. Today, much of your know-how is tacit — lose the people, you lose the know-how they carry in their heads.  How can you avoid that?  Make the know-how explicit as business rules.  That’s what POK are about. Critical success factors in engineering an effective POK include:

• Communication must be strictly in the language of the business, not IT.
• Interaction must be gauged to the knowledge level (and authorization) of each individual party.
• Less-experienced parties playing the consumer role must be enabled to perform as closely as possible to the level of the company’s most experienced workers.
• Know-how — business rules — must be presented and applied in a succinct, highly-selective fashion.
• Know-how — business rules — must be presented and applied in a timely fashion (i.e., ‘just-in-time’) to accommodate fast-paced refinement and change in business policies and practices.

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #7 Question: How do business rules relate to knowledge retention? The classic test of whether knowledge is tacit or explicit is this: If you lose the person, do you lose the knowledge? Clearly, you want basic business know-how to be explicit, so a basic principle of the Manifesto is …

3.3. Rules must be explicit.  No rule is ever assumed about any concept or fact.

Rules capture and encode operational business know-how in a form that can be retained, managed and re-used. What are rules really about? A well-expressed rule is based on terms and facts (or more accurately, noun concepts and verb concepts). These concepts represent the basic stuff of the business – operational-level things that are talked about, managed and processed day-in and day-out, often many, many thousands of times. Rules provide criteria that guide this operational activity in a consistent way. So the Manifesto emphasizes …

3.4. Rules are basic to what the business knows about itself – that is, to basic business knowledge.  

In business, of course, knowledge is not an end in and of itself. Rather, the goal is consistent application of the knowledge – as well as its continuous improvement. Achieving these goals requires that the people who understand the knowledge – business people, subject matter experts, and business analysts – be able to work with it directly and effectively. After all, the true test of knowledge quality is not whether an application program runs, but whether you get the right (or best) results. So the Manifesto says …

9.3. Business people should have tools available to help them verify business rules against each other for consistency.

In the plainest possible terms, IT professionals simply shouldn’t be the ones to determine whether business logic ‘works’.