Columns

Industry Insider

• By Jason Martin
• July 5, 2001

In the early 1970s, systems organizations began to realize that data should not be "owned" by an application area, but is best shared among the applications that use it. Systems programmers tried to optimize the physical location of data on devices, but had little control over the duplication of data across files. We began to see data as a central resource that should be shared across applications and made available for online, decision support and analysis.

This view has grown to include warehousing data for further analysis and dissemination. The organizations that suffered through these changes grew a new organization, usually called Data Administration (DA). This central data control organization acts as a clearing house for all data requests, standardizing and controlling all access.

DA was tasked with the tracking and control of the central data resource. Most shops made some efforts toward mapping and logically modeling the data in a form higher than its physical storage. These DA organizations became an overhead to the systems shop, but they also provided a service to the application groups, who could view the central data, but were not totally responsible for it. There remained pockets of duplicated, replicated, redundant data in some areas, but these were considered minor problems. Some duplication may have been justified by heterogeneous environments or varying access needs. Middleware has recently come into existence to make data seamlessly available across platforms. It has taken some 20 years to centralize and standardize the data administration function across the organization.

What are objects?

Objects are not necessarily "owned" by an application but might be used by several applications. Most objects are related to a certain data structure or database, but this is not the discerning factor. Objects are a combination of data and process rules, carefully isolated to represent some real-world metaphor. The service performed by the process portion is usually called a "method."

Since objects are reusable by more than one application, they should be stored in an accessible, (yet controlled) repository or library. Given that objects are based in data, shouldn't the object repository simply be an extension of the data administration function? That seems a plausible solution for some organizations, but perhaps only for those where DA has the broadest definition and most encompassing power.

To truly place the responsibility for objects, we must clearly examine the efforts that go into building and maintaining objects and their repository. Few would deny the benefits from effectively using such a library, but no one seems to want the responsibility for building it.

Let's consider an object vaguely analogous to the subroutine of olden days. Major productivity gains are realized from its reuse, and, more subtly, quality improvements are gained from that same reuse. (Residual defects are likely to be found in the earliest implementations. Later reuse is far less likely to discover a defect.) On the down side, someone has to put a little extra effort into building and generalizing the routine for reuse. Once built, it must be cataloged to make it available for reuse.

Defining, building and cataloging reusable components will take more time and effort. The first project to use the object will gain, perhaps only slightly from its existence. Now, in the big picture, we should define, build and catalog the objects for future use because it will benefit the organization as a whole. But let's be realistic. From a project manager's view, there is little to gain on immediate schedule or budget. The benefits will mostly come to future projects through reuse. With day-to-day pressures, the individual project manager has little incentive to contribute to the organizational object repository.

Does this assume that all projects are dominated by short-term management thinking? Yes. The current budget and schedule are usually the driving forces behind project decisions. If this is so, who is responsible for the higher level benefit to the organization? Who is looking for the productivity improvements and long-term quality enhancements of reuse? If not the project managers, then surely the chief information officer (CIO) would be looking out for the corporate good. Right? This depends largely on expected tenure and other demands of the moment. With the current tenure of CIOs limited to around three years, they show little understanding and emphasis on long-term investment in object repositories. Building reusable objects (like subroutines) takes a little extra effort, but more than pays for itself in the long-term reuse. We must encourage project managers and their teams to identify and build objects.

Repository access

Assuming that we can get developers to add the necessary effort to make good, reusable objects, we still need to make them available to other projects. This is no small feat.

Accessing objects means that their meaning and value must be comprehensively cataloged so that other potential users will know that the object exists. Where a complete enterprise data model exists, there should be an easy extension of the model to note objects that represent and service the entities. Objects should be easily accessed using standard interfaces depending on the interface capabilities of the platform and language. Ideally, these qualities will become more and more compatible as time goes on, currently following the Corba standard. Eventually, we should expect to see interfaces that are transparent of platform, operating system and language considerations.

In the meantime, the use of objects will still probably require some human intervention, but who will do it? DA organizations say that it's not their job. Applications groups have a more narrow view. Systems programmers of bygone days are more focused in other environmental concerns. Who is to keep the repository of objects?

A new organization? In these days of downsizing, how can I even suggest such a thing? Not easily, but its day has come. Perhaps our next organizational designation is the "object-based administrator." This position would work closely with data administration to coordinate the logical modeling of data and the physical storage of it. Most importantly, the object-based administrator would maintain a catalog of the objects, making them available for reuse. Such a catalog would contain descriptions of function, procedures to use, performance statistics and physical residence information for the data objects and the service routines -- basically everything one would need to know in order to consider using the object.

The object-based administrator would serve a purpose similar to present database administration. The object-based administrator would attend requirements and design walkthroughs to look for reuse opportunities and suggest repository usage. Access to the repository could be standardized and reuse measured.

The object-based organization

The organization of the future will make maximum reuse of all resources, process, data and objects. The overhead of data and object administration will be considered small in relation to the vast gains in productivity and quality that stem from reuse.

Just like the programmer of old would seldom choose to rewrite a sort routine instead of using a sort utility, the new developer will first refer to the object base catalog before reinventing any wheel.