The document outlines an information technology strategy for ABC International aimed at deploying next-generation business and manufacturing software systems. It emphasizes the importance of separating data from processes, aligning IT with business plans, and developing a flexible architecture to support ongoing technological evolution and rapid business changes. Additionally, it discusses the necessity of an integrated approach to improve operational effectiveness and achieve a competitive advantage.

1. IT Strategy Page 1
• IT STRATEGY SUMMARY
Never before has Information Technology (IT) played a more important role in bringing competitive
advantage to an organization.
[1]
Yet IT has never before been more complex. In the past, the mainframe
paradigm provided turnkey solutions to complex business problems. The functionality was provided by
the software vendor, which may have also been the hardware vendor. The business processes were
adapted to this functionality. As these processes evolved it was discovered that the systems were not
sufficiently flexible or adaptable to meet the new demands of business. The introduction of distributed
processing provided a means to deal with the inflexibility and monolithic nature of these legacy
applications.
The consequences of this new, flexible, adaptable technology is that the turnkey nature of the software is
no longer valid. The deployment of the distributed processing paradigm now requires careful analysis,
planning and execution. These behaviors were required for the previous generation software systems, but
now disparate systems, applications and databases need to talk to each other – and many times, they
don’t. An architecture is needed to assemble these components into a functioning system that provides
improved productivity across the enterprise, while maintaining the desirable attributes of the mainframe
environment. (reliability, availability, performance).
The goal of any enterprise technical architecture must be to enable rapid change in business processes
and the applications that support them. Companies that adapt these architectures gain a significant
competitive advantage, since IT can be easily aligned with the business and more importantly, quickly
realigned when business requirements change.
[2]
The IT Strategy presented in this document describes the steps to be taken by ABC International in the
deployment of the NEXT GENERATION OF BUSINESS AND MANUFACTURING SOFTWARE SYSTEMS. The path to
be taken has many options, risks and rewards. The IT Strategy described here lays the groundwork for
this journey. Many more steps are required before the final system can be realized.
The IT Strategy contains the high level strategies associated with managing the business of deploying
computer systems as well as many levels of technical detail. Reading the IT Strategy in its entirety will be
a challenge for many. This is not to suggest that the skills and intellect are not present in all of the
readers. Rather that the content of the IT Strategy is rich and complex.
This section presents the must know concepts for the DEF Group Data Management Project. The
understanding of these points is vital to the understanding of the strategy. They are:
ü Data is the Life Blood of ABC – it is the data that represents the intellectual property of the
manufacturing process. Data is transformed into information. Information is used to run the business
ü Data and process must be separated – in the current systems, the data is trapped within the
application software.
ü This data must be owned and managed as a capital asset – information about products,
manufacturing processes, suppliers, and customers is as important to ABC as the physical plants and
the people who work in them.
ü The architecture of the next generation system must support the continuous migration of its functional
components – by separating the data from the processes, the software and hardware components
can be migrated as the technology improves.
1
OpenBlue Executive Summary, IBM’s vision of the future. www.software.ibm.com/openblue. This
reference is not an endorsement of IBM’s strategy. This approach however, is shared by numerous other
systems vendors, academic researchers, government and industry CIO’s. This vision is restated in the
early sections of the IT Strategy. Stating the vision is important, developing the detailed plans for
implementing the vision is mandatory, but executing the detailed plans that support the vision is the
crucial step not described in any of the marketing brochures. The IT Strategy presented here lays the
groundwork for this vital step.
2
Larry DeBoever, Senior Vice President of Enterprise Architecture Strategies, META Group, Inc.

2. IT Strategy Page 2
EXECUTIVE OVERVIEW
This document presents the Information Technology Strategy for the DEF Group Data Management
Project. This IT Strategy provides a guide to the Manufacturing Resource Team (MRT) on the strategic
activities to be taken during the course of the Data Management project.
These include:
ü Aligning the IT Strategy with the DEF Group Business Plans. §
ü Defining the target business units which make use of the various system components. §
ü Defining the applications suites that can be deployed against these target business units. §
ü Defining the architectural alternatives for the DEF Group environment. §AA
ü Defining the processes used to map the business requirements against the system architecture. §BB
ü Defining the detailed strategies for managing the DEF Group data. §CC
ü Defining the strategies for procuring Commercial Off The Shelf software systems. §DD
ü Defining the technical infrastructure needed to deploy the Data Management system. §EE
ü Defining the organizational changes needed to support the Data Management system. §FF
The IT Strategy contains three (3) major themes. These themes form the foundation of the IT Strategy as
well as the tactical processes that will be deployed in support of these strategies.
These themes are:
ü Business improvements are enabled by Information Technology that is integrated not disintegrated.
This integration must be horizontal versus vertical. Horizontal systems remove islands of information
and build bridges between the business units. In this integrated system, multiple data sources are
made transparent to the end users as well as the applications that utilize them.
ü Information Technology requirements are always growing, changing, and being extended. The
Information Technology is no longer static, but dynamic adapting to the changing business
requirements.
ü Information Technology is about abstractions. If only hardware, software, and data were the only
foundations of a system, then Information Technology would not be able to keep pace with the
business requirements. Instead, business processes, objects, and services are the foundation of the
system, which then drive the business processes in their adaptation of the changing market forces.

3. IT Strategy Page 3
• WHAT IS STRATEGY?
Strategy is creating fit among a company’s activities. The success of a strategy depends on doing many
things well – not just a few. The things that are done well must operate within a close nit system. If there
is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment
process. Management then reverts to the simpler task of overseeing independent functions. When this
occurs operational effectiveness determines the relative performance of the organization.
[3]
Improving operational effectiveness is a necessary part of management, but it is not strategy. In
confusing the two, managers will be unintentionally backed into a way of thinking about competition that
drives the business support processes (IT) away from the strategic support and toward the tactical
improvement of operational effectiveness.
Managers must be able to clearly distinguish operational effectiveness from strategy. Both are essential,
but the two agendas are different. The operational effectiveness agenda involves continual improvement
business processes that have no trade–offs associated with them. The operational effectiveness agenda
is the proper place for constant change, flexibility, and relentless efforts to achieve best practices. In
contrast, the strategic agenda is the place for making clear tradeoffs and tightening the fit between the
participating business components. Strategy involves the continual search for ways to reinforce and
extend the company’s position in the market place.
The concept of fit among functional units is one of the oldest ideas in strategy. Gradually however, it has
been supplanted with new concepts of core competencies, critical resources and key success factors. In
fact fit is far more critical to the success of the IT systems than is realized.
[3]
Strategic fit among the
various systems components and the business processes they support is fundamental not only to
competitive advantage but also to the sustainability of that advantage.
Fit among a company’s activities creates pressures and incentives to improve operational effectiveness.
Fit means that poor performance in one activity will degrade the performance in others, so that
weaknesses are exposed drawing management’s attention. Conversely, with increasing fit, improvements
of one activity will pay dividends in other areas.
The challenge now is to create fit among the IT components and their matching business components.
3
“What is Strategy,” M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61–78.
Jack Welch Speaks: Wisdom from the World’s Greatest Business Leader, J. Welch and J. C. Lowe, John
Wiley & Sons, 1998.
Control Your Destiny or Someone Else Will: Lessons in Mastering Change–From the Principles Jack
Welch Used to Revolutionize GE, N. M. Tichy and S. Sherman, Harpers Business, 1994.

4. IT Strategy Page 4
• WHAT IS SYSTEM ARCHITECTURE AND WHY DO WE CARE?
If we were setting out to build a home, we would first lay out the floor plans, grouping each room by
function and placing structural items within each room according to their best utility. This is not an
arbitrary process – it is architecture. Moving from home design to IT system design does not change the
process. Grouping data and processes into information systems creates the rooms of the system
architecture. Arranging the data and processes for the best utility is the result of deploying an
architecture. Many of the attributes of building architecture are applicable to system architecture. Form,
function, best use of resources and materials, human interaction, reuse of design, longevity of the design
decisions, robustness of the resulting entities are all attributes of well designed buildings and well
designed computer systems.
[4]
In general, an architecture is a set of rules that defines a unified and coherent structure consisting of
constituent parts and connections that establish how those parts fit and work together. An architecture
may be conceptualized from a specific perspective focusing on an aspect or view of its subject. These
architectural perspectives themselves can become components in a higher–level architecture serving to
integrate and unify them into a higher level structure.
The architecture must define the rules, guidelines, or constraints for creating conformant implementations
of the system. While this architecture does not specify the details on any implementation, it does establish
guidelines that must be observed in making implementation choices. These conditions are particularly
important for component architectures that embody extensibility features to allow additional capabilities to
be added to previously specified parts.
[5]
This is the case where Data Management is the initial
deployment activity followed by more complex system components.
By adopting a system architecture motivation as the basis for the IT Strategy, several benefits result:
ü Business processes are streamlined – a fundamental benefit to building enterprise information
architecture is the discovery and elimination of redundancy in the business processes themselves. In
effect, it can drive the reengineering the business processes it is designed to support. This occurs
during the construction of the information architecture. By revealing the different organizational views
of the same processes and data, any redundancies can be documented and dealt with. The
fundamental approach to building the information architecture is to focus on data, process and their
interaction.
ü Systems information complexity is reduced – the architectural framework reduces information system
complexity by identifying and eliminating redundancy in data and software. The resulting enterprise
information architecture will have significantly fewer applications and databases as well as a resulting
reduction in intersystem links. This simplification also leads to significantly reduced costs. Some of
those recovered costs can and should be reinvested into further information system improvements.
This reinvestment activity becomes the raison d’état for the enterprise–wide system deployment.
ü Enterprise–wide integration is enabled through data sharing and consolidation – the information
architecture identifies the points to deploy standards for shared data. For example, most ABC
business units hold a wealth of data about products, customers, and manufacturing processes.
However, this information is locked within the confines of the business unit specific applications. The
information architecture forces compatibility for shared enterprise data. This compatible information
can be stripped out of operational systems, merged to provide an enterprise view, and stored in data
repositories. In addition, data standards streamline the operational architecture by eliminating the
need to translate or move data between systems. A well–designed architecture not only streamlines
4
A Timeless way of Building, C. Alexander, Oxford University Press, 1979.
5
“How Architecture Wins Technology Wars,” C. Morris and C. Ferguson, Harvard Business Review,
March–April 1993, pp. 86–96.

