Telling a user that he "owns" some corporate data is a very dangerous thing. He might try to exercise "rights" of ownership which could be disastrous to the enterprise and its data. To talk about "ownership of data is tempting, but dangerous. The term "stewardship" may be a better term to use, because it implies a broader responsibility where the user must consider the consequences of making changes over "his" data. Furthermore, data "ownership" may lead to "data hoarding" with possible negative consequences to the organization. This article identifies several specific kinds of ownership or control which people may exercise in an enterprise. It proposes a different kind of stewardship which may be more useful.

Why Have Ownership?

"Data ownership" is a seductive term and a concept which is tempting to throw around. It is often employed to generate interest in data, as in the tool vendor speaking to an end user. "You own this data! Don't you want to have access to it?"

Or the concept of ownership is often employed to find someone who will be responsible for the quality of the data. "The owners of the data must be responsible for its quality." This is often heard when information technology people wish to absolve themselves of responsibility for something-- like data quality, for instance.

However, data ownership in a large and complex enterprise can be a dangerous concept, and it should be the enterprise itself which owns the data. Then, everyone who has any influence over the content and/or structure of the data (end users, data entry, DBAs and application developers) may be encouraged to assume a "stewardship" responsibility for the preservation and quality of the data.

Power to . . . Example Freq.
of
Occurrence
Appl.
Impact
Control who sees data Grant authority to view data Common Low
Control who changes data Grant update or insert authority Common Low
Change incidental attributes Change a zip code Common Low
Change foreign key data about instance Change a departmental assignment Rare Substantial
Create new instance of object Create a new sales district record Often Minimal
Name an instance Decide how to name a district Rare Downstream
Create new business object Create a new way to group dealers Rare Severe
Change definition of object Mutate a district into something else Rare Dangerous
Change definition of attribute Change dealer type to credit rating Rare Dangerous

Figure 1: Forms of Power over Data

Ownership is Power

One may think that a person who "owns" data has power over it. It is, therefore, useful to look at the kinds of power this person might have. There are several levels of power which an end user may have (or attempt to exercise) over business data and the definitions. Power over data can be categorized as shown in Figure 1. Following is greater detail describing each of these kinds of power.

Power to Control Who Sees the Data: If this is exercised in an effort to control empires, it defeats the purpose of sharing company data with those who truly need it. Never tell an end user that he has this option.

There are legitimate situations where viewing (as well as updating) of data should be tightly controlled. Some data is highly sensitive (salaries in the payroll system and, perhaps, some pricing data). Limits on its visibility are appropriate but should be a reasoned policy, not a personal dictate of some executive.

Rather, encourage the sharing of non- sensitive data around the enterprise to avoid its duplication and potential synchronization problems.

Power to Control Who Changes the Data: This should be a power shared between an application design analyst and the most responsible end user sponsor/patron of the application. The application design should clearly state who can change what data and when. This type of decision should be made on a rational assessment of what works.

Power to Change Incidental Data About an Instance of a Business Object: This kind of authority may be distributed by policy to various functional departments in the enterprise. For example, when setting up a new customer, the credit department may determine the credit rating, while the distribution department may determine the customer's shipping zone. Both of these attributes (credit rating and shipping zone) are attributes of a single table (customer master file) but have different update authority. Thus, it is meaningless (and silly) to speak of "ownership" of the customer table in this way.

Power to Change Foreign-Key Data About an Instance of a Business Object: The assignment of a customer to a particular sales division may be governed by business policy (depending, for example, upon where the customer is located). Or, that assignment may be determined by some executive effort to allocate the work load equitably. Either way, that foreign key (and the "grouper" business object it points to) is often a basis for aggregating activity and should be as stable as possible.

Normally, changes to the values of such foreign keys are rare; but when they do happen, they can be painful. Sometimes, history needs to be restated. It is better to tightly control who has the power to change these values and to change them only when necessary--and then in a thoughtful manner.

Power to Create a New Instance of a Business Object: The power to create an instance of a subject entity or business object is often widely distributed around an organization, depending upon the nature of the entity. All subject entities can be organized into the following general categories:

1. Point-in-time business events (e.g., order, invoice, shipment, deposit, etc.);

2. Long-life, stable entities (e.g., vendor, customer, basic product or service);

3. Limited-life entities having an effective date range (e.g., price offering, contract).

Most of the business events are trivial in that just about anyone (especially a sales representative) can create one. More consequential in their creation are the long-life, stable entities. A sales representative may be authorized to create a new customer record. But a sales rep cannot create a new sales district. Someone higher up in the organization must do that.

Changing an attribute, description or condition of an already- existing event is another matter.

Power to Declare What We Name a Given Instance of a Business Object:

The authority to give a name to a customer or a product is generally limited to those in the enterprise who have the skills and understand the consequences. Very often, the spelling of the name may be critical for sort purposes or how it is interpreted by various scanners.

Power to Create a New Business Object: This is very rare. A business executive might find lots of reasons to do it, but unless the automated systems can adapt fast enough, the business evolution is constrained by the design of the legacy systems. For example, as a company grows, a new level in the sales organization hierarchy may be created. This is pretty consequential. Many reporting programs may have to be changed to include a new control break, and a new column or field may need to be added to a lot of tables.

Any exercise of this power is almost always tempered by the inability of the computer systems to incorporate the new business object in their database design and operations. So while an executive may have the legal power to declare a new business object, his wishes may not be implemented until an application is modified. And even then, some analysts have to look at the situation and evaluate the cost and impact. At least they should.

Power to Change the Definition of What a Business Object Is: As the enterprise evolves, there may be pressure to do this, but few executives have the vision to see what is going on in that evolution, and thus don't express their volition in just this way.

