International Case Study 2

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

1. What are the benefits of a centralized IS department, and what are the benefits of a
decentralized IS?
2. What is the relationship between the corporate structure and IS structure and what is the
problem faced by Cook?
3. What forces (drivers) caused Digital to change its organizational structure?
4. Which of the changes introduced by Digital can be considered BPR?
 5. Are there any cultural, economic, political, or other environmental factors unique to the
European location that may impact the delivery of IT?

1
This 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.