Microservices has been the catchword in the DevOps world for a long time, with digital natives like Netflix, Amazon, and Twitter setting new benchmarks with this potentially disruptive technology. However, implementing microservices necessitates a change in team dynamics. Check out the essential checklist below for building cross-functional teams.
When talking about microservices, our mind draws a mental picture with a set of components having little or no dependencies between each other. Isolation, independence from other services, is the basic concept of microservice systems.
But how can you handle microservices in an organization? Are teams really capable of capitalizing on the opportunities and constraints imposed by microservices? This article is about the organizational aspect we must consider to achieve these goals.
The Traditional Approach
Traditionally, large enterprises are organized as a set of functional units per department. When digital automation emerged, enterprises introduced their own IT departments as another functional unit and split them into teams of programmers, testers and system administrators. Its rigidity was not due to a reluctance of putting additional efforts into analyzing management efficiency, but rather the substantial inertia of organizational processes and the lack of challenges that would threaten organizational success.
Separating teams by function creates distance between them. If a separate QA team does testing, then developers focus strictly on writing code and often do not concentrate on testing, which could result in a product with features that don’t work properly. Even worse, teams might end up getting siloed, which reduces the organization’s efficiency and can contribute to a damaged corporate culture.
Moreover, the decision-making process is far too slow in strictly functional organizations. It takes a long time to reconcile a service delivery schedule among teams where employee experience and skill sets have to be aligned. The learning curve and knowledge-sharing slows down processes as workers from infrastructure and QA teams face a constant task switch while servicing requests from various development teams.
When IT with a traditional organizational structure faces the need to react to business demands almost instantly, it’s incapable of supplying the technology response required. Rapid growth in the number of technologies and their evolution only exacerbated this lag, especially when combined with maintaining skills and experience in the dedicated departments. Since the main task of IT is to effectively supply the whole product lifecycle, developers and operationalists should be organized into autonomous, self-sufficient teams.
Cross-Functional Teams
A cross-functional team is a group of people with different functional expertise working toward a common goal. Today, innovation is a leading competitive advantage and cross-functional teams promote innovation through a creative collaboration process.
A cross-functional microservice’s team consists of developers, database engineers, testers, infrastructure engineers, etc. They ship code faster than functional teams because they can make their own decisions and can focus on improving their cycle time, implementing continuous deployment in order to resolve challenges almost instantly.
The transition from functional teams to cross-functional teams can be a smooth and evolutionary process. Cross-functional teams are formed around the most valuable business capabilities that require a fast response from IT. Members of functional teams move to cross-functional teams, deepening their expertise, improving team autonomy, and aligning the decision-making process. At some point, the functional team is completely transformed into a set of cross-functional teams.
Learn More: Why Businesses Resort to VPNs During COVID-19 CrisisOpens a new window
The emergence of Platform Teams
Even having an ideal cross-functional team does not mean you have achieved the best conditions to produce microservices and address business demands in the most efficient way. There are still lots of challenges for development and operational teams, including:
- Data Synchronization (Consistency)
- Security
- Services Communication
- Discovery
- Distributed Logging, Cyclic Dependencies of Services and Debugging
- Data Staleness
- Testing
- Monitoring and Performance
- DevOps Support
- Fault Tolerance
Many concerns are common to cross-cutting across the set of microservices. More precisely, the concerns are about the infrastructure serving as a foundation for any given microservice, not about the microservice itself. Many organizations call this infrastructure the “platform†or underlying environment on which microservices can be built, executed, and evolved.
Once enterprises reach a certain size and level of dependency on technology, areas of friction emerge. Without addressing these, businesses struggle to move faster, explore new opportunities, and innovate. The answer is a platform made up of “blocks†of capabilities in focus areas, like delivery infrastructure and customer touchpoints, all honed to perform, deliver, and come together to lift the entire organization. Platforms can enhance system stability and best of all, create happier teams.
Engineering organizations have a common problem: how many people should be working directly on “the product†versus how many engineers should be working on “the platform?†Why? One major argument is: the platform needs ownership, dedication, and specialized expertise.
One of the pillars of microservices is to “use smart channels and dumb pipes.†But even a “dumb†pipe requires governance and ownership. If a set of teams each owns a microservice, who is in charge of the channels between them? Who will reconcile service discovery, security, monitoring etc. for the whole service landscape? Who will deal with tools and approaches for continuous and comprehensive testing? If you assign these responsibilities to product teams, then what is the strategy for doing so? Finally, will the product team remain autonomous and agile in their products? This is the point when the platform team appears!
The platform team is a dedicated cross-functional team that manages a digital platform, a foundation of self-service APIs, tools, services, knowledge, and support that are arranged as a compelling internal product.
The blueprint of the digital platform strategy serves for platform-building and is comprised of five essential pillars. Breaking down the complexity of an enterprise platform provides a targeted focus on delivering business value through classes of foundational technology. To remove friction and build ecosystems, it focuses on the key areas of delivery:
- Delivery Infrastructure
- Architecture & API Remediation
- Self Service Data
- Experiment Infrastructure & Telemetry
- Customer Touchpoint Technology
Autonomous product delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination. It is unified, consistent, and maintains control and flexibility in individual teams with different ways of working. However, it takes time to adapt and build and if implemented incorrectly, the “enabler†becomes a single point of failure. Thus, we should anticipate challenges and risks and plan our activities and cross-team collaboration accordingly.
Learn More: Technology Tips to Protect Remote Employees During a PandemicOpens a new window
Synergy of Interaction
So, how can you cooperate with the platform team? Here are two of many possible approaches: First, consumption of the platform as a product, where the platform team produces increments of the platform, and provides it as a self-service API (e.g. as a VM or container image with hardened capabilities or as an extensible, but constrained framework). Another option is the penetration of the product teams, where they have a platform team member.
In conclusion, the organizational structure must take advantage of the diversity of today’s architectural and technology choices. Conway Law says an organization tends to produce designs copying the organizational structure, but I tend to believe the opposite is also true. The system structure implicitly hints at an organizational structure that best suits its implementation.
The modern, highly innovating, and rapidly evolving IT industry encourages the highest level of organizational agility to supply excellent, fast response to business demands. To achieve the efficiency desired, we should constantly think of necessity and the possibility of organizational transformation.
Let us know if you liked this article on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!