Information engineers wanted to build enterprise models; to achieve the goals of modern Case, modelers must understand, translate business strategy - computer-aided software engineering

Richard Mach

INFORMATION ENGINEERS WANTED TO BUILD ENTERPRISE MODELS

When corporate management asks MIS management to explain why their projects are late and over budget, a language barrier often prevents them from understanding each other. The CEO's prime focus is on business concerns, such as productivity and quality, while the systems manager's main concern is technology.

Companies today are challenged to exploit technology to help accomplish business goals.

In order to do so, the MIS profession needs to change its focus from "technology" to "business." MIS professionals need to become business professionals first. Similarly, users and their management need to get involved with "computers" as an integral part of their business.

A methodology offering a common ground is computer-aided software engineering (Case). Case is not only a direction of data processing, but is part of an overall business management movement that focuses on quality and productivity as a means to improve our competitive situation in the world market.

"Case is a fundamental paradigm shift in the business of data processing," said Donna Rund, an information engineering manager for Levi Strauss & Co. in San Francisco. "[It entails] fundamental changes to what data processing is all about."

Indeed, it entails fundamental changes to how businesses approach MIS. These changes promise to impact skill sets, personality profiles, organizational structures, ideas of specialization and career paths. In short, MIS is facing culture shock.

Mary Rich, an expert in enterprise modeling and an independent consultant from the Los Angeles area, said, "The key to success doesn't really depend on the tools. There are lots of good tools. It depends on developing a culture in which they can be [effectively] used."

Software developers and managers of DP who are looking toward Case as a cure-all should keep this in mind: The underlying message of Case is productivity and quality. It's central theme is not about technological sophistry or even running faster.

In my revised story of the race between the tortoise and the hare, the hare never falls asleep, but still loses the race. Although the hare runs at speeds in the Mach range, he never takes the time to plan his race route. In fact, he never knows where the finish line is. His philosophy is that if he runs fast enough, he will impress the crowd and eventually find the finish line. He never does.

The tortoise, on the other hand, operates at subsloth speeds. When the gun goes off to start the race, he does not start running. Instead, he gets out some maps and asks race officials and aficionados where the finish line is (the goal). Only when he has a reasonable plan does he start the race. He wins, hands (or is it claws?) down.

The story of the tortoise and the hare is one of efficiency and effectiveness. The hare was efficient. He did things right! He ran fast! The tortoise was effective. He did the right thing! He went directly to goal!

Case products can be used to achieve efficiency. Developers can program faster. Database managers can build databases faster. However, Andrew Galat, senior partner, CSC Partners, a consulting firm in Oak Brook, Ill., suggests that the implementation of Case products may actually result in doing things slower, but better.

LIFE-CYCLE COSTING

A spokesperson from a firm trying to improve its implementation of data administration said, "We get gold stars for delivering systems on time and within budget, not for integration." Could this firm, which did not want to be identified, have used Case? They are in fact using data modeling and functional modeling which are key components of Case products. But it is "magic" modeling for a "pilot" project with a narrowly defined scope. It is being done in the back room by lower-level analysts, without much user participation.

The pilot project may produce an application of higher quality within narrowly defined concepts. For example, the supporting databases may be "pseudonormalized." But it is doubtful that any significant integration will occur. Instead, another "island of automation" will be created.

A few years ago, my family decided to buy a new dishwasher. The price tag on the one we wanted was much more than most other brands. We bought the "more expensive" brand because we felt the life cycle of that dishwasher was much longer than the cheaper brands. We also calculated that the maintenance costs would be lower, the aggravation less and the dishes washed better. We were thinking in terms of the cost of a dishwasher over its life cycle--that is, life-cycle costing--not of the cheapest purchase price.

Life-cycle costing is well-established concept among quality engineers, such as Joseph M. Juran and W. Edward Deming, Americans who taught the Japanese about quality after World War II. The Japanese have made hay (at our expense) with this concept. Essentially, what the Japanese believe is that "quality is productivity" and vice versa.