5. IT Strategy Page 5
the internal information value chain, but it can provide the infrastructure necessary to link information
value chains between business units or allow effortless substitution of information value chains.
ü Rapid evolution to new technologies is enabled – client / server and object–oriented technology
revolves around the understanding of data and the processes that create and access this data. Since
the enterprise information architecture is structured around data and process and not redundant
organizational views of the same thing, the application of client / server and object–oriented
technologies is much cleaner. Attempting to move to these new technologies without an enterprise
information architecture will result in the eventual rework of the newly deployed system.
• FRAMEWORK FOR THE IT STRATEGY
Before proceeding with the IT Strategy, a framework is needed to represent the various views of the IT
System. This Framework is based on the seminal work of John A. Zackman.
[6]
Using the architectural
paradigm, the Framework provides answers to:
ü What – is the system made of? What components are assembled to make the system what it is? How
are these components connected? What are the mechanisms used to connect the components?
ü How – does the system work? What are the details of the system integration? What tools have been
used to integrate the components? Are these tools appropriate for the task at hand?
ü Where – are the components of the system located relative to one another? What is the topology for
the data and processes? How is this topology managed?
ü Who – does what relative to these system components? How do the users interact with the system?
How is access controlled to the system resources?
ü When – do things happen in the system? What is the sequence of events within the system? How is
work routed through the system? How are the users notified that work is ready, complete, suspended,
canceled?
ü Why – are various system choices being made? What is the underlying architecture of the system?
How did the system components come to be connected? How will these components be migrated to
the next generation?
The Framework provided through this approach is:
ü Simple – since it is easy to understand. In its most elemental form, it provides three perspectives: The
Owner, the Designer, the Builder and three abstractions: Material, Function, and Geometry.
ü Comprehensive – is addresses the Enterprise in it entirety. Any issues can be mapped against the
Framework to understand where they fit within the context of the Enterprise as a whole.
ü Language – it helps develop a set of thought processes for addressing complex concepts and
communicates them precisely with few, non–technical words.
ü Planning Tools – it helps the participants make better choices since these choice are no longer made
without a context.
ü Problem Solving Tool – is enables the participants to work with abstractions, to simplify, to isolate
simple variables without losing sense of the complexity of the Enterprise as a whole.
ü Neutral – is it defined totally independently of tools or methodologies and therefore any tool or any
methodology can be mapped against it to understand their implicit tradeoffs.
The Framework for Enterprise Architecture is not the answer. It is a tool for thinking about the answers.

6. IT Strategy Page 6
[6]
Data Function Network People Time Motivation
Scope
What is the span of
interest for the system
and its users?
List of things important
to the business units
and the data that
represents them.
List of processes the
business units perform
and the operations to
be incorporated into
the system.
List of locations in
which the business
operates
List of organizations
important to the
business and their
interactions with the
system.
List of events
significant to the
business units
List of business goals
and strategies to be
addressed by the
system.
Enterprise Model
How are the process
and data elements
arranged within the
enterprise?
Semantic models
describing the
meaning and use of
the data elements.
Business process
models describing
how the data is used
within each business
process.
Logistics models
describing the logical
connectivity between
the various system
components.
Work flow models
describing the steps
taken for each work
process.
Master schedules
describing the
temporal sequencing
of the business
processes.
Business plan
describing the cost
and benefits of
automating each
business process.
System Model
How are the process
and data elements
arranged within the
logical system?
Logical data model for
each process in the
system.
Application
architecture describing
the connections
between the various
applications.
Distributed system
architecture describing
network arrangement
of each processing
element.
Human interface
architecture describing
the various user
interface components.
Processing structure
describing the
processing sequences
of each application
step.
Business rule model
describing the
business rule for each
process and data
element.
Technology Model
What are the
technological
elements of the
system?
Physical data model
each process in the
system.
System design of the
application and data
elements
System architecture
describing the
arrangement of the
technological
elements of the
system.
Presentation
architecture describing
the mechanisms of
presenting information
to the users
Control structure
describing the
interconnections
between the
processing steps in
terms of sequence
and effectiveness.
Rule design
describing the detailed
business rules for
each processing step
and the associated
data.
Detailed
Representation
How are these
elements represented
in practice?
Data definition for
each element in the
data models
Programs used to
implement the system.
Network architecture
for the actual
hardware and
software components.
Security architecture
for each application
and user community.
Timing definitions for
each application and
associated data.
Rule specification for
each data and
process access
sequence.
Figure 1 – Zackman Enterprise Architecture Framework
6
This table is taken from John Zachman’s original works, “A Framework for Information Systems Architecture,” J. A. Zachman, IBM Systems
Journal, Volume 26, Number 3, 1987. “Extending and Formalizing the Framework for Information Systems Architecture,” J. F. Sowa and J. A.
Zachman, IBM Systems Journal, Volume 31, Number 3, 1992.

7. IT Strategy Page 7
• VERTICAL VERSUS HORIZONTAL APPROACHES
The IT Framework in Zachman’s works describes five (5) increasingly detailed levels or views: scope,
enterprise model, system model, technology mode, and detailed representation of three (3) architectural
components: data, process and technology (see Figure 1):
The majority of strategic business and technology breakthroughs using this approach are found within the
top rows of Figure 1. The first two rows are business management views of the architecture that have
nothing to do with the underlying technology. The lower levels of the architecture have to do with building
actual applications and databases. The focus of the IT Strategy will be on the top levels of Figure 1 for the
following reasons:
ü Having a plan is necessary to ensure success, but it not sufficient. Most architectural efforts skim
through the higher–level views and spend months or even years becoming mired in the technical details
of the system. The high–level view defines the boundaries of what should be automated in any one
information system. This approach focuses the effort on successful business deployment, not just the
technical details of the products and services.
ü The higher–level views of the system are the foundation and must stand the test of time. The lower
levels of the architecture are actually unstable due to the rapidly changing technology environment.
ü In order to gain control over the technology assets, the business units need to understand that
architecture provides the structure that guides, scopes, and controls the implementation process. Many
significant breakthroughs occur during the development of the business views of the enterprise
information architecture.
Within the IT Framework, there are two (2) primary approaches to IT System Architecture:
ü Vertical – which creates disconnections between the various architectural components. This organization
comes about by developing systems to meet the needs of individual use groups, rather than the needs of
the business enterprise.
The information technology psyche begins at the department level or lower, rather than at the business
or enterprise level. As a result, the system’s design becomes very department–dependent, often to the
point at which expenditures and activities were optimized to the benefit of the department and the
detriment of the enterprise.
[7]
Placing the emphasis on end–user satisfaction continues to encourage this departmental myopia,
creating vertical systems with their own proprietary data, software, and technology components. Each
system is optimized for productivity within the department, not the enterprise.
ü Horizontal – using the architectural concept of planned deployment, the enterprise information systems
architecture framework described in Figure 1 provides an alternative approach to the departmental
isolation of the vertical system architecture. This architecture allows integration and coordination across
the enterprise. This integration and coordination always requires a shift away from the vertical or
proprietary approach to a horizontal approach that cuts across the organizational lines of data and
process ownership.
The Value of Architecture
Software architecture design is intimately related to life cycle cost. A well–designed software architecture
represents a valuable investment that yields adaptability to new requirements and technologies over the
system’s life cycle.
7
L. Runge, Computerworld, October 24, 1994, pp. 113.

8. IT Strategy Page 8
• INFLUENCES OF IT STRATEGY
The IT Strategy components described in § are based on the physical and logical technologies of the IT
Infrastructure. These describe how, what, when, and where to technology of the IT Strategy is to be
deployed. The effects of this technological deployment are another element of the IT Strategy. In the
Zachman approach to IT Strategy is supply side focused and the domain of IT professionals.
[8]
In order to
complete the IT Strategy the influences of these technologies on the organizational aspects of the business
must be understood. The questions to be answered include:
ü What IT applications should be deployed to yield competitive advantage?
ü What technological opportunities should be considered?
ü What IT platforms should be deployed and what IT policies are needed to manage these platforms?
ü Which IT capabilities should be nurtured and which should be acquired from outside sources?
ü How should IT activities be organized and what is the role of the IT function?
ü What is management’s role in the IT domain and what IT capabilities are required for today’s managers?
The answers to these questions involve determining how the components of the IT Strategy Fit together and
how they are Interrelated. The influences approach to IT Strategy is based in a simple and effective view of
how business executives are able to conceptualize strategic decision-making processes in the domains of:
ü Organizational Strategy
ü Information Systems Strategy
ü Information Technology Strategy
ü Information Management Strategy
It is the discovery and description of the interdependence between these four (4) strategies to forms the
basis of this approach.
8
Integrating IS and the Organization: A Framework of Organizational Fit, Michael J. Earl, London Business
School, Centre for Research in Information Management Working Paper, CRIM WP95/4.
“Information Technology Planning in he 1990’s: Directives for Planning and Research,” A. C. Boynton, MIS
Quarterly, March 1987.
Information Management: The Organizational Dimension, M. J. Earl, Oxford University Press, 1996.
The Chief Information Officer: A Study of Survival, M. J. Earl, Centre for Research in Information
Management Working Paper WP93/3, reprinted as WP95/1, London Business School.
“Experiences in Strategic Information Systems Planning,” M. J. Earl, MIS Quarterly, Volume 17, Number 1,
March, pp. 1-24, 1993.
Information Management: The Strategic Dimension, M. J. Earl, Oxford University Press, 1988.
“Information Systems Strategy Formulation,” in Critical Issues in Information Systems Research, edited by R.
J. Boland and R. A. Hirscheim, John Wiley and Sons

