Is Centralization the Answer?
In response to the need for a central, unified source of data definition, structure, content, and use across the corporate information factory, the notion of a central repository arises (see Figure 12.3).
Figure 12.3 One approach to managing metadata is the data dictionary or the central repository approach.
The central repository approach is a good solution to the needs for sharability of metadata. However, is a central repository the answer to the organization’s needs?
Consider the scenario of a DSS analyst working on Excel who is deep into solving an analytical problem. At 2:17 A.M. the DSS analyst has an epiphany and makes changes to the Lotus spreadsheet. Does the analyst need to call the data warehouse administrator and ask permission to define and analyze a new data structure? Does the DSS analyst need permission to derive a new data element on the fly? Shouldn’t this new data structure and new data element be documented in the metadata repository?
Of course, the DSS analyst does not need or want anyone telling him or her what can and cannot be done at an early morning hour in the middle of a creative analysis of a problem. The DSS analyst operates in a state of autonomy and the central repository is neither welcome nor effective. The repository simply gets in the way of the DSS analyst using Excel. The DSS analyst does what is needed to bypass the repository, usually ignoring updates to the metadata in the repository.
The need for autonomy at the DSS analysis level is so overwhelming and the tools of DSS access and analysis are so powerful that a central repository does not stand a chance as a medium for total metadata management.
Is Autonomy the Answer?
If a powerful case can be made for why a central repository is not the answer, consider the opposite of the central repository where everybody “does their own thing,” as shown in Figure 12.4.
Figure 12.4 The autonomous approach to metadata management.
In the figure, autonomy exists in that every environment and every tool has its own unique facility for interpreting metadata. Because no constraints of any type can be found anywhere in the environment, complete autonomy is in place. The autonomy suggested by the figure is pleasing to the DSS analyst in that no one or no authority is telling the DSS analyst what to do. However, the following questions arise:
- What happens when one DSS user wants to know how data is defined and used elsewhere?
- What happens when a DSS user wants to know what a unit of data means?
- What happens when one DSS user wants to correlate results with another DSS analyst?
- What happens when a DSS analyst needs to reconcile results with the source systems providing the data for analysis?
- What happens when data is not interpreted consistently? What profit figures are correct?
The result is chaos. There simply is no uniformity or cohesiveness anywhere to be found in the autonomous environment. The purely autonomous environment is as impractical and unworkable as the central repository environment.
Achieving a Balance
Neither approach is acceptable in the long run to the architect wanting to make the corporate information factory a professionally organized environment.
In order to be successful, the CIF architect must balance the legitimate need to share metadata with the need for autonomy. Understanding the problem is the first step to a solution. In order to achieve a balance, a different perspective of metadata is required, distributed metadata.
Figure 12.5 The metadata within each component is either shared or autonomous. The categories are mutually exclusive.
The structure for metadata suggested in Figure 12.5 states that there must be a separation of metadata at each component in the architecture between metadata that is sharable and metadata that is autonomous. Metadata must be divided at each component of the CIF:
- Applications
- Operational Data Source
- Data warehouse
- Data mart
- Exploration/data mining warehouse
Furthermore, all metadata at an individual node must also fit into either a shared or autonomous category. There can be no metadata that is neither sharable nor autonomous. Likewise, metadata cannot be sharable and autonomous at the same time.
But Figure 12.5 has other ramifications. The metadata that is managed at an individual component must be accessible by tools that reside in that component. The tools may be tools of access, analysis, or development. In any case, whether the metadata is sharable or autonomous, the metadata needs to be available to and usable by the different tools that reside at the architectural component.
Another implication of the figure is that sharable metadata must be able to be replicated from one architectural component to another. Once the sharable metadata is replicated, it can be used and incorporated into the processing that occurs at other components of the corporate information factory.
|