In the information systems (IS) development world, two pertinent and startling figures have been bandied about for years: 80% of MIS development resources are consumed by maintenance and enhancements to existing systems; and 80% of the cost of systems maintenance is traceable to requirements (either faulty or changing). Yet, estimates for systems or database projects do not factor in the costs of maintenance.

Buying into Case means buying into a philosophy. The technology is important, but secondary. The underlying theme of Case is the same as the underlying theme of world-famous quality engineers: that is, quality is productivity.

A company turning to Case must be ready for this philosophical shift.

According to Juran, quality means that the goods and services delivered to a customer are usable--the first time. This idea is central to quality programs such as "zero defects."

To put quality into a more significant context, Juran said that to some degree a customer always values quality, delivery and price. In short, a customer wants a usable product, delivered "just in time" at a fair and competitive price.

Businesses that fail to deliver what their customers value will sonn find themselves out of business. Many businesses do not make the effort to understand how the customer uses the product. Thus, a business' quality specs often reflect their own perspective of quality, rather than the customer's.

USERS ARE CUSTOMERS

A DP organization must realize that its users are customers. In the mid-'70s, as an MIS manager, I was given the task of establishing an information center at my firm. The idea was to give the users access to the data they needed to produce reports when they wanted them and in the form they wanted. Basically, the information center provided training and hand-holding. We would not write programs for the users. They had to invest time and effort into this endeavor if they wanted to share in its benefits. The users loved it. In the first year of operation, over 100 users had been trained and over 50 users were actively programming in the query languages.

Like most MIS departments, we had a huge backlog of "systems service requests." The information center was supposed to address this backlog. Actually, many users had stopped submitting these requests, because they knew they would never be serviced. A longer-term goal was to increase the "computer literacy" of the user community, essentially to improve the communications between MIS and the user community.

The MIS community resisted. The attituse was reactive, not proactive. MIS professionals were guarding their fiefdoms. Cleary, to some, users were not customers.

The same scenario took place when personal computers first hit corporate America. The MIS folks were scurrying to implement "corporate standards" that would essentially give them veto power over whether a user could buy a PC. They wanted to maintain control over the introduction and management of computers within the corporation.

A DP organization should seek out its markets. Instead, MIS tends to spend time classifying requests as either maintenance or enhancement. Users properly regard this behavior as defensive. They see no value added by these classifications, but rather a scheme to fix blame.

Case vendors such as: Oracle, Belmont, Calif.; KnowledgeWare, Atlanta; and Texas Instruments, Plano, Texas, share some viewpoints:

* The belief that systems and databases need to be tied explicitly to business goals, objectives and plans.

* The need for a broad-based, overall architecture/blueprint for development. This architecture is cross-functional and models how things fit together (integrate) in an enterprise.

* Development projects will be phased, reflecting an orientation to large, complex information systems.

PLATFORM-INDEPENDENT DESIGN

The Case approach promotes the idea of a platform-independent design. With this approach, design is split into two phases: logical and physical.

A logical design is free of technological constraints and assumes perfect technology; that is, computers are as fast and reliable as you need, they cost nothing and communications is not an issue (and thus there are no distribution issues).

Although these assumptions are ludicrous, advantages to this approach include:

* A large portion of the systems and database specifications can be effectively and efficiently reused, regardless of platform. For example, a conversion from IMS to DB2 could be made relatively painlessly.

* The design is easier to communicate with non-DP professionals, because it is free of a lot of the technical jargon. At the same time, however, it introduces various functional and data modeling jargon.

* Assuming that the Case products can capture all or most of the knowledge necessary to make various logical-physical transformations (with the addition of some metrics), then reliable, error-free programs and database definitions can be automatically generated (and regenerated).

* It frees software developers of the burden of knowing all the eccentricities of various technical approaches.

Texas Instruments claims that its IEF Case tool has generated over six million lines of code without a defect. That is an outstanding claim.

