Transcript IS 425 Enterprise Information Spring 2008

IS 425
Enterprise Information
Spring 2008
James Nowotarski
1 May 2008
Today’s Agenda
Topic
Duration

Recap of 4/24
20 minutes

Solution delivery process (SDLC)
60 minutes
*** Break
15 minutes

Current event reports
30 minutes

Software architecture
40 minutes

Assignment 2 (Nestle)
20 minutes

Wrap-up
10 minutes
2
Anatomy of an Enterprise
System
Source: Adam & Sammon
Anatomy of Data Warehouse/Data Mining
other
sources
Operational
DBs
Monitor
&
Integrator
Metadata
Extract
Transform
Load
Refresh
Data
Warehouse
OLAP Server
Serve
Analysis
Query
Reports
Data mining
Data Marts
Data Sources
Data Storage
OLAP Engine
Front-End Tools
Simple cumulative
5
Simple cumulative
Data Model for Data
Warehouse
6
A Sample Data Cube
TV
PC
VCR
sum
1Qtr
2Qtr
3Qtr
4Qtr
sum
Total annual sales
of TV in U.S.A.
U.S.A
Canada
Mexico
sum
Country
Date
What is data mining
• Data mining is the process by which analysts apply
technology to historical data (mining) to determine
statistically reliable relationships between variables.
• Generally, it is the procedure by which analysts
utilize the tools of mathematics and statistical testing
applied to business-relevant, historical data in order
to identify relationships, patterns, or affiliations
among variables or sections of variables in that data
to gain greater insight into the underpinnings of the
business process (Kudyba & Hoptrof)
Information Systems IS 425 Class Four
Examples of What People are Doing with Data Mining:
 Fraud/Non-Compliance Anomaly
detection
 Recruiting/Attracting
customers
– Isolate the factors that lead to
fraud, waste and abuse
 Maximizing profitability
(cross selling, identifying
profitable customers)
– Target auditing and
investigative efforts more
effectively
 Service Delivery and
Customer Retention
 Credit/Risk Scoring
 Intrusion detection
 Parts failure prediction
– Build profiles of
customers likely to
use which services
 Web Mining
DePaul University
11
Information Systems IS 425 Class Four
Why Now?
• Data is being produced
• Data is being warehoused
• The computing power is available
• The computing power is affordable
• The competitive pressures are strong
• Commercial products are available
DePaul University
12
Information Systems IS 425 Class Four
Query Examples
 Database
– Find all credit applicants with last name of Smith.
– Identify customers who have purchased more than
$10,000 in the last month.
 Data Mining
– Find all customers who have purchased beer
– Find all credit applicants who are poor credit risks.
(classification)
– Identify customers with similar buying habits. (clustering)
– Find all items which are frequently purchased with beer.
(association rules)
– Describe attributes of customers likely to spend the most
(segmentation)
DePaul University
13
Data Mining Models and Tasks
Association Rules
•
•
•
There has been a considerable amount of research in the area of Market
Basket Analysis. Its appeal comes from the clarity and utility of its results,
which are expressed in the form association rules.
Given
– A database of transactions
– Each transaction contains a set of items
Find all rules X->Y that correlate the presence of one set of items X with
another set of items Y
– Example: When a customer buys bread and butter, they buy milk 85% of
the time
+
What is analytics
The extensive use of data, statistical
and quantitative analysis, explanatory
and predictive models, and fact-based
management to drive decisions and
actions (Davenport)
 Much of the attention focuses on
“advanced” analytics, of which
predictive analytics is a subset

16
Data Mining Models and Tasks
Analytics
Most common business
processes enabled by
analytics applications
Supply chain
 Customer acquisition, retention, profit
maximization
 Product and service quality
 Pricing

18
Examples of analytics
applications
Predict problems with demand and
supply chains, to achieve low rates of
inventory and high rates of perfect
orders.
 What products their customers want
 How many items each will buy in a
lifetime
 What triggers will make people buy
more
 What prices those customers will pay

