This post is one in a series of Cloud Native Transformation Patterns, which begins with Cloud Native Transformation Patterns: Introduction.
Though a successful Cloud Native transformation requires commitment and buy-in from across the entire organisation, the work itself is not “all hands on deck.” Instead, a Core Team of engineers and architects is created to lead the transition. This team is tasked with taking ownership of the project’s technical vision and architecture and then taking the first steps toward implementation.
Cloud Native technologies are new and complex, and implementing them requires an intense time investment to learn the tools and platforms. The Core Team is given the time to learn, and experiment with, all the elements in the execution plan. Concentrating upon and working through each new phase together, the team quickly and steadily builds the necessary knowledge and experience. When the project is ready, the Core Team stands ready to guide the rest of the organisation into the Cloud Native world.
What’s the Context?
The foremost context for Core Team is when a company is planning its move to Cloud Native and has begun considering resource allocations for the project. In general, institutional knowledge of Cloud Native technologies is low or even nonexistent, though there may be some teams who have independently gotten isolated, small scale Cloud Native setups running. Overall, though, there are many uncertainties. There may, in fact, be a general feeling of anxiety about coming changes to organisational structure and processes, much less migration from legacy tools and techniques to unknown Cloud Native replacements. This can lead to varied levels of motivation and commitment from team to team, and even manager to manager, within the organisation.
The Problem to Contend With
Responsibility for the Cloud Native transformation is placed in a team that ultimately has a low chance of success, due to some or all of these reasons:
- Lack of clear goals and deadlines
- Conflicting goals and deadlines
- Responsibilities diffused across too many teams
- Lack of alignment between team members working on the transformation
These challenges -- plus any others that may also pop up -- can lead to the transformation being derailed, reduced in scope, or in worst case scenario to the total failure of the initiative.
Management may not even be aware of this slow-motion failure, because many times project responsibilities have been divided up into disparate teams. Each team reports successful results and ongoing progress -- but their work is disconnected from that of other teams. Because the different pieces are disjointed and uncorrelated, the overall transformation progresses unevenly -- or, more likely, not at all. In most cases, executive management will only know that transformation is not succeeding after a year or even longer.
The Forces at Play
Some of the forces at play in this context include:
- Managers tend to distribute projects based on functional requirements, regardless of the interest and motivation of the teams and team members.
- Teams working both on both urgent and important tasks will tend to prioritize urgent tasks first. In many companies, there is a constant flow of urgent tasks which leads to constant de-prioritization of important tasks such as CN transformation.
- Large teams require a lot of easily parallelizable tasks available to become productive.
The Solution
An effective solution to either counter the negative forces or harness the positive ones: Create a single Core Team of 5-8 engineers and architects to lead the transformation. This team is dedicated to the process and allowed to prioritize their work on it. They are given sufficient resources to experiment, resource and implement the technology. The CoreTeam is also given access to any necessary supports, internal or external, such as trainings, conferences, expert consultants, etc.
Among others, Core Team responsibilities will include:
- Ownership of the technical vision and architecture
- De-risking the transformation by running a series of PoCs (Proof of Concepts) to test technical assumptions
- Building a Minimum Viable Product system
The Core Team’s work does not end with a successful initial implementation -- that was simply their initial task. Once the major parts of the transformation are up and running, the team continues to work on platform and architecture improvements to refine and optimize the system. Only a dedicated and constantly improving team can consistently dive deeper into technical challenges.
The New (and Improved) Context
As the transformation proceeds, the Core Team is leading has all the necessary knowledge and resources for successful execution. If there is any change in context, the Core Team will pick up on this and incorporate this into the vision and execution plan.
Other teams may join when they are ready, and they will be guided into the CN world by the Core Team.
Related Patterns
Gradual onboarding, De-risking technical project, Reference Architecture, Demo Apps, Cross-functional teams, Vision First, Focus on Bottlenecks, Common Services, Libraries & Tools
A real world example of the pattern:
In the past four years, all the clients that Container Solutions has helped guide through Cloud Native transformations have included a Core Team.
One of these organisations was HolidayCheck, the Switzerland-based travel reservations website. When we first began working with them, HolidayCheck had been trying on their own to introduce microservices, containers and some other related Cloud Native technologies. They had worked with limited success for nearly two years, held back by a lack of experience of working with these technologies even while keeping pressure on delivering new functionality.
The first and most important change we suggested was naming a Core Team of five or six engineers and give them three months to experiment with the technologies. They would work to create the vision, come up with an architecture, and implement a simple version of the platform. Their final task would be to successfully migrate one application to the new platform.
This change was extremely successful. The team delivered the results almost within the deadlines, gained a massive amount of knowledge and in only 4 months started onboarding other teams to the new platform. Following the successful onboarding, the team continued for additional several months to finish building the platform and educating others across the organisation.
Once the platform itself was reasonably feature-complete and the platform team fully functional, and once all the development teams were on-boarded, the Core Team was not needed anymore. The transformation was complete and HolidayCheck was ready for the future. At that point, the Core Team disbanded, and its members returned to their original teams and original tasks.
The patterns appearing in this blog are condensed from the forthcoming book, Cloud Native Patterns: Architecture, Design and Culture. Complete and in-depth information regarding each pattern, including case studies from real-world Cloud Native enterprise migrations, will be found in the book — please check back for updates regarding the publication date in 2019!
Feature image photo by rawpixel on Unsplash
Want to learn more about Cloud Native? Download our free eBook below:
Previous article
