Designing Company-wide Information Systems: Risk Factors ......5'6'9'1° Often referred to as...

Designing Company-wide Information Systems: Risk Factors and Coping Strategies Albert H. Segars and Varun Grover

INCREASINGLY, PLANNERS CHARGED with organizing, controlling and adapting the firm's collection of information technologies (IT) are facing a 'productivi ty paradox'. On the one hand, top management is demanding an investment in innovative IT systems which will result in a measurable impact on market competi t ion and financial results. On the other hand, this impact is expected in a shorter time and with less investment financial resources. These expectations give planners the responsibil i ty for channelling resources into those projects which can yield the greatest organizational effectiveness. In such an environment there is little tolerance for error. Prioritization schemes and development schedules must reflect the true organizational needs for IT rather than existing information biases or political 'hand waving', other- wise the technologies are unlikely to have the consequences which are expected by top management.

The effect of this 'productivi ty paradox' is com- pounded by the proliferation of new, flexible IT systems that might leverage a competitor 's position. However, the effective utilization of IT can only be achieved through a careful evaluation of organizational needs and a matching of technological solu- tions. Reacting to the ' technology of the year' bandwagon can be myopic and expensive. Many planners are shifting their focus to the determination of organizational IT requirements rather than merely responding to the requests of managers and end-users. These efforts are ambitious and require information systems (IS) planners to understand the enterprise IS strategies, processes and information usage, and IT's role in improving its functioning. A means to this end is the development of an Information Systems Architecture (ISA). The ISA is a collection of products

which enables senior IS managers to identify the needs of the enterprise. 1'2 Unfortunately, while the development of these architectures is the most important issue facing senior IS execut ives) it is also the most difficult. 4 There have been few reports of success in the development of ISA and given the large outlays of time and money, the value of architectural planning has been questioned. 5

~ Pergamon S0024-6301(96)00024-6

Long Range Planning, Vol. 29, No. 3, pp. 381 to 392, 1996 Copyright © 1996 Elsevier Science Ltd

Printed in Great Britain. All rights reserved 0024-6301/96 $15.00÷0.00

The concept of ISA, its process and products is not well-understood. 6-s Therefore it has been difficult to explain the objectives of the process and the factors which inhibit the success of ISA, and where and why they occur. This research study addresses this problem. Our first objective was to define the process and products, and the criteria for evaluating 'architecture' in the development of IT. The second objective was to identify the 'risk factors' which inhibit the successful development of ISA and the coping strategies used by IS planners in surmounting these obstacles. These risk factors and coping strategies were revealed through interviews with 40 architectural planners in 20 large US firms. The experiences of these planners and the conceptual framework will provide useful guide lines for planners involved in the development of an ISA.

Information Systems Architecture The concept of ISA represents an important evolution in organizational planning for IT. Unlike 'bottom-up' planning approaches which emphasize the informational needs of functional areas (Finance, Market- ing, Engineering etc.), the architectural approach is ' top-down', focusing instead on the informational support needed for organizational processes which span functional structures. Conceptually, ISA structures the strategic objectives of the enterprise, models the entire business in terms of its functions, processes or tasks, and relates them to the information required for successful performance. Ideally, ISA should meet the strategic and information needs of the organization with minimal redundancy in data flow, processing and storage.

Although ISA was originally conceived as a method for prioritizing and developing all aspects of IT (i.e. storage, communicat ions and processing), most prac- tical and theoretical attention has been concentrated on the development of organization-wide data storage schemes. 5'6'9'1° Often referred to as 'strategic data planning' or ' information engineering', the end result of these planning efforts is a set of integrated databases which are independent of organizational structure and technologies. In fact, these are the only 'architectures' that have well-developed pictorial representations which illustrate components of data and their interrelationships. Unfortunately, the actual development and implementat ion of these data-based architectures has proved to be difficult in practice. Organization-wide modelling of data classes is often perceived as time-consuming, nebulous and expensive by top-level executives who opt not to pursue this r o u t e 4'5'9 and describe their architectures in terms of simple documentat ion of organization wide hardware and applications. Additionally, dynamic organizational processes such as interorganizational link-

ages, electronic messaging systems (E-mail, EIS), and informal modes of information transmission (memos, meetings etc.) are often beyond the scope of any of these planning efforts and, in many instances, rep- resent more critical and 'higher payoff' applications. Such results have prompted many observers to call for richer conceptualizations of ISA and for the exten- sion of architectural modelling from data to emerging strategic resources such as communications. 7,s As suggested by Zachman: 7

