[ad_1]
Moving to microservices requires a cultural shift at the organizational and team structure level. This is where Conway’s Law has played — and continues to play — a crucial role in microservices architecture implementation.
In this article, we’ll take a brief look at the history and significance of Conway’s Law in the software industry. Then, we’ll look at the inseparable links between Conway’s Law and the fundamental principles of microservices development. Finally, we’ll look at some of the specific ways to apply Conway’s Law when forming microservices development teams.
What is Conway’s Law?
In 1967, computer programmer Melvin Conway defined the relationship between a company’s hierarchy and the products they build in a paper called “How Do Committees Invent?” One of the core ideas of the article was to highlight the flaws of distributed teams — a concept popularly known as Conway’s Law:
Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.
Conway’s Law entered the mainstream when renowned computer scientist Fred Brooks made reference to it in his 1975 book The Mythical Man-Month, a collection of essays and observations on software project management that still holds status as one of the industry’s most authoritative written works. Although Conway had originally framed his idea in a general business context, Brook’s citation emphasized its pivotal importance in the field of software development.
Furthermore, subsequent studies on the relationship between organizational structure and product design have demonstrated that effective application of Conway’s Law can result in more efficient software development processes, more productive collaboration efforts and the ability to better manage modular, distributed software architectures. This is where the relationship between Conway’s Law and microservices begins.
Where Conway’s Law and microservices converge
Plenty of other fundamental concepts that underlie microservices development go in tandem with Conway’s Law. This is particularly true when it comes to assignment of responsibilities, as the principles of microservices demand that services should encapsulate a single responsibility or single capability to form a loosely coupled service architecture.
Now that microservices-based architecture has become one of the industry’s leading software design standards, the relevance of Conway’s Law has taken on a renewed sense of significance. Where companies want to deliver reliable software at scale and speed, Conway’s Law attempts to foster a structure where teams can work independently, deliver changes rapidly and eliminate the hassle of collaboration and coordination between teams.
Through microservices, organizations seek to achieve the benefits of a service-oriented architecture while facilitating the ability of small development teams to independently deploy, manage and optimize loosely coupled application components at will. These decentralized microservices also make it possible for certain application services and functions to operate through their own dedicated CI/CD pipeline, database and versioned API.
Applying Conway’s Law to microservices development
Agility is a crucial feature of the microservices architecture that is achieved through a small and compact team. Too often, organizations are inclined to enforce shared ownership of application components and management responsibilities across development teams. Although this approach may introduce consistency in terms of things like feature releases and deployment cadences, the complex web of coordination and communication it creates across large software teams can quickly become unmanageable.
Conway’s Law endorses the formation of small teams dedicated to one core business capability, such as invoice processing or inventory tracking. To ensure microservices teams have autonomy, they must be loosely coupled and responsible for a specific business function. Such a culture will give them the liberty to develop, deploy and scale services as they see fit — and, if needed, fail in isolation. Organizations will need to assess their own unique needs to determine how to best size their teams.
An oft-cited example of an “ideal” team size under Conway’s Law is Amazon’s two pizza rule, which dictates that individual project teams shouldn’t contain more members than two pizzas could feed in a meeting. However, the core factor to consider during team alignment is the ability to remain cross-functional instead of being siloed. To that end, a microservices development team that pulls in expertise from QA, UI design, security, database administration and product delivery might free itself from communication delays by forming its own end-to-end ecosystem of software delivery lifecycles.
[ad_2]
Source link