If you’re migrating legacy applications from physical infrastructure to the cloud, you’re in a prime position to adopt a ‘You Build It You Run It’ approach to app management.

With the right implementation, this approach has several benefits:

• significant operational efficiencies
• more satisfied development teams, and
• improved application performance for your business overall.

Here’s three steps you’ll need to consider for success.

Step 1: Think about the organisational structure required to best support the apps once they are migrated.

In most cases prior to a cloud migration, there will be one large development team tasked with overseeing all applications.

Unless you change that dynamic, every application will sit with one large service management team once it’s migrated to the cloud.

For ‘You Build It You Run It’, you want to achieve a scenario where multiple, smaller development teams can focus intently on a reduced number of applications.

Ideally, those smaller teams will be involved in the process of migrating the applications to the cloud in the first place.

Before you can map which team should migrate which application(s), you need to determine:

• How many teams will we need?
• What applications will those teams migrate, and then maintain in the future?

Your team structures should be based on two considerations:

1. Ensure close alignment with the structure of your business organisation.

For example, in a migration project we conducted with Her Majesty’s Revenue and Customs —a non-ministerial UK government department involved in the collection of taxes and other regulatory regimes—we initially moved from one large-scale development team to four smaller teams.

• One team managed all applications associated with processing self-assessments.
• One team was responsible for VAT and business tax.
• One team managed everything associated with personal tax, aside from self-assessments.
• One team oversaw all other applications: international tax, health applications, and other comparatively lower usage applications.

With this prospective structure, we could plan the migration of each application to ensure it involved the team who would ultimately inherit its maintenance.

This approach is beneficial for many reasons. Once we start to scale the migration, it’s easier to scale the teams and add applications based on who will eventually run them. Then, when the initial migration is finished, each team will have a thorough knowledge of the way each app was migrated; knowing how they were moved, the teams are better placed to run them moving forward. Ultimately, by aligning your new teams to the business organisation, you create an end-to-end value stream.

2. Establish the rate of change for each application and calibrate each team’s responsibility accordingly.

Have you got applications that require frequent feature updates? And applications that remain relatively stable? You can use the rate of change to determine both capacity and resourcing for each new team.

For example, imagine you’re migrating 15 applications to the cloud. You might have a small team (say, four developers) responsible for an application that changes frequently. Then, another larger team (of twelve developers) might look after the remaining 14 applications which don’t change as frequently.

Across both teams, the rate of change will likely be the same, despite the imbalance in the amount of applications each team is managing.

Step 2: Consider any training or up-skilling that may be required for re-deployed team members.

Now you’re faced with a simple reality. If the team developing the application is charged with running it too—rather than having two dedicated teams for each responsibility—there’s likely to be a surplus of team members.

Remember, the purpose of ‘you build, it you run it’ is to create efficiencies; less hand-off between development teams can ultimately mean fewer hands required on deck.

Fear not. This is an excellent opportunity to upskill and re-train team members for deployment in new capacities.

Consider the existing skill set and pre-disposition of each team. This can help to guide your decisions and approach to upskilling for role redistribution.

For example:

• People with experience in Incidents and Support have valuable skills in triage. With an ability to identify and locate issues quickly, these team members can make highly effective Technical Analysts.
• Alternatively, if team members from Incidents and Support have basic coding skills, they can be re-deployed as Automation Testers with some simple re-training.

These are just two quick hypothetical examples.

Now’s the time to reflect and consider: What new options will be open to people in the wake of the migration?

Step 3: Use data to strategically determine which applications will benefit from ‘You Build It You Run It’. And just as importantly, which won’t.

Once you’ve mapped the appropriate structure for your teams and established rates of change for each application, it’s time to focus on incidents.

You need to establish the number of incidents for each application. Are there some applications that experience more incidents than others?

If the answer is yes, use this information to guide and prioritise your training efforts with certain teams throughout the migration process.

For example, in our project with Her Majesty’s Revenue and Customs, the team discovered higher rates of incidents on the Self-Assessment tax applications. These applications were also some of the highest used and required the most frequent updates (highest frequency of change).

Given that context, it was clear we needed a strong focus on training the team involved in migrating—and who would then eventually run—the Self-Assessment apps.

From there, in conjunction with the migration of the Self-Assessment apps, we set about developing a cultural and technical environment to make it easier for the dedicated team to run all Self-Assessment applications in future.

Importantly, incident data can also help you to determine which applications will not benefit from ‘You Build It You Run It’.

Sometimes, there simply aren’t enough incidents to validate a separate team dedicated to the development, migration, and maintenance of an application. Especially if the applications do not serve a business-critical function.

Rather than the expensive rates associated with paying local developers to maintain support around the clock, there could be a more cost-effective approach in offshore support. This is particularly true when applications don’t need to be available 24/7.

The following questions and considerations will help you to identify any applications that may not benefit from ‘You Build It You Run It’:

• How often does this application need to be available?
• Is the application serving a business-critical function 24/7, 365?
• If the application goes down in the middle of the night, can we justifiably wait until the morning—local time—to reboot it and regain availability?

If you don’t need to support an application, and that application doesn’t experience a high rate of incidents, ‘You Build It You Run It’ may not be the best approach.

Ultimately, ‘You Build It You Run It’ is all about creating efficiencies. And sometimes, there are efficiencies to be gained in acknowledging the presence of a more viable option.

Contact us!

We hope you find this useful.

For more information about cloud migration or the HMRC project take a look at our HMRC case study.

If you’d like us to share our experience with you, please get in touch in the form below.