9. IT Strategy Page 9
CC,DD,EE,FF
Y,Z,AA,BB
U,V,W,X
Q,R,S,T
I,J,K,L
M,N,O,P
A,B,C,D
E,F,G,H
Clarification – The character of
the processes by which the
organizations strategy
influences the information
strategic domains (IM, IS, IT)
Constitution – linkages from
the IM domain are processes
of "governance"
Foundation – defines ways
in which the infrastructure
is to be built.
Orientation – is the
character of the
processes by which the IS
Strategy influences other
domains
Clarification Orientation
Constitution Foundation
IT Strategy Framework
IT Strategy Framework
R1.0 Master Process Relationships 7/31/98 GBAlleman
G
G
,H
H
,II,JJ
KK,LL,M
M
,NN
O
O
,PP,Q
Q
,R
R
SS,TT,UU,VV
OrganizationalStrategy–Wherefore
WHY
Organizational Strategy
Attributes
Forms the
operational
orientation, focus or
criteria for making
business choices.
Business – Corp
strategy is concerned
with mission. SBU
strategy is concerned
with competitive
positioning.
Intent – forces a
crystallization of
purpose, an
operational
orientation, in making
choices.
The formal
definitions,
configurations and
instruments of
structure and control
Organization – chose
the organizational
structure or design,
management control
systems and formal
policies.
The formulation and
implementation of
business strategy.
Context – context of
the Strategy. The
influences on IM, IT
and IS.
This is the "ethos" of
the organization, the
management style of
the culture. How
management is put
into IM, IT and IS.
Components
What
Information Systems Strategy
InformationSystemsStrategy–What
Product–Market
strategies are not
complete without
consideration of the
IS needs
SBU – Business Unit
Alignment –
identifying the
applications required
to support the
business strategy
Concerned with
global capabilities,
new ways of
organizing, or with
the search for
synergy and added
group value
Group – Enterprise or
Group of Business
Units
Opportunity –
searching for
innovative uses of
technology which can
be exploited to
enable business to
be done differently.
Pursue new themes
in IS strategy and the
search for intent
across the highest
levels of the
organization
Focus on procedural
forms of planning
using Critical
Success Factors
Components
Attributes
Who
Information Management Strategy
InformationManagementStrategy–Who
Components Attributes
Describes the
documented roles of
the organization
Roles – who has
responsibility and for
information resource
policies and actions
Describes the formal
relationships
between the
organizations
Formal – the intent
of roles and
relationships
Relationships – how
are relationships built
between CIO and
others to assure
success over time
Describes the
informal or actual
roles played in the
organization
Describes the
informal relationships
between the
participants in the
CIO domain
Informal – the
context of roles and
relationships
How
Information Technology Strategy
InformationTechnologyStrategy–How
Attributes
Components
Control the
infrastructure,
metadata, and
metaprocesses
within the
architecture
Skill sets are based
on the architectural
foundation, not the
available resources
Powers – are
required to
implement & monitor
the architecture.
Powers are used to
exercise technology
stewardship.
Architecture – the
technology
framework which
drives, shapes and
controls the IT
infrastructure.
Capability –is the set
of skills, knowledge
assets and activities
needed to be
competent in the
market place.
Control of the
centralized verses
decentralized
boundary between
users and specialists
Driven by the
business needs and
the skill sets.
Alignment of these
two items is a critical
success factor
Scope – which
technologies are to
be formally included
in the Information
Strategy
Figure 2 – Organizational Influences of the IT Strategy

10. IT Strategy
• Methodology of the IT Influences Description
The following narrative describes the details of the IT Strategy Framework. Each Framework component described
in the diagram influences the other three (3) components in ways described below. The individual lettered influences
originate from the four (4) results produced by the intersection of the attributes and components of each What, Why,
How, and Who. The individual descriptions follow in clockwise manner around the intersection matrix, starting in
the upper left corner.
Components
Attributes
B, K, R, Z
DD,V,O,F
HH,LL,PP,TT
D, I, T, BB
FF,X,M,H
II,MM,QQ,UU
C, J, S, AA
EE,W,N,G
JJ,NN,RR,VV
A, L, Q, Y
CC,U,P,E
GG,KK,OO,SS
Figure 3 – Legend of the IT Influences Diagram
The Influence diagram contains the following elements:
ü Components – of the business strategy.
ü Attributes – or characteristics of the organization.
Four interacting elements of the strategy are:
ü Organizational Strategy – describes the organizational structure of the various business units, how
they interact, the named participants in each organization and the informal behind the scenes
participants
ü Information System (IS) Strategy – describes the behavioral aspects of the system which support,
promote, or enhance the business activities.
ü Information Technology (IT) Strategy – describes the actual computing systems, their architectures,
operation and maintenance. Although focused on the physical technology, the acquisition, installation
and deployment of these technologies and a critical component of the IT Strategy.
ü Information Management (IM) Strategy – describes the creation, management and use of information.
This information is usually in the form of database contents and the work processes built around
them.

11. IT Strategy
• Four Elements of the Strategy
In each of the four strategy elements the components and attributes are organized in the following
manner:
ü Organizational Strategy – WHY (the wherefore and rationale for the strategy)
v Components of WHY
Ø Organizational components – chose the organizational structure or design, management
control systems and formal policies.
Ø Business components – the corporate strategy is concerned with mission. The strategic
business unit strategy is concerned with competitive positioning.
v Attributes of WHY
Ø Intent – forces a crystallization of purpose, an operational orientation, in making choices.
Ø Content – is the context of the Strategy. The influences of the Organizational Strategy on the
other three strategy elements.
ü Information Systems Strategy – WHAT (the components of the strategy)
v Components of WHAT
Ø Alignment – identifying the applications required to support the business strategy.
Ø Opportunity – searching for innovative uses of technology which can be exploited to enable
business to be performed better.
v Attributes of WHAT
Ø Strategic Business Unit – the individual business unit.
Ø Corporate or Group – the highest level of the business organization in which the individual
business units operate.
ü Information Technology Strategy – HOW (the mechanisms of the strategy)
v Components of HOW
Ø Scope – which technologies are to be formally included in the information strategy
Ø Architecture – the technology framework which drives, shapes, and control the Information
Technology Strategy.
v Attributes of HOW
Ø Capability – is the set of skills, knowledge assets and activities needed to be competent in
the market place
Ø Powers – are required to implement and monitor the architecture. Powers are used to
exercise technology stewardship.
ü Information Management Strategy – WHO (the participants in the strategy)
v Components of WHO
Ø Roles – who has responsibility for information resource policies and actions
Ø Relationships – how are relationships built between he CIO and others to assure success
over time.
v Attributes of WHO
Ø Formal – the intent of roles and relationships
Ø Informal – the context of roles and relationships
The following sections describe the details of the influences between Why, What, How, and Who.

12. IT Strategy
• What’s Influence on Why
The influences between What and Why include:
A – Focus on procedural forms of planning using Critical Success Factors – The enterprise–wide
management of data demands an enterprise–wide data and process management planning
horizon. The uniformity of the procedural focus encompasses all participants rather than
individuals.
B – Pursue new themes in IS strategy and the search for intent across the highest level of the
organization – Pursuing intent across the enterprise consolidates the operational choices for all
participants. Acting as one origination can now be facilitated through the IT Strategy.
C – Concerned with global capabilities, new ways of organizing or with the search for synergy and
added group value – The consolidation of the product vision can now cross business unit
boundaries. This impacts the organizational aspects of the decision making process, since
participants are now impacted as a collective rather than in isolation
D – Product–Market Strategies are not complete without consideration of the IT Needs –
Economies of scale can now be applied to each business unit, while reusing their existing
infrastructure. The consolidation of this infrastructure demands that the participants share in the
infrastructure vision as well as provide for its management.
• Why’s Influence on Who
The influences between Why and Who include:
I – The Ethos of the organization, the management style of the culture. How management is put
into Information Management, Information technology, and Information Systems – The
collective vision of the enterprise-wide IT system must be propagated throughout the
organization. This can not be done by simply starting at the top and working down. A bottom-up
and top-down approach is required to assure all participants share in the same vision at the
same time
J – The formulation and implementation of business strategy – The creation of the components of
strategy must take place through the collaborative process of consensus building. The resulting
system is not a sum of all opinions but is built on an architectural foundation, which meets the
needs of all participants.
K – Forms the operational orientation, focus or criteria for making business choices – The
participants in the IT Strategy process must be focused on the operational aspects of the
decision making activities. As such, they must have a detailed understanding the operational
processes and the consequences of the various IT Strategy options.
L – The formal definitions, configurations and instruments of structure and control – The integration
of the various individual organizations can not be based on a shared organization chart.
However, some form of consistency between each participant’s business structure is needed to
assure uniform reporting paths. As a result, the IT Strategy must assume a uniform reporting
and deployment structure as well as consistent deployment metrics throughout the
organization.
• Who’s Influence on How
The influences between Who and How include:
Q – Describes the documented roles of the organization – The creation of a formal organization
chart and job description will form the basis for documenting the various roles within the IT
organization and the organizations it serves.
R – Describes the formal relationships between the organizations – The relationships between the
various participants can be formally described. The roles and responsibilities document is one

