I have written about “rules” in an MDM context before.  How an organization masters rules is not a new topic; analysts have written about (business) rules engines before.  But MDM is bringing a focus to the topic again, in the context of:

• What type of rules are there?
• Who authors such rules?
• How are such rules used?
• If rules or parts of rules (or rule making processes) are re-used, how can this be made effective?

It is the last question that is making users of MDM conclude that rules and MDM need to be related more closely.  And because BI is immersed in rules, the connection between BI and MDM is more important.  A client inquiry brought this connection unto clear focus today with the following description:

“We have been developing BI for many years, and we recognize that rules that adjust data in some fashion exist at many places in our systems, from initial identification, transformation, load, then aggregation, and even ‘post BI’ since users then take data and drop it into a spreadsheet and do more manipulations.”

These rules, in the context of BI, are what constitute aspects of what I call, “passive governance”.  My college, Mark Beyer, would chuckle and correct me with, “Andrew, this is not governance at all” and Mark is correct; I am just a little kinder and I accept that these rules have a job, that is to clean up and process data in a way that should be meaningful to the user/business.  As such, when “active governance” is established (aka MDM) then rules are again created to clean up and process data in a way that is meaningful to the user/business.  The different is that in BI land, these rules are created and managed by IT independent of the operational system; with MDM these rules are defined by business and directly interacting with the operational system.

So the challenge for me is much clearer – after this one dialog with a client – spelled out the obvious.  Over time more and more users will rationalize that they need to apply MDM disciplines to rules that process master data; and also, beyond that, integrity and re-use of those rules, even those that process non master data, can also yield business benefit through more effective management.  The connection between mastery of business rules, and how MDM tools help, will only increase in strength in the next few years.

It seems the Rime of the Ancient Apps Manager/Mariner should be something like:

Rules, rules, every where,

And all the re-use did shrink,

Rules, rules, every where,

And not an object to link.

We have business rules all across the IT stack; from inside ETL tools to manage how data is mapped and moved, to business applications to control how data is processed, even to within a data services environment that operates system wide.  We did not host a session at the Gartner MDM Summit on business rules, yet there were many sessions where speakers drilled down on the existence and use of business rules.  Ted Friedman talked about rules in his data quality session (on Monday in fact); Debbie Wilson talks tomorrow about business rules in her Procurement MDM presentation and how they help buyers automate managing and cleaning up procurement oriented master data.   Deb Logan and I talked about business rules in our governance session today; and tomorrow Mark Beyer and Michael Blechar talk about business and data services rules when they talk about SOA, data services, and metadata management.  But, where are the business rules engine vendors – and don’t they have an MDM-like role to play in the emerging business process platform?  I would guess yes… 

As I said a few times at the Summit, we have just spend 20 years building many tall, thick-walled vertical silos oriented around business applications and business intelligence with data stuck firmly inside those silos.  We are just starting on a journey where we will spend the next 20 years throwing that out (as a design concept) for a new set of horizontal silos.  BPM will be one large common discipline across the business; MDM will be another.  Perhaps Business Rules Management will be another…

What do you think?  Too complex?  Too many different requirements and degrees of granularity?  I don’t think we are their yet for MDM, but maybe soon?