For a long time, organizations have maintained the top-to-bottom hierarchy where decision-makers and employees are two different kinds. But as times change, so do organizations. Or, at least, the smart ones. Today, the modern business world is more about distributed teams. In recent years, many organizations have switched to new approaches that foster an organization’s speed and help to elevate the employees’ level of responsibility. One such approach is developing independent remote teams.

 Hiring across geographical boundaries

ThoughtWorks’ Martin Fowler believes co-located teams are productive but remote teams are often more productive than co-located teams. He argues that remote teams have the advantage of hiring without geographic boundaries, and that enables employers to assemble world-class groups. Finding the right set of people with desired technical and nontechnical skills in one geographical area can be difficult compared to hiring people from different locations and then uniting them to work together.

 Limit your technical debt

An independent team is one such approach wherein we can have a group of people with specific skillsets focused to work in a particular domain of technology. Such a team can be in-house or an outsourced team. Also, that helps you in limiting your technical debt. For product development, the entire workflow can be divided into such teams. The most important thing for an enterprise to succeed depends on how well these independent teams collaborate and work towards the common goal of achieving success.

 Higher value with faster delivery

Delivering software rapidly is one way to generate higher value. It helps in getting faster feedback from customers. Hence faster feedback again puts software improvement back in hands of customers. This, in turn, enables you to make them faster than your competitors can. Monolithic systems have too many dependencies where things slow down. Teams that are tightly coupled together are unable to work independently.

In a technical sense, for faster software delivery, the software must be built as independent services that can be later stitched together by way of contracts to form an application or system as a whole. The way of contracts can be design files, API specification documents, etc depending upon the way teams are collaborating towards a common goal. In this way, services with their independence can evolve and change separately from one another, resulting in faster delivery.

 Conway’s Law for organizing teams

Many years ago, Melvin Conway, a computer scientist, computer programmer, and hacker, observed that how organizations were structured would have a strong impact on any systems they created. In his research paper “How Do Committees Invent” he wrote:

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.

This principle is not only limited to software project management, but it can also be applicable to others as well. Teams must be organized in a way that they own the end to end responsibility for development and production throughout the entire lifecycle of a chunk of software. Such a team is a service. A concept based on Robert (Uncle Bob) Martin’s single responsibility principle states that,

A service does one thing and one thing well

Whether you call it a microservice or not, it actually doesn’t matter. Hence for your teams to deliver software faster and scale without sacrificing quality, a shift in team structure around the principle of Conway’s Law can help. It can also help you to replace each service with a SAAS solution in the future to adopt the best.

Many top companies have structured themselves around multiple small teams each with individual responsibility for a small part of the overall system. If these organizations had adopted the idea of a larger monolithic system then that would not have given them the same ability to adapt, experiment, and ultimately keep their customers happy.

Summary

The microservice architecture is innovative, its roots go back atleast to the design principles of Unix. Not enough people consider a microservice architecture. Many software developments would be better off if they used it.

TL;DR

• It will be easy to organize your development teams.
• You can decide on each service to keep it inhouse or outsource it.
• You can replace each service with a SAAS solution, adopting a best-of-breed strategy.
• You limit your technical debt.
• Hiring becomes easy because you as you can have different technologies running different services.
• You can implement new features way faster, as they concern small code-bases updates or entirely new services.