19
Example: Marriott - Factor Analysis
Identifies What Is Important
Please Rate the
Importance of the Following
Aspects of Your Stay:
Low
Room Cleanliness
Comfort of Bed
High
Months Since Deep Clean
Age of Bed
Speed of Room Service
Use of Fitness Center
Fitness Center
Spending in Restaurant
Room Prices
Check-In Experience
TV Channels
2: Framework
1: Monitoring
Importance of Attributes in Predicting
Propensity for Guest Return:
Room Service
Restaurant
3: Predictive
Room Price
Speed of Check-In
Premium Movie Channel
Long, arduous journey
The Schumacher Group,
April 2008
21
Today’s Agenda
Topic
Duration

Recap of 4/24
20 minutes

Solution delivery process (SDLC)
60 minutes
*** Break
15 minutes

Current event reports
30 minutes

Software architecture
40 minutes

Assignment 2 (Nestle)
20 minutes

Wrap-up
10 minutes
22
Classification of IT portfolio
Operations
Decisions
SAP
Finance
Accounting
Marketing
Human
resources
Etc.
Peoplesoft
Enterprise
Systems
Strategies
Custom
Oracle
IBM (Cognos)
SAS
Microsoft
JD Edwards
BI Platforms
Information Builders
Core Concepts
Systems development life cycle (SDLC)
Example
Planning
Modeling
Construction
Deployment
24
Core Concepts
SDLC model
• The iteration and control strategy adopted by a
systems development organization
• Examples
- Waterfall
- Iterative/Evolutionary/Spiral
- Incremental
25
Core Concepts
The waterfall model is the granddaddy of life cycle models
Planning
Modeling
Construction
Deployment
26
What’s wrong with waterfall?


27
What’s
Protracted integration and
late breakage
wrong with waterfall?
Conventional application of the waterfall
model typically results in late integration and
performance showstoppers
Late design
breakage
100%
Development progress
(% coded)
Integration
begins
Original
target date
28
Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).
Core Concepts
Iterative/Evolutionary/Spiral life cycle models
advocate multiple “threads” through the SDLC
phases
Version 1
M
C
D
Version 2
M
C
D
Version 3
M
C
D
29
Core Concepts
Incremental life cycle models advocate
delivering the end product piecemeal
Version 1
M
C
D
Version 2
M
C
D
Version 3
M
C
D
30
Rational Unified Process
(RUP)
31
Product is the result of
development cycles
Product delivered to users
Version 1
Development Cycle
Version 2
Development Cycle
Version 3
Development Cycle
32
Development cycle consists of
phases
Development Cycle
Inception
Elaboration
Construction
Transition
33
Phase consists of Iterations
Development Cycle
Elaboration
Iterationn
Iterationn+1
34
Iteration consists of Activities
Development Cycle
Elaboration
Iterationn
R
A&D
Iterationn+1
R
A&D
C
Each phase
contains one or
more iterations
C
T
T
35
Each Iteration is a mini-waterfall
R
R
A&D
R
A&D
C
A&D
C
T
C
T
T
36
Iterative
Advantages/Disadvantages
Advantages
Disadvantages


37
Why focus on change?
Cost of change
y = axp
Req
Anal. Des. Impl. Test
Prod
Life cycle phase
39
Waterfall model
System
requirements
Software
requirements
Analysis
Program
design
Coding
Source: Royce, W. (1970,
August). Managing the
development of large software
systems. IEEE Proceedings,
WESCON, 1-9.
Testing
Operations
40
Is RUP = Waterfall in disguise?
Inception
System
requirements
Elaboration
Software
requirements
Analysis
Construction
Program
design
Coding
Testing
Transition
Operations
41
Inside each phase, you plan
iterations across disciplines
42
Phase boundaries in waterfall
are activities
System
requirements
Software
requirements
Analysis
Program
design
Coding
Testing
Operations
43
Phase boundaries in RUP are
milestones
System
requirements
Software
requirements
Analysis
Program
design
Milestone
Coding
Testing
Operations
44
Agile/Light/Lean Methods

On February 11-12, 2001 seventeen
proponents met at Snowbird ski resort and
what emerged was the:
Agile “Software Development” Alliance

“We have come to value:




