Strategic Management of Information Systems Fifth Edition Information Systems Strategy: Architecture...

Strategic Management of Information SystemsFifth Edition

Information Systems Strategy: Architecture and Infrastructure

Keri Pearlson and Carol Saunders

Chapter 6

PowerPoint® files by Michelle M. RamimHuizenga School of Business and Entrepreneurship

Nova Southeastern University(c) 2013 John Wiley & Sons, Inc.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

(c) 2013 John Wiley & Sons, Inc. 6-2

Learning Objectives

• Understand how strategy drives architecture, which then

drives infrastructure.

• Identify and define the three configurations for IT architecture.

• Define how business goals can be translated into IT

architecture and then into infrastructure.

• Know the different types of frameworks used to design and

build the IT architecture and infrastructure.

• Understand the importance of knowing the details of the

existing architecture and infrastructure of the organization.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Real World Examples

• Over the past 10 years Valero Energy (gas/oil refiner) has

experienced hypergrowth.

• Revenue has grown from $29 to $90 billion.

• This growth came with a mixture of disparate IT systems and

applications.

• Difficult and expensive to manage.

• Not easily integrated into ERP system.

• IT architecture needed to be redesigned to meet future needs.

• Flexible in design and able to grow with the company.

• An SOA system was selected: SAP R/3 ERP.

• 90 service components were built on the SAP platform.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Real World Examples (Cont.)

• The results were dramatic.

• New applications made operations more efficient and effective.

• Development costs were kept low.

• One application saved the company $500K in fees.

• The new application provides visibility to the tankers.

• Communications with employees reduced scheduling conflicts.

• Managers were able to control the loading and unloading of

tankers, which was previously unavailable.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


From Vision to Implementation

• Architecture translates strategy into infrastructure

(Figure 6.1).

• The architect develops plans based on a vision of how the

customer will use the system (or in the example a house),

which is a blueprint of the company’s systems.

• This IT architecture “blueprint” is used for translating

business strategy into a plan for IS.

• The IT infrastructure is everything that supports the flow

and processing of information (e.g., hardware, software, data,

and networks).

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Figure 6.1 From abstract to concrete – building vs. IT.

Abstract Concrete

Owner’sVision

Architect’sPlans

Builder’sImplementation

Strategy Architecture Infrastructure

InformationTechnology

Building

© John Wiley & Sons

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


The Manager’s Role

• The manager’s role is to:o Understand what to expect from IT architecture and

infrastructure to make full and realistic use of them.

o Effectively communicate the business vision to IT architects

and implementers.

o Modify the plans if IT cannot realistically support them.

o Be involved in the decision-making process.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


From Strategy to Architecture

• The manager must start out with a strategy.

o Use the strategy to develop more specific goals (Figure 6.2).

• Business requirements for each goal must be fleshed out in order to

provide the architect with a clear picture of what IS must accomplish.

• The manager must work with the IT architect.o Translate the business requirements into a more detailed view of the systems

requirements, standards, and processes.

• The architectural requirements include considerations such as:o Data demands, process demands, and security objectives.

• The IT architect takes the architectural requirements and designs the IT

architecture.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


From Architecture to Infrastructure

• This stage entails adding more detail to the architectural plan

such as:o specifying hardware, data, networking, and software(Figure 6.2).

• Decisions are made about how to implement these specifications:

o What hardware, software, storage, interface, network, etc. to use

in the infrastructure.

• Components must be assembled in a coherent pattern according to

the blueprint in order to have a viable infrastructure.

• Infrastructure has several levels:

o Global level

o Interorganizational level

o Application-level

• Infrastructure also refers to the platform.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Figure 6.2 From strategy to business requirements.


Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


A Framework for the Translation

• The framework for transforming business strategy into

architecture and then into infrastructure should consider

basic components (Figure 1.8):o Hardware – physical components.

o Software – programs.

o Network – software and hardware.

o Data – numbers and text.

• Understanding the technology behind each component of

the infrastructure and the technical requirements of the

architecture is a much more complex task.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-12

Figure 6.3 Infrastructure and architecture analysis framework with sample questions.