We are having difficulties communicating with one another about ISA because a set of architectural representations exists, instead of a single architecture. One is not right and another wrong. The architectures are different. They are additive and complimentary. There are reasons for electing to expend the resources for developing each architectural representation. And there are risks associated with not developing any one of the architectural representations.

Thus, it seems necessary to flame ISA in a manner which more fully describes the process of formulating ISAs and which includes all functional aspects of IT. Further, it is critical to conceptualize higher-level planning processes which are designed to align the efforts of IS managers with those of top management. Merging these processes with the well-known exercises of generating information (data) architectures provides a more holistic view of ISA development. Within such a framework, dialogue among prac- titioners and researchers concerning ISA can be structured and potential problem areas are more readily identifiable.

ISA: A Conceptual Framework Reconciling literature in the area of general IS strategic planning 4'11-14 strategic data planning 5'6'9'1°'15 and I S A , 1'2'7's'13'16 fl holistic view of organizational ISA development in terms of its levels, processes and products is illustrated in Figure 1.

As shown in Figure 1, ISA development starts with a broad conceptual level analysis of the business and proceeds to more specific levels of logical systems analysis and physical systems implementation. At each level a different planning process is employed which results in very different 'architectural products'. Between levels the respective architectural products are ' transformed' with regard to specificity, i.e. the architectural products of higher levels are used as input into the lower level processes until the physical system emerges. The entire process includes all aspects of IT and subdivides the overall ISA into sub- architectures of Data, Communications, Technology and Applications. In the sections that follow each of these levels and their respective components are more fully described.

Enterprise Analysis At the conceptual level of ISA development, the relevant perspective is strategic (i.e. that of top

Designing Company-wide Information Systems: Risk Factors and Coping Strategies

management). An important objective of this high level of analysis is to understand, articulate and rep- resent the strategic direction of the enterprise and to transform this vision into a set of concrete strategies for IS development. Further, it is important to gain an understanding of how the enterprise is organized in terms of structure, processes and policies. In essence, 'enterprise analysis' seeks to uncover how the business operates, where the business is going and when it should get there. The result from this analysis is a set of 'enterprise models ' which capture the strategic and tactical information about the chosen businesses, the competitive approach, the organizational structure and related effectiveness criteria. This set of models becomes the lens through which IS planners view and influence organizational strategy. Such models should build consensus regarding the requirements of the business system, render explicit strategic alignment between the strategy and objectives of IS and those of the enterprise, establish the roles and responsibilities of each business and functional unit with respect to systems development and support the formal reengineering of organizational processes. 1°

Logical Systems Design Logical systems design takes a more mid-management (tactical) perspective of systems planning. In effect, this level of architecture development is concerned with matching information requirements with the functions, processes and tasks identified in the broader enterprise model. In doing so, opportunities for enabling strategy or for more effectively restructuring organizational processes with IT are identified. A major planning product of this level of analysis is the Information Architecture. As formally defined by Brancheau and Wetherbe: 1

An Information Architecture is a high-level map of the information requirements of the organization. It is a personnel, organization, and technology independent profile of the major information categories used in the enterprise. The profile shows how the information categories relate to business processes and how the information categories must be interconnected to facilitate support for decision makers.

Once developed, the Information Architecture provides a blueprint for developing more specific conceptualizations of data usage, data flow, applications usage and processing needs across the processes of

Long Range Planning Vol. 29 June 1996

Communications Architecture: the Movement of Information

Applications Architecture: the Distribution of Software

Technology Architecture: the Distribution of Hardware

Data Architecture: the Distribution of Information

the enterprise. As shown in Figure 1, these four sub- architectures are less encompassing than the Infor- mation Architecture and provide greater detail concerning the use of information and information technologies within the enterprise. Figure 2 charac- terizes the nature of these sub-architectures along dimensions of structure and integration. As shown, each architecture captures the integration of information, information flows, applications and technologies across structural (process) components of the enterprise. Both interfunctional and intrafunc- tional processes are concerned with internal methods of accomplishing work while interorganizational processes are those which span firm boundaries.

The Communications Architecture provides a con- ceptualization of how information is transferred or flows throughout the enterprise. 2'13 These communicat ion links inter-connect organizations, people and machines and provide a degree of coordination among the firm's processes. Through identification of these patterns in information flow, managerial planners can assess the capacity/richness of existing chan- nels and more accurately match appropriate te lecommunicat ions technologies with the requirements of individual or groups of information flows. 17 In more ambitious planning efforts, 'network analysis' techniques can be used to model organizational communicat ion processes at varying levels of abstrac-