13. IT Strategy
tool for this description. Service Level Agreements are another mechanism through which
relationships and the associated performance metrics can be described.
S – Describes the informal relationships between the participants in the CIO domain – The
deployment of operational systems will depend on the informal relationships between the IT
providers and the IT consumers. These relationships can be established and maintained
through the support environment.
T – Describes the informal or actual roles played in the organization – The skill sets necessary to
successfully deploy, operate, and maintain the system must be broader than the formal job
description. The compartmentalization of roles must be avoided. Generalist must be recruited,
trained, and deployed throughout the IT provider’s organization
• How’s Influence on What
The influences between How and What include:
Y – Skill sets are based on the architectural foundation, not on the available resources – The skill
set availability directly impacts what functions can be performed by the deployment and
operational teams. The demand for skill sets must be met with the supply of skill sets. This in
turn will influence which technologies can be deployed within the scheduled timeframes.
Z – Control the infrastructure, metadata, and metaprocesses within the architecture – The
guidelines for controlling the infrastructure will influence what technologies are deployed in the
operational environment. The mechanism for controlling this infrastructure is usually defined
within the IT Strategy and the operational departments in the IT Organization.
AA –Control the centralized versus decentralized boundary between users and specialist – The
mechanism for controlling the boundary between centralized and decentralized environments
and the user and specialist domain is defined in the IT Strategy. This control focuses on the
operational aspects of the applications. Infrastructure elements are separated from the
application elements. The infrastructure elements are usually centralized while the application
elements are nearer the end user domain.
BB –Driven by the business needs and the skill sets. Alignment of these two items is a Critical
Success Factor – The scope of the deployment mechanism is controlled by the available skill
sets. Each business unit’s needed will place a specific burden on the available resources for
installation, startup and operations of the various application suites.
• What’s Influence on How
CC – Focus on procedural forms of planning using Critical Success Factors – these Critical Success
Factors must be traceable to the architectural components. Each architectural component can
be used to support a CSF using metrics. By building on the businesses Critical Success
Factors, the IS Strategy can directly support the measurable outcomes.
DD – Pursue new themes in IS strategy and the search for intent across the highest level of the
organization – the coupling of product and market strategies with the IT Strategy provides a
directly measurable benefit for both the product organization and the IT organization. By
supporting the production environment with enabling technology, the IS Strategy can be
developed around the business needs, while maintaining its architectural foundations.
EE – Concerned with global capabilities, new ways of organizing or with the search for synergy and
added group value – The Globalization of the IT Strategy is actually based in the concept of
removing the boundaries of operation from the system. Localization’s must be avoided, while
still provided sufficient flexibility to meet specific business process needs. This can be
accomplished through an architectural foundation strategy in which system components are
tailored to meet specific needs. The foundation of these tailored components forms the basis
of the modifications. This is the primary role of object technology. New behaviors are derived
from existing objects, through new or altered methods, while maintaining the standard
behaviors and interfaces for all other users.

14. IT Strategy
FF – Product–Market Strategies are not complete without consideration of the IT Needs – The
individual product / market strategies must be owned by the operational unit managers. Using
the foundation architecture, the IT system will be deployed to meet these strategies. Any
localization will be managed in isolation (using the tools of the system).
• How’s Influence on Who
U – Skill sets are based on the architectural foundation, not on the available resources – The skill
set requirements directly influence the personnel being deployed.
V – Control the infrastructure, metadata, and metaprocesses within the architecture – The
controlling personal are responsible for implementing the infrastructure need to understand the
metadata and metaprocesses for the organization. This understanding should be based on a
specific model of the data and processes, which is maintained in the IT Organization.
W – Control the centralized versus decentralized boundary between users and specialist – The
assignment of the personnel for controlling the centralized versus decentralized boundaries
must understand both the meta data and processes issues as well as the computing
infrastructure.
X – Driven by the business needs and the skill sets. Alignment of these two items is a Critical
Success Factor – The personnel responsible for aligning the centralized and decentralized
application domains must have the skill sets to deal with the individual business processes.
• Who’s Influence on Why
P – Describes the documented roles of the organization – The organizational description need to
be clearly defined so that responsibilities and man loading requirements can be
O – Describes the formal relationships between the organizations – The formal relationships for the
organizational components are necessary in order to define who does what. This organization
chart only defines the formal lines of communication, the informal lines are also necessary to
actually make the organization function.
N – Describes the informal relationships between the participants in the CIO domain – These
informal relationships form the basis of the real work within the organization. Based on the
formal aspects of the business, the knowledge of where and how to get something done is
usually held in locations outside the formal repositories – simply because of the tribal
knowledge and job movement.
M – Describes the informal or actual roles played in the organization – The informal roles played by
the participants is as important as the formal roles. Mentoring, external advise, historical
knowledge, and outside opinions all add to the value of the IT Strategy and its supporting
processes.
• Why’s Influence on What
E – The Ethos of the organization, the management style of the culture. How management is put
into Information Management, Information technology, and Information Systems – The culture
of the organization influences what the IT Strategy delivers through the design and deployment
of the business systems. What is important to the organization is conveyed in the level of detail,
business process control, support systems, performance and capital expenditure levels.
F – The formulation and implementation of business strategy – By articulating the business strategy
is terms of system behaviors (the external behavior as seen by customers and clients), the
business units are creating a vision of their operations.
G – Forms the operational orientation, focus or criteria for making business choices – By defining
the measurable behaviors of the system, through the operational metrics the software
components become embedded in the culture of the business. We do it this way because that’s
the way we do it – becomes the rational for the underlying systems. The organization then
takes on the culture of the software systems.

15. IT Strategy
H – The formal definitions, configurations and instruments of structure and control – The formal
model of the organization is held in the software system. The Metadata and Metaprocesses
come to represent the business operations. The users of the system then drive to software
system directly, which in turn drives the underlying business processes indirectly.
• Why’s Influence on How
SS – The Ethos of the organization, the management style of the culture. How management is put
into Information Management, Information technology, and Information Systems – By setting
down the cultural aspects of the IT Strategy, the implementation boundaries can be defined.
What methods, technologies, expectations, and personnel behaviors are expected can be
used to form the underpinnings of the planning process.
TT – The formulation and implementation of business strategy – By formulating the clear and
concise business strategy the implementation plans can be aligned with the business plans.
Without this alignment the metrics needed to verify the business goals can not be
determined.
UU – Forms the operational orientation, focus or criteria for making business choices – Defining the
intentions of each business in their use the IT technology and its operational behaviors
resulting is a clear set of goals and objectives by which the resulting system can be
measured
VV – The formal definitions, configurations and instruments of structure and control – The formal
definitions of the organization’s expectations can be translated into actual project plan details.
• How’s Influence on Why
KK – Skill sets are based on the architectural foundation, not on the available resources – The
development of skill sets facilitates the development of the underlying technology. In many
cases the addition of new skill sets brings new ideas into the organization that would not have
normally been found in the static maintenance and operation of the legacy system.
LL – Control the infrastructure, metadata, and metaprocesses within the architecture – By
controlling the infrastructure the delivery of IT Systems can be provided in a uniform manner.
A single face of the system can be presented. The result of this uniform delivery process can
be seen as dial tone to the end user community
MM – Control the centralized versus decentralized boundary between users and specialist – By
defining the boundaries between infrastructure and end user applications the common
components of the system can be syndicated across the organization. The specialized
components of the system can then be isolated to minimize their effect.
NN – Driven by the business needs and the skill sets. Alignment of these two items is a Critical
Success Factor – The skill set inventory must be maintained throughout the life cycle of the
system. These skills are driven by both the technology and the business needs.
• Who’s Influence on What
OO – Describes the documented roles of the organization – Each role in the IT Organization must
be mapped to the various levels of the operational business units. Some roles span the entire
organization, while others are targeted to specific business activities within an individual
business unit.
PP – Describes the formal relationships between the organizations – The formal mapping of these
roles defines the boundaries of the organization chart.
QQ – Describes the informal relationships between the participants in the CIO domain – The
informal relationships that exist between the providers of technology and business
applications and the end user must be capable of adapting to the ongoing needs of the user
community.

16. IT Strategy
RR – Describes the informal or actual roles played in the organization – By providing multi–talented
individuals, knowledge not normally found in a structured organization can be provided with
no extra cost or effort.
• What’s Influence on Who
GG – Individual project managers and the IT Information System organizational planning process
must be facilitated by individuals with the proper skills and motivations.
HH – By creating and holding a vision of the IT System, the architectural aspects of the system will
drive the business and technical components. It’s the vision thing should be the watchword of
the IT Organization.
II – Using IT as a strategic weapon the organization can add value to the business operations.
Continuous improvement of IT based processes is no different than continuous improvement
of all other manufacturing processes.
JJ – By providing both technology and business expertise within the IT Organization, the product
and market strategies will be on equal footing with the software, hardware, cost and
operational strategies.

17. IT Strategy
• TARGET BUSINESS ENVIRONMENTS
Figure 4 describes the scope of the business units targeted for the IT Strategy. The components of the
next generation system will be distributed within these organizational units. Depending on their
applicability, some applications and the data they manage will span the entire enterprise from the Plant
level through the Group level. Other applications may be applicable only within a Business Unit or a
Commodity. By design, the applications will span no lower than the Business Unit level. § describes the
concepts between vertical and horizontal system architectures and the motivations for deploying
horizontal architectures.
DEF Group
GHI Manufacturing
Casegoods
Contract Group
Seating Systems Lodging Cabinets / Furniture
Location1
Location2
Location3
Location4
Location5
Loation6
Loation7
Location9
Location8
Location10
Location11
Location12
Location13
Location14
Location15
Locatio16
LMN Casegoods OPQ RST XYZ Furniture
ZZZ
Hills
ZZZ
Corp.
UVW
Group
Sub Group
Commodity
Business
Unit
Plant
Group
Sub Group
Commodity
Business
Unit
Plant
Figure 4 – Target Business Environments
Using Figure 4 and Figure 1 the mapping between the IT system components and the various business
units can be constructed. § and Figure 8 provides a high–level map between these two components.
• PROBLEM STATEMENT AND SOLUTION SPACE
The current DEF Group Data Management systems can be classified as large, monolithic, centralized
software system is tied to small islands of information creation and use. The problems associated with
this system includes:
ü Limited flexibility
ü High integration costs with other systems
ü High development, enhancement and maintenance costs
The next generation manufacturing system must resolve these problems while enabling:
ü Commercial off the shelf alternatives to internal proprietary systems
ü Solutions assembled from multiple vendor’s offerings.

