Transcript Server Consolidation Approach Models

Commonwealth of Massachusetts
Statewide Strategic IT Consolidation (ITC) Initiative
Detailed Infrastructure Consolidation Plan
Workshop
September 10, 2009
DRAFT – FOR DISCUSSION PURPOSES ONLY
IT Consolidation Initiative
Table of Contents
I. Overview
3
A.
Background
4
B.
Business Risks
6
II. Approach
7
A.
Process Model
8
B.
Roles and Responsibilities
9
IV. Data Center Services Consolidation
12
A.
Overview, Scope, and Exclusions
13
B.
Building the Playbook
14
C.
Categorizing Applications
15
D.
Consolidation Approaches
17
E.
Mapping Approaches to Applications
27
F.
High Level Steps
30
G.
Process Flows
34
H.
Benefits of Consolidation
42
I.
Cost Comparison Model
43
V. More Information
44
Appendix
A.
Industry Leading Product Solutions
45
B.
System Architecture Build Plan Template
53
DRAFT FOR DISCUSSION PURPOSES ONLY
-2-
Overview
DRAFT FOR DISCUSSION PURPOSES ONLY
-3-
Background
In February, Gov. Patrick issued Executive Order 510 calling for IT Consolidation and
defined the three major requirements:
• The appointment of Secretariat CIOs with authority over
IT budgets and resources
• Consolidation of four IT services at the Secretariat level:
desktop, Helpdesks, web content, applications
• Consolidation of four IT services at the Commonwealth
level through ITD: networks, data centers, web hosting,
enterprise applications (e-mail)
The Commonwealth’s new IT model aims at achieving three simple goals:
To make our IT environment more:
• Efficient – through standardization of IT resources
• Effective – This requires and elevates strategic IT planning with
SCIOs and enables Secretariats to align resources with their
business priorities
• Secure –To enable a coherent and streamlined architecture for
information security
DRAFT FOR DISCUSSION PURPOSES ONLY
-4-
Framework and Scope for Infrastructure Consolidation
Based on Executive Order No. 510, the Commonwealth will consolidate four common services as
identified in the diagram below.
Data Center Services — Enterprise computing
resources, including: Raised Floor and/or
Cooled Data Centers, Server Rooms,
Server/Telecom Closets, SUDs (Servers Under
Desks)
Network and Telecom Services — Centrally
governed network architecture, associated
processes and staff, that transport voice, data,
and video traffic.
Commonwealth-wide IT infrastructure services
included for the consolidation effort.
DRAFT FOR DISCUSSION PURPOSES ONLY
Website Hosting and Portal Services —
Standardized Mass.Gov hosting platform,
associated processes and people, that
provides tools for web publishing and selfmanagement of content
Enterprise Services (e-mail) — Electronic
messaging system, with basic collaboration
capabilities like calendaring and tasks. A
centralized Active Directory service with
appropriate security designations.
-5-
The Mandate – Executive Order No. 510
On February 20, 2009, Governor Deval Patrick issued Executive Order 510 mandating IT consolidation in Executive
departments. The order outlined the provisions for the consolidation process, one of the seven initiatives outlined in the
Commonwealth’s IT strategic plan. Specifically, the order outlined a planning timeline as described in the table below.
Compliance
Deadlines
Executive Order No. 510
Compliance Requirements
Corresponding
Deliverables/Milestones
05.30.2009,
Saturday
“By May 30, 2009, the Commonwealth CIO shall issue a high level description of his or • High-level Commonwealth IT
her plans for completing the migration of lnfrastructure Services for all Executive
Infrastructure Consolidation Plan
Department agencies to the Information Technology Division ("ITD"), except those
services, if any, that the Commonwealth CIO determines cannot be centralized at ITD
due to restrictions imposed by state or federal law.” – Sec.5, p.3
07.01.2009,
Wednesday
“By July 1, 2009, with the approval of the Legislature, agency budgets for IT shall be
aggregated at the secretariat level and managed by each secretariat’s SCIO.” – Sec.3,
p.2
• Secretariat-level IT Consolidation
Plans
07.01.2009,
Wednesday
“Each SClO shall submit to the Commonwealth CIO for review and approval a
secretariat consolidation plan ("Secretariat Consolidation Plan") demonstrating how
the Secretariat will, no later than 9/30/09, migrate to the most efficient model for the
delivery of IT services.” – Sec.4, p.2
• Secretariat-level IT Consolidation
Plans
Periodically
“Secretariat Consolidation Plans shall provide for the submission of periodic IT and IT
procurement plans to the Commonwealth CIO for the CIO’s review and approval.” –
Sec.4, p.3
• Secretariat-level IT Consolidation
Plans
9.30.2009,
Wednesday
“Following the Commonwealth ClO's approval of their respective Secretariat
• Governance Framework, IT
Consolidation Plans, and no later than September 30, 20009.9, each SClO shall
Organizational Development,
manage IT for his or her secretariat based on that approved plan.” – Sec.4, p.3
and Workforce Development
plans
09.30.2009,
Wednesday
“By 9/30/2009, the Commonwealth CIO shall finalize a detailed plan for
completing the migration of lnfrastructure Services for all Executive
Department agencies to ITD.” – Sec.5, p.3
• Commonwealth Detailed
Infrastructure Consolidation
Plan
12.30.2010,
“By 12/30/2010 ITD must substantially complete the consolidation of lnfrastructure
Sec.5, p.3
• N/A: Not in scope for Phase II
DRAFT FOR
DISCUSSION PURPOSES
ONLY
Thursday
Services for
the Executive Department at ITD.” –
-6-
Business Risks
With a program as complex as IT Consolidation, many risks exist, risks have been and continue to need
to be monitored and strategies developed to help mitigate the impact of these risks:
Risk Category
Details and Impacts
Data Gathering
• A lack of accurate, timely, and comprehensive inventories will result in use of
assumptions for recommendations; poses risks to efficacy and value of
recommendations
• Lack of comprehensive staff inventories may impact ability to complete staffing
models
Financial
Resource
Constraints
• Inability to identify additional funding sources risks insufficient funding to complete
consolidation activities, program continuity, ability to prioritize activities, or
effectiveness with which recommendations or plans may be carried out
Human
Resource
Constraints
• Staff reductions may impact continuity of institutional knowledge, key consolidation
decisions, required activities, or may delay consolidation activities
• Lack of appropriately trained staff may impose risks to service levels
• Volume of staff acting under multiple hats may impact staffing models or ability to
transition staff easily
Service Levels
• Reduction in service levels may impact the ability for Commonwealth constituents
to conduct business
Client Outages
• Client outages pose risks to continuity of work and decision making
• Outages increases the likely hood that rework may be needed
DRAFT FOR DISCUSSION PURPOSES ONLY
-7-
Approach
DRAFT FOR DISCUSSION PURPOSES ONLY
-8-
Approach to Infrastructure Consolidation – the “Playbook”
To achieve efficiencies in planning and execution, a “Playbook” approach incorporating the operational
and technology consolidations is employed. This repeatable consolidation process is tailored to meet
the needs of each of the technology threads for Network/telecomm, Data center services, and Shared
enterprise services.
Step 1:
Assess current
environment and
existing
requirements
Step 2:
Develop
infrastructure
consolidation
approaches
Step 3:
Define detailed
infrastructure plan
Step 9:
Refine
capabilities
Step 8:
Transition to
operations
Step 4:
Build ITD
base
capabilities
Primary responsibility
ITD
Secretariat
Joint
Step 5:
Develop
detailed
Secretariat
consolidation
plan
DRAFT FOR DISCUSSION PURPOSES ONLY
Step 7:
Execute
consolidations
and stabilize
environment
Step 6:
Prioritize
Provision
resources
according to
plan
-9-
Playbook – Planning Process – Roles and Responsibilities
Step 1:
Assess current environment
and existing requirements
Step 2:
Close information gaps and
plan for dependencies
Step 3:
Define detailed infrastructure
plan
ITD
Secretariat
Agency
Assess current capabilities, target
architectures, and secretariat
requirements
Attend Working Group Meetings
Validate and clarify requirements
Assess results from pilot migrations
Identify and provide input into
organizational capabilities and
strengths
Identify and provide input into
organizational capabilities and
strengths
Request details to close information
gaps and identify dependencies
Identify agency subject matter experts
Review and validate ITD reconciled
capabilities and requirements
Publish initial service catalog
Review draft infrastructure
consolidation plan and provide
feedback
Review draft infrastructure
consolidation plan and provide
feedback
Share vision for target architectures
Review, provide feedback, and accept
Infrastructure plan, chargeback vision
and integrated support operations
model
Review, provide feedback, and accept
Infrastructure plan, chargeback vision
and integrated support operations
model
Prepare consolidation approach
options for all technology threads for
secretariats
Share vision for chargeback and
integrated support operations model
DRAFT FOR DISCUSSION PURPOSES ONLY
- 10 -
Playbook – Repeatable Process – Roles and Responsibilities
Step 4:
Build ITD base capabilities
Step 5:
Develop detailed
Secretariat migration plan
Step 6:
Provision resources
according to plan
Step 7:
Execute consolidations and
stabilize environment
ITD
Secretariat
Agency
Execute capability gap closure plan
Accept ITD operational readiness for
migrations
Create consolidation plans following
Detailed Infrastructure Plan
Establish Service Management
process/tool integration points
Acquire/Transfer hardware, software,
licenses, staff
Execute consolidations per plan
Provide SMEs to support planning
Integrate support processes with ITD
Decommission legacy environment
Validate capacity and capabilities
Integrate support processes
Support migrations per plan
Stabilize environments
DRAFT FOR DISCUSSION PURPOSES ONLY
- 11 -
Playbook – Transition to Operations – Roles and Responsibilities
Step 8:
Transition to operations
Step 9:
Refine capabilities
ITD
Secretariat
Agency
Deploy solution
Accept operational solution
Provide technical and functional
support for applications
Support and maintain hosted solution
platform
Provide regular feedback to Service
Account Manager
Deploy standard solution to other
agencies
Monitor and manage Service Levels
Determine improvements and
upgrades
Monitor and manage Service Levels
DRAFT FOR DISCUSSION PURPOSES ONLY
- 12 -
Data Center Services Consolidation
DRAFT FOR DISCUSSION PURPOSES ONLY
- 13 -
Data Center Services Consolidation Overview, Scope, and Exclusions
Applications and underlying infrastructure will be aligned to the migration waves defined in Phase I
based on prescribed playbook approaches. Data center services consolidation does not include file and
print services but can include consolidation of applications that have been initially placed on file servers
but have become required for continued operation of Secretariat or Agency business processes.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 14 -
Building the “Playbook” for Data Center Services
In steps 1 to 3 of the consolidation process, detailed infrastructure consolidation plan will
be created from the repeatable playbook-based approach
Step 1:
Assess current
environment and
existing
requirements
Collected data allows ITD to
understand each agency’s
application profiles
1
Agency Application
Profile
Supporting Servers
and Storage
2
Step 2:
Develop
infrastructure
consolidation
approaches
Step 3:
Define detailed
infrastructure plan
• Applications are mapped to migration models for servers/storage/BC/DR based on their
individual characteristics.
• ITD standard service offerings dictate the order of preference for each approach area
Server Consolidation Models
Storage Consolidation Models
Disaster Recovery Model
Virtual to Virtual
Shared to Shared
Springfield <-> MITC
Physical to Virtual
Dedicated to Shared
MITC <-> Agency
Physical to Physical
Dedicated to Dedicated
Springfield Only
Lift and Shift
Lift and Shift
MITC Only
Platform and Backend
Operations and
Support Profile
3
The migration approach
for each application is
supported by a standard
set of ITD solutions
DRAFT FOR DISCUSSION PURPOSES ONLY
Configure Options Supporting ITD Solutions
Service Level /
Service Delivery
Model
Security
Requirements
Network
Requirements
Facilities
Requirements
- 15 -
Application Categorization Based On Collected Data
Application
Inventory Data
Mainframe
Mainframe Category
Supporting Servers
and Storage
High Level
Infrastructure
Type
Platform and Backend
Virtual Server Category
Virtualized
Server
Operations and
Support Profile
Physical Server
Physical Server Categories
Gate 1: Hardware Type and System Config
•
•
Is the application running on a unique hardware or OS?
Is the hardware or OS not compatible with ITD’s standard service
offerings?
If Yes
Legacy Physical Server
Category
If Yes
Unsupported Physical
Server Category
If Yes
Restricted Physical Server
Gate 2: Software Support
•
•
Is virtualization disallowed by the vendor/licensing terms?
Is the application minimally supported at the agency?
Gate 3: Regulatory/Compliance Profile
•
Does any regulation or statute require the application maintain
physical or logical separation?
Gate 4: Application Performance Profile
•
•
Does the application have high IO requirements?
Does the application require special component hardware
configuration?
If Yes
Performance Constrained
Physical Server
Standard Physical Server
Category
DRAFT FOR DISCUSSION PURPOSES ONLY
- 16 -
Application Categorization Based On Collected Data (cont.)
Application Category
Description
Application Profile Drivers
Mainframe
•
Mainframe application
Virtual Server
•
Already running on virtualized platform
•
Application running on unique hardware or
OS
Server or OS platform is not supported by
ITD standard service offerings
•
•
Hardware model
OS version
Minimally supported application
Virtualization disallowed by vendor licensing
•
•
Vendor / application name
Life cycle phase
Running on a stand-alone server that must
maintain separation by statute
•
•
•
•
Statutory requirement
Integration points
Data classification
Encryption requirements
•
•
Bandwidth requirements
Database type and
performance requirements
HA set-up
Legacy Physical Server
Unsupported Physical Server
Restricted Physical Server
Performance Constrained
Physical Server
•
•
•
•
•
•
Application with high IO needs
Unique hardware requirements
•
•
•
Standard Physical Server
•
DRAFT FOR DISCUSSION PURPOSES ONLY
Running on stand-alone server
Hardware and OS type and config. in-line
with ITD standard services
Standard performance specifications and
minimal restrictions
- 17 -
Server Consolidation Approach Models
Approach
Considerations
Preference
• Virtual to Virtual
(V2V)
Benefits
• Allows continued leverage of benefits gained from previously virtualized
application.
• Leverages consolidated, virtualized environment for the Commonwealth to
increase cost/performance.
Risks
• Caution should be taken if moving from one virtualization vendor to another to
mitigate uniqueness of any single virtualization platform.
• Physical to Virtual
(P2V)
Benefits
• Leverages the cost/benefit of virtualization and potentially reduces the physical
footprint demands.
• Positions Commonwealth for maximizing dynamic use of hardware as well as
common procedures and tools, while minimizing costs for resources
Risks
• Base applications, COTS , coding language, etc. must be technically
compatible and have licensing options to support virtualization.
• Applications that have I/O can be problematic for virtualization
DRAFT FOR DISCUSSION PURPOSES ONLY
- 18 -
Server Consolidation Approach Models (cont.)
Approach
Considerations
• Lift and Shift
(L&S)
Benefits
• For applications that require specialized/legacy hardware.
• For applications that do not have sufficient SME resources to “rebuild”
application on newer platforms.
• Requires least amount of new investment
Risks
• Tends to require the longed downtime to relocate.
• Minimizes ability to increase cost performance aspects of newer hardware.
• Minimizes ability to leverage the dynamic use of the hardware investment
• Continues dedicated hardware to applications and minimizes capability of
dynamic use of investment
• Can introduce risk to center from less hardened servers
• Tends to not allow much cost efficiency because of the specialization of the
platform.
Preference
• Physical to Physical
(P2P)
Benefits
• Can provide benefit to the application in increased performance, reduced
maintenance risk, etc. by migrating to newer hardware.
• Can minimize downtime as application can be fully “rebuilt” and tested prior to
“go-live”
Risks
• Required for applications that cannot take advantage of virtualization for either
technical, licensing, or statutory restrictions
• Continues dedicated hardware to applications and minimizes capability of
dynamic use of investment
• Does not provide any of the performance or cost benefits of virtualized
applications
DRAFT FOR DISCUSSION PURPOSES ONLY
- 19 -
Storage Consolidation Approach Models
Approach
Considerations
Preference
• Shared to Shared
(S2S)
Benefits
• Provides ability for a more dynamic allocation and utilization of storage assets
throughout the Commonwealth as application needs change.
• Continues higher reliability of storage through inherent technologies in the
arrays
• Allows for lower maintenance costs through standardization of physical
hardware as well as support tools and processes
• Dedicated to Shared
(D2S)
Benefits
• Provides ability for a more dynamic allocation and utilization of storage assets
outside the agency as application needs change
• Can provide higher reliability of storage through inherent technologies in the
arrays
• Allows for lower maintenance costs through standardization of physical
hardware as well as support tools and processes
• Dedicated to
Dedicated
(D2D)
Benefits
• Can provide benefit to the application in increased performance, reduced
maintenance risk, etc. by migrating to newer, standardized hardware.
• Required for applications that cannot take advantage shared storage for either
technical, licensing, or statutory restrictions
Risks
• Does not allow for maximizing investment through dynamic allocation
DRAFT FOR DISCUSSION PURPOSES ONLY
- 20 -
Storage Consolidation Approach Models (cont.)
Approach
• Lift and Shift
(L&S)
Preference
DRAFT FOR DISCUSSION PURPOSES ONLY
Considerations
Benefits
• For applications that require specialized/legacy hardware.
• For applications that do not have sufficient SME resources to “rebuild”
application on newer platforms.
• Requires the least new investment.
Risks
• Tends to require the longest downtime to relocate.
• Tends to not allow much cost efficiency because of the specialization of the
platform.
- 21 -
Disaster Recovery Consolidation Approach Models
Application Category
(primary | secondary)
Considerations
Interim Preference
• MITC | Agency
Benefits
• Provides for applications to build DR capability to reduce risk exposure
• Reduces risk exposure of application from agency data center deficiencies for
primary site
• Can be first step in migration of application to a more robust facility for
Active/Active & Active/Passive implementations
• Can provide some geographic diversity for Business Continuity
Risks
• Requires rebuild in and swing to MITC for applications
• Continue any risk exposure at the agency data center
• Agency | MITC
Benefits
• Provides for applications to build DR capability to reduce risk exposure
• This can be initial step in migration of application to a more robust facility for
Active/Active & Active/Passive implementations
• Can provide some geographic diversity for Business Continuity
Risks
• Continues any risk exposure at the agency data center as primary site
• MITC Only
Benefits
• Provides for application to reduce risk exposure in the near term for agencies
data centers that are less than sufficient
• May provide some HA capabilities
• Positions for ability to add DR capability in the future using Commonwealth-wide
standards
Risks
• Des not provide any geographic diversity
DRAFT FOR DISCUSSION PURPOSES ONLY
- 22 -
Disaster Recovery Consolidation Approach Models (cont.)
Application Category
(primary | secondary)
Considerations
Longer Term Preference
• Springfield | MITC
Benefits
• For applications that need to build DR capability and reduce risk exposure from
less sufficient agency data centers
• Will provide some geographic diversity for Business Continuity
• May allow for some load balancing of resource utilization at the Commonwealth
level
Risks
• Requires postponement until after DC2 build-out
• Springfield Only
Benefits
• Provides for application to reduce risk exposure for agencies data centers that
are less than sufficient
• Positions for ability to add DR capability in the future using Commonwealth-wide
standards
• May allow for some load balancing of resource utilization at the Commonwealth
level
Risks
• Requires postponement until after DC2 build-out
• Does not provide any geographic diversity
DRAFT FOR DISCUSSION PURPOSES ONLY
- 23 -
Service Level and Service Delivery Characteristics
Relevant Data Collected from Agencies and Secretariats
Currently Established
Service Level
Hours of Operation
RTO/RPO
Regulatory
Requirements
Supporting Service Level and Service Delivery Model
Hosting Model:
•
•
Will the application be hosted in a “hotel” or managed service model?
What will be ITD’s management responsibilities?
o Facilities only
o Facilities plus network, storage, and backup
o Managed service through the OS layer
Service Levels:
•
Incident and
Support Integration:
•
Will there be any difficulties integration the application with standard support tools and
processes/E2E?
Monitoring &
Automation Tools
•
What are the monitoring requirements, and will they be met by ITD standard service
offerings?
Backup Support
•
What are the backup requirements and will they be met by ITD standard service offerings?
Will ITD be able to meet or exceed currently established Service Level for the application?
o Availability/Reliability
o Incident response/resolution time
o Network performance
o Hours of operation
• What capabilities or process enhancements need to be made to support the application?
DRAFT FOR DISCUSSION PURPOSES ONLY
- 24 -
Security Characteristics
Relevant Data Collected from Agencies and Secretariats
Regulatory and
Compliance
Requirements
Data Classification
Unique Firewall
Requirements
Unique Encryption or
Authentication
Requirements
Security Requirements
Security Zone:
•
What standard security zone will the application infrastructure be placed in based on
standard zone definitions?
Firewall and
Policy Setup:
•
•
•
Will the application be accommodated by standard ITD service offerings for firewalls?
Will there be a need to purchase any specialty hardware to accommodate the application
requirements?
What is the high-level firewall policy/design to accommodate the application?
o High level rule-set
o Is there capacity on existing devices?
Are there any specialized tunneling arrangements required?
•
•
Can the application be supported by ITD standard security tools and infrastructure?
Will any special requirements dictate the need for new tools/hardware?
•
Encryption/
Authentication/
Misc
DRAFT FOR DISCUSSION PURPOSES ONLY
- 25 -
Network Architecture Characteristics
Relevant Data Collected from Agencies and Secretariats
Bandwidth and Latency
Requirements
Network Integration Points
Infrastructure Supporting
Application
Network Requirements
Network
Architecture:
•
•
•
•
Integration Points:
•
•
•
Can ITD standard service offering/MAGNet accommodate the applications bandwidth and
latency requirements
What is the high-level network architecture required to support the application?
Will the required architecture require the purchase of new/specialty equipment, or is there
capacity available on current network?
Are there any special protocols required?
Can MAGNet meet the connectivity requirements for the application to reach its external
integration points?
What, if any, modifications will be required to support the application?
Are there any Virtual Private Network (VPN) requirements?
DRAFT FOR DISCUSSION PURPOSES ONLY
- 26 -
Facilities Characteristics
Relevant Data Collected from Agencies and Secretariats
Infrastructure Supporting Application
Regulatory Requirements
Facility Requirements
Special Facilities
Requirements:
•
Will regulatory or other requirements dictate any special facilities setup?
o Physical separation from particular applications/systems
o Locked cage or physical dividers
o Special building security/access for facilities staff
Rack
Design/Layout:
•
Given the high-level network/server/security design, what facilities layout will accommodate
the consolidated systems?
Is there room in existing facilities for the purposed architecture?
Will the purposed hardware introduce any power/cooling/floor space issues in the space
available?
•
•
DRAFT FOR DISCUSSION PURPOSES ONLY
- 27 -
Server Consolidation Approach to Application Category Mapping
Application Category
V2V
P2V
P2P

