How Build an Accelerator for Cloud Migration Cloud-Native Transformation Model

Cloud Migration Cloud-Native Transformation Model

adminMay 11, 2022

1 375 6 minutes read

When I was building an architecture capability system recently, I happened to see “Cloud Native Transformation” (English photocopy version) by O’Reilly Publishing House – a book about cloud-native transformation, combining cloud-native migration + organizational culture transformation. dimension. The book spends four chapters on the relevant patterns of cloud-native transformation. The types of patterns in the book are strategy and risk reduction, organization and culture, development and process, infrastructure, and cloud. As a half-transformation “brick home”, I am probably familiar with some of these patterns, and I have thought about writing-related patterns in the past, but I have never had the time to write them.

Therefore, in this article, I will combine the cloud-native transformation 
model and developer experience design to reconstruct the cloud-native 
transformation model system. So, I rescale it into five dimensions and describe 
only some important patterns (relative):

Reshape the team. Relevant patterns such as core transformation team, enabling team, transformation office, team topology
Shared cognitive community. Relevant patterns such as internal open source, special interest groups, technical topic communities
Automate “developer as a service”. Related patterns such as self-service, developer center
Organizing collaborative design. Related patterns such as Team API, Technical Evangelist
Build a bio-type culture. Relevant patterns such as Legacy Organization Modernization, Design Thinking, Proof of Concept

PS: The pattern here is reworked by me. For readers who want to go deeper into related transformations, due to the different knowledge systems, it is recommended to read “Cloud Native Transformation”, hereinafter referred to as CNT.

Mode 0: Shift in mindset

There are too many discussions on articles related to cloud-native concept change, and I don’t want to discuss too much, mainly the following three points.

Legacy Culture Migration

For most organizations, legacy systems are not a challenge for developers, and developers have plenty of plans b to improve legacy systems. Every developer is smart but is limited by the cultural factors of the organization, and it is often difficult to confidently make relevant decisions – from a risk-taking perspective.

So, you can rethink, the technical issue is not the core issue, the legacy cultural issue is.

Developers first

Secondly, in the process of cloud migration, another important factor is developer experience design, that is, considering the problem from the developer’s level. A relevant counter-example in this regard is that some requirements are biased towards a KPI-style driving approach, and the internal objection to the platform is naturally growing.

Developers, need to solve their problems efficiently.

Product thinking: ☁ The cloud platform is the product.

Finally, an often mistakenly adopted model for building cloud platforms is to adopt a platform mindset. After switching to product thinking, many questions are easily solved, such as: Why do internal technical operations? Why do you need an internal tech community, etc.? For example, in the Thoughtworks Technology Radar, a related technical practice was recommended in 2017: “Applying Product Management Thinking to Internal Platforms”. It means building empathy with internal consumers (development teams) and collaborating with each other on design.

Like any other product, good product management is about creating products that consumers love.

Pattern Set: Reinventing Team Shape

For medium and large organizations, implementing cloud migration means that multiple teams such as infrastructure, cloud-native platforms, and cloud-native frameworks are needed to help various teams of various sizes within the organization to migrate. Therefore, there will be a series of team modes such as Core Team, Platform Team, and SRE Team mentioned in “Cloud Native Transformation”. From the perspective of modes, they are all platform teams and empowerment introduced in “Team Topology”. team mode.

Therefore, we combine the platform/product thinking, reorganize the team form, such as the core transformation team, or use the team topology theory to re-divide the organizational team.

Core Transformation Team

The Core Team got from Cloud-Native Transformation, is expected to have groups of designers and engineers focused on finding the best change way and executing it en route. It reduces risk in the transition while the team gains experience that will help them later join the rest of the team.

Simply put, it is to participate in the team’s cloud-native migration tasks, solve problems as much as possible, and summarize common problems. This way, it can be quickly rolled out to other teams.

Transformation Office

Transformation is essentially a change and therefore requires management. Therefore, you can refer to the transformation office mechanism adopted in agile transformation, which is used to ensure consistent goals, efficient communication, and rapid response from management to grass-roots teams in the transformation process, so as to effectively achieve organizational transformation goals.