tion facilitating the restructuring of communicat ion links and/or the reengineering of business processes through telecommunications technologies. 13

The Applications Architecture documents both existing and required applications necessary to support the processes of the enterprise. The proliferation of commercial packages, cl ient-server computing and fourth-generation languages has steadily increased the importance of this particular planning model. Specifically, the need to share information across functional areas has caused several firms to implement stringent guidelines in the purchase and development of software. Additionally, redundancies in project development between functional areas rep- resent a source of extraneous expense which can be reduced through developmental policies and pur- chasing procedures formulated through this planning model.

The Technology Architecture illustrates how processing technologies are distributed in support of organizational processes. Such planning models have been important in the efforts of many organizations to reengineer or 'rightsize' their base of computing assets. As noted by Allen and Boynton, 11 organizations can now choose from a cont inuum of highly centralized to highly distributed processing architectures. Each point along the cont inuum has it advantages and disadvantages; and, given the


diverseness of organizations, there is no solution which is ideal for everyone.

The Data Architecture is a blueprint of data created and used by the various processes of the enterprise. Such models are used to identify potential subject area databases (SADBs). Ideally, these databases should contain uniform data descriptions and little or no redundancy in terms of data creation and storage. In addition, SADBs should be posi t ioned closest to those processes which create and use its resident data, thus ensuring accurate and timely informational representation. 18 Global data models and entity description catalogues are some of the many tools used to engineer these logical data structures. ~° As noted earlier, this aspect of architectural development is perhaps the most wel l-understood in terms of methodology and supporting software tools. 6

In sum, the logical level of architectural development takes the broad Information Architecture and factors it into more specific architectures of data, communications, technology and applications. Such blueprints facilitate the detailed design of particular systems and the setting of priorities for implementation. 15 Although less developed in the literature than the Information Architecture, these sub-architectures are nonetheless just as critical to successful systems implementation. 8 Their more detailed nature along with specific technological focus greatly facilitate managerial understanding of critical IT needs and the specific contribution of IT to organizational processes.

The Physical Level: Systems Implementation The physical level of the architectural process is concerned with the actual implementat ion and development of databases, networks, system typologies and applications derived from the sub-architectures formulated at the logical level. In practice, this phase occurs many t imes- -once for each system defined and adopted in the sub-architectures. 15 While similar to a traditional systems life cycle, in that a feasibility s tudy is undertaken for each application, a critical difference is that system implementat ion starts with a notion of the overall ISA--guiding the implementation and its integration with other systems. These plans are very detailed compared with those of the higher levels and take on the perspective of oper- ations or project management. At a minimum the implementat ion plan should include components of project scope (cost, t ime frame), development strategy, and organizational impact. 15

The Benefits to the Organization Given the development of an overall view of ISA, it is now important to identify the criteria against which the planning process can be evaluated. There is con- siderable academic and practitioner literature which outlines both goals and benefits of such approaches.

Synthesizing this vast array of literature, five general categories of potential goals/outcomes of ISA can be derived. 5 Each of these outcomes is briefly sum- marized:

1. Implementation of integrated systems. Resulting architectures should lead to the identification and development of information resources integrated across the targeted domain of the planning effort. Thus, documentat ion of interrelationships and interdependencies in terms of data, communications, technologies and applications must be incorporated within architectural representations.

2. Documentation. Resulting architectural representations should provide sufficient documentat ion to identify clear areas of progress in terms of informational resources. As noted by many observers, maintaining valid representations of IS architectures remains a problem within organizations. 1 Like road maps, architectures must be formulated so that they can be updated or used for 'what if' analysis. Archi- tectures should be formulated as 'snapshots of the way we are' and 'portraits of the way we would like to be'.

3. Prioritization of systems. Perhaps the most frequently ment ioned benefit of architectural representations, prioritization of systems facilitates the allocation of scarce IS resources to those projects which are most critical to supporting organizational needs. Hence, architectural representations, when properly developed, should be free from existing usage and political biases which are inherent in 'bottom-up' approaches to project selection.

4. Business reengineering. Business reengineering is a rather new concept in the area of systems design. In effect, reengineering is a process of rethinking the s t a t u s q u o . 19'20 System designers should refrain from merely automating current organizational processes and instead creatively redesign them with IT. Given that architecture development involves modelling the enterprise in terms of processes and informational resources, there is a potential opportuni ty creatively to rethink current organizational processes.

5. Education and communication. Archi- tectural representations can foster improved dialogue between IS and top planners. In essence, understanding the critical role played by information resources and identifying of potential competitive uses can facilitate the transfer of managerial support as well as financial resources to development efforts. Thus, the link be tween organizational and IS strategies is made stronger.