Mainframe
Virtual Server

Legacy Physical Server
Unsupported Physical Server
Restricted Physical Server

Performance Constrained
Physical Server
Standard Physical Server
DRAFT FOR DISCUSSION PURPOSES ONLY
L&S








- 28 -
Storage Consolidation Approach to Application Category Mapping
Application Category
S2S
D2S
D2D

Mainframe
Virtual Server

Legacy Physical Server


Unsupported Physical Server
Restricted Physical Server
Performance Constrained
Physical Server
Standard Physical Server
DRAFT FOR DISCUSSION PURPOSES ONLY
L&S













- 29 -
DR Consolidation Approach to Application Category Mapping
DR solutions for different application profiles will evolve over time in order to reduce risk exposure
“Warm” & “Hot” DR Models
{Typically an instance of application has already been built in another location with replication of
data. Application is not load balanced but can be recovered in less than 24 hours for “Hot” DR.
Near Term Solutions
Agency Primary | MITC DR
MITC Primary | Agency DR
“Cold” DR Models
{Typically includes server acquisition/build
and can take at least 72 hours to recover}
MITC Only
Virtual Server
Virtual Server
Mainframe*
Restricted Physical Server
Restricted Physical Server
Virtual Server
Performance Constrained
Physical Server
Performance Constrained
Physical Server
Legacy Physical Server
Standard Physical Server
Standard Physical Server
Unsupported Physical Server
Stage 1 DR Setup
Stage 2 DR Setup
Restricted Physical Server
Standard Physical Server
Long Term Solutions
* May include use of Sungard for Mainframe
Springfield Primary | MITC
DR
Springfield Only
Virtual Server
Virtual Server
Restricted Physical Server
Legacy Physical Server
Performance Constrained
Physical Server
Unsupported Physical Server
Standard Physical Server
Restricted Physical Server
Stage 3 DR Setup
DRAFT FOR DISCUSSION PURPOSES ONLY
Standard Physical Server
- 30 -
V2V Server Consolidation Approach High Level Steps
High level steps and notional timeline to be used for planning purposes to build detailed
infrastructure consolidation plan.
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9
Week 10
Week 11
Week 12
Week 13
Week 14
Week 15
Week 16
M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F
Validate detailed schedule for
Secretariat application
`
Integrate ITD and Secretariat
operational processes
Validate capacity sizing for server
containers and storage
Configure server containers
Allocate storage
Identify network / firewall
restrictions
Configure appropriate network
routing
Build / Transfer application
(e.g. VMMOVE)
Set network restrictions per
security model
Schedule backups in common
backup platform
Configure data replication for DR
(As required)
Conduct Load and User
Acceptance Testing
Conduct Operational Readiness
Testing
Go Live {Update DNS}
Update Service Asset &
Configuration Mgmt DB
Outage Window
Stabilize and transfer to operations
Decommission old instance
*Assumes that any procurement of application
licenses has already been completed by the
Secretariat prior to start of the timeline.
Primary responsibility
ITD
Secretariat
Joint
DRAFT FOR DISCUSSION PURPOSES ONLY
- 31 -
P2V Server Consolidation Approach High Level Steps
High level steps and notional timeline to be used for planning purposes to build detailed
infrastructure consolidation plan.
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9
Week 10
Week 11
Week 12
Week 13
Week 14
Week 15
Week 16
M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F
Validate detailed schedule for
Secretariat application
Conduct Performance test existing
application instance
Integrate ITD and Secretariat
operational processes
Validate capacity sizing for server
containers and storage
Configure server containers
Allocate storage
Identify network / firewall
restrictions
Configure appropriate network
routing
Build / Transfer application
(e.g. VMMOVE)
Set network restrictions per
security model
Schedule backups in common
backup platform
Configure data replication for DR
(As required)
Conduct Load and User
Acceptance Testing
Conduct Operational Readiness
Testing
Go Live {Update DNS}
Update Service Asset &
Configuration Mgmt DB
Outage Window
Stabilize and transfer to operations
Decommission old instance
*Assumes that any procurement of application
licenses has already been completed by the
Secretariat prior to start of the timeline.
Primary responsibility
ITD
Secretariat
Joint
DRAFT FOR DISCUSSION PURPOSES ONLY
- 32 -
P2P Server Consolidation Approach High Level Steps
High level steps and notional timeline to be used for planning purposes to build detailed
infrastructure consolidation plan.
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9
Week 10
Week 11
Week 12
Week 13
Week 14
Week 15
Week 16
M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F
Validate detailed schedule for
Secretariat application
Integrate ITD and Secretariat
operational processes
Validate capacity sizing for servers
and storage
Configure new servers (e.g OS
image, monitoring tools, etc.)
Allocate storage
Identify network / firewall
restrictions
Configure appropriate network
routing
Build / Transfer application
(e.g. VMMOVE)
Set network restrictions per
security model
Schedule backups in common
backup platform
Configure data replication for DR
(As required)
Conduct Load and User
Acceptance Testing
Conduct Operational Readiness
Testing
Go Live {Update DNS}
Update Service Asset &
Configuration Mgmt DB
Outage Window
Stabilize and transfer to operations
Decommission old instance
*Assumes that any procurement of application
licenses has already been completed by the
Secretariat prior to start of the timeline.
Primary responsibility
ITD
Secretariat
Joint
DRAFT FOR DISCUSSION PURPOSES ONLY
- 33 -
L&S Server Consolidation Approach High Level Steps
High level steps and notional timeline to be used for planning purposes to build detailed
infrastructure consolidation plan.
Week 1
Week 2
Week 3
Week 4
Week 5
Week 6
Week 7
Week 8
Week 9
Week 10
Week 11
Week 12
Week 13
Week 14
Week 15
Week 16
M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F M T W T F
Validate detailed schedule for
Secretariat application
Integrate ITD and Secretariat
operational processes
Validate server, storage, and
ancillary equipment configuration
Identify firewall/security
requirements
Prepare centralized facilities for
new equipment
Shutdown, disconnect and pack at
Agency location
Transport, rack and stack at
centralized location
Configure network routing
Set network restrictions per
security model
Go Live {Conduct User
Certification Testing}
Schedule backups in common
platform (As required)
Configure data replication for DR
(As required)
Outage Window
Harden the instance to meet
security requirements
Conduct Operational Readiness
Testing
Update Service Asset &
Configuration Mgmt DB
Stabilize and transfer to operations
*Assumes that any procurement of application
licenses has already been completed by the
Secretariat prior to start of the timeline.
Primary responsibility
ITD
Secretariat
Joint
DRAFT FOR DISCUSSION PURPOSES ONLY
- 34 -
V2V Server Consolidation Approach Process Flow
The following outlines the rules of engagement for the consolidating an agency application that has already been virtualized.
Secretariat/
Agency
ITD Service
Account Mgmt
Infrastructure
Planning Group
ITD Hosting
Operations
Agency Team
ITD SAM
IPG Members
Hosting
Members
Review the
Service Catalog
choosing an
existing ITD
service offering
utilizing standard
policies
Work with
Secretariat /
Agency to
complete BAR
with service
targets.
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Service Catalog must be continually
updated with new standard service
offerings when economies of scale can
be found. In an optimum position, the
majority of offerings should meet the
agency needs and unique agency
configurations should be minimized.
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Legend
Process Activity
Governance Activity
Create a detailed
migration
schedule for the
ACS
agency’s
application
Create technical
and process
requirements for
application
SABP
instance
Key Documents*
Wiki Page
Key Documents
Off-page Connector
Validate sizing for
server containers
and storage
SABP
Update capacity
plans as
appropriate
Key Decision Point
Metrics and Estimates
Iterative Process
Configure server
containers
Allocate
storage
Configure
network routes
Identify
firewall/security
requirements
Validate security
zoning for
application
Build / transfer
application
Set network
restrictions per
security model
Post Build
DRAFT FOR DISCUSSION PURPOSES ONLY
- 35 -
V2V Server Consolidation Approach Process Flow (cont.)
The following outlines the rules of engagement for the consolidating an agency application that has already been virtualized.
Secretariat/
Agency
ITD Service
Account Mgmt
Service Desk /
NOC
ITD Hosting
Operations
Agency Team
ITD SAM
SD Members
Hosting Members
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Key Documents*
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Plan &
Build
Legend
Process Activity
Integrate ITD and Secretariat operational processes
Governance Activity
Wiki Page
Conduct load and
User Acceptance
Testing
Schedule
backups
Key Documents
Off-page Connector
Key Decision Point
Configure Disaster Recovery replication (As required)
Metrics and Estimates
Iterative Process
Go Live
Conduct Operational Readiness Testing
Update Asset &
Config Mgmt DB
Stabilize and transfer to operations
Decommission
old instance
DRAFT FOR DISCUSSION PURPOSES ONLY
- 36 -
P2V Server Consolidation Approach Process Flow
The following outlines the rules of engagement for the consolidating an agency application that is migrating from a physical
to a virtualized environment.
Secretariat/
Agency
ITD Service
Account Mgmt
Infrastructure
Planning Group
ITD Hosting
Operations
Agency Team
ITD SAM
IPG Members
Hosting
Members
Review the
Service Catalog
choosing an
existing ITD
service offering
utilizing standard
policies
Work with
Secretariat /
Agency to
complete BAR
with service
targets.
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Service Catalog must be continually
updated with new standard service
offerings when economies of scale can
be found. In an optimum position, the
majority of offerings should meet the
agency needs and unique agency
configurations should be minimized.
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Legend
Process Activity
Governance Activity
Create a detailed
migration
schedule for the
ACS
agency’s
application
Create technical
and process
requirements for
application
SABP
instance
Key Documents*
Wiki Page
Key Documents
Off-page Connector
Key Decision Point
Load and execute
performance
discovery tool
Metrics and Estimates
Iterative Process
Validate sizing for
server containers
and storage
SABP
Update capacity
plans as
appropriate
Configure server
containers
Allocate
storage
Configure
network routes
Identify
firewall/security
requirements
Validate security
zoning for
application
Build / transfer
application
Set network
restrictions per
security model
Post Build
DRAFT FOR DISCUSSION PURPOSES ONLY
- 37 -
P2V Server Consolidation Approach Process Flow (cont.)
The following outlines the rules of engagement for the consolidating an agency application that is migrating from a physical
to a virtualized environment.
Secretariat/
Agency
ITD Service
Account Mgmt
Service Desk /
NOC
ITD Hosting
Operations
Agency Team
ITD SAM
SD Members
Hosting Members
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Key Documents*
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Plan &
Build
Legend
Process Activity
Integrate ITD and Secretariat operational processes
Governance Activity
Wiki Page
Conduct load and
User Acceptance
Testing
Schedule
backups
Key Documents
Off-page Connector
Key Decision Point
Configure Disaster Recovery replication (As required)
Metrics and Estimates
Iterative Process
Go Live
Conduct Operational Readiness Testing
Update Asset &
Config Mgmt DB
Stabilize and transfer to operations
Decommission
old instance
DRAFT FOR DISCUSSION PURPOSES ONLY
- 38 -
P2P Server Consolidation Approach Process Flow
The following outlines the rules of engagement for the consolidating an agency application that is migrating from a physical
to a new physical environment.
Secretariat/
Agency
ITD Service
Account Mgmt
Infrastructure
Planning Group
ITD Hosting
Operations
Agency Team
ITD SAM
IPG Members
Hosting
Members
Review the
Service Catalog
choosing an
existing ITD
service offering
utilizing standard
policies
Work with
Secretariat /
Agency to
complete BAR
with service
targets.
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Service Catalog must be continually
updated with new standard service
offerings when economies of scale can
be found. In an optimum position, the
majority of offerings should meet the
agency needs and unique agency
configurations should be minimized.
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Legend
Process Activity
Governance Activity
Create a detailed
migration
schedule for the
ACS
agency’s
application
Create technical
and process
requirements for
application
SABP
instance
Key Documents*
Wiki Page
Key Documents
Off-page Connector
Validate capacity
sizing for server s
and storage
SABP
Update capacity
plans as
appropriate
Key Decision Point
Metrics and Estimates
Iterative Process
Configure server
containers
Allocate
storage
Configure
network routes
Identify
firewall/security
requirements
Validate security
zoning for
application
Build / transfer
application
Set network
restrictions per
security model
Post Build
DRAFT FOR DISCUSSION PURPOSES ONLY
- 39 -
V2V Server Consolidation Approach Process Flow (cont.)
The following outlines the rules of engagement for the consolidating an agency application that is migrating from a physical
to a new physical environment.
Secretariat/
Agency
ITD Service
Account Mgmt
Service Desk /
NOC
ITD Hosting
Operations
Agency Team
ITD SAM
SD Members
Hosting Members
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Key Documents*
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Plan &
Build
Legend
Process Activity
Integrate ITD and Secretariat operational processes
Governance Activity
Wiki Page
Conduct load and
User Acceptance
Testing
Schedule
backups
Key Documents
Off-page Connector
Key Decision Point
Configure Disaster Recovery replication (As required)
Metrics and Estimates
Iterative Process
Go Live
Conduct Operational Readiness Testing
Update Asset &
Config Mgmt DB
Stabilize and transfer to operations
Decommission
old instance
DRAFT FOR DISCUSSION PURPOSES ONLY
- 40 -
L&S Server Consolidation Approach Process Flow
The following outlines the rules of engagement for the consolidating an agency application that the physical relocation of
infrastructure from one physical location to another.
Secretariat/
Agency
ITD Service
Account Mgmt
Service Desk /
NOC
ITD Hosting
Operations
Agency Team
ITD SAM
SD Members
Hosting
Members
Review the
Service Catalog
choosing an
existing ITD
service offering
utilizing standard
policies
Work with
Secretariat /
Agency to
complete BAR
with service
targets.
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Service Catalog must be continually
updated with new standard service
offerings when economies of scale can
be found. In an optimum position, the
majority of offerings should meet the
agency needs and unique agency
configurations should be minimized.
Key Documents*
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Legend
Process Activity
Governance Activity
Create a detailed
migration
schedule for the
ACS
agency’s
application
Wiki Page
Key Documents
Off-page Connector
Create technical
and process
requirements for
application
SABP
instance
Validate facility
requirements;
updating capacity
plan as
SABP
appropriate
Key Decision Point
Metrics and Estimates
Iterative Process
Identify
firewall/security
requirements
Validate security
zoning for
application
Prepare
centralized
facilities
Integrate ITD and Secretariat operational processes
Shutdown,
disconnect, and
pack
Transport, rack,
and stack
Post Move
DRAFT FOR DISCUSSION PURPOSES ONLY
- 41 -
L&S Server Consolidation Approach Process Flow (cont.)
The following outlines the rules of engagement for the consolidating an agency application that the physical relocation of
infrastructure from one physical location to another.
Secretariat/
Agency
ITD Service
Account Mgmt
Service Desk /
NOC
ITD Hosting
Operations
Agency Team
ITD SAM
SD Members
Hosting Members
ITD Storage
Operations
Storage & Backup
Members
ITD Security &
Network
ITD Facility
Engineering
Network &
Security
Facility
Members
Key Documents*
ACS
Application Consolidation Schedule
SABP
System Architecture Build Plan
Prepare &
Move
Legend
Process Activity
Configure
network routes
Governance Activity
Wiki Page
Set network
restrictions per
security model
Go Live
Key Documents
Off-page Connector
Schedule
backups as
required
Key Decision Point
Metrics and Estimates
Iterative Process
Configure Disaster Recovery replication (As required)
Harden the server and ancillary equipment as required
Conduct Operational Readiness Testing
Update Asset &
Config Mgmt DB
Stabilize and transfer to operations
DRAFT FOR DISCUSSION PURPOSES ONLY
- 42 -
Benefits of Data Center Services Consolidation
• Improves security and reliability of agency applications through placement in
properly maintained facilities and resilient infrastructure.
• Positions the Commonwealth for the reduction of future recurring costs
through achieving economies of scale in acquisition and elimination of
duplication of maintenance and support services.
• Positions the Commonwealth to provide enhanced talent management and
resource utilization through pooling of technical resources.
• Improves business continuity in Commonwealth services offered to the
constituents in the longer term through geographic diversity of critical
applications.
• Improves flexibly to more rapidly respond to requirements of the
Commonwealth’s Secretariats and agencies through use of common
architecture.
• Improves ability to support a more graceful evolution of the Commonwealth’s
infrastructure.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 43 -
Agency Cost Comparison
In addition to the benefits gained from consolidation, some agencies will need to capture
their current costs to make an equitable comparison to the ITD service rates.
Hosting Cost Framework
COST COMPONENTS
Hardware Costs
Server Lease Costs
Server Purchase Costs
Depreciation
Maintenance/Support Costs
Storage Lease Costs (SAN/Backup Devices/Fiber Backbone/etc)
Storage Purchase Costs
Depreciation
Maintenance/Support Costs
Data Center LAN Lease Costs (Standard Switches, etc)
Data Center LAN Purchase Costs
Depreciation
Maintenance/Support Costs
Facilities Costs
Computer Room/Data Center Rent
Computer Room/Data Center Power/Electricity Bill
Facilities Security Costs
Misc Facilities/Utility Cost (Water for cooling, waste/refuse)
Standard Rack/KVM/Console Equipment
Software Costs
Monitoring Software License Costs
Depreciation
Maintenance/Support Costs
Backup Software License Costs
Depreciation
Maintenance/Support Costs
OS Software License Costs
Depreciation
Maintenance/Support Costs
Storage Management/ILM Software License Costs
Depreciation
Maintenance/Support Costs
Misc System Software License Costs
Depreciation
Maintenance/Support Costs
Staff and Professional Services Costs
Hardware Installation
Software Installation
Network Installation
Facilities Administration and Support
Server Administration and Support
Training
Backup or DR Services (e.g. Iron Mountain/SunGard)
Server Disposal/Removal Service
External services and integration
Total Cost
DRAFT FOR DISCUSSION PURPOSES ONLY
Year 1
$0
Year 2
$0
Annual Costs
Year 3
$0
Year 4
$0
Year 5
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
$0
- 44 -
For More Information
• To learn more about IT Consolidation in the Commonwealth:
• Visit the IT Consolidation Wiki:
https://wiki.state.ma.us/confluence/display/itconsolidation/Home
• Look also for the IT Consolidation Email Blast and Newsletter released regularly by
Consolidation leadership
• Have a Question or Feedback?
• Search for answers at the Consolidation Frequently Ask Questions page,
https://wiki.state.ma.us/confluence/display/itconsolidation/Frequently+Asked+Ques
tions
• Post your comments at www.mass.gov/itd/itconsolidationfeedback
• Use the email address:
[email protected]
to provide your comments anonymously
DRAFT FOR DISCUSSION PURPOSES ONLY
- 45 -
Appendix A: Industry-Leading Product Solutions
DRAFT FOR DISCUSSION PURPOSES ONLY
- 46 -
IT Service Desk Magic Quadrant
What You Need to Know
Gartner's 2008 IT service desk Magic Quadrant focuses on
enterprise-class vendors that met Gartner's criteria, as defined
below, that includes the vendor's ability, demonstrated through
customer references, to address the needs of customers seeking to
provide functionality for incident, problem, change, knowledge, selfservice and service-level agreement (SLA) management. Additional
analysis for the 2008 Magic Quadrant has been placed on change
management features, functionality and integration, because
Gartner is finding that 60% to 80% of organizations are choosing
change management and the service desk from the same vendor.
IT organizations adopting a holistic approach to IT service and
support tend to acquire the vendors' suites of IT service
management (ITSM) modules. These suites can help clients
aggregate data among modules, which leads to better decision
making regarding end-user downtime, whether due to application
failure or end-user-based issues, the cost and quality of IT service
and support, and the business's overall satisfaction with IT. Tool
selection is influenced by ease of deployment, integration with other
ITSM modules, in particular change management and configuration
management database (CDMB), pricing, as well as core functionality
around incident and problem management, self-service, reporting,
dashboards and workflow. The vendor's ability to deliver feature
enhancements and additional ITSM modules has been evolutionary,
not revolutionary.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 47 -
IT Event Correlation and Analysis Magic Quadrant
What You Need to Know
Gartner's Magic Quadrant for IT Event Correlation and Analysis
(ECA), 2009 evaluates vendors' ability to execute and their
completeness of vision relative to a defined set of evaluation criteria
regarding current and future market requirements. A Magic Quadrant
should not be the only criterion for selecting a vendor, because the
right solution for a given situation can be in any quadrant, depending
on the specific needs of the enterprise. Enterprises considering the
purchase of an ECA product should develop their own list of
evaluation criteria and functional requirements in the categories of
event collection/consolidation, processing/correlation and
presentation. Large enterprises should consider a multitier event
management hierarchy, pushing some event processing and
correlation out to the managed IT element at the bottom of the
hierarchy. These enterprises should use specialized event
management tools in the middle, and should place a "manager of
managers" or a business service management (BSM) product on
top.
When investing in event management, prospects should understand
how the product will fit with their overall event-to-incident/problem
resolution processes, including workflow, escalation and integration
with service desk tools.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 48 -
IT Asset Management Repository Market Scope
What You Need to Know
• The enterprise-class IT asset management (ITAM) repository marketplace has undergone
considerable consolidation by large players, reflecting the increased focus on financial management in
a holistic IT management toolset.
• ITAM repositories are moving toward financially supporting integrated IT service management and
portfolio management visions.
• The advent of the configuration management database (CMDB) has led to some confusion about the
role and use of ITAM repositories in the marketplace
DRAFT FOR DISCUSSION PURPOSES ONLY
- 49 -
Enterprise Storage Market Scope
What You Need to Know
2007 saw a reinvigoration of technology innovation in the high-end enterprise disk array storage market as storage vendors
began delivering such technologies as thin provisioning, enhanced replication facilities, redundant array of independent
disks (RAID) 6, and internal serial advanced technology attachment (SATA) disk support. While that innovation continued in
2008, albeit more slowly, economics and support capabilities continue to play a greater role in equipment and vendor
selection. High-end enterprise disk array storage users are inherently risk-averse. They understand and embrace
technology that is mature and stable, tending to wait for technologies to be proven before deploying them. However, the
price also has to be right. In today's high-end enterprise disk array market, Gartner research shows that vendors that can
compete on price and support are finding success in the market.
End users considering a high-end enterprise disk array purchase are therefore encouraged to include non-product criteria
in the selection process, as well as array functionality. These non-product criteria include:
Presales support
• Break/fix service and post-sales support
• Total-cost-of-ownership evaluation
• Technologies that have the net effect of reducing power and cooling consumption and space requirements
• Independent software vendor support
• Acquisition, upgrade, service and warranty pricing
• The impact of changing storage vendors on procedures, automation and scripts, storage management tools, and training
DRAFT FOR DISCUSSION PURPOSES ONLY
- 50 -
Storage Resource Software (SRM) Magic Quadrant
What You Need to Know
SRM tools are used to improve the cost-effectiveness of storage hardware and
operational processes. This has remained a fundamental value proposition from SRM
vendors since Gartner started tracking the SRM market. Combined with the
continuous growth in customer demand for storage capacity and the additional
operational costs of storage management, the requirement for SRM tools has grown.
SRM tools are mandatory for the effective management of shared-storage
environments; however, the breadth of features, ease of use of SRM tools and
product integration within the suites has improved. Implementation times and support
overheads have been reduced by “agentless” offerings. Niche vendors maintain their
value by offering solutions for functions not addressed by general-purpose products
and by providing lower-cost alternatives, when only a portion of the SRM functionality
is required.
Gartner believes that the SRM market will segment into two product categories that
mirror customer maturity, installed storage capacity and complexity. The first will
consist of between three and five major SRM vendors that will have holistic and
comprehensive SRM products used in large, mature storage-heterogeneous
enterprises. The second will consist of three or four specialist SRM vendors offering
fundamental SRM facilities to monitor use, performance and performance capacity
planning for small to midsize enterprise customers. The major vendors — CA, EMC,
HP, Hitachi Data Systems, IBM, NetApp and Symantec — have integrated their
diverse modules into SRM suites that now have a consistent look and feel within their
solutions.
Breakthrough features and technologies, such as change management, problem
determination and root-cause analysis have now improved and are common in the
comprehensive SRM solutions from the major vendors. During the past six to 12
months, the ability to report and correlate storage used by server virtualization
solutions and hypervisors was added to most SRM products. This is a significant
requirement recognized by the SRM vendors, because server virtualization solutions
and projects often reduced storage visibility, management, utilization and
subsequently increased storage costs. Therefore, customers demanded hypervisor
support from their SRM vendors to reduce costs by improving storage manageability
and use in virtualized server environments.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 51 -
Back and Recovery Software Market Scope
What You Need to Know
This Market Scope represents a major change in the way that Gartner is evaluating the backup market and measuring vendor success in that market. It is important to understand this
new direction to properly use the vendor rating table in this research. It has become clear that although all the vendors in this research have met the historical requirements for tapebased backup and even a certain level of disk-based support, success in the new recovery-focused market will require performance against a new and more demanding set of metrics
that respond to new recovery requirements. The vendor rating table in this research should be viewed as the first evaluation of vendors against these new metrics and should not be
compared with historical tables, which measured vendors against a different set of criteria and market needs.
Backup vendors have seen the change in the market and have already begun to change, extending their products to better support disk-based recovery solutions and associated
storage targets, such as virtual tape and de-duplication offerings. However, enterprises are demanding better solutions for PC backup (desktop/laptop), and more-robust support for the
unique requirements of server virtualized environments and remote-office recovery needs. Because the current enterprise backup solutions have not kept up with all the changing
requirements, companies have had to turn to point solutions to fill these gaps, meeting recovery requirements but at the cost of greater management complexity. As companies begin to
deploy archiving solutions for long-term retention and as backup sets are saved for a handful of months, not years, replacing a backup product will become easier. Users should look to
keep or switch to vendors that continue to innovate, deliver strong product support and ship quality code (relatively bug free), while addressing their current and anticipated
requirements. Companies not satisfied with product functionality, support or costs (acquisition or service/maintenance costs) should consider changing their backup vendors.
The enterprise backup vendors in this research will begin to transform their backup catalogs into recovery management tools that move beyond the focus on tape and simple disk-based
implementations to embrace new approaches that promise to meet more-demanding, recovery time objectives and recovery-point objectives. Enterprise backup products that fail to
make the transition will lose out to other vendors' products.
In the past, the primary competition for enterprise backup vendors was limited to other backup vendors. Today, these backup vendors are also confronting fierce competition from
nontraditional sources as users consider augmenting or replacing backup solutions with numerous server based replication, network-attached replication and array-based replication
solutions. The use of replication to deliver frequent snapshots of data is becoming more common for critical data. The proliferation of vendors and cost points for storage services — the
software-as-a-service (SaaS) market — is also becoming a viable option for a portion of an organization's recovery requirements.
Just as we have the concept of tiered storage for multiple service and cost levels of primary storage, we also have the notion of tiered recovery for backup data. Not all primary data is
equal. Thus, the protection of these differentiated tiers of data is not equal either, leading to the concept of multiple service levels, and possibly multiple technologies and even disparate
solutions to protect data. Users don't want a proliferation of point products. Vendors that offer a well integrated, feature-rich solution set at an acceptable price point will win out in the
marketplace over narrowly focused vendors.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 52 -
Network Configuration and Change Management Market Scope
What You Need to Know
Network configuration and change management (NCCM) for the enterprise market is moving from being exclusively the
domain of element management systems from network equipment manufacturers to becoming the province of vendors with
multivendor configuration management, change detection and compliance audit capabilities. Corporate audit and
compliance initiatives are the chief drivers changing this. Network managers will increasingly be called on to replace manual
processes with automated NCCM tools to monitor and control network device configurations, thus improving staff efficiency,
reducing risk and enabling the enforcement of compliance policies. Use this MarketScope to assist in vendor decisions and
to establish enterprise strategies for NCCM. However, prior to investing in tools, establish standard network deviceconfiguration policies to reduce complexity and enable more-effective automated change.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 53 -
Network Firewall Magic Quadrant
What You Need to Know
The enterprise firewall market is one of the largest and most
mature security markets. It is populated with mature vendors, and
shortlists are fairly homogeneous among horizontal and vertical
markets. Innovation has been limited, and opportunities for
reducing firewall unit costs have increased because of fewer
points of differentiation between competing products and
virtualization. Organizations' final product selection decisions must
be driven by their specific requirements, especially in the relative
importance of management capabilities, ease and speed of the
deployment, acquisition costs, IT organization support capabilities,
and integration with the established security and network
infrastructure.
DRAFT FOR DISCUSSION PURPOSES ONLY
- 54 -
Appendix B: System Architecture Build Plan Template
DRAFT FOR DISCUSSION PURPOSES ONLY
- 55 -