Mike Watters, vice president, general manager, Advanced Information Management Division, Texas Instruments, in commenting to the press about IBM's AD/Cycle, said "It's important that the application development environment be as separate from the 'technology environment' or 'platforms' as it can be. If I am a heterogeneous DP shop, I might have an IBM mainframe, an HP or DEC minicomputer and maybe a Sun workstation--multiple hardware and operating systems. What is needed is an application environment that is consistent across all of those technologies."

What Watters described is the idea and ideal of the Case logical/physical separation.

The read world is heterogeneous, and will continue to be so. The fact is, certain platforms are better at certain things. IBM rules the mainframe world of administrative data processing. Desktop publishers prefer the Apple Macintosh, and Digital Equipment Corporation is strong on the manufacturing shop floor.

Increasingly, MIS is (rightfully) loosing its stranglehold as the "managers of technology" within the business environment.

In such an environment, the logical design becomes the key deliverable, an opposed to technical database definitions and Cobol programs. Maintenance is then done to the logical design, not the programs.

Programmers and database administrators could perceive a threat from such a philosophy. Cloene Goldsborough, director of data resource management at TWA, Kansas City, a TI client using IEF, said, "The emphasis will shift to people who can do reuirements analysis and design." [Software Magazine, September 1989, p. 40.]

Steven Barsh, president of SECA, Conshohocken, Pa., which helps companies implement Case software, said, "The greatest barriers to software engineering are cultural rather than technological" and "education is the catalyst."

According to Barsh, "A broad consensus now exists among MIS managers that software engineering is both necessary and inevitable, but it is difficult to get the...programmer to go along. Programming is considered an art, and many programmers resent the formal, documented approach that software engineering requires." In this case, the cultural problem is to modify the behavior or attitude of programmers. They must see that creativity is enhanced by a more disciplined, methodical approach to developing software.

Howard Fosdick, an independent consultant from the Chicago area, thinks culture shock has something to do with the reduction of specialization that Case will make more and more possible. In short, with Case's internal knowledge about generating code and various control blocks, there will be less of a need for specialists in IMS or CICS, for example. With the help of Case tools, analysts will be technically capable of doing more of the total job.

Consultant Rich said that "developing the culture" in which Case can be used effectively may be the big deal of the day.

DISCIPLINE COUNTS

Discipline, according to Webster, is an "orderly or prescribed conduct or pattern of behavior or a rule, or system of rules governing conduct or activity. It is enforcing order."

All Case products use both process and data modeling techniques. Discipline, in this case, would mean that an enterprise would follow the rules governing the chosen modeling techniques. Note also that each Case product has, more or less, standard deliverables associated with each development phase. This implies the imposition of order.

Methodology takes Case development a step further. Webster defines methodology as "a body of methods, rules and postulates employed by a discipline: a particular procedure or set of procedures."

There are different viewpoints on the importance of a particular methodology in respect to Case products. TI bundles the components of its Case product and feels that methodology is the cornerstone. Oracle offers a methodology. Knowledge Ware lists methodology-independence as a benefit of its Application Development Workbench (ADW) product.

METHODOLOGY NEEDED

There is some confusion about where methodology ends and modeling techniques begin. Some people refer to a methodology as a step-by-step guideline for development; others seem to think that the application of a particular modeling technique is, in itself, a methodology.

IBM, with its broad customer base, has promised that AD/Cycle will be methodology-free.

Whatever the particular position on the methodology, it is clear that the implementation of Case does impose a more disciplined development approach. Case vendors uniformly believe that a client implementing Case needs a good methodology.

For a firm that values integration, which might well be an overriding reason to buy into Case, discipline, if not methodology, is essential.

On the other hand, methodologies are a two-edged sword. Oracle's literature warns: "Many mechanistic techniques available today are so repetitious, procedural and boring that good people forget to use their brains and are inhibited from thinking of better ways of doing things."

Firms believing that a methodology will automatically result in a more disciplined approach are perhaps in for an unpleasant surprise. Notice that the definition of methodology is that it is employed by "a discipline," not the other way around.

