The University of Kentucky has over 30,000 students and staff and houses its on-campus data center in the aging McVey Hall building. McVey Hall no longer has proper backup power or cooling and the university's computing needs have outgrown the building's capacity. The university president and provost want to use the space for academic purposes. Moving computing infrastructure to the cloud would help address budget and resource constraints while improving disaster recovery capabilities and flexibility to scale with demand. The university has begun moving some systems like email to the cloud and is evaluating options to migrate more services off-campus.
1 of 16
More Related Content
Don’t Rain on my Service Management Parade
3. About the University of Kentucky
Demographics
30,000+ students
12,500 staff
2,300 faculty
Flagship University
Land Grant
$992M Endowment
784 Acres
Offices in all 120 KY counties
IT Staff
250+ Campus IT
250+ UK Healthcare IT
200+ College/Department IT
4. Why make the move to the cloud?
McVey Hall
Built – 1928
Currently houses
UKAT Data Center
No generator backup
Old wiring and power grid
Difficult to maintain proper cooling & humidity levels
Computing footprint at maximum
Disaster Recovery plan no longer viable
University President & Provost want
space for academic purposes
5. Shrinking operational budget
Longer gaps in hardware refresh
Limited opportunity to change
architecture
Why make the move to the cloud?
Increasing labor
time spent on
maintenance
functions vs new
project/creative
solution work
Infrastructure team not
able to scale configurations
to meet peak loads for
critical academic events
Operational Challenges
6. Why make the move to the cloud?
Other RisksNatural disasters Security
Resource Management
10. Positioning for Maneuvers
1.Define needs – How to position IT as a Service
2.Contract a cloud broker
3.Determine scope of cloud offerings
4.Put RFPs on street
11. UKAT Maneuvers to get out of McVey Hall
Maneuver Current State
1) Move ERP system to private cloud In strategy phase – determining
configuration requirements and scope
2) Move server and VM farms Documenting all servers and their
purpose – evaluating VM strategy
3) Move High Performance Research
Computing to co-location facility
In strategy phase – documenting
research needs
4) Move email/office tools to Microsoft
Office 365
In process
5) Everything else Not started
Each individual area was their own snowflake – unique and unlike any other area – and each area had their own set of snowflakes
Of course, when you have the right set conditions, all the snowflakes combined together into a blizzard
IT then setup a set of process to recover from the blizzard and this became the normal operations
Convincing people they did not need to have a snowflake became a challenge
Leadership buy in
Education about cloud – reading Cloudonomics – gap between CIO and leadership in thinking
Operational Silos – lack of current configuration and process documentation – communications issues
Lack of skill sets in DevOps, Collaboration, Vendor Management, Remote Work
Getting staff through their periods of “grief” over the change -
Determine what cloud offerings you are going after – IaaS, SaaS, hosted servers/storage, etc.
Hiring a broker – 3 reasons – a) to help you navigate the market b) to help identify best/lowest cost entry points, c) act as a “futures” agent - to help you secure lower price points of future service(s) use
Something brilliant here
Competitive bids from the market – helps establish “sole source” needs
Service catalog – redrafting – found the IT team did not understand the service delivered or how service components are bundled – service offerings currently based on hierarchal structure – identifying new opportunities to bundle service components
Service Levels – doing analysis of our current targets and how cloud vendor standard agreement may change the target
Free vs freemium vs premium offerings
Changes to Incident and Request models
1 Our current state roadmaps not well documented – made it difficult to think about transition to a future state
a. documentation of process and technical components
b. lots of assumptions on “how things worked”
c. exposed “silo thinking”
2. Communication
a. Using templates help “standardize” the messaging/marketing
b. Consistency in messaging took good planning
c. The new terms need immediate definitions – not defining contributed to confusion and frustration
d. No matter how well we planned and communicated, some team members converted the message into something it was not intended to be
3. Reaction – Fear, Anger, Not Impressed, ambivalent – planned for each reaction, made sure to have talking points on how to handle these emotions
4. Training – Had to define the new skills needed and who should be pursuing obtaining the skills – balance expectations (not everyone could move forward to the future state) – Work with line managers to ensure skills development incorporated into learning plans –
Reading Cloudonomics – understanding what the cloud really is and the ecosystem around the cloud
Reading “The Goal” and “The Phoenix Project” to build understanding of theory of constrains and devops
5. Talking about “the future” with line staff is very difficult without plan – did not deal well with ambiguity