18. IT Strategy
ü Use of existing systems while delivering new capabilities from the next generation systems.
The next generation system must provide a high degree of interoperability among applications,
manageable applications replacement and integration, and rapid system reconfiguration through the
reuse of the system components.
The IT Strategy provides a guide for defining such a system. The essential tenet of the solution space is
to deploy a technology framework that provides the tools necessary to support the system requirements.
The specific technology solution is not yet known, but such technologies are available in the market place
today.
There are a number of important perspectives from which to view the system architecture needed to
address these requirements. One is the technical architecture that captures the elements of the
distributed system components, frameworks, and event–driven systems. Another is the functional
architecture that captures the functional elements of the system and the relationship between those
functional elements. The functional architecture is built on, and leverages, the structures of the technical
architecture.
The technology framework must address:
ü How to assemble a system from components obtained from different vendor’s or from internal
development sources.
ü How to extend and specialize the existing system to accommodate new business requirements.
ü Replace portions of the existing system with components that better meet the business requirements.
To accomplish these goals, the functional architecture must identify which functional components can be
separated from each other and what interfaces and interactions are required for these separate
components work together as an integrated whole. The IT Strategy provides the guidelines for developing
such a Functional Architecture and defines the boundaries within which the architecture can be
developed.
• COMPONENTS OF THE IT SOLUTION
The high level logical components of the next generation system are described in.
[9]
These include:
[10]
ü CAD – the use of computers in interactive engineering drawing and storage of designs.
v 2D Drawing production – is the process of rendering 3D models and other I–DEAS modeling
objects into 2D drawings. These drawings will be produced in a neutral format, which is capable
of being delivered to a variety of workstation environments. These drawings will be considered
archival objects capable of being stored and retrieved in the absence of the current software
applications.
[11]
Since the display of these drawings (and possibly any other documents) must be
provided over the life of the product, plus its warranty and litigation period are must be taken to
assure that the file formats are in fact usable in the future.
9
This list is not a complete description the various components of these systems. It is only meant to
provide a high level overview of each component. Detailed technical descriptions of each component,
how these components interact, how each component is implemented by a specific vendor and the
consequences of selecting one vendor’s implementation over another are beyond the scope of this
document. There are no industry standards for many of these components, therefore the definitions are
vendor specific in many cases. There are standards for workflow however, Workflow Management
Coalition: The Workflow Reference Model, TC00–1003, Issue 1.1, November 29, 1994.
10
APICS Dictionary, 7
th
Edition, 1992.
11
See “From Digits to Dust”, Business Week, April 20, 1998, pp. 128. The primary issue here is the
viewing and printing of the 2D drawings at some point in the future. The current approach of providing the
drawings in HPGL format creates a risk that this format will not be readable some time in the future. For
litigation support, documents and drawings may be required to be maintained for decades. This
requirement places a heavy burden on the document management system to maintain a legally viable set
of documents.

19. IT Strategy
v 3D Modeling – provides the visualization of the product entities within the I–DEAS environment.
v Finite element design – is the process of design products material dynamics analysis.
v Parametric design – is the process of regeneration of product entities using alterable parameters
instead of specific measurements. The geometry and topology of the object is maintained, while
the specific dimensionality is altered.
v Workflow – is the process of computerizing the facilitation or automation of a business activities,
in whole or in part. This includes the workflow language as well as the workflow management
system. The workflow management system completely defines, manages, and executes
workflows through the execution of software whose order of execution is driven by a computer
representation of the workflow logic.
[12]
The workflow component is considered Infrastructure and may be used in other application
environments than CAD.
v Vault management – is the process of providing a single place where objects are stored and
controlled. A typical vault or repository has four primary parts, which exist, in client and server
applications, within a database and in file storage systems.
[13]
The vault or repository component is considered Infrastructure and may be used in other
application environments than CAD.
ü Product Data Management – A set of technologies and capabilities for comprehensively managing
design intent and product development processes across the enterprise.
v Project Management – is the process of managing the product components and the business
processes, which support the building of the products through the various phases of design,
manufacture and deployment.
v Configuration Management – is the process of managing the design, delivery and support of
products. This is sometimes referred to Product Structure Management.
v Parts Classification – is the process of classifying parts according to families, which includes
descriptive attributes.
[14]
ü Enterprise Resource Planning – is a broad term describing the next generation of manufacturing
business systems and manufacturing resource planning (MRP II) software. The components of the
ERP system include: product planning, parts purchasing, maintaining inventories, interacting with
suppliers, providing customer service, and tracking orders. ERP can also include application modules
for the finance and human resources aspects of a business.
v Materials Management – describes the grouping of management functions related to the
complete cycle of material flow, from the purchase and internal control of production materials to
the planning and control of work–in–process to the warehousing, shipping and distribution of the
finished product. It differs from materials control in that the latter term, traditionally, is limited to
the internal control of production materials.
v Logistics – provides an integrated set of applications to manage product shipping, tacking of
shipments, forecasting of the demand for logistics resources, and specialized logistics
applications for packaging and labeling
12
Work Flow Management Coalition definitions.
13
Electronic Document Management Systems, L. Bielawski and J. Boyle, Prentice Hall, 1997.
Document Management for the Enterprise: Principles, Techniques and Applications, M. J. D. Sutton, John
Wiley & Sons, 1996.
14
Although the term Parts Classification is used here, the PDM vendors provide parts classification as
part of Component and Supplier Management (CSM). The CSM capabilities manage not only the parts
and their classification, but also the procurement of these parts.

20. IT Strategy
v Order Management – the process of accepting and translating what a customer wants into terms
used by the manufacturer or distributor. This can be as simple as creating shipping documents for
a finished goods product line, or it might be a more complicated series of activities, including
engineering effort for make-to-order products.
v Procurement – provides an integrated set of applications for managing the procurement of
components and services. These services include the integration for the Component and Supplier
Management components of Product Data Management.
v Shop floor scheduling – provides an integrated set of application for managing the materials,
manufacturing centers and scheduling activities on the shop floor.
v Integrated Financials – provides an integrated set of applications for Activity Based Accounting,
cost accounting AP/AR and GL.
CAD
ERP
Parametric
Design
Order
Management
Logistics
Finite Element
Design
3D Modeling
Procurement
Shop Floor
Scheduling
Integrated
Financials
Materials
Management
PDM
Parts
Classification
Configuration
Management
Project
Management
2D Drawing
Workflow
Processes
Vaulting
Electronic Document
Management
Figure 5 – Logical Connectivity of the Components of the IT Solution
By drawing circles, boxes, stacks or other regularized pictures of the system architecture the implication is
that the underlying system is represented by these topologies like the logical connectivity in. The physical
connectivity of the system is described in Figure 6. This organization can be viewed as a representation
of the physical architecture, rather than the actual architecture. In practice, the architecture of the system
represents the connectivity of the various software and data components. The infrastructure of the system
is present in the operating systems, database managers, middleware and other supporting components
described in Figure 6. The components of the system architecture are then held together by these
supporting components through an assemblage of cooperating processes. In order to provide the abilities
of the future, the actual connections between these supporting components, the data being managed and
the applications participating in the system is formed through the federation of the data and applications.
In other words there is no permanent connectivity between each element, only the binding of the data,
applications and infrastructure to form the system during runtime.

21. IT Strategy
These bindings will be provided through the federation of the participating components (§XX). This
approach allows systems to be interconnected without the detailed integration activities usually
associated with tightly coupled architectures.
[15]
Network
Software and Hardware
Server Hardware
Network Operating System
Server Operating System
Middleware
File Management
Database Management
Microsoft
applications
environment
CORBA
COM/DCOM,
NFS, and SQL
Connections
HP–UX
NT
MVS/VM
HP
Intel
System/390
TCP / IP
SNA
IPX
Application Software
User Interface
Workstation ApplicationWindows 3.1
Windows 95
Windows NT
X–Windows
Oracle
DB/2
Kimball Standards Layers of the System Logical Components
TCP/IP
Socket connections
are standards here
IP Addressable
Devices are used
here
TCP/IP based
networks are
standard
Figure 6 – Physical and logical layering
This physical layering approach assumes that a layered approach is implemented. In this approach, the
layers can be distinguished through their interlayer interfaces. Although this approach is descriptive in its
simplest form, the actual organization of a distributed processing system may take on many forms which
have no resemblance of the layered structures. §5 presents the details of the possible logical and
physical organizations, which are available in the current strategy.
The components in Figure 6 consist of:
ü Network software and hardware – these components provide the physical and logical connectivity
between processors on the network. Within the network layers are other layers of protocols which
provide the connectivity management, transport and monitoring of messages carried by the physical
network system
15
The concept of federating an information processing system has many dimensions. The federating of
the databases, to allow cross–database queries was the first development in the technology of federation.
In the current system environment, federation is the technology is loosely coupling, autonomous systems
that agree to share data and services. This approach is intended to enable cooperative relationships and
processing among system components, while preserving the local autonomy. The details of the federation
architecture are developed in §Error! Reference source not found..

22. IT Strategy
ü Server hardware – the hardware for each server in the distributed system is the host for the operating
system, file management and database management systems. In many cases, application software
executes on the server.
ü Network operating system and server operating system – in order for the individual servers to
collaborate, the server operating system and the networking facilitates must be integrated in a
seamless manner. The management of shared facilities is the responsibility of these two operating
system components.
ü File management and database management system – the server provides storage facilities for
information in the distributed environment. Flat files and database tables are managed by applications
that are components of the operating system as well as applications running on the server.
ü Middleware – the assembly of objects, their use and management is provided by the middleware
components. These middleware components provide a variety of services. In some cases application
logic is placed at this level. The Logia constraints algorithm could be an example of an application
that could run independently of its user interface.
ü Application software – server applications that make use of these objects may execute on the server.
These applications are native processes making use of the operating system facilities as well as the
network resources provided by the middleware and the network operating system.
ü User interface and workstation application – the workstations that interact with the user provide user
interface applications and possibly applications components. The connectivity between the
workstation applications and the server applications can take many forms. All of these forms
however, make use of the middleware protocols, network protocols and the underlying operating
system components.
Figure 7 represents the application view of the various system components. This view is provided through
the NIST (National Institutes of Science and Technology, Boulder, Colorado).
[16]
The portability and
interoperability aspects of this view are more important than the details of the various layers.
Application Software
User Interface Communication InterfaceInformation Interchange Internal System
Operating
System
Graphics
Facilities
Network
Facilities
Data
Interchange
Data
Management
ProgramUser Interface
Security Services / System Management Services
Hardware / Software Platform
Human User Other Application PlatformsExternal Data Storage
Platform External Environment
API
Application
Platform
External
Environment
Interface
Figure 7 – Application Portability Profile (NIST)
16
Application Portability Profile (APP) The U.S. Government's Open System Environment Profile OSE/1
Version 2.0., G. Fisher. NIST Special Publication 500–187. National Institute of Standards and
Technology, Boulder, Colorado, June 1993.
Department of Defense Technical Architecture Framework for Information Management, Volume 1 – 8,
Version 3.0, 30 April 1996.