The successful user of a methodology understands the underlying disciplines. We cannot simply describe the "process" that architects go through, if the user of this process is not an architect. It does little, if an engineering department lays out a step-by-step procedure for designing products, if the user of this methodology is not an engineer of a designer.

According to TWA's Goldsborough, "The emphasis will shift to people who can do requirements analysis and design. We've found that...action diagram[s]...can be done very well ... or very poorly."

Good programmers are not necessarily good analysis. Usually they lack adequate training in the systems analysis discipline, and sometimes have the wrong personality profile. On the other hand, many technical people make excellent analysts. Some brilliant analysts will be liberated by the new jobs, which will demand much greater skills in the arena of human interaction.

An even bigger problem is the lack of expertise in the "discipline" of systems architecture or high-level requirements analysis.

Levi Strauss recognized that "Case concepts" would have a major impact on their environment. The company believed that the implementation of these concepts would create a huge culture shock, and thus required investment in retooling and retraining.

The company's Rund believes that all too frequently companies buy software "willy-nilly," without a vision of where it takes them, or where they are going in the greater scheme of things. She believes that this leads to a DP "feeding frenzy."

In 1987, Levi Strauss developed the "Martinizing Plan." A major part of this plan was to start developing the skill sets necessary in these new disciplines. It included developing skills in logical and structured design and data modeling.

A key component of the plan included the establishment of a chief information officer (CIO) who would understand the company's goals and strategies, and educate management on how they could use information systems to strategic advantage.

They began changing relationships with users in the development process, getting them involved and establishing partnerships.

Within the plan, they began to develop their information engineering organization. This included training and application in the information engineering tools and methods, and developing the infrastructure to support integration across functional project teams.

As part of the "Vision program, the company became serious about Case software in 1989. Levi Strauss wanted software that was full-life-cycle, and had the capability of porting designs across multiple platforms. The company chose KnowledgeWare's Information Engineering Workbench because of KnowledgeWare's commitment to an open architecture.

One of the more difficult adjustments is getting across the idea that projects cannot be managed independently. The consequences to other functions have to be considered.

The plan's ideals include:

* From a corporate standpoint, data should reside in the database only once.

* A conscious effort to try not to duplicate business functions.

Rund said their strategy entails a "change in the basic assumptions." For example, the investment strategy is to invest in good, reusable design, not code. And the integration of business and process include positioning for "business reengineering."

Consistency, accessibility and availability generally define the quality characteristics of information. They also define productivity. This is what the application of the Case concept is all about.

"ENTERPRISE VIEW" ESSENTIAL

Some major strategies underlying the goals of Case include integration, business orientation, and asset or resource management.

What makes payroll think that there are 4,500 employees, while personnel swears there are 5,000? They probably count them differently. There is no shared "enterprise view."

John Flanagan, a partner in Affiliated Business Consultants, who is based in Northridge, Calif., put it this way: "The computer is a fast and accurate idiot, but it can't handle ambiguity ... it is incapable, by itself, of dealing with a language as insidious and ambiguous as English." This knowledge must be "engineered."

In a "logical design," the tactics of data (ultimately language) integration primarily include the elimination of redundancy and ambiguity in meanings, not storage. Also, they are used to discover language concepts missing in the enterprise language. Presently, the major underlying disciplines aimed at addressing this significant "improvement opportunity" are mathematically based in disciplines like relational and predicate calculus. In Case, they primarily take the form of data models.

From the process perspective, the strategy is much the same: the elimination of redundant and overlapping functions.

Ultimately, the separation of data and process is unnatural. Data has no meaning unless it is put into the context of what a business does. Similarly, a process that does no capture and use data is meaningless. Data and process models are just two viewpoints of the same thing: your business.

The application of technology without a comprehensive understanding of the business process that it serves

often leads to a decrease, rather than an increase, in productivity.

Alexander Meikeljohn, an American educator (1872-1964), said, "There is, I think, nothing in the world more futile than the attempt to find out how a task should be done, when one has not yet decided what the task is."

What is needed is a professional and disciplined approach to requirements. It must incorporate what management values and address what can be done to achieve those values; that is, business processes, not computer processes.