Individuals and interactions
Working software
Customer collaboration
Responding to change
over
over
over
over
processes and tools
comprehensive documentation
contract negotiation
following a plan”
45
Agile methods wind the RUP
model more tightly
System
requirements
Software
requirements
Analysis
Program
design
Functioning
Code
Coding
Testing
Operations
46
What are Agile methods
Cost of change
Agile methods purport to change the curve so that the
cost to find and repair software problems does not rise
dramatically over time
Time
47
Today’s Agenda
Topic
Duration

Recap of 4/24
20 minutes

Solution delivery process (SDLC)
60 minutes
*** Break
15 minutes

Current event reports
30 minutes

Software architecture
40 minutes

Assignment 2 (Nestle)
20 minutes

Wrap-up
10 minutes
48
Today’s Agenda
Topic
Duration

Recap of 4/24
20 minutes

Solution delivery process (SDLC)
60 minutes
*** Break
15 minutes

Current event reports
30 minutes

Software architecture
40 minutes

Assignment 2 (Nestle)
20 minutes

Wrap-up
10 minutes
49
Who is Fritz Bauer?
• Professor of
Mathematics and
Computer Science at
Munich University of
Technology
50
Who is Fritz Bauer?
• Chairman of 1968
NATO Software
Engineering
Conference
• Credited with coining
the term “software
engineering”
51
Who is Fritz Bauer?
• Software engineering = “The
part of computer science that is
too difficult for the computer
scientists.”
52
Core Concepts
Software Engineering
• The establishment and use of sound
engineering principles in order to economically
obtain software that is reliable and works
efficiently on real machines (Fritz Bauer, 1969)
53
Does SE Matter?

Buy vs. build

Lease (utility model) vs. buy
• Open source vs. lease

Software as a commodity?
54
Architecture
arch·i·tec·ture n. An
architecture depicts the
overall structure of a
man-made complex
system
55
Architecture
arch·i·tec·ture n. The
fundamental
organization of a
system embodied in its
components, their
relationships to each
other, and to the
environment, and the
principles guiding its
design and evolution.
Source: IEEE
56
An overloaded term

Enterprise architecture
Business architecture
 Technology system architecture

• Data architecture
• Applications architecture
• Application-1 architecture
• Application-2 architecture
• Etc.
• Middleware architecture
• System software architecture
• Hardware/Network architecture
57
System architecture as a
“stack”
Applications and
Data
Middleware
System Software
Hardware/Network
CRM
ERP
Claims processing
Payroll
Application programming
interfaces
Transaction processing
monitors
Development tools, languages
Web servers, App servers
Database Management Systems
Operating Systems
Workstations, Mobile Devices
Servers, Storage
Routers, Switches, Bandwidth
58
System architecture as a
“stack”
Vendors/Products
Applications and
Data
Middleware
System Software
Hardware/Network
Custom developed
SAP, Peoplesoft, Oracle
Salesforce.com
Enterprise application
integration (EAI)
ODBC
BEA Tuxedo
J2EE
Apache
BEA WebLogic
DB2, Oracle, SQL Server
Linux, Unix, Windows, z/OS
Dell, HP, Sun, EMC, Cisco
AT&T, MCI, Sprint
Public Internet
59
Software architecture
Applications and
Data
• Presentation layer
• Application logic
• Data management
Middleware
System Software
Hardware/Network
60
What is software architecture?
Software architecture is a level of design that
“involves the description of elements from which
systems are built, interactions among those
elements, patterns that guide their composition,
and constraints on these patterns.”
Shaw, M., Garlan, D. (1996). Software architecture: Perspectives on an
emerging discipline. Upper Saddle River, NJ: Prentice-Hall.
61
Key principles of
architectural design
Abstraction
 Modularity
 Reuse

62
Abstraction

There is a limit to the number of ideas
you can comprehend at any one time


Raise the level of detail by creating
relationships


7 +/- 2
Example: Grouping
Think in logical instead of physical
terms
63
Grouping: What’s easier to
understand and retain?
Grapes
Milk
Potatoes
Eggs
Carrots
Dairy
Oranges
Butter
Apples
Sour cream
Fruit
Vegetable
Sour cream
Milk
Eggs
Butter
64
Logical vs. Physical
IT-enabled
solution
Business
problem
Analysis
Logical
Design
Physical
Design
Build
Test
Deploy
65
Analysis model
Combination of text and diagramming
 Depicts requirements:

Data
 Function
 Behavior