Empower the team

More and more large-scale IT organizations, such as Tencent’s engineering performance coaches and Huawei’s software coaches, have developed professional empowerment teams that help different teams improve their capabilities. That is, to improve the IT capabilities of the organization through professional talents, they can better improve the core transformation team for related capabilities

Team topology

Team topology is a way of re-dividing an organization’s team building. It reconstructs the team elements within the IT organization and divides it into four types of teams: product-oriented teams, enabling teams, complex subsystem teams, and platform teams, which interact with each other to form the organization’s team model.

The introduction of the team topology model allows us to analyze the team shape required by the organization more quickly.

Pattern Sets: Communities of Shared Knowledge

The intention of the community with shared cognition is to build an internal cloud-native community and share relevant cognition to greatly accelerate the speed of transformation. Such as sharing successful experiences, problems encountered, desensitizing, and recording related content.

Simply put, let the team help the team.

Internal open source project

Endogenous means integrating open source methodologies (best practices, collaborative approaches, architectural patterns, etc.) into how an organization builds and releases software to create an open source-like culture within the organization. For cloud-native transformation, it can be an example open-source application, open-source example architecture, open documentation project, template application, etc. An example application is often more useful than a thousand documents.

Technology Topic Community

Through internal and external IM around the theme of cloud-native, relevant technical communities are launched to allow developers to help developers solve problems.

Special Interest Group (SIG)

Special Interest Groups (SIGs) Groups that focus on specific topics, with the purpose of adding attention to those topics, or focusing on development. Based on this model, organizations can build a series of interest groups around web frameworks, databases, containerization, platforms, etc., and use experts (the core difference from topic communities) to solve technical problems on specific topics.

Pattern Set: Automating “Developer as a Service”

This part of the model is mainly considered from the platform level, which is used to improve the efficiency of the cloud platform and reduce the fragmentation time of platform developers.

self-service

Self-service refers to providing a series of automated services that allow users of platforms or tools to quickly complete the use of related technologies. All the while, there is no requirement for direct help from the platform group.

Based on this model, a series of designs and measurements of developer experience needs to be done.

Developer Portal

Anyone who understands.

Bezos API Authorization

It comprises a progression of updates, for example, All groups should give information and different capacities as administration interfaces. For the platform, all its support for developers should be API-able to enable high-cohesion-low-coupling teams.

Pattern Set: Organizing Collaborative Design

In this series of modes, the emphasis is on designing the boundaries between the team and the organization, so that team members can pay more attention to their own interiors.

internal evangelist

This role is often used in companies that are productizing technology, but it also applies to medium to large organizations. Its responsibility is to share opinions, give feedback, help other teams, provide feedback to platform team technology, establish communication mechanisms, etc. It can be used as the interface between different teams and the platform team to improve the efficiency of the platform team.

Team API

Team API is a concept mentioned in “Team Topology”, which contains related content such as code, version, documentation, practices, and principles. One of the goals is to allow teams to operate independently on a contract-based, API-based model. It can cut off the code base dependency between teams – that is, the B team cannot directly modify the A team’s code, it should be in the form of a Pull Request or pairing.

Pattern Set: Building a Bio-Type Culture

In the future, we will still encounter more related challenges.

PS: I’m not good at writing this.

Legacy Organization Modernization

Compared to legacy systems, I think legacy organizations are probably the biggest challenge people will have, so I don’t need to go into details. Read more about software modernization

design thinking

Design Thinking is an innovative, human-centered approach to solving complex problems that leverage the designer’s understanding and approach to match technical feasibility, business strategy, and user needs to translate into customer value and market opportunities.

other

I really like the cloud-native maturity model in the book, but I forgot the source and I don’t want to look for it. It is probably in the following dimensions: culture, product/service design, team, process, architecture, operation and maintenance, delivery, Provisioning, and infrastructure.

However, this model is problematic, with too much bias in granularity and dimensionality.