23. IT Strategy
A profile is a collection of specifications developed to meet a set of requirements. Elements of a profile
may consist of formal standards, i.e., those developed within a voluntary standards organization such as
ANSI or IEEE, or de facto standards, i.e., those accepted within the marketplace. Each element of a
profile may be a specification in its entirety or a specification with certain options or parameters chosen.
The NIST Application Portability Profile (APP) was developed by NIST to meet the requirements of
Federal Agencies for an Open System Environment (OSE). A Federal Agency uses the NIST APP to
develop profiles specific to its individual requirements. The NIST APP is organized into several service
areas, which reflect the breath of services needed by an OSE application.
These service areas are:
ü Operating System Services – those services providing basic manipulation of a system's fundamental
resources such as processes and files.
ü User Interface Services – those services providing for the interactions between the end user and the
system such as window management and multimedia access.
ü Programming Services – those services supporting the application programmer such as programming
languages and software development tools.
ü Data Management Services – those services providing for the definition and manipulation of data
such as schema definition and query languages.
ü Data Interchange Services – those services which provide common representations for the exchange
of data between systems such as document formats and display representations.
ü Graphics Services – those services providing for the creation and manipulation of displayed
multidimensional images.
ü Network Services – those services providing interoperability among systems such as communication
protocols.
• MAPPING THE SYSTEM COMPONENTS TO THE BUSINESS ENVIRONMENT
Figure 8 describes the first–level mapping of the applications to the DEF Group business environments.
This figure shows the depth of the penetration of the applications for each application component.
Although this map is representative of the application’s deployment across the various structures of the
business, there are several dimension that are not shown:
ü The temporal nature of the data and applications. As the data moves through its lifecycle, its locality
may change. Defining and documenting this movement of data and process focus through time is one
of the most difficult aspects of the system model. One approach to modeling these behaviors – as
well as actually controlling them – is through a working modeling tool. The results of this tool can then
be deployed as executable workflows in the production environment.
ü The infrastructure components are deployed across the highest levels of the enterprise. Their use
how ever is localized, since they are supporting activities within a specific Commodity, Business Unit,
or Plant activity. In the distributed computing model, the locality of an application is not well defined.
Processes and the data they manage can be moved within the computing environment without regard
to their logical usage or temporal sequencing.
ü The physical location of data and applications is not described in any of these figures. The proposed
system will be distributed in the sense that application processing and data storage need no be
centralized for the architecture to function properly.

24. IT Strategy
Group
Plant
Business
Unit
Commodity
SubGroup
Group
Plant
Business
Unit
Commodity
SubGroup
Enterprise Resource Planning
IntergatedFinancials
ShopFloor
Scheduling
Procurement
OrderManagement
Logistics
Materials
Management
WorkFlow
Vaulting
ElectronicDocument
Management
Infrastructure Product Data Management
PartsClassification
Configuration
Management
2DDrawing
ProjectManagment
CAD
3DModels
FiniteElement
Modeling
ParametricModeling
andDesign
Figure 8 – Mapping the Components to the Business Environment
• THE CURRENT IT ENVIRONMENT
The original concept of a Data Manager – which consolidates all the DEF Group data in one place,
manages this data and provides the data to current and new applications – has been further refined over
the past months. Developing the DEF Group process and data models highlighted the fact that there is a
common set of data flowing throughout each business unit.
There are several issues that must be understood before proceeding with the IT Strategy for deploying
the Data Manager:
ü The dominant paradigm in the DEF Group software systems is a legacy data housed within Copics
and its associated applications. In principal, the information in Copics provides a view of the work
processes in place at ABC. As XX shows however, there are other applications used to augment the
capabilities of Copics. In some cases, the connectivity between Copics and these applications is well
defined architecturally.
[17]
In other cases, the applications are poorly architected. This lack of
architectural soundness is not caused by the lack of skills of the software developers or the system
integrators. It is caused by the lack of an overall architectural vision of the system. Without such a
vision, the construction of the system proceeds along tactical lines to meet the needs of the
immediate problem. The resulting collection of software components may or may not meet the
strategic needs of DEF Group. The old adage – If you don’t know the destination, any road will take
you there – is the primary example of this approach.
ü As DEF Group moves toward a new organizational paradigm – consolidated operations, more flexible
manufacturing sites, commonality of components and designs, reuse of design models, massive
customization of products – the underlying systems must be capable of supporting this paradigm.
One of the largest challenges to DEF Group is how to build an effective manufacturing system, while
maintaining its decentralized business model.
17
In this document and other planning documents, the concept of architecture is the primary focus. This
does not mean that design and other development and deployment activities are not critical success
factors. Architecture though is the foundation of all of these activities. Without an architecture the
remaining activities will proceed without a sound foundation.

25. IT Strategy
ü The system currently in place is considered Legacy, since the information it holds and manages is
resistant to modification and evolution. There are several sources of this resistance:
v The applications are large monolithic pieces of code, usually written in COBOL. In principal this is
not a problem, except that the COBOL environment does not support direct integration with other
systems. It assumes that the application software owns the machine environment and operates in
a non–collaborative manner, which is counter to the current system design and development
methodologies. In the majority of applications, the COBOL paradigm embeds the management of
the data within the code.
v The management of this data includes transformations of the syntax and semantics during
runtime. This programming method was popular at the time these systems were built. It is now
understood that this approach creates hidden data structures and hidden semantics. Discovering
the meaning of the data requires understanding the COBOL application’s use of the data.
v They are built around legacy databases (IMS)
[18]
– since the data created and managed by the
legacy system is tightly coupled to the application software, it cannot be accessed, used or
modified without the application being active. This creates an autonomous set of applications,
whose data is trapped within their application environment.
v To complicate matters even more, these applications are Mission Critical. They are essential to
DEF Group’s daily operations. Without their proper operation the business of manufacturing
furniture could not take place.
ü Although the classic legacy system is mainframe based, this paradigm is also applicable to other
applications in use within DEF Group. The CS&S Logia application is one such example. Coupled to
Copics and other applications, through a file transfer mechanism, the information created and
managed by Logia is not available outside the Logia boundaries – it is trapped within Logia, just as
the Copics information is trapped.
• MOVING FORWARD
The scope of the Data Management project is (as stated in the Needs Analysis):
The project will provide a data and process model for the existing
business processes. This information will be used to analyze the
alternative architectures of the Future State. These architecture
alternatives will be based on the specific needs of DEF Group and its
commitment to meet the Critical Success Factor.
Data management in a distributed environment is different from managing data in a legacy environment.
The application logic, data manipulation logic (process–based), and the data associated with the
metadata are implemented as separate resources, logically connected by a distributed computing
architecture. The monolithic legacy code is decomposed into manageable chucks of identifiable physical
entities. Each entity is mapped to a relevant business process. The business processes in turn support a
macro and micro process transformation. The quality improvements are manifested in the appropriate
computing applications. This holistic approach is necessary for the legacy transition process to be
successful.
Within this scope, there are several activities directly supporting this approach:
ü Define data and processes, which form the basis for ABC’s business units.
ü Extract the Core business functions using this process and data information.
18
Although this may first been seen as a critical problem, there are technical solutions to accessing and
migrating the IMS data. Object wrappers are now available which allows IMS resident data to be
expressed through the OMG object interface. The IBM product that supports the wrapping of IMS
databases with an Object Oriented paradigm is the IMS Object Connector.

26. IT Strategy
ü Create an integrated system architecture, which includes the business processes – Develop
Products, Take Orders, Plan Production, Produce Products, Deliver Products, Service Customers,
and Collect and Disperse Funds.
There are two (2) approaches to moving forward within the project scope:
[19]
ü The Cold Turkey Approach in which the legacy systems are replaced in–kind with the new systems.
There are many impediments to this approach:
v A better system must be promised – the current user base expects that the replacement system
will perform significantly better, since the effort necessary to deploy the new system needs to be
paid back many times over.
v Business conditions never stand still – the new system must be capable of evolving with the
changing business conditions. As time moves on, the requirements themselves change. Changes
in the deployed system must be capable of keeping up.
v Specifications rarely exist for the current system – by definition, the legacy system is poorly
documented.
v Undocumented dependencies frequently exist in the current system – over time, the legacy
system has become customized to meet the previous tactical requirements.
v Legacy systems are usually too big to be simply cut over from old to new – millions of database
entities and hundreds of mainframe applications are tightly coupled to form the legacy system.
This complexity becomes a serious burden simply to understand.
v Management of large projects is difficult and risky – all the problems associated with managing
large projects are present.
v Lateness is rarely tolerated – since the legacy system is mission critical, any delays become
exaggerated.
v Large projects tend to become bloated with new and unjustified features – once the system is
opened to migration, all sorts of new features will be required.
v Homeostasis is prevalent.
[20]
v Analysis paralysis sets in – with all the issues stated above, the analysis activities become
bogged down in details.
ü The Chicken Little approach in which the system components are incrementally migrated in place
until the desired long–term objectives have been reached.
Rome was not built in a day – neither will DEF Group’s next generation business systems.
The attributes of the Chicken Little approach are:
v Controllable – since the scope of each incremental effort can be managed within the overall
architecture of the system vision. The failure of one step in the process does not affect the
proceeding deployments. In principle, the failure of one step would also not affect future steps.
Once the failed step has been corrected, the project would proceed as planned.
v Only one step fails – there is no Big Bang approach, with an all or nothing result
v Incremental, over time – effort, budgets, human resources can be incrementally deployed.
v Conservatively optimistic – success is always in hand with incremental benefits paving the way.
19
The concepts of Cold Turkey and Chicken Little are taken from a seminal book Migrating Legacy
Systems, M. L. Brodie and M. Stonebraker, Morgan Kaufmann, 1995. This book is a detailed account of
the legacy system migration efforts at GTE Telephone Operations. Over a four year period 80%of GTE’s
business applications, supporting 10,000 workstations, were moved from legacy mainframe applications
to client / server platforms. This book should be required reading for all MRT members.
20
ho•me•sta•sis n.1. the tendency of a system to maintain internal stability owing to the coordinated
response of its parts to any situation or stimulus tending to disturb its normal condition or function. 2. A
state of psychological equilibrium obtained when tension or a drive has been reduced or eliminated.