66
Use-Case Diagram
Arms/ disarms
syst em
Accesses syst em
via Int ernet
sensors
homeow ner
Responds t o
alarm event
Encount ers an
error condit ion
syst em
administ rat or
Reconf igures sensors
and relat ed
syst em f eat ures
67
Entity relationship diagram (ERD)
68
Program Graph
Big idea: As a prelude to creating a design, represent
the basic computational requirement for the system to
be designed in more abstract terms, i.e., in terms of
data flow
employee_data
PRINT_
PAYCHECK
salary
CALC_
SALARY
taxes
employee_
data
READ_
DATA
salary
CALC_
TAXES
69
Basic DFD Notation
External
entity
Process
Data
object
D1 Data store
A producer or consumer of information that resides outside
the bounds (or at the boundaries) of the system to be
modeled.
A transformer of information (a function) that resides
within the bounds of the system to be modeled.
A data object; the arrowhead indicates the direction of data
flow.
A repository of data that is to be stored for use by one or
more processes; may be as simple as a buffer or queue or
as sophisticated as a relationship database.
70
DFD Context Model for SafeHome
Security System
Control
panel
User commands
and data
SafeHome
software
Sensor
status
Sensors
Display
information
Alarm
type
Control
panel
display
Alarm
Telephone
number tones
Telephone
line
This highest level model is also called a Level 0 model or a Fundamental model.
71
Level 1 DFD for SafeHome security
function
Control
panel
Configure
system
User
commands
& data
Configure
request
Interact
with
user
Password
Configuration information
Start /
stop
Configuration
data
Activate/
deactivate
system
Process
password
Valid ID msg
Configuration
data
Sensors
Configuration
data
Sensor
status
Monitor
sensors
A/d
msg
Display
information
Display
messages
& status Alarm
Sensor
information
Control
panel
display
Alarm
type
Telephone number
tones
Telephone
line
72
SafeHome Security: State
Transition Diagram
Resetting
Start/
stop
switch
power
“on”
SystemOK
Entry/set systemStatus “inactive”
Entry/set displayMsg1 “Starting system”
Entry/set displayMsg2 “Please wait”
Entry/set displayStatus showBlinking
Do: run diagnostics
failureDetected /
set displayMsg2
“contact Vendor”
Reset
Activate
deactivatePassword
Idle
Entry/set systemStatus “inactive”
Entry/set displayMsg1 “Ready”
Entry/set displayMsg2 “”
Entry/set displayStatus steady
keyHit/handleKey
off/powerOff
deactivate
Password
ActingOnAlarm
MonitoringSystemStatus
Entry/set systemStatus “monitoring”
Entry/set displayMsg1 “Armed”
Entry/set displayMsg2 “”
Entry/set displayStatus steady
Do: monitorAndControlSystem
KeyHit/handleKey
falseAlarm
timeOut
sensorTriggered/
startTimer
Entry/set systemStatus “monitorAndAlarm”
Entry/set displayMsg1 “ALARM”
Entry/set displayMsg2 triggeringSensor
Entry/set displayStatus fastBlinking
Do: soundAlarm
Do: notifyAlarmResponders
keyHit/handleKey
sensorTriggered/
restartTimer
73
Think in logical instead of physical
terms
Big idea: As a prelude to creating a design, represent
the basic computational requirement for the system to
be designed in more abstract terms, i.e., in terms of
data flow
employee_data
PRINT_
PAYCHECK
salary
CALC_
SALARY
taxes
employee_
data
READ_
DATA
salary
CALC_
TAXES
74
Modularity

Modular design



Reduces complexity
Facilitates change
Results in easier implementation by supporting parallel
development of different parts of the system.

Information hiding

Functional independence

Objectives: High cohesion, low coupling
75
Call and return
PROCESS_PAYROLL
for each employee
get_data(:employee_data)
calc_salary(employee_data:salary)
calc_tax(salary:tax)
print_check(employee_data, salary, tax)
employee_data
employee_data
employee_
data
salary
salary
tax
salary
GET_DATA
CALC_SALARY
CALC_TAX
tax
PRINT_CHECK
76
Cohesion and coupling


