When we talk about microservice architecture, a set of autonomous, practically independent of each other, components appears before our eyes. Insulation is the cornerstone of any microservice system. But, even if we are confident in our ability to create microservices, the question arises – how ready is the organization structure for such a task? Are we able to capitalize on the opportunities and limitations brought by microservices? How to adapt teams to work successfully with this architecture? In this article we will try to discuss the organizational aspect of developing a microservice system.

Traditional
approach

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.

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.

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 is
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 (additional
costs 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 due to the reduction of the hierarchy of the organizational
structure (up to 11%).

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 into cross-functional teams, while
deepening their experience and generally improving team autonomy and the decision-making
process. At some point, the functional commands are completely transformed into
a set of cross-functional commands.

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, maintenance and support, the most significant of which are:

  • Synchronization (consistency) of data;
  • Data obsolescence
  • Security;
  • Interservice communication;
  • Service discovery;
  • Distributed logging and monitoring;
  • Cyclic dependencies between services and debugging;
  • Testing;
  • Reliability and fault tolerance;
  • Performance.

Most of
them are not local tasks of any particular microservice. These are the 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;
  •     API architecture and fix;
  •     Self Service Data;
  •     Experimental infrastructure and telemetry;
  •     Interaction with the client

Stand-alone
microservice teams get the opportunity to use the platform to accelerate
support for 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 to adapt the strategy in the organization;
  • the need for additional resources – the platform team needs to study the specifics of various microservice teams, as well as form 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.

Conclusion

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 strive to create, we must consider
the need and possibility of organizational transformation.