27. IT Strategy
• Sequencing the System Deployment
Now that the incremental development process is understood, the major system components and their
phasing in a project present several challenges:
ü Which components should be deployed in what sequence?
ü How can short term benefits be accrued while maintaining the strategic focus?
ü How can the appropriate sequence of system deployment be determined?
ü What are the alternatives to the roll out plan if:
v The business units remain in the same organizational structure as they are today. That is, the
business units maintain the status quo. In this case the focus may be on capturing the design
data and preparing for the deployment of PDM.
v The business units undergo a reengineering effort to take advantage of flexible manufacturing
technologies. In this case, the focus maybe on organizing the data for use by the ERP system.
The analysis of these alternatives and many others needs to be done with the direction setting
actions of the IT Steering Committee. At this point there is no firm business direction in place, so the
IT Strategy will assume that design information will be captured and made ready for a PDM system
Each of the above questions has a multitude of answers. Each answer has a multitude of consequences.
Determining and evaluating these consequences is the role of the System Architect, Project Manager and
DEF Group Executives.
Figure 10 describes the major system components, the major data elements and the functional
components. This description is not an accurate representation of the actual system components nor is it
inclusive of the data and processing steps. It is meant to be a carton of the proposed system used to
illustrate the options for sequencing of the system rollout.
Option Description
PDM Focused
Deployment
ü Organize the information produced by I–DEAS in a repository. Place this
information is a PDM–Like system for management, distribution and control. It may
not be necessary to have an actual PDM system for this application. ERP systems
have PDM components that may be applicable for the DEF Group requirements.
ü Capturing this information provides control and management, within the Design
processes. The data produced by I–DEAS consists of product structure, parts
descriptions and assembly information. The organization of this data is relatively
straightforward compared to the data typically managed within PDM systems.
ü Additional functionality can be rolled out, including Component and Supplier
Management (CSM)
[21]
to deal with any gaps in the PDM capabilities. This
approach starts down the road of a best of breed, since the PDM system may not
provide all the features needed to manage the production of OFG products.
EDM Focused
Deployment
ü Locate the high payback document opportunities and deploy an Electronic
Document Management System.
ü The EDMS would capture the documents in a repository that would be shared by
all follow on applications.
ü The architecture of the EDMS would follow the overall system architecture. This
would allow the EDMS to be integrated with PDM and ERP.
ü The high value documents would be placed in the EDMS. These documents are
currently generated through existing publications systems, either manually or
automatically. They are not duplicated in any other system today, therefore their
management adds direct value to DEF Group.
ü Deploying the EDMS does not prevent the concurrent deployment of PDM or ERP.
21
The concept of Component and Supplier Management includes Parts Classification applications.
Simply having the Parts Classification software does not move DEF Group forward. The supply chain
management components provide control of product cost in ways Parts Classification alone can not.

28. IT Strategy
Option Description
PDM Assembled
from Best of Breed
Components
ü Organize the information produced by I–DEAS in a repository as above.
ü Deploy Best of Breed components, which may include components form the
available ERP system suite.
ü Migrate these components into an integrated system. This migration process will
follow the deployment phases of the ERP system.
ERP Components
rolled out across
the organization in
a series of
functional steps.
ü Locate the PDM components within the candidate ERP systems. Deploy these
components to provide a bridge PDM system.
ü As the components mature or as the PDM Best of Breed components are
integrated into the ERP system, the capabilities of the PDM system will also mature.
The infrastructure components, EDM. Workflow, Vaulting, can be integrated with the
ERP system as it rolls out across the enterprise.
ü This approach does not prevent the concurrent deployment of the EDMS
applications, Workflow and vaulting. In fact, separating the EDM functions from ERP
and PDM provides a broader spectrum of solutions, since the resulting EDMS is
actually infrastructure, where the EDMS embedded in ERP and PDM are application
specific implementations.
Figure 9 – Alternative Deployment Strategies
Each of these approaches makes the following assumptions regarding the project costs and benefits:
ü The project will be deployed incrementally, so that the benefits of the project are always available at
the conclusion of each logical step.
ü The projects will be deployed in a self–sustaining manner, so the benefits are bookable toward to
investment expenses.
ü The selection of target business areas and the supporting applications will consider immediate
payback as the highest priority. Although infrastructure projects will be components of the IT Strategy,
the immediate payback projects must be considered as the funding source for projects that have less
immediate returns.
• Parallel Deployment Strategies
Figure 10 describes the major components that will participate in the alternatives analysis. By isolating
the decision participants, some understanding of the tradeoffs can be gained.
For example:
ü The capture and management of Product Data is an essential component to the overall IT Strategy
(and is the primary goal of the Data Management Project). However, the road map to managing all
the data elements, including documents, needs to be laid out carefully. Many vendors provide
facilities within their products to deal with peripheral requirements. Document management is one of
those peripheral facilities. The Needs Analysis describes how document management is addressed in
PDM systems and how the needs of a document management system are not fully met by such an
approach.
ü The management of specific object classes – documents, design data, parts data, manufacturing
processes, reporting information, decision support information – should be seen as a generic
architecture issue. What applications software and what vendor is appropriate to use in managing
these objects, is not a question that needs to be asked early in the process. Without a clear
understanding of the business processes, the business case analysis and the overall architecture of
the system, deploying point solutions will simply replicate the past legacy approach to information
systems.
ü The documents to be managed by the EDMS are present in the business processes today. Their
management is not an option. The tools for managing them range from crude to sophisticated. The

29. IT Strategy
real question is not what tools should be used, but what documents should be managed to provide
the highest pay back for DEF Group?
SDRC
I–DEAS
Team Data
Manager
Design
Information
Product
Management
Shop Floor
Data
Management
Manufacturing
Financials
Corporate
Financials
Product
Data
Financial
Data
Manufacturing
Data
Product
Modeling
Product
Organization
Component
Supplier
ManagementElectronic
Document
Management
Product
Configuration
Management
Product
Cost Analysis
CAD
PDM
ERP
Business Unit
Financials
Figure 10 – High–Level relationships between the three major components.
• MOTIVATIONS FOR A NEW PARADIGM
There are several motivations for this new paradigm of deploying systems using this incremental
approach:
ü Business – the use of software in the process of innovation in the business context provides the
mechanisms for expansion. The presence of the new system drives the business processes.
v Software provides the central vehicle, which enables a strategic approach to innovation. By
incrementally deploying the software component, the business processes can be migrated as
well.
v Many manual steps can be shifted to software which can dramatically lower innovation costs,
decrease product development risks, shorten design and introduction cycle times, and increase
the values of innovation to the customer base. By making these transitions incrementally, the
disruption to the ongoing business processes can be minimized.

30. IT Strategy
ü Technical – interacting subsystems, rather than mega–systems, can be deployed. End–to–end
integration is difficult to accomplish in the current centralized system architecture. These critical
subsystems, database, engines and user interfaces must adopt the following attributes:
v Using interface integration standards (integration on the glass) allows each subsystem to be free
to contribute as quickly as possible, allowing incremental implementation and interactive learning,
and avoiding long costly development cycles.
v Successful developments are based on software, which insulates users from the complex rules
and sophisticated methodologies of its internal operation. By incrementally deploying the software
components, this complexity can be absorbed into the organization with minimal impact to the
ongoing processes.
v Effective architecture provides systems interfaces, which match up stream and down stream
systems. This is not the same as integration, but is a coupled architecture in which data is moved
between systems in a controlled manner.
ü Operational – by unifying the underlying data management resources, a single view of DEF Group’s
operational information can be provided. Today the Create, Read, Update and Delete (CRUD)
aspects of the data have no consistent architecture. By managing each process with the CRUD cycle,
consistency, reliability and trustworthiness can be achieved. The incremental migration of the data
provides a means to prove out the processes before moving to the next stage.
ü Personnel – in the current environment, users and suppliers of information systems are engaged in a
process of vertical integration – whatever is needed for the immediate task at hand is provided
through the localized system.
[22]
This paradigm will be changed to one of the delivery of strategic
system, to support the strategic business processes using an incremental deployment approach.
• ALIGNING THE BUSINESS NEEDS AND DEF GROUP CORE COMPETENCIES
The challenge faced by DEF Group and the Manufacturing Resource Team (MRT) is how to align the IT
Strategy with the Business Strategy. The current IT Strategy document does not attempt to layout the
details of this alignment. Since the DEF Group business plans are an integral component of this analysis
and are not currently available in a form compatible with the IT Strategy, the completion of the Business
Strategy / IT Strategy alignment is an unassigned activity.
In the absence of a completed Business Strategy, the methodology for aligning the two goals (IT and
Business) will be provided below. This strategy is based on developing Core Competencies within the
MRT to match the requirements of the DEF Group Business Strategy.
Using the definition of core competency from
[23]
, the definition for DEF Group could be:
A Core Competency is the collective know–how of an organization that gives it a
competitive advantage. This know–how is a result of learnings that are driven by the
business strategy and built through a process of continuous improvement and
enhancement that may take a decade or longer.
The process of explicitly identifying existing and desired core competencies should become an integral
part of the DEF Group strategic and tactical planning processes. By thinking about needs strategically, it
is easier for managers to directly tie technology and system improvement objectives to the business
22
Although there are enterprise–wide systems in place, there are used in a localized manner.
23
The term competency describes the skills, resources, and infrastructure necessary to support the
matching Business Strategy elements. The following references provide the starting point for this concept.
“The Core Competence of the Corporation,” C. Prahalad and G. Hamel, Harvard Business Review,
May/June, 1990, pp. 79–91.
“Core Skills: Doing the Right Things Right,” R. Irvin and E. Michaels, McKinsey Quarterly, Summer 1989,
pp. 4–19.
“Analysis of Strategy Formulation and Implementation at Hewlett–Packard,” R. Feurer, K. Chaharbaghi
and J. Wargin, Management Decision, Volume 33, Number 10, 1995, pp. 4–16.