Cohesion
A measure of the relative functional strength of
a module
Func A-1
Func B-1
Func A-2
Func B-2
Func A-3
Func B-3
High Cohesion (good)
Coupling
A measure of the relative interdependence
among modules
High coupling (bad)
77
Cohesion

"Cohesion is the degree to which the tasks performed
by a single module are functionally related.“ IEEE,
1983

"Cohesion is the "glue" that holds a module together. It
can be thought of as the type of association among the
component elements of a module. Generally, one
wants the highest level of cohesion possible.“
Bergland, 1981

"A software component is said to exhibit a high degree
of cohesion if the elements in that unit exhibit a high
degree of functional relatedness. This means that each
element in the program unit should be essential for that
unit to achieve its purpose.“ Sommerville, 1989
78
Cohesion

A cohesive module performs a single task within a
software procedure, i.e., it should do JUST ONE
THING.

Strive for HIGH cohesion.
Low
“Scatter-brained”
Much worse
than mid level
cohesion.
High
“Single-minded”
Often acceptable. Almost
as good as high cohesion.
Strive for high
cohesion.
79
Coupling

A measure of interconnection among modules in
a program structure.

Goal is LOW coupling in order to increase
understandability and reduce the rippling effect
during change.
Low
High
80
Types of coupling
Module M
Module M’
No direct
coupling
a
Data
structure
d
Data
(variables)
i
Control
flag
Stamp
Coupling
Data
Coupling
Control
Coupling
b
c
e
f
g
j
k
h
Common
Coupling
Global
data
area
81
Architectural styles


A set of design
rules imposed on
the entire system
Typically applied
to physical design
82
Taxonomy of architectural
styles
 Data-centered
 Data
flow (aka pipes and filters)
 Call and return
 Object oriented architectures
 Layered Systems
 Online transaction processing
 Process control
83
Data flow
Filter
Pipe
Filter
Filter
Pipe
Filter
Pipe
Filter
Filter
Pipe
Pipe
Pipe
Filter
 Examples:
 UNIX shell commands
 Compilers:
Lexical Analysis -> parsing -> semantic analysis -> code
generation
 Batch Processing
84
Call and return
85
Benefits of a well-done
software architecture

86
Benefits of a well-done
software architecture








Productivity
Consistency
Quality
Rapid delivery
Maintainability
Interoperability
Controlled complexity
Maximum leverage of scarce technical skills
87
Software architecture vs.
software engineering
methods

Software engineers tend to focus on
the computer science domain. It is up
to the architect to ensure that the
engineers understand the application
domain models because it is those
models that represent the semantics
of the problem domain. Solving the
wrong problem can cause entire
projects to be scrapped, wasting time
and money (Albin, Chapter 2)
88
Software architecture vs.
software engineering
methods

So to identify a new profession called software architecting is to make a
statement that we recognize that software development is really not
scientific but rather more closely resembles the craft guilds of the
Middle Ages. This is not to say that we do not strive for a scientific
underpinning to what we do as software developers, but that we are
realistic about the state of the art in software design. To claim the title is
also to make the statement that we recognize that software
development is really not a homogeneous activity relegated to a single
specialty (programming) but involves many specialties and different
technologies. Even though these technologies are all software, they
really require different expertise and design methods. Therefore, we
recognize that software architecting involves interdisciplinary software
engineering methodologies from object-oriented analysis to functional
decomposition; from object-oriented programming to relational database
design and XML schema design, and even user interface and usability
design (Albin, Chapter 1)
89
Architecture: Compelling need to
stay ahead
Think of the architecture as an “application” to be used by
systems developers
Architecture development and application development
are related but separate activities that are staggered and
occur in parallel:


Architecture
Analyze
Design
Implement
Support
Application
Analyze
Design
Implement
Support
90
Importance of the “quality
requirements”

As systems grow in complexity,
certain other quality attributes
become more relevant . . . such as
portability, security, reliability, and
modifiability

also known as the “ilities”
91
Quality requirements are a
key driver of architectural
decisions

“[Q]uality requirements tend to exhibit trade-offs that must
be carefully negotiated and resolved.