(c) 2013 John Wiley & Sons, Inc.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


A Framework for Translation (Cont.)

• Managers must begin with an overview that is complete and

delivers a big picture.o Figure 6.3 entails questions that typify those asked in addressing

architecture and infrastructure issues associated with each component.

• The framework asks three types of questions that must be

answered for each infrastructure component:o What is the specific type of technology?

o Who is involved (individuals, groups, departments)?

o Where is everything located?

• Figure 6.3 shows the connections between the business strategy

and the infrastructure.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Common IT Architecture Configurations

• Three common configurations of IT architecture (Figure

6.4).

o Centralized architecture: everything is purchased,

supported, and managed centrally via a data center.o A large data center with a mainframe and a number of legacy

mainframe environments.o Many computers are linked together to form a centralized IT core

that operates very much like the mainframe, providing the bulk of IT services necessary for the business.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Common IT Architecture Configurations (Cont.) • Decentralized architecture arranges the hardware, software,

networking, and data in a way that distributes the processing and

functionality between multiple small computers, servers, and

devices.o Relies heavily on a network to connect them.

o Utilizes numerous servers located in different physical locations.

o A server-based architecture.

• Service-oriented Architecture (SOA) utilizes relatively small

chunks of functionality available for many applications or reuse.o Useful for building applications quickly.

o Offers managers a modular and componentized design that is easily

modifiable.

o SOA utilizes software-as-a-service (SaaS) or Web services.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-16

Figure 6.4 Common architectures.

(c) 2013 John Wiley & Sons, Inc. © John Wiley & Sons

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Centralized Versus Decentralized Architectures

• A manager must be aware of the trade-offs when considering

centralized versus decentralized architectures.

o Decentralized architectures are more modular than

centralized architectures.

o Additional servers can be added with relative ease and

provide greater flexibility for adding clients with specific

functionality for specific users.

o Decentralized organizational governance, such as that

associated with the networked organization structure, is

consistent with decentralized architectures.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-18

Additional Infrastructures

• Peer-to-peer – allows networked computers to share resources

without a central server.

• Wireless (mobile) – allows communication from remote locations

using a variety of wireless technologies.

• Web-based – significant hardware, software, and possibly even data

elements that reside on the Internet.o Offers greater flexibility when used as a source for capacity-on-demand

or for additional processing capability for a fee.

• Bring Your Own Device (BYOD) - employees bring their own

devices and connect to enterprise systems.o Raises issues with capacity, security, and compatibility.

o Consumerization of IT – the push for employees and customers to use

their own devices to access corporate systems and the ensuing issues to

make them work. (c) 2013 John Wiley & Sons, Inc.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


From Strategy to Architecture to Infrastructure• The process of converting strategy to architecture to

infrastructure:

o Define the strategic goals.

o Translate goals into business requirements.

o Specify architectural requirements.

o Translate specs into hardware, software, data protocols,

interface designs, and other components that will make up the

infrastructure.

• Figure 6.5 lists questions raised when applying the framework to

TennisUp’s architecture goals and related infrastructure.

• Figure 6.6 lists possible infrastructure components.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-20

Component What Who Where

Architecture Infrastructure Architecture Infrastructure Architecture Infrastructure

Hardware What kind of supplemental server capacity will the new EDI transactions require?

Will TennisUp’s current dual CPU NT servers handle the capacity, or will the company have to add additional CPUs and/or disks?

NA Who is responsible for setting up necessary hardware at the partner site?

Where does responsibility for owning and maintaining EDI hardware fall within TennisUp?

Which hardware components will need to be replaced or modified to connect to the new EDI hardware?

Software What parts of TennisUp’s software architecture will the new architecture affect?

Will TennisUp’s current Access database interface adequately with the new EDI software?

Who knows the current software architecture well enough to manage the EDI enhancements?

Who will do any new SQL coding required to accommodate the new software?

NA Where will software patches be required to achieve compatibility with changes resulting from new software components?

Network What is the anticipated volume of transactions between TennisUp and its manufacturing partners?

High volume may require leased lines to carry transaction data; dial-up connections may suffice for low volume.

