james nowotarski 1 may 2008 is 425 enterprise information spring 2008

James Nowotarski

1 May 2008

IS 425Enterprise Information

Spring 2008

2

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

Today’s Agenda

Anatomy of an Enterprise System

Source: Adam & Sammon

Anatomy of Data Warehouse/Data MiningAnatomy of Data Warehouse/Data Mining

DataWarehouse

ExtractTransformLoadRefresh

OLAP Engine

AnalysisQueryReportsData mining

Monitor&

IntegratorMetadata

Data Sources Front-End Tools

Serve

Data Marts

Operational DBs

othersources

Data Storage

OLAP Server

5

Simple cumulative

6

Simple cumulative

Data Model for Data Warehouse

A Sample Data Cube

Date

Product

Coun

trysum

sum TV

VCRPC

1Qtr 2Qtr 3Qtr 4Qtr

U.S.A

Canada

Mexico

sum

Total annual salesof TV in U.S.A.

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

DePaul University

11

Fraud/Non-Compliance Anomaly detection

– Isolate the factors that lead to fraud, waste and abuse

– Target auditing and investigative efforts more effectively

Credit/Risk Scoring Intrusion detection Parts failure prediction

Recruiting/Attracting customers

Maximizing profitability (cross selling, identifying profitable customers)

Service Delivery and Customer Retention

– Build profiles of customers likely to use which services

Web Mining

Examples of What People are Doing with Data Mining:


DePaul University

12

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

13

Query Examples

Database

Data Mining– Find all customers who have purchased beerFind all customers who have purchased beer

– Find all items which are frequently purchased with beer. Find all items which are frequently purchased with beer. (association rules)(association rules)– Describe attributes of customers likely to spend the most Describe attributes of customers likely to spend the most (segmentation)(segmentation)

– Find all credit applicants with last name of Smith.Find all credit applicants with last name of Smith.– Identify customers who have purchased more than Identify customers who have purchased more than $10,000 in the last month$10,000 in the last month..

– Find all credit applicants who are poor credit risks. Find all credit applicants who are poor credit risks. (classification)(classification)

– Identify customers with similar buying habits. (clustering)Identify customers with similar buying habits. (clustering)

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

Importance of Attributes in Predicting Propensity for Guest Return:

Months Since Deep Clean

Age of Bed

Use of Fitness Center

Spending in Restaurant

Room Price

Speed of Check-In

Speed of Room Service

Premium Movie Channel

Please Rate the Importance of the Following Aspects of Your Stay:

Low High

Room Cleanliness

Comfort of Bed

Fitness Center

Restaurant

Room Prices

Check-In Experience

Room Service

TV Channels

1: Monitoring

2: Framework

3: Predictive

Long, arduous journey

21

The Schumacher Group, April 2008

22

Topic Duration







Wrap-up 10 minutes

Today’s Agenda

Classification of IT portfolio

Operations Decisions Strategies

Finance

Accounting

Marketing

Human resources

Etc.

IBM (Cognos)

Information Builders

BI Platforms

SAS

JD Edwards

Peoplesoft

SAP

Oracle

Microsoft

EnterpriseSystems

Custom

24

Systems development life cycle (SDLC)

Planning Modeling Construction Deployment

Example

Core Concepts

25

SDLC model

• The iteration and control strategy adopted by a systems development organization

• Examples- Waterfall- Iterative/Evolutionary/Spiral- Incremental

Core Concepts

26

The waterfall model is the granddaddy of life cycle models

Core Concepts

Planning

Modeling

Construction

Deployment

27

What’s wrong with waterfall?

28

Protracted integration and late breakage

Conventional application of the waterfall model typically results in late integration and performance showstoppers

Dev

elop

men

t p

rogr

ess

(% c

oded

)

100%Late designbreakage

Original target date

Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).

Integrationbegins

What’s wrong with waterfall?

29

Iterative/Evolutionary/Spiral life cycle models advocate multiple “threads” through the SDLC phases

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