Stakeholders might want a system to be both highly secure
and easily accessible to users
Or they might want a system to have very fast response
times and support thousands of users but not cost much to
build.
Developers must find an architectural solution that
balances these conflicting needs in a way that optimizes
the delivered product’s value.
Source: Blaine, J. & Cleland-Huang, J. (2008, Mar/Apr).
Software quality requirements: How to balance competing
priorities. IEEE Software.
92
security
Security is a pervasive
thread throughout the SDLC
Planning
Analysis
Design
Implementation
93
Security terminology










Backup
Controls
Decryption/Encryption
Exposure
Fault tolerance.
Information system controls
Integrity (of data)
Threats (or hazards)
Risk
Vulnerability
94
Types of threats

Threats
Unintentional
 Intentional

• Attack
• Data tampering
• Programming fraud
95
Controls address threats





Prevention and deterrence
Detection
Limitation
Recovery
Correction
96
Types of controls

General controls
Physical
 Access
 Data security
 Communication network
 Administrative

97
Risk management
“The basic problem of software development is
risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
98
Risk management process
Identify
Analyze
$$
Cost of protection
Plan
Control
$$
Cost of exposure
99
Today’s Agenda
Topic
Duration

Recap of 4/24
20 minutes

Solution delivery process (SDLC)
60 minutes
*** Break
15 minutes

Current event reports
30 minutes

Software architecture
40 minutes

Assignment 2 (Nestle)
20 minutes

Wrap-up
10 minutes
100
Today’s Agenda
Topic
Duration

Recap of 4/24
20 minutes

Solution delivery process (SDLC)
60 minutes
*** Break
15 minutes

Current event reports
30 minutes

Software architecture
40 minutes

Assignment 2 (Nestle)
20 minutes

Wrap-up
10 minutes
101
For May 8

Mid-term due (20 points)
Readings on eCommerce

DL: Discussion on IS competencies

102
Extra slides
103
7 common targets for
analytical activity
104
Software Components
Definition:
A software component can be
defined as a nontrivial piece of
software, a module, a package, or a
subsystem, that fulfills a clear
function, has a clear boundary and
can be integrated in a well-defined
architecture. It is the physical
realization of an abstraction in your
design.
105
Students at a university
Inquiry
Lead
Enrolled
Applicant
Rejected
Admitted
Withdrawn
Matriculated
Drop Out
Graduated
106
n-tier architecture
DB
Server
Bank
Customers
Internet
Web
Server
App
Server
Legacy
Mainframe
Internet
Firewall
Application
Firewall
107
Deriving a software architecture:
Structured approach
Derive architectural context diagram
(ACD)
 Refine the DFD
 Map DFD to program structure:

Transform mapping
 Transaction mapping

108
Architecture context diagram
(ACD)
Safehome
Product
control
panel
homeow ner
Internet-based
system
target system:
Security Function
uses
surveillance
f unction
peers
uses
uses
sensors
sensors
109
Transform mapping
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
i
h
j
110
Typical design resulting from
transform mapping
main
program
controller
input
controller
processing
controller
output
controller
111
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
program structure
i
g
h
l
k
j
m
t
b
a
x2
n
d
e
x4
x3
f
g
l
x3.1
h
m
n
j
i
k
112
Summary Timeline
1960
1970
1990
1980
2000
Mainframe
Decentralized
Tech era
Distributed
Internet
Stage wise
Life cycle
model
Meth
approach
Content
Updates
Waterfall
Iterative/Incremental
Structured Analysis/Design
Information Engineering
Object-Oriented A/D
Agile
• OLTP
• Data mgmt
• JAD
• Prototyping
• UI design
• Bus process reengineering
• Data/process distribution
• CASE tools
• Multimedia content mgmt
• Quality • Network design/mgmt
• Security











Backup—an extra copy of the data and/or programs kept in a secured location(s).
Controls
Decryption—transformation of scrambled code into readable data after
transmission.
Encryption—transformation of data into scrambled code prior to its transmission.
Exposure—the harm, loss, or damage that can result if something has gone
wrong in an information system.
Fault tolerance—the ability of an information system to continue to operate
(usually for a limited time and/or at a reduced level) when a failure occurs.
Information system controls—the procedures, devices, or software that attempt
to ensure that the system performs as planned.
Integrity (of data)—a guarantee of the accuracy, completeness, and reliability of
data. System integrity is provided by the integrity of its components and their
integration.
Threats (or hazards)—the various dangers to which a system may be exposed.
Risk—the likelihood that a threat will materialize.
Vulnerability--given that a threat exists, the susceptibility of the system to harm
caused by the threat.
114

