With the continued growth and transition to microservices, it’s important to understand that the benefits of this new architecture come with new challenges. In this multi-part series, we’ll look at different components and considerations and share our experience when modernizing legacy applications to microservices. 

Up first is the most important component: your team. 

Develop a New Team Structure

Modernizing your microservices begins with your team. One of the reasons to split a monolithic application into microservices is to speed up innovation and reduce the complexity of interactions of multiple and/or large teams contributing to the product. It’s not unusual for legacy software to have been developed with traditional methodologies such as:

• Long release cycles to production, even when using sprints (hardening sprint, UAT, etc).
• Separate teams running testing and quality assurance.
• Security is an afterthought in the development process.

In this model, multiple teams have separate, distinct responsibilities. Features move from one team to the next, each of which has their own definition of ‘done.’ The lack of shared responsibility and alignment with goals increases cycle times and creates inefficiencies between teams. Most importantly, this structure does not foster innovation or enable modern practices where we treat everything as code. Nor does it specify automated testing as part of the definition of ‘done’ for a feature (where techniques such as behavior-driven development can be leveraged).

When considering breaking up a large monolith and embracing modern product team structures, it’s important to start by setting up these new teams differently and more efficiently. Spending the time to codify the RACI model between the teams will clarify responsibility, while also empowering those accountable. This is particularly relevant when the organization is still matrixed, with different silos providing resources to the product team (BAs, testers, software engineers). Everyone needs to clearly understand the definition of ‘done’ for every step in the process, including unit testing, functional testing, code reviews, security scans and quality gates.

Reorganize High-Performing Teams with Care

Without elaborating on the team development stages of forming, storming, morning, and performing, new team formations need time to gel. It takes months for people to work well together, and some teams don’t reach a high-performing state by themselves. That’s when management needs to coach the team, reestablishing alignment toward shared goals, reducing work in progress, or changing personnel. Once a team has reached that high-performing state and social bonds exist between the individuals, the type of work they do (for example, which service they own) is less important than the trust and cohesion between the team members. A great team will find opportunities and push boundaries regardless of the product they own.

One concern is the practice of dismantling existing teams in an agile train to reallocate members into new teams by having team members select their new teams based only on the products that the new team would own. The rationale behind this approach can be to either create more (smaller) teams, share knowledge, or both. This often creates less-than optimal results, as team members select their new team based on products without information about the product owners or team technical leads. First, as mentioned previously, at the end of the day, it probably matters more with whom you work than what you do. Second, teams need a few months to gel, and dismantling and rebuilding teams starts the bonding process all over again. Third, if products later move to a different team, the initial rationale to pick a product goes away, unless team members have the opportunity to move around, too (if not, the tenet loses credibility).

As for alternate approaches to creating more teams, it’s often better to increase a team’s headcount and then split the larger team into two. For building subject matter expertise in various products in an organization, knowledge can be shared by scheduling team member rotations on a voluntary basis. If that voluntary movement is not enough, incentives should be created to encourage mobility, and term limits could be considered.

Prepare the Field, Then Scale

Start with a small group of trailblazers, then scale to more teams. Being agile doesn’t mean a lack of planning and moving forward with the first idea without thinking it through. While it’s tempting to replace the aged monolith with any modern architecture, don’t get in over your head; experimentation goes a long way toward reducing risk and ensuring productive decisions.

A dedicated pilot team – or a few pilot teams – can start exploring and building complementary template services, with explicit permission to backtrack as needed. Starting small does not mean starting trivial. Include the cross-cutting concerns needed by all services, such as security, logging and observability, with support for tracing requests as they move through various microservices. Ownership can start with the team(s) creating the templates. One important aspect of a successful pilot program is a mechanism to share best practices and templates among teams (portal, wiki, touchpoints). This effort will bring standardization and consistency in the cross-cutting concepts, which simplifies the tooling around the microservices – for example, log collection is immensely simpler if all services log in the same format.

Once these skeleton services are developed, it’s time to scale up to the number of teams needed.

In part two, we’ll explore the important step in defining and establishing ownership. 

Ready to modernize your organization’s microservices? Oteemo is a leader in cloud-native application development. Learn more: https://oteemo.com/cloud-native-application-development/