30

Incremental life cycle models advocate delivering the end product piecemeal

M C DVersion 1

M C DVersion 2

M C DVersion 3

Core Concepts

31

Rational Unified Process (RUP)

32

Product is the result of development cycles

Version 1

Development CycleVersion 2

Development CycleVersion 3

Development Cycle

Product delivered to users

33

Development cycle consists of phases

Development Cycle

Inception Elaboration Construction Transition

34

Phase consists of IterationsDevelopment Cycle

Elaboration

Iterationn Iterationn+1

35

Iteration consists of ActivitiesDevelopment Cycle

Elaboration

Iterationn+1IterationnR

A&D

C

T

R

A&D

C

T

Each phase contains one or more iterations

36

Each Iteration is a mini-waterfall

R

A&D

C

T

R

A&D

C

T

R

A&D

C

T

37

Iterative Advantages/Disadvantages

Advantages

Disadvantages

39

Why focus on change?

Life cycle phase

Co

st

of

ch

an

ge

Req Anal. Des. Impl. Test Prod

y = axp

40

Waterfall model

Systemrequirements

Softwarerequirements

Analysis

Program design

Coding

Testing

Operations

Source: Royce, W. (1970, August). Managing the development of large software systems. IEEE Proceedings, WESCON, 1-9.

41

Is RUP = Waterfall in disguise?

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Inception

Elaboration

Construction

Transition

42

Inside each phase, you plan iterations across disciplines

43

Phase boundaries in waterfall are activities

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Phase

Phase

Phase

Phase

Phase

Phase

44

Phase boundaries in RUP are milestones

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

RUP Phase

Milestone

45

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 over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan”

46

Agile methods wind the RUP model more tightly

Systemrequirements


Analysis

Program design

Coding

Testing

Operations

Each day on an Agile project

FunctioningCode

47

What are Agile methods

Time

Co

st

of

ch

an

ge

Agile methods purport to change the curve so that the cost to find and repair software problems does not rise dramatically over time

48

Topic Duration







Wrap-up 10 minutes

Today’s Agenda

49

Topic Duration







Wrap-up 10 minutes

Today’s Agenda

50

Who is Fritz Bauer?

• Professor of Mathematics and Computer Science at Munich University of Technology

51

Who is Fritz Bauer?

• Chairman of 1968 NATO Software Engineering Conference

• Credited with coining the term “software engineering”

52

Who is Fritz Bauer?

• Software engineering = “The part of computer science that is too difficult for the computer scientists.”

53

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)

Core Concepts

54

Buy vs. buildLease (utility model) vs. buy

• Open source vs. lease

Software as a commodity?

Does SE Matter?

55

Architecture

arch·i·tec·ture n. An architecture depicts the overall structure of a man-made complex system

56

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

57

An overloaded term

Enterprise architectureBusiness architectureTechnology system architecture

• Data architecture• Applications architecture

• Application-1 architecture

• Application-2 architecture

• Etc.

• Middleware architecture• System software architecture• Hardware/Network architecture

58

System architecture as a “stack”

Applications and Data

Middleware

Hardware/Network

System Software

Workstations, Mobile DevicesServers, StorageRouters, Switches, Bandwidth

Development tools, languagesWeb servers, App serversDatabase Management Systems Operating Systems

CRMERPClaims processingPayroll

Application programming interfaces

Transaction processing monitors

59

System architecture as a “stack”


Middleware

Hardware/Network

System Software

Vendors/Products

Dell, HP, Sun, EMC, CiscoAT&T, MCI, SprintPublic Internet

J2EEApacheBEA WebLogicDB2, Oracle, SQL Server Linux, Unix, Windows, z/OS

Custom developed SAP, Peoplesoft, OracleSalesforce.com

Enterprise application integration (EAI)ODBCBEA Tuxedo

60

Software architecture


Middleware

Hardware/Network

System Software

• Presentation layer• Application logic• Data management

