a fit for purpose discussion

© 2010 IBM Corporation

“Fit for Purpose” – Systems Selection

IBM Systems Technical University – Lyon, France - 25-29 October, 2010

Claude RioussetExecutive IT ArchitectIBM Systems & Technology Group

« Lite version »

2 © Copyright IBM Corporation, 2010


Each tool offers varying levels of capabilities…

Lear Jet 60 (Corporate)

Capacity = 7 (8 with belted toilet)

Range = 2,691 miles

Cruise Speed = 514 mph

MD – 90 (Regional)

Capacity = 153

Range = 2,400 miles


Boeing 747-400 (Large Capacity)

Capacity = 420

Range = 8,827 Miles


The right ‘tool’… All of these tools can move a person from one place to another…real fast….



But…which is the right tool… to move 1 person? 100 people? 400 people?



Many Factors Affect Choice

Car Server

Purchase price Purchase price

Gas mileage, cost of repairs, insurance cost

Cost of operation, power consumption, floor space

Reliability Reliability

Safety, maneuverability, visibility, vendor service

Availability, disaster recovery, vendor service

Storage capacity, number of seats, towing capacity

Scalability, throughput

Horsepower Chip performance

Dash board layoutSteering wheel location

Instrumentation and skills

Handling, comfort, features Manageability

Looks, styling, size Peer and industry recognition

Would you purchase a family car solely

on one factor?



Key Concepts and Terms



How do most companies select a platform for their applications?

� First question is – “Will it run there?”

� Second question is– “How much does the hardware cost?”

� Done!

� But this is just a TCA view ……Is that all we should be thinking about?



What did we miss? Non -Functional requirements

� Shouldn’t they have asked some questions about:– Scalability? Availability? Backup? Site Disaster Recovery?

– Security? Reliability? Data Integrity? Maintainability?

– Volumes and Service Levels? Scale?

– Space? Power? Cooling?

– Operations? Scheduling? Monitoring? Server Management?

– Integration? Performance and Value of Data Proximity?

� Fit-for-Purpose thinking leads to a holistic or TCO view?



Platform Selection



Selecting a Platform

Systemz

System x

Power

Time HorizonISV Support

Non-FunctionalRequirements

Power, cooling,floor spaceconstraints

Strategic Directionand Standards

Cost ModelsSkills

Politics

PlatformArchitecture

TechnologyAdoptionLevel

DeploymentModel

Scale

GeographicConsiderations



Local Factors are Important

� Platform and workload type

� Local factors (constraints)– Skills

– Technology adoption levels

– Platform management practices

– Number of servers

– Organization considerations

� Develop comparison metrics– Consistent, collectable, usable

� Become best of breed P

latfo

rm F

acto

r (

e.g.

Ava

ilabi

lity)

Platform A

Industry Average

Best of Breed

Below AverageIndustry Average

Best of Breed

Below Average

Platform B



Strategic and Tactical Platform Choices

All Tactical Choices

• Can Lower decision costs

• Based upon history, convention, momentum, skills, and previous strategic decisions

• Narrow focus can lead to sub-optimal solutions

All Strategic Choices

• Can lower long term costs

• Can run afoul of legacy

• Strategic direction important

• New technologies will change strategies

Tactical Strategic

Complete Business Case

IT Decision

• Balance tactical & strategic

• Develop reference architectures

• Mergers and acquisitions can introduce non-strategic solutions

• Balance of visionary and established patterns



Reference Architectures

�Pattern for repeated decisions– Lower decision making cost

– Lower implementation variability

� Larger than single decision - unlike a standard

�Based upon – Actual implementations

– Architectural decisions

�Can be long term decision setting



Functional and Non -Functional Requirements

Functional“What it does”

• Correct business results

• Inputs

• Outputs

• Behaviors

• External interfaces

• Screen layouts

Non-Functional“How well it does it”

• Availability requirements

• Transactions per minute

• Security requirements

• Ease of provisioning and support

• Disaster recovery requirements

• Future growth

Select platforms based upon non-functional requirem entsdriven by business value

Select or design applications based on functional r equirements driven by business process, and non-functional requ irements



Common Deployment Models

OS

UI

OS

App

OS

Data

OS

UI App Data

Centralized

� Components are all together

� Very granular resource sharing

� OS workload management

� Strongly integrated and stacked

Virtualizer

OS OS OS

UI App Data

Virtualized

� Components split across virtual images

� Coarser grained resource sharing

� Virtualizer workload management

� Stacked and integrated over network

Dedicated

� Components split across servers

� No resource sharing between servers

