1. Business Continuity and Disaster Recovery CIO Strategic Initiative Discussion
June 15, 2015

2. Agenda Introductory comments on CIO Initiative (Ben G)
Central Administration Initiative (Sue W)
Goals
FY 15 work
Current DR timeline for CA
Appendix (ex of DR options)
CIO Initiative discussion and next steps (All)

3. Central Administration BCDR Initiative

4. HUIT Business Continuity Vision
10/30/2017
HUIT Business Continuity Vision
HUIT Business Continuity Vision
To provide technology services that can withstand a broad range of incidents and disasters
Strategic Objectives
Guiding Principles
Key Performance Indicators
Strengthen our ability to recover the University’s most critical existing systems
Design new systems to incorporate Business Continuity
Define and operationalize Crisis Management and Disaster Recovery processes
Academic and administrative needs drive priorities and requirements.
Ensure clear visibility into trade-offs between investment and risk
Solutions based on a small set of standardized options rather than custom solutions for each situation
Our plans and solutions need to be communicated, understood, tested, and validated.
Solutions maximize “bang for the buck”.
Qualitative understanding of risk and exposure
Assessment of maturity in our business continuity systems and practices
Number of critical IT services that have a regularly tested DR solution.
Existence of documented and implemented reference architectures
Uptime or # of major incidents for critical infrastructure (network, power, etc.)

5. Goal Framework
The Business Continuity and IT Disaster Recovery (BCDR) initiative has three primary goals:
Goal #1: Establish and operationalize crisis management processes to handle a broad range of incidents/crises
Goal #2: Change our existing systems to be able to recover from disasters in a way that meets the business’ needs
Goal #3: Change the way we implement new technologies to incorporate business continuity

6. Goal #1 –FY15 Update
The following activities were accomplished in 2015 to establish and operationalize crisis management processes:
Held Crisis Management workshops fall 2014
Developed runbook with clear processes to manage a crisis, roles and responsibilities outlined, checklist of tasks.
Trained staff on Crisis Management
Held Spring Emergency Management training
Conducted Tabletop exercise in June 2015 in conjunction with Harvard’s Emergency Management Team
FY 15 Result: Crisis process has been developed, documented and tested with HUIT’s Emergency Team. We are better prepared to manage an IT Crisis!

7. Goal #2 – FY15 Update
The following efforts were completed to improve and protect our current systems from a disaster:
Completed assessment for CA critical applications (criticality, roadmap, dependencies)
Developed approach to migrate applications into the cloud over three years while embedding DR in design-
Designed first critical 1 application for cloud deployment
Identity and Access Management systems for high availability and disaster recovery in AWS (July release)
Developed option to support interim DR support-
Design and tested interim Premise /DR solution
Trialed several products (Vcloud Air, Cloud Endure)
POC of for Library (Aleph Development Environment) (Complete)
Exploratory discussions with PeopleSoft for DR implementation (In Process)
Results: We have a plan to improve DR through full cloud migrations as well as an interim cloud DR solution. We have designed and will soon deploy our first critical 1 application in the cloud.
LDAP – dif files
PIN -

8. Application Assessment of CA
*Current contract provides a bare-metal DR solution, majority of applications at Sungard do not conduct regular tests.

9. Application Criticality Ratings
DR Tier
Application Description
DR Scenario
Foundational - Critical systems dependent on infrastructure (e.g. networking, connectivity, DNS) Support infrastructure for critical business systems
High availability – no interruption in service, no degradation in service 1
Mission Critical - Critical services impacted, customer interactions are interrupted (Critical business function. 2
Critical - Services continue through data collection and transaction processing may be delayed. Operational workaround exists.
Failover – minimal to no interruption in service; degraded service is acceptable 3
Important - Support services that can fail-back to manual execution. System loss may slow, but will not stop business critical activities
DR scenario – application recoverability outside of 30 days
Deferrable
Non-Critical

10. Goal #3 – FY15 Update
The following initiatives are underway to change the way we implement technologies as they relate to DR:
Included DR requirements as part of cloud migration 5 step process and all new system architectural review (Completed)
Incorporate DR questions into PMO templates for all new systems (Completed)
Result: We are thinking about DR needs upfront before we design a system and address requirements as part of the design process.

11. Current DR Plan with Cloud Migrations
Interim DR CloudEndure**
Cloud / SaaS Migration
FY16
FY17
FY18
Foundational (Tier 0)
Infrastructure
OID
Net
TWS
SunGard* -
Cloud
Cloud Cloud
Mission Critical (Tier 1)
CS - Blackboard
CS - CS Gold
CS - Message Me
Aleph
Ace
IAM
SIS
TLT
Yes No
SaaS
Partial SaaS
SaaS-
- SaaS
TBD-
- - -
Critical (Tier 2)
PeopleSoft
Yardi
Oracle eBusiness**
GMAS
CAADS
iSites
Data Warehouse
Yes-
No -
- -
- TBD-
TBD -
*Current contract provides a bare-metal DR solution
**Exploration of Oracle virtualization in FY16, prerequisite for cloud or interim Cloud Endure

12. Appendix

13. AWS Physical/Logical Architecture
US West
Region
US East
Region
Availability Zone 1
Availability Zone 2
Availability Zone 1
Availability Zone 2
Availability Zone 5
DC-e-1a
DC-e-3a
DC w-1a
DC-w-2a
DC-e-2a
DC-e-1b
DC-e-3b
DC-e-1c
Regions are physically and logically independent
Each Region has 2-5 Availability Zones (AZ)
Each AZ is comprised of 1-6 Data Centers* (though act and perform as one logical DC)
AZs are similar in concept to 60 Oxford St. + 1 Summer St model at Harvard
*Exact number and location of AWS data centers is not publicly released

14. Standard Cloud Architecture – Active / Active
“Good Design” Multi-Availability Design
Availability Zone (AZ) 1
Availability Zone (AZ) 2
Synchronized
Key DR Architecture
Active/Active (multi-AZ) design
Relative Cost $
Typical Recovery Time
< 5 min.
Protects Against
Individual DC or AZ Failure or Degradation
Appropriate for
All Production Applications
Similar to
1 Summer St Oxford St. HA design

15. DR Cloud Architecture - Pilot Light
Copy code, configuration, data
<15 min lag using snapshots and replicas
Synchronized
AZ 1
AZ 2
Region 2
West
Region 1 East
Key DR Architecture
Maintain minimal live infrastructure in remote region
Relative Cost
$$$
Typical Recovery Time
< 1 hour
Protects Against
Regional Failure
Appropriate for
Select Critical 2 Applications
Similar to
DR Contracts at Sungard