"Unfortunately," he added, "with
computer software, a certain amount
of risk has to be taken, and it is the
job of Singapore Telecom to make
sure that this risk is kept at a
minimum.“ – deputy president of
Singapore Telecom
115
Controls address threats





Controls for prevention and deterrence. Properly designed controls may
prevent errors from occurring, deter criminals from attacking the system, and
better yet, deny access to unauthorized people. Prevention and deterrence are
especially important where the potential damage is very high.
Detection. It may not be economically feasible to prevent all hazards, and
deterring measures may not work. Therefore, unprotected systems are vulnerable
to attack. Like a fire, the earlier it is detected, the easier it is to combat and the
less is the damage. Detection can be performed in many cases by using special
diagnostic software.
Limitation. This means to minimize losses once a malfunction has occurred.
Users typically want their systems back in operation as quickly as possible. This
can be accomplished by including a fault-tolerant system that permits operation in
a degraded mode until full recovery is made. If a fault-tolerant system does not
exist, a quick (and possibly expensive) recovery must take place.
Recovery. A recovery plan explains how to fix a damaged information system as
quickly as possible. Replacing rather than repairing components is one route to
fast recovery.
Correction. Correcting damaged systems can prevent the problem from occurring
again.
116
Underlying Technology: Hip and Hype
visibility
XQuery
Content Integration
Comprehensive Data Integration Tool Suites
Master Data Management
Data Profiling
OSS DBMS for Mission-Critical Applications
Enterprise Information
Management
SaaS Data Integration
and Data Quality
Metadata Ontology
Management
Entity Resolution
and Analysis
Data Service
Architectures
Open-Source
Data Integration
Tools
XML-Enabled Database
Management Systems
Data Federation/EII
Linux as a Mission-Critical DBMS Platform
Data Quality Tools
OSS DBMS for Non-Mission-Critical Applications
Real-Time Data Integration
Data Warehouse Appliances
Data Quality
Dashboards
Information-Centric Infrastructure
As of June 2007
Technology
Trigger
Peak of
Inflated
Expectations
Trough of
Disillusionment
Slope of Enlightenment
Plateau of
Productivity
time
Years to mainstream adoption:
less than 2 years
2 to 5 years
5 to 10 years
more than 10 years
From "Hype Cycle for Data Management, 2007," 2 July 2007
obsolete
before plateau
Hierarchy of Impact of Information Technology Investments
Business Value Measures
•Revenue growth
•Return on assets
•Revenue per employee
Impact
Sought
Business-Unit Financial
Business Value
C
•Time to bring a new
product to market
•Sales from new products
•Product or service quality
Dilution
of Impact
Business-Unit Operational
Business Value
B
Dilution
of Impact
•Time to implement a new
Business-Unit IT
application
•Cost to implement a new
Applications Business Value
application
Information
Dilution
Technology $
A of Impact
•Infrastructure availability
Firmwide IT
•Cost per transaction
Infrastructure Business Value
•Cost per workstation
Information
Technology $
Source: “Leveraging the New Infrastructure”, Peter Weill & Marianne Broadbent, ©1998
Time
118
Information Technology Portfolio and Business Value
Increased sales
• Shorter time
to market
• Premium
pricing
• Superior
quality
Increased control
Competitive advantage
Better information
Competitive necessity
Better integration
Market positioning
Improved quality
Innovative services
Informational
Cut costs
• 50% fail
• Some spectacular
successes
• 2-to-3 year lead
• Premium pricing
• Higher revenue
per employee
Strategic
Transactional
Increased
throughput
Business integration
Infrastructure
• 25-40%
return
• Higher ROA
• Low risk
Business flexibility
Reduced marginal
cost of business
unit’s IT
More
Less
Higher growth
Higher ROA
Reduced IT costs
Standardization
119
Source: “Leveraging the New Infrastructure”, Peter Weill & Marianne Broadbent, ©1998
IT Portfolio
120
Holistic view
Process
People
Technology
121