DIGITAL EQUIPMENT CORPORATION INTERNATIONAL: Fitting
Information Technology Architecture to Competitive Restructuring
DONALD MARCHAND
International Institute of Management Development, Switzerland
KIMBERLY A. BECHLER
Research Associate, International Institute for Management Development, Lausanne, Switzerland
In July 1991, Peter Cook, Director, European Information Systems for Digital Equipment Corporation International (Europe), was reviewing the company’s restructuring plan–designed to enable the organization to respond more capably to market demands. Cook needed to determine the extent to which IT decision-making should be centralized or decentralized; how to bridge the gap between business needs and IS deliverables: how to strike a balance between standardization (enabling sharing of information across the organization) and customization to each profit-and-loss group’s own needs: and how to build a flexible IT architecture that could both respond to today’s business requirements and accommodate radical changes in tomorrow’s business structure.
Digital International (Europe)
Digital Equipment Corporation established overseas sales and distribution in the late 1960s, which eventually led to the founding of Digital Equipment Corporation International (Europe) as a wholly- owned company in 1979. Digital International adopted a management structure similar to that of Digital US. The company’s matrix structure was built around key functional managers and geographic regions. Within the regions, country managers maintained overall responsibility for coordinating business activities. (See Figure 1, Pre-Structuring Organization Chart). Digital managed its business– along five dimensions: customer, geography, application/industry, product, and function/process. The challenge was one of overall optimization–to integrate and balance all five dimensions.
Digital Europe was comprised of two major functional parts: Sales & Service (S&S) and Logistics & Manufacturing (L&M). Sales & Service operated as subsidiary units, each managed by a country general manager and by a functional group structure based in Geneva, Switzerland, where Digital’s
European headquarters was located. S&S subsidiaries were responsible for selling, support, service, in- country distribution and logistics, and profit and loss. The Logistics & Manufacturing organization comprised the manufacturing plants and European distribution organization. L&M managed the manufacturing plants, central distribution and logistics as far as the port of entry, and operated on a standard cost basis.
Digital’s Restructuring
The driving force behind Digital’s restructuring was an increasing recognition that the firm needed to adapt more rapidly to changes in the market. The market increasingly demanded integrated solutions to problems–that is, customers wanted customization, software, and integration. Digital needed to be able to play the role of integrator.
In 1990, Digital began a restructuring plan which created three types of entrepreneurial business structures: product creation units (PCU); applications/industry business units (IBU); and account business units (ABU). The PCU was responsible for engineering, manufacturing, design, and production. The IBU provided specific services that were designed to link products with solutions which met customer needs. Both the PCU and the IBU sold its products and services to the ABUs. The ABU had various options to satisfy their customers. They could buy both IBU and PCU services, buy only products from the PCU, or they also had the freedom to go outside DEC for products and services. The ABUs would only pay for the principal costs that added value. With this new restructuring. only the ABUs operated with profit and loss responsibility. The PBUs and IBUs operated at value-added cost. In theory, the ABU paid a negotiated rate with the PBU and IBU. But, in practice, with 200 ABUs in Europe and 50-60 PBUs, it was likely that all would not negotiate different rates. According to Cook, “The system operated much like a market. Although there were price lists, those ABUs that had very big deals operated outside these lists.” (See Figure 2, Post-Restructuring Organization Chart.) Digitals “infrastructure”–i.e., finance, human resources, manufacturing, logistics, etc.–continued to operate on a centralized basis. The future impact of the restructuring plan on this part of the company was still not clear.
Cook wanted to ensure a balanced approach to addressing customer needs and the development of
products and application solutions. The sharing of applications and skill sets across customers was critcal to maintaining flexiblity.
Digital Europe’s IS Resources
Digital’s information systems (IS) were structured like the rest of the organization, with the basic separation into the field (Sales & Service) and manufacturing (Manufacturing & Logistics). (See Figure 3, P7-e-Restructuring IM&T Organizatiol Chart.) Historically, field IS had been driven strongly by the area IS organizations which developed basic functional systems. They were then implemented in the subsidiaries. Within the subsidiaries, there were user support and operations groups. Area development and maintenance were done in the subsidiaries but under area Control.
Plants, however, were mainly autonomous–each plant had the complete capability to create, implement, support, and operate its own information systems. On a scale of 0% (full autonomy) to 100% (central support), the plants historically had been 5% and the field 85%. Cook believed that neither amount was perfect. What was the ideal mix of autonomy/ccntral support for facilitating more sharing and economy-of-scale benefits in the plant IS organization? How could the subsidiaries’ “ownership” of their systems be increased? Starting in 1989, field IS was “vendorizcd” (i.e., sold at value-added cost, no profit was realized) to the service organization which, in turn, delivered the same services– consulting, advice, design, development, implementation, ù operation, support, and maintenance–to external customers. Within the plants, this “vendorization” had not occurred, as the plants were geographically fairly isolated from Digital’s customers. Electronic data interchange (EDI) was used to link the organization internally and externally.
Technically, the IS architecture was based on Digital’s successful proprietary computer operating systems and communications network, which had supported them through the 1980s. This was being extended to an open systems, multivendor base using Digital’s emerging network standard, NAS, as the framework for integration. Cook believed that the evolving role of the IS department was “to articulate the future state for users; to communicate and steer users away from the blind alleys in technology and business processes; and ~o provide support, advice, and consulting service to help users make the transition to new technologies.”
Peter Cook’s IT Strategy
To accommodate the changes in company activities and business processes generated by Digital’s restructuring, Peter Cook developed a new IT strategy. Key elements of Cook’s IT strategy included a “governance model”, de-signed to balance centralization/decentralization forces; a reconfigured IS Group to bridge the gap between business needs and IS deliverables; balancing the flexibility versus economics of scale trade-offs to minimize total company
IS costs; and scenario analysis planning, to operate better. under uncertainty.
The Governance–Market Economy Model: Balancing Centralization/Decentralization Forces
Cook described the rationale for his governance model” approach:
If we fail to decentralize the company’s IT design methods, for a company that is functionally decentralized we run into central planning, which results in conflict. However, if we have highly centralized functions with a decentralized design process, we go into a phase of scarce resources and ineffectiveness, as we always reinvent the wheel every time we design something. The ideal approach is the governance model. This model uses a combination of free market forces, which are self-interest driven, and a set of laws and rules. The laws don’t tell you what to do, but what not to do. It relies on the free market to tell you what to do.
Setting the “Laws”: The philosophy of setting the laws was “to control what was necessary to control.” Peter Cook adopted standards covering data management, transaction messaging, and the technical framework for operating systems and hardware. Data management standards were used to ensure that the data supplied by the application could be used by the corporate-wide management information systems. Transaction message standards were used to ensure that transaction traffic generated by the application could be correctly handled by the rest of the global computing system. Technical framework standards–the technical architecture of the operating systems
and hardware–were used to ensure that applications built in one location could be successfully reused in other
places without the need for major changes to the technical infrastructure, and that intercommunication was
technically possible.
“Guiding the Market”: Within the framework of standards, operational “entrepreneurial” units could choose whatever application they wanted that met their needs and conformed to standards. Applications already created by other groups were available “free of charge,” while new development projects would cost the operational units money. The advantage of this approach was that it placed the decision- making close to the business unit level, while ensuring that strategic plans and directions(in both business process and IT areas) could be managed at the corporate level by setting appropriate standards and guidelines . Cook believed the best solution was a combination of “centrally” produced packages with local selection and customization. The ideal solution was to structure applications composed of modules, each implementing a “business primitive,” which could be assembled like LEGO pieces to build systems to meet local needs. The business primitive was the smallest component of the function, representing a highly specific activity at the task level–for example, checking credit status.
The Challenge–Bridging the Gap between IT Business Needs and IT Design Via IS Organizational Re-Configuration
Within the newly configured IS group, there were three sub-functions: User Services, Systems House and an architecture, strategy, and standards group (IMT). (See Figure 4, Post-Restructuring IM&T Organization.) User Services and “System House” were the components that had been vendorized; IM&T remained centralized. The role of the “Systems House” was to develop and deliver customize(l solutions for particular entrepreneurial groups and to institutionalize the standardization process.
Digital’s objective was to have User Service Group (USG) focused on providing internal users with the systems they required to perform their functions in the company. The USG subcontracted or purchased applications expertise from the Systems Houses which were specialized in particular applications, such as customer administration, management information and decision support, data warehouses, and fiscal and accounting systems. The IM&T group was responsible for maintaining the standards and architectures within which the USGs and Systems Houses created their solutions.
The net result of this reconfiguration of the IS group was that Cook was able to reduce his resource base of operators by 30%.
Maximizing Resources: Economies of Scale (EOS) versus Local Flexibility
Cook described the trade-offs between EOS and local flexibility:
We’ve analyzed our activities to decide where we do and do not want EOS. The driver is the conflict between saving IS money and saving the overall Company money. If Digital has one huge data centre in the middle of Europe doing everything the company needs, I
can reduce the IS cost substantially. The price to the business, however, is high as it will need to adapt to my standard environment. If it is laissez-faire, I end up with a very high IS cost, but the business benefits because every system is customized to user requirements. The objective is not to minimize the IS budget as a proportion of the company’s budget, but to minimize the total cost to the organization for delivering information. It’s a compromise.
Responding to Future Uncertainty–Scenario Analysis
Cook commented, “The velocity of change is increasing.” Cook believed that the most appropriate method to create systems architecture was through scenario analysis. To get some level of consistency, Digital used the scenario of four architectures: data, technical, systems (i.e., applications modules), and business. Cook believed that the slowest to change was the systems architecture, while the business and technology architectures were changing at an ever increasing speed.
We build a systems architecture that is hopefully stable under rapidly changing environments. When we create a model, rather than testing it against business we test against possible scenarios–which may be a long way from the business needs. We attempt to identify the two or three business decisions that will have a radical impact on our systems architecture. We use these business architecture scenarios to design the modules or at least to list the modules that will be required. We pass this down as the legal structure and allow the entrepreneurial units to build whatever they need within the systems architecture using these modules–knowing full well that, once the world changes, we can re-configure the modules.
Value added from IT is based on the business manager’s ability to see business change. I want to build an architecture that will adapt to all possible scenarios. We need the architecture and systems that can respond to external forces.
Cook knew that the configuration of the new IT architecture needed to he able to support an organization that was highly decentralized in terms of its ABU Iocus and also centralized in terms of corporate-wide activities such as manufacturing, finance, human resources, etc. With the restructured company, the country management unit was no longer in place as a focal point for general management as well as IS.
Cook needed to determine where decisions about specific functions should be made–should they be decentralized or centralized? Was it optimal for the entrepreneurial units to decide on functionality, data management, transaction messaging, hardware platforms, and a technical framework for application software both its development and deployment? Or should Cook be responsible for some or all of these decisions? Which approach would enable Digital to build a better IT architecture, one that would respond to ongoing change with the most flexibility? If restructuring were to be a continually changing process, how could IS accommodate shifts in business strategies or organizational reconfigurations?
Case Study Questions
- What are the benefits of a centralized IS department, and what are the benefits of a decentralized IS?
- What is the relationship between the corporate structure and IS structure and what is the problem faced by Cook?
- What forces (drivers) caused Digital to change its organizational structure?
- Which of the changes introduced by Digital can be considered BPR?
- Are there any cultural, economic, political, or other environmental factors unique to the European location that may impact the delivery of IT?
1This case is a condensed version of the Digital Equipment Corporation International (Europe) A & B case studies. prepared by Research Associate Cathy B. Huycke with the assistance of Peter R. Cook. under the supervision of Professors Michael D. Oliff and Donald A. Marchand.
Copyright ~ 1994 by the International Institute for Management Development (IMD), Lausanne, Switzerland.
