james nowotarski 1 may 2008 is 425 enterprise information spring 2008
Post on 20-Dec-2015
217 views
TRANSCRIPT
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 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
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:
Information Systems IS 425 Class Four
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
Information Systems IS 425 Class Four
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)
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
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
22
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
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
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
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
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
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
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Inception
Elaboration
Construction
Transition
43
Phase boundaries in waterfall are activities
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Phase
Phase
Phase
Phase
Phase
Phase
44
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
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
Softwarerequirements
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
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
49
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
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”
Applications and Data
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
Applications and Data
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.
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!!!
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
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
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
98
“The basic problem of software development is risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
Risk management
100
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
101
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
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