� Limited workload management

� Integrated over physical networks



High Level Workload Definition

�Workloads are a combination of:– Application function: What it does and how it does it

– Data structure: Data residency, topology, access model

– Usage pattern: Utilization profile over time, mix of use cases

– Service level: Non-functional requirements

– Integration: Interaction between application & data components

�The workload requirements will create varying deman ds when determining server alternatives



Workload Attributes and Market Segmentation

Transaction Processing and Database

High Transaction RatesHigh Quality of ServicePeak WorkloadsResiliency and Security

Analytics and High Performance

Compute or I/O intensiveHigh memory bandwidthFloating pointScale out capable

Web, Collaboration and Infrastructure

Highly threadedThroughput-orientedScale out capableLower Quality of Service

Business Applications

ScaleHigh Quality of ServiceLarge memory footprintResponsive infrastructure



Server Architecture - More Technical Workload View

Mixed

• Highly threaded

• Shared data and work queues

• Parallel data structures

• Small discrete applications

Parallel Data Structures

Mixed

Highly Threaded

Shared Data & Work Q

Small Discrete



Consolidating Workloads Optimizes Efficiency

� Single workload model assumptions:

– Average: 21%; Peak: 79%

– Random arrival rate

� As copies of this workload are added:

– Average approaches peak

– Total CPU grows at slower rate

Single Application Server (2 CPUs)

0%

10%

20%

30%

40%

50%

60%

70%

80%

Average 21%, Peak 79%

8 to 1 Consolidation (8 CPUs)

0%

10%

20%

30%

40%

50%

60%

70%

80%



0%

10%

20%

30%

40%

50%

60%

70%

80%




Hit the earth

Miss the earth

Apollo 13

2%

Which environment would you like to _______?

�Not all workloads scale linearly�Deployments change with size and scale�Server proliferation can impact operations

– Patching, Clustering, Cabling, Disaster Recovery

�Strategies– Standardization, Virtualization,

Centralized Deployment, Automation



Scope Limitation Leads to Sub -Optimization

�A single application or departmentview is easiest to understand

� Issues– May be driven by politics

– Runs counter to enterprise IT optimization

– May make an enterprise view harder to establish

– Can lead to large hidden costs

– Server sprawl

�Enterprise wide, scope specific, reference architec tures



Developing a Cost Model



Cost per Unit of Work

�Shared costs tend to fall– Centralized & virtualized

– Level of sharing

�Dedicated costs tend to rise– Complexity

– Software

– Datacenter factors

� Local factors affect curves

�Acquisition vs. total costs

Cost per Transaction

Workload Volume

Cos

ts p

er T

rans

actio

n

Dedicated

Shared

TCA TCO



Cost Models have Different Purposes

Selection

� All measurable costs for all environments over time

� Not based on step costs such as new book, frame or chassis

� Friendly to new technologies such as virtualization & cloud

� The choice of cost and value elements can dictate what is considered the lowest cost

Acquisition

� Will include step costs such as new books, frames, chassis

� May ignore redeployed or on the shelf software licenses

� May ignore infrastructure costs for power, network, & space

� May ignore increased utilization of existing capacity

Chargeback

� Designed to recover costs

� Often simple and incomplete

� May distort choices between alternatives

� May need multiple models

� Public clouds incorporate all three cost models

� IT should own IT infrastructure

Would car choices be different if someone else paid for the gas?



Wrap Up



Also:

Beware hidden cost of sub optimization.

Large reliable servers are best for virtualization

Don’t trust benchmarkresults that scale

“nearly linearly”

Ask IBM for a “Fit for Purpose” discussion with your IBM Systems Architect

• Will this platform run my solution? • How well will it run? • What will it cost me? • What is the impact on my enterprise? • Can I operate and manage it well enough? • Will my organization accept it? • Is this platform effective for the application

scope? • How does this platform fit into my current

infrastructure? • Is this solution shared or dedicated to a single

business process? • Do I know all the inherited requirements?

Scaling with Core Count

Cores

Effe

ctive Cores


0%

10%

20%

30%

40%

50%

60%

70%

80%


0%

10%

20%

30%

40%

50%

60%

70%

80%

Local Factors Matter

System x

Power

Systemz



When to consider “Fit-for-Purpose”

� Lifecycle Refresh

�Server Consolidation

�Re-Platforming

�Data Center relocations or Consolidation

�Business case development– Early in the application design process

a fit for purpose discussion

Technology

strategic choices

tactical platform choices

important platform

lower decision costs

tactical choices

cost of repairs

cost of operation

hardware cost