31. IT Strategy
needs. Such objectives are compelling and are more likely to sustain management commitment than
ones justified solely on some methodology or technology that is poorly understood by the decision
makers.
Figure 11 is a model of how the business strategies and the core competency strategies operate in
parallel. The figure’s left side focuses on the business strategy. The right side focuses on the core
competencies required to achieve the business strategies.
The message here is:
Core Technology Competency planning is just as important as business planning in
setting the long–term strategy of an organization.
[24]
Business
Objectives
Core
Competencies
Vision
Strategy
Software Core
Competence for the
Target Business Units
Elements of the
Software Core
Competence
Strategy
Plans,
Measurable Objectives,
Progress
Exceptional
Product & Services
Produced
using Superior Know–How
Plans,
Measurable Objectives,
Progress
Focus On:
ü Markets
ü Business Impacts
ü Opportunities
Focus On:
ü Processes
ü Skills
ü Technologies
ü Know–How
Figure 11 – Relationship between Business Strategy and Core Competency Strategy
24
Although the introduction to this section spoke against the popular use of core competencies, they are
used here as a strategic positioning tool. Be defining which core competencies are needed to match the
Strategic Business Objectives, DEF Group can position itself for success, using IT as the enabling
technology.

32. IT Strategy
The essential results of the Core Technology Competency planning processes are a set of clearly stated
goals and action plans with clear links to business needs. More than any other method or process, the
DEF Group management team must provide this input.
Figure 12 is a high level overview of the relationships between the business and core competency plans.
In order to achieve the desired results when merging the Business and Core Competency Plans, the
Management Leadership of DEF Group must participate in a pre–planning session which:
ü The top management of DEF Group must be enlisted to take ownership of the Business Plan. They
must stay closely involved to provide the leadership and consistency for the long–term business
vision. This ensures that the critical processes, skills, and technologies survive and evolve despite
future organizational growth and change.
ü Provides a clear set of objectives for planning, including key process skills and know–how. These
objectives include statements of work and due dates and expected and measurable results.
ü Agrees on the scope of the planning activities. This includes both the length of the expected planning
document (expected level of detail), the amount of time it should take to create the planning
document, and the expected contents of the document. This effort should be allowed the proper time.
The planning process is a creative endeavor and “being creative on demand” is difficult. This planning
process should be done before the yearly financial planning cycle. If this plan is created
simultaneously with the financial targeting it will be difficult to get the attention of the decision–
makers.
The Core Competency Plan provides a powerful management tool that allows the DEF Group Executive
Steering Team and the Manufacturing Resource team to look into the future in four essential ways:
ü It spells out the strategic collective know–how that is key to DEF Group’s evolution.
ü It explicitly evaluates the strategic competitive advantages based on the know–how of the team
members.
ü It defines how DEF Group’s know–how is linked to the Business Plan.
ü It provides a compelling basis for long–term, continuous process improvement.

33. IT Strategy
Business Plan Core Competence Plan
1. Statement of Purpose 1. Take Vision from Business
Plan
2. Specific objectives to achieve
over of five year time period
2. Identify core competencies
necessary to fulfill long term
business vision
3. Description of customers and
channels of distribution for
products, materials and
services used by DEF Group
3. Identify core competency
elements
4. Description of the
competitors similar
environment, or some form of
benchmarking to establish
the visionary goal
4. Identify key processes and
one pivotal job
5. Description of the necessary
products and services
needed to compete in the
market place
5. Evaluate strengths and
weaknesses of solution
components compared to the
competition and the to desired
competencies.
6. Plan for development or
purchase and introduction of
products and services
6. Target areas for short term
and long term improvement
based on organizational
readiness, urgency,. And
business advantage.
7. Financial analysis of costs
and returns
7. State improvement objectives
to be achieved over a five
year period
8. Potential problem analysis 8. Summarize resources
requirements
9. Recommendations 9. Create the First Year plan
10. First Year tactical plan
Figure 12 – Relationships between Business and Core Competency Plans
§ Error! Reference source not found. describes the details of developing the Core Competencies
needed to support the DEF Group business goals. The primary difference between Business and Core
Competency planning is one of focus. The Core Competency plan focuses on processes, skills, and
technology. The Business plan focuses on products and markets. The central theme of both derives from
the business vision, purpose, and direction of DEF Group.
• STRUCTURE OF THE IT STRATEGY
This document contains the Information Technology (IT) Strategy for the DEF Group Data Management
Project. The IT Strategy is organized in layers, each progressively more detailed.
This IT Strategy document:
ü Provides a road map for planning of DEF Group’s software systems, related to Data Management.
This includes:

34. IT Strategy
v Electronic Document Management – business needs have been identified for managing high
value documents within DEF Group. A Business Case Analysis (BCA) has been developed which
describes the detailed cost and benefits of this activity.
v Product Data Management – the management of product related data generated within the
SDRC I–DEAS system has been identified as a target activity. This effort will consolidate in a
single location the information generated from product models as well as other product related
information.
v Migration from the current MRP (Copics) system to a future ERP system – the connection of
product related data with manufacturing data with a next generation ERP system is a major
undertaking. This document defines some of the architectural and data management issues
associated with interconnecting the ERP system with the Data Management system
v Infrastructure components of each of these software subsystems – each of these system
components will depend on a computing infrastructure. Some of this infrastructure is in place,
some will need to be deployed in the future. This infrastructure also includes personnel, business
organizational changes, training, maintenance and operational activities.
ü Defines the vocabulary and strategy processes in use in a prototypical IT organization – a vocabulary
for describing the architectural alternatives is presented. A specific methodology for migrating from
the current application–centric environment to a data–centric environment is presented.
ü Defines the architectural options for DEF Group – alternative architectures for deploying a data–
centric manufacturing systems are presented. These include both Logical and Physical architecture
alternatives.
ü Suggests the architecture for the various system components using the current process and data
models.
What the IT Strategy is not:
ü It is not a shopping list for software components. The detailed requirements for the system
components need to be developed for each subsystem. These requirements will evolve from the
business process requirements as they are discovered within the business units.
ü It is not a software project plan for developing and deploying the system components. The actual
software project plans for the various system components will be developed once the vendor for the
component has been identified.
ü It is not the actual data and process models for the deployable system. The current data and process
models are representative of the data and processes in use within DEF Group. The actual data
entities and the business processes will be defined during the System Requirements and Technical
System Design phases of each system component (EDM, PDM, ERP).
[25]
The data and process
models developed to date are critical information used in the Business Case Analysis and
architectural evaluations. Several more levels of detail are needed however before an actual
Technical System Design can be produced which defines each step in the deployment of the final
system.
25
These are defined phases of Niwot Ridge methodology

35. IT Strategy
• A WORD TO THE READER
This IT Strategy is provided as a road map to the real IT Strategy.
ü Actual plans need to be developed for the rollout of each system component, once the System
Requirements Analysis and Technical System Design are complete.
ü Business drivers must be used to motivate the deployment of each system component using a
Business Case Analysis during each deployment cycle.
ü Business processes must be adapted to the COTS paradigm.
ü Strategy is critical, but so is tactical deployment. All aspects, levels, and activities are critical – all the
easy problems have been solved, only the hard ones are left.
The following is a reading guide to the remaining sections of the IT Strategy.
§AA – lays the groundwork for transitioning from the legacy environment to the next generation
environment. It is assumed that this next generation environment will be a client / sever
architecture. This assumption is not stated explicitly (or at least not explicitly enough), but in fact
the technological alternatives are client / server based applications. This section focused on the
alternative architectures of the system. There are many to choose from. Choosing the appropriate
ones is the primary issue in architecture. The selection of an appropriate architecture cannot be
done in a vacuum. The requirements for the system, the existing systems and the available
systems need to be incorporated into the analysis.
The key elements for this section are the approach to federating the existing data resources in an
architecture that includes legacy data and data produced with the next generation applications.
Since the big bang approach is not considered, the legacy data must be integrated in some form
with the newer components.
§BB – defines the framework for the strategy. This framework actually works for any strategy. A detailed
set of steps is provided that allows the MRT to walk through the process of developing the IT
Strategy at the deployment level of detail.
§CC – defines the methods to be used in mapping the business requirements to the system architecture.
The abstraction of the business processes is presented as the starting point. The detailed design
of the system cannot proceed without an understanding of what the components are and how they
will go together.
§DD – defines the strategies to be used in managing the data elements, which exist in DEF Group.
§EE – defines the strategies for deploying Commercial Off The Shelf software.
§FF – defines the Technical Infrastructure strategies. These include the networking, workstation and
server issues.
§GG – defines the changes that are recommended to the MRT organization in order to meet the
demands of the next generation system.

36. IT Strategy
• ACTION ITEMS FOR THIS SECTION
ü Define the Scope of the various applications across the business units – §1.5 defines the target
business units and §1.7 defines the application set. Mapping each application to the level of business
unit will define the scope of deployment. Without this mapping, there will also be confusion about
were the applications should be deployed. The consistency and uniformity benefits for the business
processes and the related savings for the deployment and support costs will not be bookable if this
strategy is not defined.
ü Reconcile the Business Strategy with the IT Strategy – §1.12 defines the approach to mapping the
Business Strategy to the IT Strategy. A concise Business Strategy is needed. This strategy will then
be used to outline to supporting IT Strategies. Both strategies are necessary. In the absence of either
one, the one strategy has no mechanism by which it can be deployed, measured or validated.