Although there may be other benefits associated


with successful ISA development, the this represents the areas most impacted by the process. It is often these broad criteria upon which management assesses the marginal return on organizational resources invested in planning. Unfortunately, the actual development of ISA and realization of its associated benefits has eluded many organizations. Although many studies have attempted to identify the nature of these difficulties, 4'~ they have typically been entered into without a frame of reference regarding ISA and, as a result, have focused on a particular level of analysis (i.e. conceptual, logical, physical) or a specific methodology such as Business Systems Planning 4'21 or information Engineering. 5 Working within the larger framework developed here, it is possible to analyse difficulties which may inhibit planning at each level as well as the cascading effects which difficulties at higher levels may have on the successful execution of architectural processes at lower levels. We term these planning difficulties 'risk factors'.

As illustrated in Figure 3, risk factors alter the nature of the planning process from its intended state. This 'process gap' results in a realized planning process which contains some intended elements as well

as some which emerge as a consequence of the risk factor(s). This realized planning process may further lead to intended and emergent planning outcomes. In other words, actual planning outcomes may exhibit some, all or none of the benefits outlined previously. This difference is termed 'outcome gap' and is a direct by-product of the 'process gap'. Within the process of architectural planning, it is the responsibility of those involved to narrow the process gaps so that the realized processes and outcomes are those intended. We term these collections of actions 'coping strategies'. In order to identify both prominent risk factors and associated coping strategies, in-depth interviews were conducted with IS planners in 20 US organizations which had been or were actively involved in architectural planning. These planners were briefed on the ISA framework and then asked about factors which inhibit the realization of planning success and strategies used to overcome these planning obstacles.

Risk Factors and Coping Strategies Although a mult i tude of risk factors and coping strategies was identified by architectural planners, it was


Risk factor Process gap Outcome gap Coping strategies

Lack of concrete or understandable strategic plan

No ongoing assessment of strategy

Lack of interest by top management in IS planning

Lack of skills or methodologies for constructing enterprise models

Enterprise models based on unstructured view of strategy and business

Enterprise models do not reflect changes in strategic direction

Enterprise models based on IS manager's view of strategy and business

Enterprise models do not contain useful or accurate information

Invalid prioritization schedules Lost opportunities for reengineering Less alignment between IS and top managers

Invalid prioritization schedules Inaccurate documentation

Less alignment between IS and top managers

Invalid prioritization schedules Lost opportunities for reengineering Less alignment between IS and top managers

Invalid prioritization schedules Lost opportunities for reengineering Inaccurate documentationLess alignment between IS and top managers

Heighten status of top IS executive Documentation of corporate and IS strategy Consultants, planning exercises

Heighten status of top IS executive Continuous planning processes

Marketing of IS capabilities to upper-management Business versus technical dialog with upper- management

Training Development of 'in-house' methods Appropriate methods from business partners

appa ren t that m a n y of these p lann ing character is t ics cou ld be r econc i l ed into b roade r factors w h i c h were cons i s t en t in each of the 20 firms visi ted. Fur ther , it s e em ed that some of these factors fell w i th in each level of the concep tua l ISA mode l (conceptual , logical, phys ica l ) whi le others were more encompass° ing- -a f fec t ing the ent i re ISA d e v e l o p m e n t effort ra ther than any par t i cu la r level of analysis .

The Conceptual Level As s h o w n in Table 1, four factors were t roub le some in the d e v e l o p m e n t of en te rpr i se models . The first of these was a pe r c e ived lack of strategic di rect ion. M any IS p lanners no ted that the strategic d i rec t ion of the organiza t ion was not c o m m u n i c a t e d in a m a n n e r w h i c h was unde r s t andab le . In some ins tances strategic d i rec t ion was c o m m u n i c a t e d in t e rmino logy or d o c u m e n t a t i o n w h i c h was diff icult to in terpret . In o ther cases the firm s imply had no strategic plan. A c o m m o n the me among firms w h i c h had expe r i en ced this diff icul ty was a lack of c o m m i t m e n t by top management to adop t a par t i cu la r strategy. As no ted by one manager ia l p lanner :

Top management formulates strategy in broad brush strokes-- a desire to enter new markets--a desire to grow our existing markets--and desired financial objectives. What we do not seem

to have are details and commitment on their part. In other words, how and when do we get there? We are waiting for them to make up their minds.

