1. It is always important where there’s any chance of ever having to say why. 2. It should always be channel-independent. 3. You should never put yourself in a position of having to reconstruct what rules were applied in making an evaluation or decision after-the-fact. Compliance shouldn’t be the issue that it is – it doesn’t have to be. Rules of record should be a built-in feature of architectures. For all these years, we’ve been thinking ‘data’ is the key to compliance. We should have been thinking rules as applied to data. ~~~~~~~~~~~ Follow-up to my post on Rules of Record: http://goo.gl/dbKaD

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

Celebrating the 10^th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #6 Question: What role should business rules play in enterprise architecture? Reverse-engineering business rules from legacy systems accurately is virtually impossible. The full, original business intent is simply lost. Reconstruction of business logic has been tried time and time again, often aided by automated tools, but measured against time and cost, seldom achieves satisfactory results. What a waste! The solution is simply to stop hard-coding business rules into procedural languages. Rules will change and they will be needed for new business initiatives and platforms. The opportunity costs of continuing to follow traditional practices – not to mention the ‘maintenance’ costs – is simply too great. The alternative is applying rule technology that can support rules expressed in more natural (declarative) form. The Manifesto summarizes these points as follows …

6.2. Executing rules directly – for example in a rules engine – is a better implementation strategy than transcribing the rules into some procedural form.

With computing power so vastly improved, there is less and less reason every day to support business rules using procedural languages. Why are we still programming the evaluation of rules ourselves?! Just as a DBMS removes data management as an application concern, so too does a rule technology for the evaluation of rules. A related issue is compliance – not just regulatory compliance, but compliance with contractual obligations, deals, agreements, licenses, warranties, and so on. If you want to delight customers, keep your commitments. To do so you must be able to determine how your systems actually got the outcomes they did. That way, if there’s a mistake you can correct it. So the Manifesto says …

6.3. A business rule system must always be able to explain the reasoning by which it arrives at conclusions or takes action.

Today, demonstrating compliance is a largely hit-or-miss affair, always after the fact. Does it have to be? No! A state-of-the-art enterprise architecture is one that logs the rules used to make evaluations and decisions just as a DBMS logs all transactions. Compliance based on rules can and should be built-in.

Here’s a short clip about business rules from an interview in Amsterdam not too long ago. I actually agree with what I said … http://www.youtube.com/watch?v=fhv7bGf3r3Y&feature=related There are several related clips there with John Zachman, Roger Burlton, and Silvie Spreeuwenberg (LibRT) worth a few minutes of your time — business rules, decisions, business processes, enterprise architecture, and more.

@SergeThorn asks “Are Business Process Management and Business Architecture a perfect match?” http://goo.gl/kLYvs With business rules far better! There is an important overlap of concerns between business rules and enterprise architecture. The overlap actually comes in two forms: 1. Operation-time. Here the issue is really rethinking compliance. I just blogged about this today: http://goo.gl/Gl9wT 2. Business-analysis-time. A business needs to know the rules it plays by. That inevitably brings you to rulebook management. For more: http://www.brcommunity.com/b500.php?zoom_highlight=rulebook (and other articles).

Robin Bloor wrote  a very interesting piece about why business needs explicit audit trails for data: http://www.dataintegrationblog.com/robin-bloor/the-quality-of-data-is-not-strained/ Here’s the gist: “… data has no explicit audit trails, so we lose information, some of which may be critical. This has the effect of hiding the record of and the impact of data errors.” He says all data should be time-stamped. I agree … but it’s not enough. I’ve believed for decades (before it was conceivably practical) in the concept of the ‘perfect machine’. In the perfect machine, there are really no such things as changes or deletes; instead, all data just get time-stamped when created and the newer data takes active preference over the older. That gives you built-in audit trails — of data — and more importantly, (mechanized) business memory.  There is, however, at least one circumstance in which data really does need to be deleted (purged). That’s when the business is required for legal reasons to expunge all ‘records’ about some sensitive matter (e.g., the legal transgressions of a minor at age 18). In other words, there are *business rules* that sometimes require true ‘deletes’. Business rules can trump ‘perfect memory’.  Actually, there are business rules for virtually all ‘changes’ made to operational data. Failure to apply the correct business rules consistently is the rrot cause of poor data quality. And good luck trying to reconstruct after-the-fact what really happened (what business rules were actually applied) at some past point in time when things downstream go awry. And they will, of course.  What’s needed is not just an audit trail of changes to data, but an audit trail of all business rules tested at each point in time some data ‘changed’ (or was created or deleted). If the system automatically logs the relevant business rules, then you have a true, complete and indisputable record of ‘history’.  I’m talking here about nonething less here than built-in (mechanized) methods of addressing compliance. No human intervention. Compliance across the board … with external regulations, contracts, agreements, deals, business policies … whatever.  If you want your business to be both extremely agile and highly compliant (which is to say, always meet operational expectations), there’s untimately no alternative. How else can you support one-on-one customized relationships with a million customers? Of course, first you would have to know your business rules. There’s the rub. Do you?! 

… And somebody did recently: What’s wrong with current business process management (BPM) practices?  1. When a discipline becomes mature, it stops seeing itself as a solution to every problem. BPM is not there. Limitations?

• It does not provide the order-of-magnitude improvement in business agility that companies need urgently.
• It is not the solution to compliance issues.
• It does not effectively provide for massive customization or personalization.

BPM needs to recognize and accommodate peers: business strategy, business rules, business vocabulary, business decisions, and business events.  2. Words matter. Well-defined business vocabulary is not a luxury or an option. It’s fundamental to effective business orchestration. Ultimately, it’s all about business communication, whether person-to-person or automated. I don’t think BPM really gets this. 3. The business world today is already in a knowledge economy (read: know-how economy); the milestone has been passed. We need to start acting and practicing accordingly. You certainly can’t get there with only BPM.