- By Jason Martin
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
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.
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.
Jason Martin is a consultant and methodologist working in process improvements and development tools. He is a director responsible for process improvement at Prudential Insurance, Jacksonville, Fla .