61

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.”

What is software architecture?

Shaw, M., Garlan, D. (1996). Software architecture: Perspectives on an emerging discipline. Upper Saddle River, NJ: Prentice-Hall.

62

Key principles of architectural design

Abstraction Modularity Reuse

63

Abstraction

There is a limit to the number of ideas you can comprehend at any one time 7 +/- 2

Raise the level of detail by creating relationshipsExample: Grouping

Think in logical instead of physical terms

64

Grouping: What’s easier to understand and retain?

Grapes Oranges

Milk Butter

Potatoes Apples

Eggs Sour cream

Carrots

Milk

Dairy Fruit Vegetable

ButterEggs

Sour cream

Logical vs. Physical

65

Businessproblem

IT-enabledsolution

AnalysisLogicalDesign

PhysicalDesign

BuildTest Deploy

Magic!!!

66

Analysis model

Combination of text and diagramming Depicts requirements:

DataFunctionBehavior

67

Use-Case Diagram

homeowner

Arms/ disarms system

Accesses system via Internet

Reconfigures sensors and related

system features

Responds toalarm event

Encounters anerror condition

system administrator

sensors

68

Entity relationship diagram (ERD)

69

Program Graph

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

salary

taxes

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

70

Basic DFD NotationExternal

entity

A producer or consumer of information that resides outside the bounds (or at the boundaries) of the system to be modeled.

ProcessA transformer of information (a function) that resides within the bounds of the system to be modeled.

Data object

A data object; the arrowhead indicates the direction of data flow.

D1 Data storeA 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.

71

DFD Context Model for SafeHome Security System

SafeHomesoftware

Controlpanel

Sensors Telephoneline

Alarm

Controlpanel

displayUser commandsand data

Sensorstatus

Telephonenumber tones

Alarmtype

Displayinformation

This highest level model is also called a Level 0 model or a Fundamental model.

72

Level 1 DFD for SafeHome security function

Controlpanel

Interactwithuser

Processpassword

Configuresystem

Activate/deactivate

system

MonitorsensorsSensors Telephone

line

Alarm

Controlpanel

display

User commands & data

Password

Configurerequest

Start /stop

A/dmsg

Valid ID msg

Sensorstatus

Configuration information

Configuration data

Configuration data

Sensorinformation

Configurationdata

Displayinform-ationDisplay

messages& status

Alarmtype

Telephone number tones

MonitorsensorsSensor

status

Sensorinformation

Alarmtype

Telephone number tones

Configurationdata

73

SafeHome Security: State Transition Diagram

Resetting

Entry/set systemStatus “inactive”Entry/set displayMsg1 “Starting system”Entry/set displayMsg2 “Please wait”Entry/set displayStatus showBlinkingDo: run diagnostics

Idle

Entry/set systemStatus “inactive”Entry/set displayMsg1 “Ready”Entry/set displayMsg2 “”Entry/set displayStatus steadykeyHit/handleKey

ActingOnAlarm

Entry/set systemStatus “monitorAndAlarm”Entry/set displayMsg1 “ALARM”Entry/set displayMsg2 triggeringSensor Entry/set displayStatus fastBlinkingDo: soundAlarmDo: notifyAlarmResponderskeyHit/handleKey

MonitoringSystemStatus

Entry/set systemStatus “monitoring”Entry/set displayMsg1 “Armed”Entry/set displayMsg2 “”Entry/set displayStatus steadyDo: monitorAndControlSystemKeyHit/handleKey

Start/ stop switch power “on”

failureDetected / set displayMsg2 “contact Vendor”

SystemOK

Reset

Activate

deactivatePassword

falseAlarm

timeOut

sensorTriggered/startTimer

sensorTriggered/restartTimer

deactivate Password

off/powerOff

74

Think in logical instead of physical terms

READ_DATA

CALC_SALARY

CALC_TAXES

PRINT_PAYCHECK

employee_data

employee_data

salary

salary