A manufacturing firm devised a process model that expresses the business viewpoint. (See Figure 1.) The high-level process (functional) model represents the firm's viewpoint of its "customer order cycle."

The model was produced by a strategic planning team that consisted of a "partnership" of users, MIS professionals and a "systems architect" (a consultant who was expert in the discipline and methodology of strategic information planning).

The team knew that management valued certain things:

* Shortening the order cycle. That meant reducing the time required from a customer's request for product, until delivery of the goods.

* Meeting the customer's delivery schedules 100% of the time.

* Meeting or exceeding the customer's quality expectations, thus eliminating returns and allowances.

* Flexibility in allowing order changes, and being able to accurately tell a customer the status of an order at all times.

* Timely collection of payments.

The teAm's mission was to identify those business activities most pertinent to the accomplishment of these goals, seek out pertinent problems and improvement opportunities, and make recommendations. The team also had to come up with a plan for the ultimate implementation of improved business systems.

The model represents the team's version of those activities that "are most pertinent to the accomplishment of management's goals."

This particular type of process model is called an IDEF-0; a technique that is also called activity modeling. It is popular in the aerospace industry. If it is used well, it is particularly adept at expressing the "business viewpoint" and contains a lot of pertinent information on a single page. Its drawbacks is that it tends to get too busy.

If one is fairly skilled at constructing and reading such a model, pertinent facts are revealed. For example, the common purpose or goal of the system can be seen in its ultimate outputs; e.g., deliveries (shipments) and bills. Critical success factors commonly are those major "flows" between functions. For example, if shipping does not receive timely and accurate facts about what to ship, how much and to where, meeting delivery schedules will be jeopardized. This is a critical success factor.

This model clarifies the business requirements, not in terms of any specific reports, but in terms of the business functions as pertinent to servicing customer orders. Notice, in fact, there are no specific reports, screens or forms on this model.

Less obvious is that these functions need to share the pertinent data. To effectively communicate, they must share a common understanding of what the data means. Toward this end a common data planning model was constructed.

From the process model, the team found that many orders were awaiting credit approval for extended periods of time. One way to correct this would be to incorporte in the system more explicit, quantifiable "knowledge" about how a customer's financial viability is routinely verified. In this way more orders could be accepted quickly, and credit department approval would be reduced to exceptional situations. Another solution would be to use EDI to communicate exceptional orders to credit and to communicate with Dun & Bradstreet. The company could also set more specific objectives for how long a credit approval should take.

From the data side, it was found that the manufacturing plants did not share a common identifier for common products. Salespeople always assigned orders from a certain customer to a given plant, even though the same product could be produced at multiple plants. This, in turn, had the effect of single-threading manufacturing resources, wasting capacity in some plants, while overcommitting others. A common product identifier would be adopted across plants.

On the other hand, it was found that virtually every function had a legitimate, but different, viewpoint of who the customer was. For example, to order entry the customer was the organization that placed the order. To shipping it was the organization where the order was delivered.

In the case of customer XYZ Corp., the address where the bill was sent, the order was placed and the delivery made was the same. However, for Widget Co., orders were placed from/shipments were sent to different addresses. The data architecture thus reflected different roles (relationships) that the same piece of data could legitimately play. One positive effect of this was that communications would improve and the occasional embarrassing and costly shipment to the wrong address could be eliminated.

WHO KNOWS THE REQUIREMENTS?

To effectively achieve the goals of Case--integration across functional areas of the business--someone must understand the business in terms of its information and cross-functional communication needs. Process modeling tools, data modeling tools and methodologies are excellent mechanisms. But they will prove ineffective, especially at this level, if they are not applied to model the business--the real system.

A quick glance at the functional model is revealing. Each function has its own perspective. Yet by definition, the functions of a company are there to take advantage of specialization. Further, if we look at the model, XYZ Corp. is not in the business of negotiating orders, or buying products, as independent functions. The point is, all these functions must work together for the company to be effective and efficient.