Lacking a sense of strategic di rect ion, m a n y IS planners none the le s s a t t empt to bu i ld en te rpr i se mode l s based on u n s t ru c tu r ed and often i n co m p le t e strategic plans. In such ins tances , no ted ou tcomes include: less a l ignment b e tw een the strategies of top m a n a g e m e n t and IS; lost oppor tun i t i e s to res t ruc tu re bus iness processes; i l l -conce ived pr ior i t i za t ion of sys tems projects. Some firms even found themse lves unable to r e sp o n d t echno log ica l ly to changes in the com- pet i t ive env i ronmen t . A c o m m o n coping strategy of firms w h i c h had e x p e r i e n c e d this risk factor was to he igh ten the status of the top IS execut ive . The cre- a t ion of a CIO role or v ice -p res iden t pos i t ion a l lowed IS bet ter to read the 's trategic tea leaves ' of u p p e r management . In o ther ins tances , changes in the docu- men ta t i on of strategies and act ion plans p ro v ided add i t iona l means to align the act ions of IS. Ano the r p o p u l a r coping strategy was the adop t ion of formal p lann ing exercises and the use of manager ia l planning consul tants .

A n o th e r p r o m i n e n t l y m e n t i o n e d risk factor at the concep tua l level was the lack of ongoing strategic assessment . As no ted by m a n y mangers , en te rpr i se


modell ing is often a 'one shot' planning procedure. As lamented by the architectural planner of a large US financial concern:

We did a thorough job of aligning ourselves with organizational strategy. We felt confident in our analysis and proceeded to operate within the enterprise models developed. However, we did not do a good enough job of ensuring that these models were maintained. It only took a period of months before critical aspects of strategy and the business had changed.

Noted effects of this risk factor on planning outcomes include invalid priori t ization schedules, mis-aligned IS strategies and inaccurate documentat ion. Again, a part icularly effective coping strategy was the elev- ation of the top IS executive to a role on par with that of top planners. In essence, this allowed IS to be informed of, and even to suggest, changes in strategic direction. Addit ionally, many IS departments changed the nature of enterprise analysis from a yearly or semi-annual affair to a cont inuous process.

In some organizations attempts to formulate enterprise models were frustrated by a lack of interest in IS planning by top management. In many cases enterprise modell ing was still under taken but often resulted in models which represented the IS planner 's view of business and strategy rather than that of top management. In these firms IS strategies and opera- ting procedures were typical ly structured to respond to the greatest crisis, shorten development and implementat ion time and serve the interests of the most powerful departments. In essence, such an approach was designed to keep the machine running without regard to the long-term consequences of 'patchwork ' systems. Hence, IS strategies were often mis-aligned with that of top management, implementation priorities were biased in favour of power versus business need and potential opportunit ies for reengineering were lost. A common coping strategy for this risk factor was the 'selling' or aggressive marketing of IS to top management. Relatedly, such marketing was accomplished through a business rather than technical dialogue. As noted by the CIO of a large US retailer:

Much of my job is selling IS to top management. However, to sell IS effectively I have had to teach myself to talk about it in business terms rather than bits, bytes and bandwidth. The business, not technology, is the common ground for aligning our interests with theirs. Management is only interested in what can be done for the sake of the business not what can be done for the sake of technology.

A final risk factor of the conceptual level of analysis is a lack of skills and methodologies for constructing enterprise models. Many organizations wanted to formally conduct such analyses but were unsure how to proceed. Such uncertainty in the process created a severe lack of confidence in resulting models, and most of the benefits of ISA went unrealized. Coping strategies for this risk factor were more varied than those for the other risk factors and were not as clearly

successful. One exception, however, was to appropriate methods of enterprise modell ing from business partners. In many of the firms visited, methods were adopted from other firms such as suppliers, customers and in one case a competitor. Other strategies which had more limited success included training through seminars and/or conferences and formal development of ' in-house' methodologies.

The Logical Level Of the three levels of ISA development , the logical was consistently ment ioned as the most problematic by the planners interviewed. Logical systems design was described as tedious, time consuming and gen- erally difficult to accomplish. However, for those firms which were able to c i rcumvent the risk factors associated with this level of analysis, returns more than justified the financial and human capital expended. As shown in Table 2, four broad risk factors and associated coping strategies seemed evident across the firms visited.

In many firms the logical level of analysis was the starting point in ISA development. In other words, enterprise modell ing was ignored. Other firms under- took some form of enterprise modell ing but did not incorporate the results of the analysis into the logical phase of ISA development. In both instances a common complaint of upper management was that developed systems failed to reflect a 'strategic context ' . Interestingly, in the firms which ignored or discounted enterprise modelling, the goal was strictly database development. Along with a lack of strategic alignment, these firms exper ienced less-than- satisfactory results in identifying reengineering opportunities, prioritizing systems and integrating systems 'strategically' to support future competit ive initiatives. A common coping strategy in firms which had experienced this difficulty was continuous reconciliation of enterprise and logical models. As explained by the CIO of a large US textile manu- facturer:

