The Brutal Reality Of Irm

The challenge facing systems development since the MIS movement of the 1960's has been to share and reuse information resources on an enterprise-wide basis. There are substantial benefits for doing so:

• The elimination of redundant work effort in systems design and programming, thereby accelerating delivery.
• Simplified maintenance and enhancements of systems by controlling the whereabouts of information resources and how they relate and affect other components.
• Integration of systems and software, thereby eliminating data redundancy and the production of inconsistent information.

Consider this, had companies been controlling information resources properly over the years, the crossover to Y2K would have been a nonevent. Instead, billions of dollars were spent in preparation for the switch.

The concept of Information Resource Management (IRM) is actually quite simple: to inventory and control all of the resources needed to satisfy the information needs of an enterprise. This includes data components (data elements, records, files, data bases, etc.), system components (systems, business processes, procedures, programs, etc.), and business components (functions, jobs, human and machine resources, skills, objectives, and projects).

To implement IRM, technology was introduced over the years, starting with the data dictionaries of the 1970's which evolved into more robust products referred to as "Repositories" which included a manifest of all information resources and how they are interrelated. An IRM Repository, therefore, represents a centralized consolidation of the whereabouts of all corporate information resources, regardless of where used or how stored, including corporate records. For example, it is equally concerned with the information resources as maintained in manual files as it is with those as maintained by the computer. As such, an IRM Repository bridges manual processing to automated processing.

Basically, the concept of a Repository is to record design decisions during a development project much like how an engineer records design decisions when defining the components of any product. In fact, the Repository concept is derived from "Bill of Materials Processing" (BOMP) which seeks to itemize and cross-reference parts to products, thereby providing the means to share and reuse components. One important byproduct of both BOMP and the IRM Repository is that design documentation is always current and up-to-date; as design decisions and component relationships are updated, the documentation is automatically updated. Further, the design intelligence contained in the IRM Repository is so extensive and precise, it can be used to drive application development aids such as program generators, report writers, and other CASE related tools.

Although techniques such as IRM Repositories and BOMP are useful on a product-by-product basis (or system-by-system), the true benefits are derived when they are used on a corporate-wide scale, thereby promoting the true concept of sharing and reusing components. And herein lies the rub; whereas the technology is certainly available to implement this concept, the management needed to make it happen isn't. Despite the considerable benefits associated with Information Resource Management, it will never be realized in this day and age for three reasons:

1. IRM requires a global perspective of information resources. Unfortunately, corporate America is more conducive to the creation of fiefdoms and, as such, there is more of a spirit of competitiveness as opposed to cooperation in the workplace. It takes true visionaries to understand the benefits of IRM and true geniuses to make it happen.

2. IRM requires standardization and discipline. In order to implement a centralized facility to share and reuse resources, agreement must be reached in terms of the standard components to be defined, their attributes, and how they relate to other components. This also requires standard processes (methodologies) for developing systems so they can be assembled in a consistent and predictable manner. Regrettably, it is fallacious to believe there are any standards in the I.T. community and, as a result, most I.T. shops consist of mavericks with different interpretations of how to address systems development. Concepts such as standardization and discipline are steadfastly resisted. Bottom-line: IRM implies a science with governing concepts and rules, not an undisciplined art form which is how most I.T. workers currently view it.

3. IRM requires long term thinking which is the exception as opposed to the rule in most companies. The true benefits of sharing and reusing resources will not be realized immediately. Instead, it is an investment in the future. Companies will benefit the moment they start to share and reuse information resources from one project to the next. But the real payoff is when the IRM Repository matures, and components are reused time and again.

The concept of IRM reminds me of an incident years ago when there was a problem with famine in India. To help out, the United States sent seed grain to India for the local populace to plant and harvest. This was a viable long-term strategy to take. Unfortunately, when the sacks of seed were delivered to the docks, the people opened them and ate the seed as opposed to planting it. This remedied their immediate hunger problem, but ruined their long term needs. You cannot harvest a crop if you do not sow the seeds. The same is true in IRM. To harvest the crop, we must first document our resources. Only then can we realize the benefits of sharing and reusing them.

Even though IRM is a beautifully simple concept, its only weakness is the management needed to implement it. If you are considering the acquisition of an IRM Repository for your development efforts, consider your management skills first.