Who is responsible for additional networking expense incurred by partners due to increased demands of EDI architecture?

NA Where will security concerns arise in TennisUp’s current network architecture?

Where will TennisUp house new networking hardware required for EDI?

Data Will data formats supporting the new architecture be compatible with TennisUp’s existing formats?

Which formats must TennisUp translate?

Who will be responsible for using sales data to project future volumes to report to the manufacturing partner?

Who will be responsible for backing up additional data resulting from new architecture?

Where does the current architecture contain potential bottlenecks given the changes anticipated in data flows?

Does the new architecture require TennisUp to switch from its current 10Base-T Ethernet to 100Base-T?

Figure 6.5 Framework application to TennisUp.

(c)

20

13

Joh

n W

iley

& S

on

s, I

nc.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Hardware Software Network Data

3 servers: •Sales•Manufacturing•Accounting

Storage systems

ERP system with modules for:•Manufacturing•Sales•Accounting•Inventory

Enterprise Application Integration (EAI) software

Cable modem to ISP

Dial-up lines for backup

RoutersHubsSwitchesFirewalls

Database: •Sales•Manufacturing•Accounting

Figure 6.6 TennisUP’s infrastructure components.


Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Architectural Principles

• Based on a set of principles or fundamental beliefs about

how the architecture should function.

• Architecture principles must be consistent with both the

enterprise values as well as the technology used in the

infrastructure.

• The number of principles vary widely.

• Principles should define the desirable behaviors of the IT

systems and the role of the organization(s) that support it.

• Sample architectural principles (Figure 6.7).

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Enterprise Architecture

• The “blueprint” for all IS and its interrelationships in the firm.

• Specifies how IT will support business processes by identifying:

o core processes of the company and how they will work

together.

o how the IT systems will support the processes.

o the standard technical capabilities and activities for all parts of

the enterprise.

o Guidelines for making choices.

• Four key elements:

1. Core business processes.

2. Shared data.

3. Linking and automation technologies.

4. Customer groups.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-24

Figure 6.7 Sample architectural principles.


Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Enterprise Architectures (Cont.)

• TOGAF (The Open Group Architecture Framework)o Includes a methodology and set of resources for developing an

enterprise architecture.

• Zachman Framework

o Determines architectural requirements by providing a broad

view that guides the analysis of the detailed view.

• Building an enterprise architecture is a joint exercise with

business leaders and IT leaders.

• Business processes are designed concurrently with IT

systems.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Virtualization and Cloud Computing

• Virtualization infrastructure - computing capabilities, storage, and

networking provided by a third party or group of vendors, usually over

the Internet or through a private network (e.g., virtualized desktop).o Includes servers, storage, backup, network, and disaster recovery.

o Enables resources to be shared and allocated as needed by the user.

o Makes maintenance easier since resources are centralized.

• Cloud computing - virtual infrastructure provided over the Internet.

• SaaS (Software as a Service), PaaS (Platform as a Service), and

IaaS (Infrastructure as a Service).

• A cloud is a large cluster of virtual servers or storage devices.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Virtualization and Cloud Computing(Cont.) • Users purchase capacity-on-demand.

• Utility computing - computing capability is purchased on an as-

needed basis.

• Examples of applications in the cloud:

o Salesforce.com, Facebook, Gmail, Windows Azure, Apple iTunes,

and LinkedIn.

• Benefits of virtualization and cloud computing:

o Consolidated physical servers.

o Reduced physical costs of the data center.

o No upgrading.

o No maintenance, power, or electricity costs.

o No need for physical space or storage servers. o Increased speed of attaining additional capacity (provisioning).

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Virtualization and Cloud Computing – Managerial Considerations

• Managers must also understand the risks of a third-party

supplier.

o Retooling existing applications for the cloud’s

infrastructure.

o No established standards for virtual infrastructure.

o Applications not porting easily from one vendor’s

infrastructure to another’s.

• As coordination costs drop and platforms in the cloud open

up, cloud computing utilization will increase.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Understanding Existing Architecture

• The primary reason to base architecture on an organization’s strategic goals

