☁️ Reducing the time to configure cloud environments
Context
The Centers for Medicare and Medicaid Services (CMS) relies on hundreds of systems and applications to support its programs and mission, for example, Healthcare.gov. Following the crash of Healthcare.gov in 2013, CMS created a custom cloud platform, CMS Cloud, to host its applications. The new platform was intended to:
Reduce the high operating costs of managing physical data centers.
Support applications that could adapt to large spikes in traffic, like the first day of open enrollment on Healthcare.gov or Medicare.gov.
Ensure compliance across the ecosystem of applications to make sure CMS's applications are secure.
However, by 2018, CMS struggled to add more applications to CMS Cloud because it took between 3-6 months to configure a cloud environment for an application in CMS Cloud.
I led a team of service designers that worked with CMS to rethink CMS Cloud’s services and increase adoption across CMS. During my time on the project, the problem we focused on was:
How might we reduce the time it takes to migrate a legacy or new application to CMS Cloud while ensuring compliance across the platform?
Our design team included four service designers, a project manager, and me. As the design lead, I was responsible for developing our approach, providing design direction, and ensuring our team could support multiple initiatives effectively.
How we approached the program
CMS strategic priorities that influenced our work
We worked closely with the CIO and CMS Cloud Business Owners to align our approach with their strategic priorities. Some of their top priorities included:
Upskilling CMS staff in cloud technology – The CIO was championing a parallel initiative to train CMS staff in cloud technology because few CMS staff had experience with managing applications in cloud environments.
Managing compliance across the platform – CMS wanted to offer a variety of services with compliance 'baked in' so they could save costs and maintain their needed security posture.
Balancing immediate program outcomes with CMS' priorities
When we started the project, the CMS Cloud team was configuring cloud environments without defined processes. To improve the cloud configuration experience and support CMS’ strategic priorities, we proposed an approach where we would map the current service experience while understanding users' needs. Our service mapping could then be used right away for standardizing the service experience while providing a roadmap for improving the experience. In addition, we shared the insights we gained from our research to inform related initiatives at CMS.
We structured our approach into the following phases:
1️⃣ Identifying archetypal ADOs and applications.
2️⃣ Documenting the end-to-end, front-to-back configuration experience.
3️⃣ Implementing improvements.
4️⃣ Measuring our impact.
Additional context... how an application gets into the cloud
Relevant actors
There are a variety of actors in the cloud configuration journey. Below are some of the important actors for understanding our work on CMS Cloud.
Application Delivery Organization (ADO)
A team of product owners, business owners, engineers, and other technical staff that manage an application for CMS. ADOs include both CMS employees and contractors.
CMS Cloud Business Owner
CMS staff from the Office of Information Technology who are responsible for CMS Cloud. When a new ADO is interested in moving to the CMS Cloud, the CMS Cloud Business Owners determine if they're ready.
Cloud Navigator
A dedicated support provider that guides each ADO through configuring their cloud environment and migrating their application. Cloud Navigators work directly with ADOs and Technical Support Staff.
Technical Support Staff
Operations and infrastructure engineers that manage, maintain, and configure each ADOs application environment. Technical Support Staff rely on tickets created by Cloud Navigators and ADOs to configure a new application environment.
CMS Cloud Team
Refers to the cloud navigators, technical support staff, CMS Cloud business owners, and other actors not described above that manage and maintain all aspects of the CMS Cloud platform.
How an application gets on to CMS Cloud
The process to get an application on CMS Cloud requires multiple actors and a lot of steps. Below is a high-level outline of that process. Our team focused on improving the cloud configuration journey.
Illustration of what it takes for an application to get on to CMS Cloud. Click to enlarge.
1️⃣ Identifying archetypal ADOs and applications
To provide a configuration service that would scale to the diverse population of ADOs and applications, our team members developed archetypes based on user research. With these archetypes, the CMS Cloud team could cater their approach to supporting ADOs based on criteria that were identified as important.
To build archetypes, we used a variety of research methods:
Interviewed subject matter experts to identify characteristics of ADOs and applications that may affect their needs.
Surveyed ADOs about their cloud experience and application characteristics to develop initial archetypes.
Interviewed ADOs from each initial archetype to better understand their needs when using CMS Cloud.
The five archetypes we developed focused on the effects of application complexity, as determined by its origin, and ADO cloud maturity. We mapped each archetype to a service model and identified their needs and level of support across the configuration journey.
Using the archetypes we:
Created initial intake questions that CMS Cloud Business Owners could use to qualify each new interested ADO and application.
Identified training needs to support the CIO's initiative for training CMS staff in cloud technologies.
Provided valuable context about ADO's needs throughout the configuration journey.
Illustration of the archetypes and how they map to the service models. Click to enlarge.
2️⃣ Documenting the end-to-end, front-to-back configuration experience
In parallel to developing the archetypes, we observed and documented active cloud configuration journeys and developed detailed service blueprints. When documenting the experience, we visualized how each of the services that make up CMS Cloud are orchestrated in the configuration process. Later, we developed a service catalog for CMS Cloud and mapped the lifecycle of each of the services.
Observing the front-stage and back-stage experiences
During our initial discovery, we observed the entire process for configuring cloud environments for two ADOs. Then, we used the observational data collected to visualize the configuration journeys of the ADOs and Cloud Navigators. Next, we interviewed Technical Support Staff and created service blueprints that combined the front- and back-stage processes.
The service blueprints we created helped standardize the configuration process and develop a roadmap of opportunities to improve the experience.
One section of a service blueprint. Click to enlarge.
Identifying opportunities for improving the service experience
With a full picture of the experience, we saw systemic challenges with the existing configuration experience. Some of what we learned:
ADOs didn't know what the end-to-end process looks like, where they were in the process, or what the next step would be.
ADOs were asked for the same information multiple times across multiple channels, which slowed down the process and frustrated ADOs.
ADOs did not have comprehensive lists of all options/services that made up the cloud offering.
Cloud Navigators didn't know the end-to-end configuration process and couldn't track the progress of each ADO's cloud environment configuration.
Support tickets that the technical support staff used to build an ADO's infrastructure frequently lacked required information.
As the program was scaling, the only way for new Cloud Navigators to get up to speed was by actively observing an entire environment configuration process.
3️⃣ Implementing improvements
The results of our first two phases allowed our team to implement improvements to the service experience continuously.
Some of the improvements we made included:
Creating a welcome meeting script, agenda, and slide deck for Cloud Navigators to introduce themselves and set expectations for the configuration process.
Consolidating the intake form and onboarding questionnaire to focus on required information and reduce repeat information requests and determine the level of service an ADO may need.
Creating a cloud training program for ADOs that wanted to migrate to CMS Cloud, but didn't have experience with cloud infrastructure.
Creating a Cloud Navigator handbook that documented the entire configuration process.
Creating a migration dashboard where Cloud Navigators and CMS stakeholders could view the status of any new environment the team was supporting.
Standardizing support staff ticket structure and templates to make sure they had everything they needed.
Storyboard of a new visual roadmap experience. Click to enlarge.
4️⃣ Measuring our impact
As we were rolling out improvements to the configuration journey, we worked with the data analysts on our program to build reporting that helped us track each step in the process.