We never declare a particular planning process closed. We have found that constant reconciliation of our logical designs with the strategic vision of upper management is necessary in order for our systems to have the desired impact. We're always planning and we're always evaluating the consistency of our planning processes.

A number of firms actively involved topmanagement in logical design as a means of ensuring 'strategic validity' . In essence, IS planners sought the approval of top management regarding the message (i.e. implementat ion priorities, reengineering opportunities, integration) implied within the architectural representations. Such approval throughout the process was cited as useful in guiding the design effort as well as 'setting the stage' for subsequent implementation.

A particularly poignant risk factor identified by



Enterprise model does not guide logical ISA development

Scope of requirements identified for data and processes

Planning focused on supporting status quo versus redesigning processes and methods of work

Lack of skills or methodologies for constructing logical models

Logical models do not reflect a strategic or business context

Logical models 'too detailed'. Contain information difficult to interpret

Logical models reflect biases of existing information use

Logical models do not contain useful or accurate information

Invalid prioritization schedules Less 'strategic integration' of systems Lost opportunities for reengineering Less alignment between IS and top managers

Poor documentation Less 'strategic integration' of systems Invalid prioritization schedules Less alignment between IS and top managers

Lost opportunities for reengineering Less 'strategic integration' of systems Less alignment between IS and top managers

Less 'strategic integration' of systems Invalid prioritization schedules Lost opportunities for reengineering Inaccurate documentation Less alignment between IS and top managers

Continuous reconciliation of enterprise and logical models Involvement of top management in logical planning efforts

Focused approach to logical design Involvement of top management in logical planning efforts Training, cross-fertilization of IS personnel Create atmosphere conducive to change

Involvement of top management in planning efforts Secure cross-functional cooperation and involvement in planning Create atmosphere conducive to change

Training Development of 'in-house' methods Appropriate skills/methods from business partners Focused approach to logical design

planners at this level was the enormous amount of data classes, business processes and information requirements uncovered through architectural modelling. In short, planners seemed overwhelmed by the scope and complexi ty of information created and used throughout the enterprise. In some instances this risk factor completely broke down the ISA development process while in others resulting architectural representat ions were too detailed and of little use in developing schemes for systems integration and prioritization. A consistent coping strategy for firms experiencing such problems was the development of a ' focused' approach towards logical analysis. Here, identification and targeting of key business impact areas provided an attractive alternative to a larger-scale architectural representation. In many instances, top management was relied upon to aid IS planners in identifying development 'hot spots'.

Other organizations simply concentrated their efforts on particular business units or functional

areas. In essence, it was imperative that the task should not exceed the availability of skills, t ime and monetary resources in order to realize success. Ano- ther interesting strategy was the cross-training of IS personnel. In some organizations each major functional area contained at least one member of the IS organization. It was the responsibil i ty of such employees to unders tand the information usage and methods of doing business within their respective departments. Such 'cross-fertilization' was cited as useful in aggregating information requirements into coherent architectural representations

Another inhibitor of planning success at the logical level was a tendency by some firms to support the status quo rather than attempt to redesign processes and methods of work with IT. As noted by one CIO:

We had fallen into a habit of modelling the organizations as it was, not the way it should be. As a result, we were pouring millions of dollars into technology which reinforced outdated methods and ways of doing business. We simply were not getting


the gains in productivity and performance one would expect from such expenditures.

Such problems have been documented in a number of popular books and articles on business reengineering. 19'2°'22 In essence, these planners were formulating accurate depictions of existing information requirements but were missing opportunities to reengineer or position the firm's technological base to be more responsive to changes in the competitive environment. Here again, a popular coping strategy was the involvement of top management. However, somewhat different from other modes of involvement, the role of top managers in these instances was to facilitate cooperation of functional areas and help create an environment conducive to radical change. IS planners also noted that campaigns to market IT- based changes in organizational processes must pre- cede logical analysis in order for real benefits to accrue. Such campaigns were cited as improving the quantity and quality of involvement by functional managers and end users in logical architectural development.