Some astute systems analysts may recognize the pressure and recognize what is going on here and set up the design decision so everyone understands the consequence.

Power to Change the Definition of What an Attribute of a Business Object Means: This is done all over the place, usually by obscure programmers who don't talk to data administrators or anyone else. They see what appears to be a dormant field (especially in an application package like SAP) and decide to use it for some other purpose. Sometimes end users do this if they are astute.

Generally this is not a good practice, unless it is subject to a widely attended walk-through where the consequences are thoughtfully evaluated. Any change in the meaning of an existing attribute must be evaluated with consideration given to all the downstream uses of the data.

Region
Code
Region Name Sort
Seq.
1 Northeast     
2 Southeast   
3 Midwest   
4 Southwest   
5 Pacific  

Figure 2: Region Table

There are, however, areas where the definition of a data item is derived, in part, on the basis of some formula or business rule which governs its computation. Then, the power exists in the business policy (or business rules) which establish the formula. (This brings to mind my admonition that no program developed by IT should perform any calculation or manipulate data in any way other than what an end user would do if he had the time and a pencil. There should be no voodoo in the programs. The end user should understand all the rules for transforming the data.)

As can be seen, it is nearly impossible to "own" data, especially in an integrated production systems environment.

Case Study: Ownership of Foreign Keys in Organization Tables

Assume that some centralized tables (the data management method is irrelevant here) are maintained which define the sales organization. The United States is divided into regions and districts.

The region table might appear as shown in Figure 2. Each region is assigned a one-character code and has a description.

Hierarchically below the region is the sales district. The sales district table might appear as shown in Figure 3.

In addition to the district code and district name fields, there is a foreign key (region) indicating which region this district is in. Any change to this data may be very consequential. It would represent a substantial realignment of the sales organization. Furthermore, the timing of such a change may be critical, especially in downstream systems.

While an executive may "own" that third column of data (the region foreign key), it would be imprudent to give him direct ability to update or change the field in a production database. Yet some application packages (such as SAP) permit this. Thus, if the concept of "ownership" is used at all in this situation, it should be couched in terms of "stewardship" or a custodial responsibility for the whole company and all its systems.

Very often, there is a division between the authority (or power) to determine the value of a piece of data and the actual systemic ability to update it in a system table. Who, then, is the owner of that data? The concept of "ownership" becomes less clear, and less useful.

Consequence of Data Hoarding

An end user who is told that he "owns" certain data may exercise data hoarding. Not always with malicious intent, but perhaps because he fears the effort of evaluating the appropriateness of downstream access to the data. He may not have the time to even locate all the downstream uses. Rather, with many mainframe security systems, it is easier to just cut them all off.

Code Sales Distict Region Sort Seq.  
11 Boston 1      
12 New York 1    
13 Philadelphia 1    
14 Cleveland 1    
15 Washington 1    
21 Louisville 2    
22 Atlanta 2    
23 Jacksonville 2    
24 Birmingham 2    
25 New Orleans 2    
31 Chicago 3    
32 Minneapolis 3    
33 Kansas City 3    
34 St. Louis 3    
35 Memphis 3    
41 Denver 4    
42 Dallas 4    
43 Houston 4    
44 Phoenix 4    
51 Los Angeles 5    
52 San Francisco 5    
53 Seattle 5    
54 Phoenix 5    
One consequence of this will be that other potential users of the data will create their own versions. Many enterprises have multiple copies of key data. The classic is the number of customer files or product files which may be found. They may not be in sync, and they may contain conflicting data. This results in executives receiving reports which do not balance and undermines these executives' confidence in the data.

A better policy is to be as liberal as possible in granting access to data and make it so easy to get to the data (or data warehouse copies of the data) that no end user would dream of rekeying the data into his own personal version.

Stewardship of Data

The concept of stewardship is more in keeping with the interdependency of corporate departments. This term implies an accountability to external authorities--the need to consider the interests of someone (or some department) other than one's own.

Yet the role of "steward" does not necessarily include the authority, power or wisdom to decide who has a legitimate need or downstream access to the data. These questions (granting read access) should be decided in a broader context, with the steward, a data analyst, perhaps a DBA and other business people participating in the discussion and decision (especially if the data is considered sensitive and someone wants to put restrictions upon its distribution).

Quality Stewardship

This can be a shared role, between an IT analyst and a key end user with the power (and/or interest) in ensuring data quality. Some quality-preserving actions must be systemic in nature, designed by an appropriate IT specialist. But some quality issues (particularly on text fields and reference tables with description fields) are of a nature that they cannot be insured through any automated means. Rather, someone must look at the data and say, "Yes, that is right." Or, someone must say, "Yes, those are the rules which we want the data to abide by."

Definition Stewardship

This is the responsibility to define clearly what the data means and/or make decisions about consciously evolving that definition. Again, this should be shared between the application analyst, the data administration function and the most knowledgeable end users. Any changes to definitions or meanings of columns and/or tables must be given thorough consideration, especially if they (the tables and their data) are widely used around the enterprise.

Access Stewardship

This is the ability to (and responsibility to judiciously) permit or prevent read-access to data. A more narrow version of this is to decide who can update production data, although those issues are normally dealt with during application design.

Again, this stewardship may best be a shared function, with data analysts and knowledgeable end users playing a joint role.

Conclusion

Using the term "owner" of data is dangerous in a number of ways. First, it may inhibit the sharing of data around an organization. Second, it may not facilitate the quality of data. It is better to look at data stewardship as a distributed responsibility, with the designers of applications and databases having a significant role in ensuring data quality.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access