is to allow for inevitable future changes to:

o the business environment.

o organization.

o IT requirements.

o the technology itself.

• Future consideration for IT architecture should include:

o analysis of the existing architecture.

o the strategic time frame.

o technological advances.

o financial constraints.

• Evaluate the IT requirements of an evolving business strategy against

current IT capacity.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Understanding Existing Architecture - Managerial Considerations• Relevant questions for managers:

o What IT architecture is already in place?

o Is the company developing the IT architecture from scratch?

o Is the company replacing an existing architecture?

o Does the company need to work within the confines of an

existing architecture?

o Is the company expanding an existing architecture?

• A strong business strategy is a prerequisite for IT

architecture design, which is a prerequisite for infrastructure

design.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Additional Managerial Considerations

• Managers can derive the most value and incur minimal loss

when working with legacy architectures and

infrastructures by objectively analyzing:

1. the existing architecture and infrastructure.

2. the strategy served by the existing architecture.

3. the ability of the existing architecture and infrastructure to

further the current strategic goals.

• Managers must ensure that the architecture will satisfy their

strategic requirements and that it is modern and efficient.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Strategic Time Frame

• Understanding the life span of IT infrastructure and

architecture is critical.

• Strategic time frames depend on industry-wide factors such

as:

o the level of commitment to fixed resources, maturity of the

industry, cyclicality, and barriers to entry.

• Business strategy planning horizon.

• Management reliance on IT and on the specific rate of

advances affecting IT.

• Design with maximum flexibility and scalability to ensure

handling of future business changes.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Technical Issues: Adaptability

• Can the architecture adapt to emerging technologies?

• Must be able to handle and absorb technological advances.

o Innovations in storage capacity and computing power.

o Unexpected technological leaps.

• Consider both hardware and software.

• Guidelines for planning adaptable IT architecture and

infrastructure:

o Plan for applications and systems that are independent and

loosely coupled rather than monolithic.

o Set clear boundaries between infrastructure components.

o Provide access to all users when it makes sense to do so (e.g.

security concerns) when designing a network architecture.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Technical Issues: Scalability

• Refers to how well an infrastructure component can

adapt to increased, or in some cases decreased, demands.

• A scalable network system should start with just a few

nodes but have the ability to easily expand to thousands of

nodes.

• It is important to analyze the impact of strategic

business decisions on IT architecture and infrastructure.

• Ensure a contingency plan exists for potential

unexpected effects of a strategy change.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Technical Issues: Standardization

• Hardware and software use a common standard.

• Easier to plug into infrastructure or architecture (e. g.,

Microsoft Office suite).

o Interfaces often accompany the standard.

o It is easy to move data between systems.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Technical Issues: Maintainability

• The manager needs to ask:

o How easy is it to maintain the infrastructure?

o Are replacement parts available?

o Are support services available?

• Maintainability is a key technical consideration.

o The complexity of the systems increases the number of

things that can go wrong, need fixing, or need replacing.

• Should a technology become obsolete, costs skyrocket for

parts and expertise.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Technical Issues: Security

• Major concern for business and IT managers.

• Must protect key data and process elements of the IT

infrastructure.

• Extends outside the boundaries of the company (e.g., customer

data).

• Innovations encrypt or disguise sensitive information, financial

information, and business information.

• Securing assets in a highly centralized, mainframe architecture

means building protection around the centralized core.

• Decentralized, server-based architecture is more difficult to

secure due to the dispersion of servers.

• Web-based SOA that utilizes SaaS and capacity on demand

raises a whole new set of security issues.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Assessing Technical Issues: Security(Cont.)

• The security of networks continues to improve through:

o innovations such as authentication, passwords, digital

signatures, encryption, secure servers, and firewalls.

o new schemes for security such as securing specific

assets instead of just securing the perimeter of a system.

• Managing security is often a matter of managing risk.

o Assessing the likelihood of a breach and the cost of that

breach in terms of loss and recovery.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-39

Assessing Financial Issues

• IT infrastructure components should be evaluated based on their

expected financial value (Figure 6.8).

• Payback from IT investments is difficult to quantify.

