Lectures related to master data bring forth all sorts of taxonomies intended to help clarify master data and its place within an organization. Sliding scales may be presented: at the top, not master data; at the bottom, very much master data; in the middle, increasing degrees of "master data-ness." For the longest of times everyone thought metadata was confusing enough ... oops, we've done it again. And, we have accomplished the establishment of this master data semantic monster in quite a grand fashion. Depending on circumstances, metadata may be included within the boundaries of master data, giving us two fuzzy ideas for the price of one. Some tools provide the shiny veneer of simplification. The attempt often is made to convince everyone that there exist only two kinds of data, transaction and master. Of course, this does have us slip down the slopes as we try to convince ourselves that transactions updating master data are really master data and not transaction data at all.
Some pundits try to reuse perceived absolutes from multidimensional approaches, "Facts are transactions, and dimensions are master data." While it might be nice to consider all character data as master data, that approach seems wrought with overkill; not to mention the occasional confusing numeric data that in some contexts are measures for a fact, but in other contexts are dimensional in that they are used for grouping. Battle lines are drawn over inclusionary approaches trying to embrace almost everything as part of one's master data versus a tactic of exclusiveness wanting minimal data points to qualify as true master data to be managed. Justifications grope at ideas like local master data versus global master data, ultimately saying, "Yes, it is master data, but it is local master data and meant only to exist within this single application."
Just how far is it appropriate to go in designating data as master data? There are a few things that everyone can agree about regarding master data. Master data is not transactional, meaning a single service order, or purchase request, or any possibly-recurring-submission-of-something; these elements are all examples of things that would not be expected to be master data. Another point of agreement is that business objects that are likely to be considered master data are used across multiple functional areas. Therefore, each area would want to support a listing of these business objects. And should a common source of these business objects not be available, each area might create lists that somehow vary and even disagree with each other. Examples of this particular master data case could be customer lists, vendor lists, or distributor lists. Also, it is agreed that master data is important to the business; this agreement is often lost as virtually every code value, because it might be reused across applications, can get lumped under the master-data umbrella. Consistency of code sets is a good thing, and ideally should be embraced under the functionality of a DBMS' implementation of domains rather than as an ever-increasing guise of master data to be supported.
What really is master data, what might be master data, and what might not be master data are all very interesting questions. Depending on the tools, vendors, and pundits included in any discussion, varying answers will most certainly arise. At the end of the business day, each organization simply needs to agree within itself about what is important to the performance of their activities. Internal consistency gives a business the means to gain value from a master data solution. Lack of internal agreement on master data simply leaves the door open for problems down the road.