Large business corporations have historically been organized as a set of functional units: financial, marketing, operational, HR and so on. The need for digital automation of business processes has prompted the company to form another functional unit – the IT department. In turn, the IT department was subsequently divided into functional teams of programmers, testers, system administrators – by the principle of combining groups of specialists with a certain set of knowledge and functions. The pattern of organizational thinking is seen quite clearly. And its sustainability is associated not so much with the reluctance to make efforts to analyze management effectiveness, but with the great inertia of the processes and the lack of obvious challenges that would jeopardize the success of the organization.
However, the separation of personnel according to their functions inevitably creates a distance between the teams. When software testing is performed by a separate team of testers, developers focus solely on writing code and care little about its testability. As a result, the software product has numerous deviations in specifications and, even worse, teams are gradually turning into separate ones.
Note: A Silo Mentality is a reluctance to share.
information with employees of other units of the same organization. Such
behavior often leads to a decrease in organizational effectiveness and, at worst
case leads to the destruction of corporate culture.
Moreover, in strictly functional units, the decision-making process inevitably slows down. The costs of coordinating team work schedules are increasing. The qualifications and experience of the same testers, for example, need constant balancing taking into account the specifics that are required by development teams. Yes, and a high entry threshold and the need for knowledge transfer slow down the process: external experts require constant switching of the task context to serve requests from various teams.
Thus, when companies with a traditional organizational structure were faced with the need for an almost instantaneous response to challenges continuously coming from the business, their IT departments were unable to ensure the effectiveness of the solutions. The rapid evolution of technology only exacerbated this lag and complicated the task of maintaining the required level of motivation and professionalism in dedicated teams serving development. And since the main objective of IT was and is to effectively ensure the full life cycle of stand-alone products (including microservices), the need for reorganizing teams from horizontally oriented functional teams into vertically oriented, self-sufficient and autonomous teams became obvious.
Cross Functional Commands
According to Wikipedia, a cross-functional team is a group of people with various functional tasks and working towards a common goal. In today's business, innovation is a leading competitive advantage. Cross-functional teams foster innovation through creative collaboration – both within the team and with other teams in the organization.
Figure 1. Functional and cross-functional teams.
The cross-functional microservice development team consists of developers, database engineers, testers, infrastructure engineers and other specialists. Such teams make modifications faster than functional ones, because they can make their own decisions and work independently of other teams. By focusing on improving development cycle times and implementing continuous deployment, these teams are able to solve problems almost instantly.
Shamim Mohammad, IT Director of CarMax, says: “In a rapidly evolving world, it’s important to create flexible, cross-functional product teams that can quickly sort through solutions to a problem. They are endowed with all the necessary powers and the management never tells them how to solve the problem, but only what it consists of and what are the key performance indicators with which to work. This approach allows you to improve feedback, significantly speed up the development process, use trial and error to ultimately find the best solution for customers and partners. We also found that teams are more reasonably at risk and creative in achieving their goals. If you don’t have such fully integrated teams, take a look and think, are you ready for a successful digital transformation? ”
According to surveys of the Massachusetts Institute of Technology and the Deloitte Global Human Capital Trend, companies with a high level of digitalization of processes in the development of their innovations are extremely dependent on the presence of cross-functional teams. 83% of mature companies admit they use cross-functional teams. Despite increased operational complexity (they account for up to 16%), companies received significant improvements in operating indicators (up to 53%), improved access to resources and assets (up to 37%), greater flexibility (up to 12%) and a decrease in the level of excessive bureaucracy thanks to reducing the hierarchy of organizational structure (up to 11%).
Figure 2. Benefits of adapting cross-functional teams. Statistics.
A smooth and gradual transition from functional to cross-functional teams is quite possible. The first cross-functional teams are formed around the most valuable business opportunities that require constant attention and quick response from IT. Members of functional teams move to cross-functional teams, while deepening their experience and generally improving the team’s autonomy and decision-making process. At some point, the functional commands are completely transformed into a set of cross-functional commands.
Figure 3. Transition to a cross-functional team.
The emergence of platform teams
However, the mere presence of cross-functional teams does not mean that we have provided the best conditions for the creation of microservices and most effectively meet the requirements of the business. There are still a number of tasks related to the development, support and maintenance, the most significant of which are:
• Synchronization (consistency) of data;
• Data obsolescence;
• Interservice communication;
• discovery of services;
• Distributed logging and monitoring;
• Cyclic dependencies between services and debugging;
• Reliability and fault tolerance;
Most of them are not local tasks of any particular microservice. These are tasks of the system level as a whole and more relate to the infrastructure of the microservice system. Many organizations call this infrastructure a “platform,” the foundation on which microservices are created and developed.
In fact, with the growth of the organization, its level of dependence on the technologies used increases. Multiple areas of inconsistency arise more and more often, which leads to the organization losing its ability to quickly advance in the market, assess emerging opportunities, and innovate. A possible way out of this situation is the transition to the use of a “digital platform” consisting of “blocks of opportunities” in the most important areas of the organization’s activity (such as the infrastructure for delivering solutions or interacting with the client). Digital platforms minimize the gap between concepts and investments; improve system stability and, more importantly, improve the microclimate within the organization.
Many IT organizations are wondering: how many staff need to be allocated to work directly on the "product", and which to work on the "platform"? One of the most important arguments for the benefit of such a separation of personnel is the following: a digital platform needs owners who are dedicated to ensuring compliance with the principles declared by the platform, having extensive experience and a high level of expertise in the development, implementation and maintenance of platforms.
To illustrate the need for the introduction of digital platforms as an independent product, we turn to one of the fundamental principles of microservices: the use of smart filters and simple channels.
No matter how simple the channel, it still requires an owner. And if there are many teams, each of which “owns its own microservice,” then who is responsible for their interaction? For the discovery of services, for security, monitoring at the level of the whole system (or even at the organization level, if it comes to the intersystem level)? Who will be responsible for comprehensive testing? If we begin to assign these responsibilities to particular microservice development teams, what will be our strategy and selection criteria? And finally, will such teams (development, I remind you) remain flexible and autonomous in their products? It seems that the time has come when the platform development team should appear on the stage!
The platform development team (abbreviated as platform team) is a specialized cross-functional team that manages the digital platform – the basis for the formation of APIs, tools and services, the knowledge and support of which are organized into an independent internal product.
The digital platform strategy is focused on providing business value. To eliminate inconsistencies in building a microservice ecosystem, the strategy focuses on five main areas of technological solutions delivery:
• Delivery infrastructure;
• Architecture and patch API;
• Self-service data;
• Experimental infrastructure and telemetry;
• Interaction with the client.
Figure 4: Digital Platform Strategy
Autonomous microservice teams get the opportunity to use the platform to accelerate the support of the functions of their products and at the same time reduce the degree of necessary cross-team coordination.
Undoubtedly, the concept of dedicated specialized platform teams has both advantages and disadvantages:
The benefits include:
• Unification and sequence of communication channels;
• Providing control while maintaining the flexibility of individual development teams.
The disadvantages include:
• Time costs for adapting the strategy in the organization;
• Need for additional resources – the platform team needs to study the specifics of the various microservice teams, as well as formulate requirements for creating a unified platform;
• If the platform is not implemented correctly, it will become a bottleneck in the organization’s processes.
Thus, we must take into account possible problems and risks when planning team and cross-team activities within the organization.
Synergy of interaction
So, how can interaction with the platform team occur? There are several possible approaches, among which two can be distinguished:
– Using the platform as a product. The platform team regularly updates the platform versions and provides it to microservice teams as a product API. This can be an image of a virtual machine, or a container with improved (compared to the previous version) capabilities, or an extensible framework.
– Penetration into microservice teams when a representative of the platform team is present in the microservice team (or one of the members of the microservice team is allocated for communication with the platform team). Using this approach, microservice teams have the ability to provide faster feedback with the platform team and can initiate the process of introducing changes to the platform.
Figure 5: Interaction with the platform development team: on the left is the platform as a product, on the right is penetration into the teams.
In conclusion, I would like to emphasize once again that the organizational structure should make it possible to effectively use the advantages of architectural and technological choice. Conway’s law states that an organization seeks to create projects that are copies of the organizational structure. But I am also inclined to believe that the opposite is also true: the structure of the system tells the organization the structure that is best suited for its implementation.
To ensure the necessary quality of response to business requests, the modern IT industry must have the highest level of organizational flexibility. And, in order not to lose the effectiveness of the system that we are striving to create, we must consider the necessity and possibility of organizational transformations.