o Takes the form of increased productivity, increased interoperability

with business partners, improved service for customers, etc.

o Focus on how IT investments enable business objectives rather than

on their quantitative returns.

o Quantify returns on infrastructure investments by:

1. Quantifying costs.

2. Determining the anticipated life cycles of system components.

3. Quantifying benefits.

4. Quantifying risks.

5. Considering ongoing dollar costs and benefits.(c) 2013 John Wiley & Sons, Inc.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6

6-40

Figure 6.8 TennisUp’s managerial considerations.


Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Chapter 6 - Key Terms

Architecture (p. 169) - provides a blueprint for translating

business

strategy into a plan for IS.

Bring-your-own-device (BYOD) (p. 177) - employees bring

their own devices and connect to enterprise systems.

Capacity-on-demand (p. 177) - the availability of additional

processing

capability for a fee.

Centralized architecture (p. 173) - everything is purchased,

supported, and managed centrally via a data center to eliminate

the difficulties that come with managing a distributed infrastructure.

Client (p. 175) - a device or software program that requests data

and sometimes instructions from another software program,

usually running on a separate computer.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Chapter 6 - Key Terms (Cont.)

Cloud computing (p. 183) - an architecture based on

services

provided over the Internet.

Consumerization of IT (p. 177) - the drive to port

applications to

personal devices and the ensuing issues to make them work.

Decentralized architecture (p. 174) - The hardware,

software,

networking, and data arranged in a way that distributes the

processing and functionality between multiple small

computers, servers, and devices, relying heavily on a network

to connect them together.

Enterprise architecture (p. 180) - the “blueprint” for all IS

and its interrelationships in the firm.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6



Infrastructure (p. 169) - everything that supports the flow and

processing of information in an organization, including hardware,

software, data, and network components.

Peer-to-peer (p. 176) - allows networked computers to share

resources without a central server playing a dominant role.

Platform (p. 172) - an infrastructure or an underlying computer

system.

Reuse (p. 174) - relatively small chunks of functionality available

for

many applications.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6



Scalable (p. 188) - how well an infrastructure component can adapt to

increased, or in some cases decreased, demands.

Server-based architecture (p. 174) - a decentralized architecture

that uses numerous servers often located in different physical

locations. Service-oriented architecture (SOA) (p. 174) -

applications delivered over the Internet.

Standards (p. 188) - rules or principles.

TOGAF (p. 182) (The Open Group Architecture Framework) - a

methodology and set of resources for developing an enterprise

architecture.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6



Utility computing (p. 184) - computing infrastructure available when

needed in as much quantity as needed.

Virtualization (p. 183) - a virtual infrastructure where software

replaces hardware in a way that a “virtual machine” or a virtual

desktop system” was accessible to provide computing power.

Web-based architectures (p. 176) - architectures in which

significant

hardware, software, and possibly even data elements reside on the

Internet.

Web services (p. 175) - services delivered over the Internet.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6



Wireless (Mobile) Infrastructure (p. 176) - allow

communication from remote locations using a variety of

wireless technologies (e.g., fixed microwave links, wireless

LANs, data over cellular networks)

Zachman Framework (p. 182) - determines architectural

requirements by providing a broad view that helps guide the

analysis of

the detailed view.

Pearl

son

an

d S

au

nd

ers

– 5

th E

d. –

Ch

ap

ter

6


Copyright 2013 John Wiley & Sons, Inc.

All rights reserved. Reproduction or translation of this work

beyond that named in Section 117 of the 1976 United States

Copyright Act without the express written consent of the

copyright owner is unlawful. Request for further information

should be addressed to the Permissions Department, John Wiley

& Sons, Inc. The purchaser may make back-up copies for

his/her own use only and not for distribution or resale. The

Publisher assumes no responsibility for errors, omissions, or

damages, caused by the use of these programs or from the use

of the information contained herein.

Date post:	11-Jan-2016
Category:	Documents
Upload:	prosper-sanders
View:	256 times
Download:	9 times

Strategic Management of Information Systems Fifth Edition Information Systems Strategy: Architecture...

Documents