For this to happen, the right (availability) facts must be communicated accurately and clearly (consistency) in the form they are needed and when they are needed (accessibility).

But none of these functions has a global understanding of the whole "order service cycle." Thus, none is capable of planning information requirements at this level, particularly if these requirements must be translated so that the "fast, accurate idiot" can understand them.

The fact is, nobody understands the information requirements at a strategic level.

Certainly, it will take the combined knowledge of all these functions to construct a good strategy. It must be a team effort. Yet can such a team build an architecture suitable for development?

Let's try an analogy. Antiqua is planning to build a new high school, which will have a gym and a theatre. Thus, the Antiqua School Board assigns the basketball coach and the drama teacher to come up with an architecture and plan for the new facility. Ridiculous! These people are not architects.

PREDICTABLE RESULTS

Time and again, firms put together "management teams" to come up with a strategic information plan; they normally include a high-level MIS manager. The results are all too predictable. Typically, MIS teams will take a perfunctory look at the plan, say they reviewed it and are conforming to it, and go on with what they were doing or start all over.

Obviously, an information architect is needed. Typically, firms do not do a good job of training their lower-level systems analysts, much less an "information architect." Most firms do not have a single systems architect. Companies will not be successful with Case unless they realize they will need to train and build architectural skills. Meanwhile, they will undoubtedly have to look outside--to high-level consultants--for these skills.

To get MIS under control, companies are hiring chief information officers or enlisting the help of a consultant. The "right" solution probably includes both options.

The CIO option is necessary if business goals and the strategic directions of the company are to be incorporated in their information management plans. In modern manufacturing companies few people actually touch the product (5-10%). This means the remaining 90-95% are knowledge or information workers. Information management is an incredibly important (and costly) facet of the modern corporation, thus a CIO as a member of the board needs input to affect corporate directions and values.

This move signals a change in the role of MIS from managers of technology to managers of data--real information resource management (IRM).

But it also signals the beginning of the final incorporation of MIS into the mainstream of business. IRM is starting to take its place as a resource management "function" within the organization. (See Figure 2.)

Like other resource management functions, IRM is cross-functional. Similar to managing people or managing money, all mainline functions will be concerned about managing information. In this environment, functional budgets will contain routine entries for information resource expenditures, just as they do for head counts and salaries.

It is also a certainty that IRM will assume corporate policy-making roles covering such things as integration, and data sharing and capture policies. Reward/consequence programs will be set up (including commission and omission) for the appropriate and inappropriate use of corporate information.

Functional management needs to make decisions about the application of computer technology as they would to the purchase of a copying machine or a drill press. Improvements must be financially justified. Because computer technology has become inexpensive and relatively easy to grasp, line functions will increasingly manage the introduction of appropriate technology. MIS cannot fight the trend; they are on the way out as managers of technology. No amount of "mainframe bias" will reverse this trend.

On the other hand, it is certain that, left uncontrolled (unmanaged), the plethora of local applications of technology will lead to an increasing problem with "islands of technology." Information and data captured within these islands may well need to be shared by other functions within the company. Without an approach to manage this data across functions, the organization risks becoming functionally efficient, but organizationally ineffective. This does not spell productivity.

STAGES OF DP EVOLUTION

Richard L. Nolan (re)presented his stage theory of data processing evolution in the article, "Managing the Crisis in Data Processing" [Harvard Business Review, March/April 1979]. (See Figure 3.)

Nolan's six stages of DP evolution go from "initiation" to "maturity." It tells the story from the "inception of the computer into the organization" to the "management of data resources." The Nolan stage theory, first developed by him as a four-stage theory in 1974, has proved remarkably accurate.

According to Nolan, the transition point occurs sometime in the control stage, where the focus shifts from the management of technology to the management of data itself. "This shift in orientation is a direct result of analyses about how to put more emphasis, in expanding DP activities, on the needs of management control and planning as opposed to the needs of consolidation and coordination in the DP activities themselves," said Nolan.