A final risk factor mentioned prominently by architectural planners was a lack of skills and methodologies for developing architectural models at the logical level. Similar to concerns voiced at the conceptual level, planners did not feel confident in their approach to logical design and therefore were not certain that architectural models contained the right information to guide development efforts. Lacking such expertise, the ISA efforts of these firms yielded little or no benefits. A typical coping strategy adopted in these situations was a very narrowly focused approach towards logical design. In essence, logical architecture development would start as a very limited exercise on an isolated business unit or functional area. Typically, such efforts would focus on database development because of the wider availability of documented approaches. The experiences (successes, failures etc.) of this limited design effort were then incorporated into 'in-house' approaches for developing broader architectures of technology, applications and communications. Other coping strategies included training/seminars and the appro- priation of design methods from business partners.

The Physical Level Table 3 outlines three broad risk factors associated with the physical level of ISA development. In general, each of these factors inhibits the execution of prioritization and integration schemes called for in logical architectural plans. Two interrelated and prominently mentioned factors are 'political game- playing' by powerful coalitions of managers/end- users and a tendency to avoid replacing existing systems. Such coalitions and resistance to change were frequently successful in frustrating the efforts

of systems developers to integrate disperse systems, reengineer business processes with IT and follow prioritization schedules. In many cases, these coalitions saw the initiatives suggested by ISA as an invasion of organizational turf. In others, discontent over the importance or prioritization of 'pet projects' were the source of political games. In still others, managers viewed the revamping of existing systems, particularly integration, as a potential loss of informational power. To cope with this risk factor many IS planners resorted to use of 'political capital'. Such capital was secured through top management endorsement of the ISA effort and top management involvement at each level. Another successful coping strategy centred around involvement of various functional managers in the formulation of logical models. These managers were informed of the ISA effort and, when possible, made part of the development team. Questions, comments and devils advocacy were encouraged and favourably received by these managers. A final coping strategy was the marketing of the ISA implementation effort by IS planners.

As noted by one architectural planner:

Involvement of various functional managers is definitely important. However, we have also found it necessary to fully inform and, in a sense, market our implementation plans to those areas most affected. We have a simple policy regarding implementation-no surprises.

Thus, it seems important to enter the implementation phase with the full backing of top management and with full disclosure to those areas most impacted by system changes. While such strategies seem sim- plistic and a matter of common sense, they require modes of thinking and approaches to management which were foreign to many of the technically-trained IS managers interviewed. To realize success, many of these managers had to re-tool their approach and find a common dialogue with managers from various functional areas.

A final risk factor in the implementation phase concerned a semantic gap between logical and implementation plans. In other words, planners found it difficult to transform the logical plan into a set of timetables, resources requirements and guidelines for implementation responsibility. Some planners noted that the scope and level of the logical design phase contributed to this problem. For example:

Organizational (architectural) modelling is broad and encompassing in nature while implementation plans are detailed--dealing with actual time, money and personnel. We have found that architectures point out problems but provide little insight into action plans to resolve them. Sometimes the architectures make it (implementation) look easier than it actu- ally is.--IS Manager in Charge of Strategic Planning, Large US Transportation Concern.

This seemed to be less of a problem in efforts where the scope of the ISA project was narrowed. Addition- ally, in organizations which constantly reconciled



'Political game-playing' in execution of implementation plans

Tendency to avoid replacing 'tried and true' systems

Semantic gap between logical and implementation plans

Systems implemented without regard to logical models

Systems implemented without regard to logical models

Unclear guidelines or responsibilities for system implementation

Less 'strategic integration' of systems Invalid prioritization schedules Lost opportunities for reengineering Less alignment between IS and top managers

Less 'strategic integration' of systems Invalid prioritization schedules Lost opportunities for reengineering Less alignment between IS and top managers

Less 'strategic integration' of systems Invalid prioritization schedules Less alignment between IS and top managers

Big Brother tactics--use of political capital Cross-functional involvement in formulation and revision of logical models Marketing IS plan to powerful coalitions

Big Brother tactics--use of political capital Cross-functional involvement in formulation and revision of logical models Marketing IS plan to powerful coalitions

Continuous reconciliation of logical and Implementation plans Focused planning approach

logical and implementat ion plans, guidelines were more easily developed and actual planning outcomes mirrored those intended. Not surprisingly, many of these firms had previously attempted ISA development on larger scales and failed. In essence, these coping strategies al lowed instances, third attempts.