taxes

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

75

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

Modularity

76

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)

GET_DATA

employee_data

CALC_SALARY

employee_ data

salary

CALC_TAX

salary

tax

PRINT_CHECK

employee_data

salary

tax

77

CohesionA measure of the relative functional strength of a module

Cohesion and coupling

Func A-1

Func A-2

Func A-3

Func B-1

Func B-2

Func B-3

High Cohesion (good)

CouplingA measure of the relative interdependence among modules

High coupling (bad)

78

"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

Cohesion

79

A cohesive module performs a single task within a software procedure, i.e., it should do JUST ONE THING.

Strive for HIGH cohesion.

Low High

“Scatter-brained” “Single-minded”

Coincidental

Logical

Temporal

Procedural

Communicational

Sequential

Functional

Strive for high cohesion.

Often acceptable. Almost as good as high cohesion.

Much worse than mid level cohesion.

Cohesion

80

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

No direct

coupling Data

coupling Stamp

coupling Control

coupling External

coupling Common

coupling Content

coupling

81

Types of coupling

a

b c

d

e

f g h

i

j k

Global data area

Data structure

Data (variables)

No direct coupling

Controlflag

Module M Module M’

Data Coupling

Stamp Coupling

ControlCoupling

CommonCoupling

82

Architectural styles

A set of design rules imposed on the entire system

Typically applied to physical design

83

Taxonomy of architectural styles

Data-centeredData flow (aka pipes and filters)Call and returnObject oriented architecturesLayered SystemsOnline transaction processingProcess control

84

Examples: UNIX shell commands Compilers:

Lexical Analysis -> parsing -> semantic analysis -> code generation Batch Processing

FilterFilter

Filter Filter

Filter

Filter Filter

Pipe Pipe

Pipe

Pipe

Pipe

Pipe

Pipe

Pipe Pipe

Pipe

Data flow

85

Call and return

86

Benefits of a well-done software architecture

87

Benefits of a well-done software architecture

Productivity Consistency Quality Rapid delivery Maintainability Interoperability Controlled complexity Maximum leverage of scarce technical skills

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

90

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

Application

Analyze

Analyze

Design

Design

Implement

Implement

Support

Support

Importance of the “quality requirements”

As systems grow in complexity, certain other quality attributes become more relevant . . . such as portability, security, reliability, and modifiabilityalso 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.

92

Source: Blaine, J. & Cleland-Huang, J. (2008, Mar/Apr). Software quality requirements: How to balance competing priorities. IEEE Software.

93

Security is a pervasive thread throughout the SDLC

Planning

se

cu

rity

Analysis Design Implementation

Security terminology

Backup Controls Decryption/Encryption Exposure Fault tolerance. Information system controls Integrity (of data) Threats (or hazards) Risk Vulnerability

94

Types of threats

ThreatsUnintentionalIntentional

• Attack• Data tampering• Programming fraud

95

Controls address threats

Prevention and deterrence Detection Limitation Recovery Correction

96

Types of controls

General controlsPhysicalAccessData securityCommunication networkAdministrative

97

98

“The basic problem of software development is risk”

Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley

Risk management

99

Risk management process

Identify Analyze Plan

Cost of protection Cost of exposure

$$ $$

Control

100

Topic Duration







Wrap-up 10 minutes

Today’s Agenda

101

Topic Duration







Wrap-up 10 minutes

Today’s Agenda

102

Mid-term due (20 points) Readings on eCommerce DL: Discussion on IS competencies

For May 8

103

Extra slides

7 common targets for analytical activity

104

105

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.

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.

106

Students at a university

Inquiry Lead Applicant

Admitted

Rejected

Withdrawn

Enrolled Matriculated Graduated

Drop Out

107

n-tier architecture

BankCustomers

Internet

InternetFirewall

WebServer

ApplicationFirewall

AppServer

DBServer

LegacyMainframe

108

Deriving a software architecture: Structured approach

Derive architectural context diagram (ACD)