Generally, larger organizations have already introduced computers (initiation). Most major organizations have evolved to some point from late in the control stage (stage 3) to somewhere in the integration stage (stage 4). Smaller organizations are typically in earlier stages of the evolution. It is doubtful that any organization, except maybe in Japan, is in stage 6.

Levi Strauss seems to be in early stage 5, and preparing for stage 6.

The organization apparently values the integration of applications, shared data and data administration. They are trying to effect stage 6 characteristics such as joint user and DP responsibility (partnerships) and data resource strategic planning.

CULTURE SHOCK BAROMETER

Nolan's stage theory is a good barometer for talking about the "culture shock" an organization will experience with Case.

If an organization has reached DP maturity, stage 6, there is no culture shock. Case is simply the "enabling technology." In such an organization, data (information) is considered an enterprise resource, like people or money. As such, everyone is naturally involved in "managing" this vital resource.

"Business systems" are the thing. Computer systems are simply a tool to facilitate the business processes of the organization. Data is recognized as the key, shared source or supply (resource) from which information can be developed from the receiver's point of view; that is, what they need, when they need it and in the form they need it.

As such, the organization strategically plans and architects this key resource. It is taken for granted that the top person in the DP organization is among the top executives of the organization.

Users routinely participate in all development projects. There is no culture shock to these organizations.

Organizations that are in stage 5 realize that integration, shared data and common systems are needed. There is data administration. Users are probably involved in the definition of key data and in reaching some consensus across functional areas about the data and the "flows." JAD sessions are probably common. Users appreciate DP problems and realize that they are key players in the equations. However, systems are still thought of as "computer systems" and data is restricted to what resides on computer databases.

In such an environment, integration means that computer systems and databases fit together.

The examination of business processes (as the system) for effectiveness and efficiency is not clearly understood. Users do not really see this as the business of DP, and do not see it as a strategic management issue. "Competitive advantage," so popular a term for the application of technology today, is restricted to "Band-Aid approaches" such as electronic communication.

In such an environment Case will be a front-end culture shock. The need for integrating strategic information plans as an integral part of business planning will not be clearly understood or appreciated. Comprehensive business requirements will be subopoptimized. Business people, particularly executives, will not get involved to a serious extent. They will regard forays into this arena as diversions from their regular jobs. The full promises of Case will not be achieved.

Case will be most useful in the dsign of databases and computer systems. While its application will encourage integration and will result in improved effectiveness and efficiencies, it will still have a technologic and bottom-up flavor. The labor intensity of designing and implementing databases and programs will be reduced. In short, Case will still have a lot of "hare" in it and not enough "tortoise."

RETROFITTING APPLICATIONS

In stage 4, integration, the emphasis is on retrofitting existing applications using DB technology. Users and their management have little appreciation for data integration issues, other than there ought not to be so many duplicate computer files. They do appreciate online access to databases. Steering committees are formeD, but they concentrate on prioritizing computer applications; that is, which is the most important "island of technology."

In this tage, Case products like the reverse-engineering processes from Bachman Inforamtion Systems, Inc., Burlington, Mass., are a terrific idea. Old non-DB or old DBMS applications can be efficiently, if not effectively, converted or reverse-engineered to the latest and greatest DBMS. By the way, Bachman's tools are extremely useful, even essential, in stage 5 and 6 environments, because firms will always face the heady issue of how to fit new development with existing applications and databases.

New projects are always constrained by what is already there. In this environment, full Case implementation is a risky endeavor for MIS management, because management does not appreciate the full implications of "data as a resource" and instead stil gives gold stars for the delivery of local systems, on time and within budget. The "hare" characteristics of Case are what will sell. But can expectations be managed?

Any organization that is in stages 1 through 3 had better think Case over very carefully. The cultural and political risks are immense. Only efficiency issues will sell. But is Case really about efficiency?

Mach is a partner of Affiliated Business Consultants, based in Racine, Wis., and Northridge, Calif. ABC provides consultation and project management in data-driven and business analysis approaches.

COPYRIGHT 1990 Wiesner Publications, Inc.
COPYRIGHT 2004 Gale Group