Other Risk Factors In addition to the risk factors previously identified, two unique planning difficulties were identified by the planners interviewed. Unlike risk factors germane to a particular level, these obstacles were more encompassing in nature. Specifically they made it difficult to undertake an architectural approach to IT planning. The first of these factors is the time, personnel and financial resources required to conduct the analysis effectively. Although there may be a clear need for an ISA approach to planning, many organizations are unwill ing or unable to supply adequate resources. It is not easy to justify the cost of planning. However, according to those involved in the processes, it is a critical part of ensuring ISA success. Secondly, the ISA approach may not deliver a finished product as quickly as more conventional planning approaches. Unfortunately, in many organizations, development time is a key criterion upon which IS managers are evaluated. Unless the IS manager can narrow the project quickly, ISA

approaches may work against the very criteria upon which he/she is evaluated. As noted by several of the interviewees, unless organizational incentive systems support the ' top-down' nature of ISA, such approaches will be hap-hazard and largely inef- fective.

Conclusions As IT becomes a more integral component of organizational functioning and competit ive positioning, approaches to IT planning which take an organizational perspective will become increasingly important. Integrating diverse systems across the organization, reengineering business processes with IT, and accurately identifying opportunit ies to enhance competit ive position through IT-based strategy are not competit ive luxuries, increasingly, they are competit ive necessities. ISA provides a structured process for realizing these desired outcomes. However, ISA should be entered into with a clear understanding of the process, products and potential pitfalls. As the experiences of these planners dem- onstrate, there is more to ISA than building conceptual models. The entire process must be managed in such a way that incentive systems, resources, top management support and the support of various functional managers compliment the efforts of architectural developers.


References 1. J. C. Brancheau and J. C. Wetherbe, Information architectures: methods and practice,

Information Processing and Management 22, 453-463 (1986).

2. C. E. Wardel, The evolution of information systems architecture, Proceedings of the Fifth International Conference on Information Systems, Tucson, AZ, pp. 205-217 (1984).

3. F. Niederman, J. C. Brancheau and J. C. Wetherbe, Information systems management issues for the 1990s, MIS Quarterly 15, 475-502 (1991).

4. A. L. Lederer and V. Sethi, Meeting the challenges of information systems planning, Long Range Planning 25, 69-80 (1992).

5. D. L. Goodhue, L. J. Kirsch, J. A. Quillard and M. D. Wybo, Strategic data planning: lessons from the field, MIS Quarterly 16, 11-34 (1992).

6. R. D. Hackathorn and J. Karimi, A framework for comparing information engineering methods, MIS Quarterly 12, 203-220 (1988).

7. J. A. Zachman, Business system planning and business information control study: a comparison, IBM Systems Journal 21, 31-51 (1982).

8. J. A. Zachman, A framework for information systems architecture, IBM Systems Journal 26, 276-292 (1987).

9. D. L. Goodhue, J. A. Quillard and J. F. Rockart, Managing the data resource: a contingency approach, MIS Quarterly 12, 373-392 (1988).

10. J. Martin, Strategic Data-planning Methodologies, Prentice Hall, Englewood Cliffs, NJ (1982).

11. B. R. Allen and A. C. Boynton, Information architecture: in search of efficient flexibility, MIS Quarterly 15, 435-445 ( 1991 ).

12. B. Bowman, G. B. Davis and J. C. Wetherbe, Three stage model for MIS planning, Information and Management 6, 11-25 (1983).

13. A. H. Segars and V. Grover, Communications architecture: towards a more robust understanding of information f lows and emergent patterns of communication in organizations, European Journal of Information Systems 2, 1-14 (1993).

14. C. H. Sullivan, Systems planning in the information age, Sloan Management Review26, 3-12 (1985).

15. J. Karimi, Strategic planning for information systems: requirements and information engineering methods, Journal of Management Information Systems 4, 5-24 (1988).

16. J. J. Johnson, Enterprise analysis, Datamation, 15 December, 97-103 (1984).

17. C. H. Sullivan, Planning for information networks, Sloan Management Review 28, 39-44 (1987).

18. G. B. Davis, Strategies for information requirements determination, IBM Systems Journal 21, 4-30 (1982).

19. T. H. Davenport and J. E. Short, The new industrial engineering: information technology and business process redesign, Sloan Management Review26, 11-25 (1990),

20. M. Hammer, Reengineering work: don't automate, obliterate, Harvard Business Review 68, 104-112 (1990).

21. IBM, Business Systems Planning, IBM Manual No. GE20-0527-3 White Plains, New York (1981).

22. G.W. Keen, Shaping the Future: Business Design Through Information Technology, Harvard Business School Press, Boston, MA (1991).


Designing Company-wide Information Systems: Risk Factors ......5'6'9'1° Often referred to as...

Documents

Transcript of Designing Company-wide Information Systems: Risk Factors ......5'6'9'1° Often referred to as...