A Fit for Purpose discussion

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

“Fit for Purpose” – Systems Selection
Claude Riousset
Executive IT Architect
IBM Systems & Technology Group

« Lite version »
© 2010 IBM Corporation


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

Lear Jet 60 (Corporate) MD – 90 (Regional) Boeing 747-400 (Large Capacity)
Capacity = 7 (8 with belted toilet) Capacity = 153 Capacity = 420
Range = 2,691 miles Range = 2,400 miles Range = 8,827 Miles
Cruise Speed = 514 mph Cruise Speed = 503 mph Cruise Speed = 563 mph

Each tool offers varying levels of capabilities…
2 © Copyright IBM Corporation, 2010


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



Many Factors Affect Choice

Car Server

Purchase price Purchase price
Would you purchase
a family car solely Gas mileage, cost of repairs, Cost of operation, power
on one factor? insurance cost consumption, floor space
Reliability Reliability

Safety, maneuverability, visibility, Availability, disaster recovery,
vendor service vendor service
Storage capacity, number of Scalability, throughput
seats, towing capacity
Horsepower Chip performance

Dash board layout Instrumentation and skills
Steering wheel location
Handling, comfort, features Manageability

Looks, styling, size Peer and industry recognition



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

Time Horizon
Scale
ISV Support

Non-Functional
Deployment Requirements
Model

System System
Technology z x
Adoption Geographic
Level Considerations

Platform Power, cooling,
Power floor space
Architecture
constraints

Politics Strategic Direction
and Standards

Skills Cost Models



Local Factors are Important

Platform and workload type

Platform Factor (e.g. Availability)
Local factors (constraints)
– Skills Best of Breed
– Technology adoption levels Industry Average Best of Breed

Below Average
– Platform management practices Industry Average

– Number of servers Below Average
– Organization considerations

Develop comparison metrics Platform A Platform B

– Consistent, collectable, usable

Become best of breed



Strategic and Tactical Platform Choices

IT Decision

• Balance tactical & strategic
Tactical • Develop reference architectures Strategic
• Mergers and acquisitions can
introduce non-strategic solutions
• Balance of visionary and
established patterns

All Tactical Choices All Strategic Choices

• Can Lower decision costs • Can lower long term costs
• Based upon history, convention, • Can run afoul of legacy
momentum, skills, and previous Complete Business Case
• Strategic direction important
strategic decisions
• New technologies will change
• Narrow focus can lead to sub- strategies
optimal solutions



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

Select or design applications based on functional requirements
driven by business process, and non-functional requirements

Functional Non-Functional
“What it does” “How well it does it”

• Correct business results • Availability requirements
• Inputs • Transactions per minute
• Outputs • Security requirements
• Behaviors • Ease of provisioning and support
• External interfaces • Disaster recovery requirements
• Screen layouts • Future growth

Select platforms based upon non-functional requirements
driven by business value



Common Deployment Models

OS OS OS OS OS OS OS

UI App Data
UI App Data UI App Data

Virtualizer

Centralized Virtualized Dedicated

Components are all Components split across Components split across
together virtual images servers
Very granular resource Coarser grained resource No resource sharing
sharing sharing between servers
OS workload Virtualizer workload Limited workload
management management management
Strongly integrated and Stacked and integrated Integrated over physical
stacked over network 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 demands
when determining server alternatives



Workload Attributes and Market Segmentation
Transaction Processing Analytics and High Performance
and Database

High Transaction Rates Compute or I/O intensive
High Quality of Service High memory bandwidth
Peak Workloads Floating point
Resiliency and Security Scale out capable

Business Applications Web, Collaboration
and Infrastructure

Scale Highly threaded
High Quality of Service Throughput-oriented
Large memory footprint Scale out capable
Responsive infrastructure Lower Quality of Service



Server Architecture - More Technical Workload View

Shared Parallel Data
Data & Work Q
• Shared data and Structures
• Parallel data
work queues structures

Highly Small Discrete
Threaded
• Small discrete
• Highly threaded
applications

Mixed
Mixed



Consolidating Workloads Optimizes Efficiency

Single workload model As copies of this workload are
assumptions: added:
– Average: 21%; Peak: 79% – Average approaches peak
– Random arrival rate – Total CPU grows at slower rate

Single Application Server (2 CPUs) 8 to 1 Consolidation (8 CPUs) 64 to 1 Consolidation (36 CPUs)
80% 80% 80%

70% 70% 70%

60% 60% 60%

50% 50% 50%

40% 40% 40%

30% 30% 30%

20% 20% 20%

10% 10% 10%

0% 0% 0%

Average 21%, Peak 79% Average 39%, Peak 76% Average 61%, Peak 78%



Which environment would you like to _______?

Not all workloads scale linearly
Deployments change with size and scale Hit the
earth
Miss the
earth
2%
Server proliferation can impact operations
– Patching, Clustering, Cabling, Disaster Recovery

Strategies
– Standardization, Virtualization,
Apollo 13
Centralized Deployment, Automation


Scope Limitation Leads to Sub-Optimization

A single application or department
view 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 architectures



Developing a Cost Model



Cost per Unit of Work

Shared costs tend to fall Cost per Transaction
– Centralized & virtualized

Costs per Transaction
– Level of sharing Dedicated
Shared

Dedicated costs tend to rise
– Complexity TCA TCO

– Software Workload Volume

– Datacenter factors

Local factors affect curves

Acquisition vs. total costs



Cost Models have Different Purposes

Selection Acquisition Chargeback

All measurable costs for all Will include step costs such as Designed to recover costs
environments over time new books, frames, chassis
Often simple and incomplete
Not based on step costs such as May ignore redeployed or on the
new book, frame or chassis shelf software licenses May distort choices between
alternatives
Friendly to new technologies such May ignore infrastructure costs
as virtualization & cloud for power, network, & space May need multiple models
The choice of cost and value May ignore increased utilization Public clouds incorporate all three
elements can dictate what is of existing capacity cost models
considered the lowest cost IT should own IT infrastructure

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



Wrap Up



Ask IBM for a “Fit for Purpose” discussion
with your IBM Systems Architect
Also:
System System
z x
Beware hidden cost
Power
of sub optimization.

Local Factors Matter
Large reliable servers are best for virtualization
• Will this platform run my solution? 8 to 1 Consolidation (8 CPUs) 64 to 1 Consolidation (36 CPUs)
• How well will it run? 80% 80%

70% 70%

• What will it cost me? 60% 60%

50% 50%

• What is the impact on my enterprise? 40% 40%

30% 30%
• Can I operate and manage it well enough? 20% 20%

10% 10%
• Will my organization accept it? 0% 0%

• Is this platform effective for the application
scope? Scaling with Core Count

• How does this platform fit into my current Don’t trust benchmark
infrastructure? results that scale

Ef civ C r s
f e t e oe
• Is this solution shared or dedicated to a single
business process? “nearly linearly”
• Do I know all the inherited requirements? Cores



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

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to A Fit for Purpose discussion (20)

More from Claude Riousset (13)

Recently uploaded (20)

A Fit for Purpose discussion