Have you ever been confused about why you were not allowed to do what you tried to do? Been judged or evaluated in a way you didn’t expect? Stumped by the result or decision a business system produced? If so you are a why victim. In today’s business world all of us are why-victims more and more often. The remedy is business rules. Not technical rules masquerading as business rules, but real business rules expressed of, by, and for the business represented purely in business terms. Business rules are part of the broader solution, Why Engineering. This article introduces Why Engineering and its basic principles, along with the Why Button. Find out what it takes to be effective at Why Engineering in today’s business environment.
The Why Button
Business rules are all about answering the question why? Why things are disallowed. Why specific judgments or evaluations are made. Why certain decisions are reached.
Imagine you had a Why Button handy whenever you encountered some disconnect in day-to-day business operations. Hit the Why Button and presto – answers appear in the form of relevant business rules.
Not technical rules but rules of the business – statements of guidance you can read and understand no matter what your role – business manager, business product developer, operational worker, business analyst, data analyst, or IT professional. A single representation accessible to all audiences that is:
- Precise enough to remove all ambiguity.
- Detailed enough to produce the same results no matter whether applied by workers ‘manually’ or automated by machines.
What would that do for your business? For one thing it would keep know-how from walking out the door – i.e., make your business logic explicit, not tacit, so you can retain it. For another it would eliminate semantic silos – people using the same words, but not really communicating. It would also go a long way in closing the gap between business and IT. Overall it would mean stepping up to do business intelligently in the knowledge economy.
The Who of Why Engineering
To achieve this vision you need a Why Engineer™.
A Why Engineer is not a knowledge engineer in the sense of expert systems and not a technical wizard in ontologies. Rather, a Why Engineer is someone who uses rigorous discipline to capture, represent and communicate business rules based on carefully engineered business vocabulary. A Why Engineer is an architect who:
- Takes great care – and pride – in how things are expressed and defined.
- Can probe deeply into the ‘why’ of business logic never once using a term or structure whose origin lies in IT or system design.
- Believes basic operational know-how has huge value and therefore should be managed and leveraged in every way possible.
The How of Why Engineering
What can a Why Engineer offer your requirements process? Business rules provide the ‘why’ – the basic rationale – for business requirements and elements of system design. They provide a solid basis for motivating each part of the solution you envision.
As an example suppose you are creating functional requirements for a truck-routing problem. Let’s say you arrive at the four requirements illustrated in Figure 1.
Figure 1: Four functional requirements for a truck-routing problem.
The obvious question is what ties the requirements together? What’s the underlying business rationale?
If you had started from a business rule, the business rationale would be straightforward – little or no further explanation needed. The focus shifts from the requirements to the business rule: Is the rule right for the business? Figure 2 illustrates the possible starting-point business rule (expressed in RuleSpeak®1) for the requirements above.
Figure 2: Possible starting-point business rule for the four functional requirements.
Today’s system-driven approaches result in a lot of arm-waving about the motivation for business requirements. A great many pages of generally formless documentation are often produced no one really reads.
All that is far from harmless noise. It detracts from delineating:
- The core business policies needed to actualize the business strategy.
- The elemental know-how that differentiates your product/service and provides the basis for achieving excellence in its delivery.
How have methodologies strayed so far from the very know-how that keeps you in business?! The Why Engineer puts things back on track.
The What of Why Engineering
Why Engineering is based on three fundamental architectural principles:
Principle 1. The same complete, intelligible, unambiguous, deployable meanings (business rules and definitions) should be presented to all key audiences in the business – managers, business product developers, operations, business analysts, data analysts, and IT professionals.
Looking back to the truck-routing example, none of these audiences is likely to have much trouble understanding the structured rule statement: A truck carrying hazardous material must not be routed through a downtown street. This example is a relatively simple one; reality of course is often more complex. Let me return to that point momentarily.
Principle 2. A Why Button should be part of every architecture and business solution.
Consider the following scenario for the truck-routing problem. The local manager in a large city needs a load of automotive parts picked up on the docks and sent rush-delivery to a parts dealer across town. He assigns a driver to the job, tells her to get it there fast, then goes about his other tasks. Meanwhile the driver requests optimal routing for the shipment and is surprised by the result, a route by no means the shortest or fastest. The driver is tempted to take a much more direct route right through town – after all, the manager said to get the load there fast – but first she hits the Why Button. The response she sees:
A truck carrying hazardous material must not be routed through a downtown street.
- This shipment includes air bag modules.
- Air bag modules are hazardous material.2
Principle 3. The same form of “why” answers (business rules) created originally should be re-used and provided to each audience3 in identical form whenever the Why Button is hit.
In the scenario above, the same business rule statement originally harvested before designing the system plays a direct role during its subsequent operation. And why not? It’s a simply a business rule – a rule for running the business. That’s its purpose; that’s the role it should play – to inform and shape everyday behavior at the operational level. Every game has a rulebook for reference; putting the rules directly to work in automated systems is simply good architecture practice.
Dealing with Complexity at Scale
The truck-routing business rule is a relatively easy one to comprehend. Reality is generally more complex for at least three reasons.
- Many (perhaps most) business rules are more highly nuanced (qualified). That’s one reason for following careful guidelines in expressing them such as offered by RuleSpeak. Through extensive real-world experience, best practices have also been developed for handling lists4 and decision tables.5
- The vocabulary for the product/services of many organizations is more abstruse. Solid business definitions of terms are essential, something every data professional should strongly support. A reasonable comparison in that regard is to the legal profession. In one 22-page contract I reviewed recently, I found five full pages of definitions. That’s 23% of the total content!
- The devil is in the details – organizations often have 1,000s or 10,000s of business rules. So a glossary of business definitions is not enough. You need a specific kind of architecture – a blueprint – to organize the underlying concepts. That’s the only way coherency in significant numbers of rules can be achieved. Such blueprints for business semantics come in the form of a concept model based on structured business vocabulary. We offer ConceptSpeak™ to guide professionals in developing this kind of structure.6 By the way, we call it a ‘concept model’ rather than a ‘conceptual data model’ because, quite simply, that’s the right name for it. It’s not directly about data.
Learning and Applying Why Engineering
Why Engineering really has nothing to do with IT directly. It can be (and has been) used even where no automated system is being built. It’s a very pure form of business architecture.
In a sense Why Engineering is simply about highly precise business communication. Is that a skill every architect or IT professional possesses naturally? Unfortunately no – not even close. It must be learned.
Fortunately, effective techniques for Why Engineering are available and have been proven in practice. They consist of structured natural language tools such as BRS ConceptSpeak™, RuleSpeak® and TableSpeak™. These notations – really thinking tools – are based on a rich standard, SBVR (Semantics of Business Vocabulary and Business Rules),7 developed over many years by world-class experts in formal logic, linguistics, and software engineering. SBVR itself is based on ISO terminology standards.
Is Why Engineering hard? Yes and no. The organizing principles and thinking tools can be readily learned. As for any engineering discipline, however, there’s a definite learning curve. It takes diligence and practice to become really good at it.
Actually, the hardest part of Why Engineering is getting at the buried assumptions and know-how in people’s heads – or lost in the jumble of legacy systems. The thinking tools of Why Engineering simply offer professionals the essential means for discovery, representation and validation.
The ultimate prize – common understanding in explicit form – is something the Why Engineer must still work hard to achieve. If it were easy, everyone would already be doing it!
Summary
Why Engineering is engineering in the fullest sense of the word. All engineering strives to produce something useful for people or their organizations. In Why Engineering that product is business rules, explicit business logic.
In general, engineering requires two things: source material and structural principles. For Why Engineering:
- The source material is literally words – or more accurately the concepts and meanings behind the words.
- The structural principles indicate how business logic can be represented in an unambiguous, anomaly-free form that is free of any IT or system-design artifacts or bias.
Why Engineering is engineering at its best.
- As in all good engineering the product of Why Engineering is highly re-usable. What you develop as business logic is directly re-usable as the answers produced by the Why Button in operation. Nothing more is required. It is exactly the same stuff – unified and re-used with pinpoint accuracy.
- Good engineering is also always concerned with sustainability of the product. Point-in-time (“bandaid”) solutions are avoided. In Why Engineering, sustainability can be achieved by business-level rulebook management,8 something we believe should also be part of every architecture.
End Notes:
- RuleSpeak is a set of guidelines for expressing business rules in structured natural language. The guidelines are free on www.RuleSpeak.com.
- http://phmsa.dot.gov/staticfiles/PHMSA/DownloadableFiles/Files/Hazmat/Alpha_Hazmat_Table.pdf
- Obviously, answers should be available only to those duly authorized – but authorizations are simply more business rules.
- Tabulation of Lists in RuleSpeak®: A Primer – Using “The Following” Clause, free download on http://www.brsolutions.com/b_ipspeakprimers.php
- Decision Tables – A Primer: How to Use TableSpeak™, free download on http://www.brsolutions.com/b_ipspeakprimers.php
- Business Rule Concepts: Getting to the Point of Knowledge (4th edition), by Ronald G. Ross, 2013.
- Refer to the SBVR Insider section on www.BRCommunity.com.
- “What Rulebooks, Rulebook Management and GRBS Are About,” http://goo.gl/iBwsrE
