Architecture & High Performing Teams

Companies have a never ending quest to continuously adopt new tools, processes and new architectures with the goal of enabling teams to move fast and build high performing teams. What is a high performing team? If you ask a product manager, they will say "It’s a team that can deliver new value faster". If you ask a Team lead they will say along the lines of "A high performing team can pay down its tech debt faster, spends majority of the time building new value to the product and optimizes their work for improved quality and faster delivery."



"so what makes these teams move fast?" Now this is a great question! I have been fortunate to work with some of these high performing teams.  Juggling down the memory lane, I was trying to find the answer to this question in a way that discounts the personal traits of any individual in the team. I stumbled upon three unique qualities that distinguished a high performing team from others:
  1. Ability to make sweeping changes: A high performing team is cable of making large scale sweeping changes in their code base. They can change their underlying domain model, database schema or even create a new version of a service. And most importantly, they can do this without the need of handholding any other team. 
  1. Damage control: The biggest damage one can do by check in any new piece of code is limited to their own stack. Every change in code is a risk to the system and can break production. One should never check in any code and break service that belongs to some other team. In some cases this may not be entirely possible but the goal is to keep the blast radius as small as possible.
  1. Zero downtime deployments - Teams I have worked with have embraced componentized and independent deployments. They can quickly deploy or rollback (when things go wrong) versions of their services and apps, again without the need to hand hold any other team. 
None of these qualities are unique to any individual and actually it’s a misconception that you can build a high performing team by putting together smartest people in the room and call it a team. These three qualities points to architectural principles and practices that can be adopted across the board
  1. Ability to make sweeping changes: this requires clear boundaries in the code and sense of ownership along with well understood dependency b/w teams. Architecture principles that enables this are:
    • API first development 
    • APIs as a clear interface for communication for both internal and external consumption
    • Bounded context boundaries
  2. Damage control: Principles and practices that enables damage controls are:
    • Discourage sharing internal domain artifacts: DRY is an anti-pattern in microservices architecture. Note -you can share frameworks and other general purpose libraries as long as they are not rapidly introducing breaking changes.
    • Work in small batches
    • Self-contained repository structures
  3. Zero downtime deployments: Principles and practices that enables ZDT are:
    • small deployable artifacts (services or apps)
    • Forward/Backward compatible code
    • Feature toggles and branch by abstraction
    • Blue/green deployments
I believe anyone can apply these principles and practices in order to achieve the three underlying characteristics.


Popular posts from this blog

Break functional and orchestration responsibilities for better testability

Image
Microservice architecture paradigm fits well within the Unix’s first principle/philosophy: “Make one program do one thing well”.  We love creating small services which has identity of its own (within a bounded context). These services have their own CI/CD pipelines and provides loose coupling b/w components which significantly improves our ability to deliver code to production. In reality, a workflow can span multiple services. Its very common to find scenarios like below: In the above example, a workflow spans 3 services (Service-1, 2 and 3). Service1 receives the original request. In order to process this request, it GET(s) some data from its dependent services(d1/d2/d3). It further runs some business logic and produces an intermediate response #A. It then makes a state mutable call (POST/PUT/DELETE/PATCH) to Service-B using #A as input and waits for its response. Service-B follows the same paradigm and the workflow ends when all services returns.  The scena...
Read more

Microservices and Tech Stack - Lessons Learned

Image
In this blog, I want to talk about how our technology stack has evolved over time while transitioning from Enterprise to adopting Microservice architecture as a main stream development practice and share some of the lessons learned. Tech stack for us has evolved from being a Monolithic Enterprise to Cloud to now Microservices. During Enterprise days, it looked something liked this: At the app layer, we had a desktop client written in Windows form and WPF. The app would talk to the Service Layer which was SOA architecture written completely in C#. It was the only language allowed for us to use. These were monolithic and stateful services communicating to each other over WCF. We used SQL server as backend storage. All this get deployed on premise meaning our clients buy our software and host it on their own hardware. I work for Finance industry (Stock Market to be precise) and they were sort of late adopter of public cloud. They absolutely hated the idea of putting their data on p...
Read more

Prefer Consumer over Integration Tests

Image
Recently I attended an RCA meeting for an incident that happened in prod few weeks back. The issue was somewhat of a 2nd degree failure. To put it in simple terms, lets say a workflow composed of two services - A and B. When user performed an action from the UI, it made a call to Service A which then internally called service B with some parameters based on user preferences. In this case, due to some unusual combination of preferences, Service-A ended making call to Service-B with parameters that Service-B didn’t fully understood. Solution - Write an integration test to cover this scenario. Reasoning - Since this involved 3 different components (User Preferences, Service A and Service B), it should be covered by an integration test. More Reasoning: This is sort of the usual way of thinking about the integration tests - meaning whenever there are multiple services involved, we immediately think about writing an integration test. But is this the right approach specially in microserv...
Read more