Refine the DFD Map DFD to program structure:

Transform mappingTransaction mapping

109

Architecture context diagram (ACD)

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses

110

Transform mapping

data flow model

"Transform" mapping

ab

c

d e fg h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j

111

Typical design resulting from transform mapping

main programcontroller

inputcontroller

processingcontroller

outputcontroller

112

Transaction Mapping

a

b

t

g

h

d

e

f

i

k

j

l

m

n

Data flow model

x1

b

a

t

x2 x3 x4

d e f g h x3.1 l m n

i j

k

mapping

program structure

Summary Timeline

1960 1970 1980 1990 2000

Tech eraMainframe

Decentralized

Distributed Internet

Life cyclemodel

Stage wise

Waterfall

Iterative/Incremental

Methapproach

Structured Analysis/Design

Information Engineering

Object-Oriented A/DAgile

ContentUpdates

• Data mgmt • UI design• Bus process reengineering • Data/process distribution • CASE tools

• JAD• Prototyping • Multimedia content mgmt

• Network design/mgmt • Quality• Security

• OLTP

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

Technology Trigger

Peak ofInflated

Expectations

Trough of Disillusionment Slope of Enlightenment Plateau of

Productivity

time

visibility

Years to mainstream adoption:

less than 2 years 2 to 5 years 5 to 10 years more than 10 yearsobsoletebefore plateau

As of June 2007

XML-Enabled Database Management Systems

Linux as a Mission-Critical DBMS Platform

OSS DBMS for Non-Mission-Critical Applications

Real-Time Data Integration

Data Warehouse Appliances

Data Federation/EII

OSS DBMS for Mission-Critical Applications

Data Profiling

Comprehensive Data Integration Tool Suites

XQuery

Master Data Management

Data Service Architectures

Enterprise Information Management

SaaS Data Integration and Data Quality

Information-Centric Infrastructure

Open-Source Data Integration Tools

Entity Resolution and Analysis

Data Quality DashboardsMetadata Ontology

Management

Content Integration

Data Quality Tools

From "Hype Cycle for Data Management, 2007," 2 July 2007

118

Firmwide IT

Infrastructure Business Value

Business-Unit IT

Applications Business Value

Business-Unit Operational

Business Value

Business-Unit Financial

Business Value

Time

Impact

Sought

Dilutionof Impact

•Revenue growth•Return on assets•Revenue per employee

•Time to bring a new product to market•Sales from new products•Product or service quality

•Time to implement a new application•Cost to implement a new application

•Infrastructure availability•Cost per transaction•Cost per workstation

Business Value Measures

Dilu

tion

of IT

Impa

cts

Dilutionof Impact

Dilutionof Impact

InformationTechnology $

InformationTechnology $ A

C

B

Source: “Leveraging the New Infrastructure”, Peter Weill & Marianne Broadbent, ©1998

Hierarchy of Impact of Information Technology Investments

119

Increased control

Better information

Better integration

Improved quality

•Shorter time to market•Premium pricing•Superior quality

Increased sales

Competitive advantage

Competitive necessity

Market positioning

Innovative services

•50% fail•Some spectacular successes•2-to-3 year lead•Premium pricing•Higher revenue per employee

Cut costs

Increased

throughput

•25-40% return•Higher ROA•Low risk

Business integration

Business flexibility

Reduced marginal

cost of business

unit’s IT

Reduced IT costs

Standardization

More Higher growth Less Higher ROA

Infrastructure

Transactional

Informational Strategic

Source: “Leveraging the New Infrastructure”, Peter Weill & Marianne Broadbent, ©1998

Information Technology Portfolio and Business Value

120

IT Portfolio

121

Holistic view

Technology

ProcessPeople

james nowotarski 1 may 2008 is 425 enterprise information spring 2008

Documents

data mining data mining

data warehouse slide

data modeling

historical data mining

available slide

data marts operational

adam sammon slide

simple cumulative slide