Build micro-organizations, not just micro-services
TLDR: Often overlooked in discussions of micro-services are their positive effects on the human organization. Following Conway’s Law, micro-services are a modular, vertically integrated technical architecture matching a loosely coupled, vertically integrated human organization structure. Both together enable efficiency and agility in large organizations.
Micro-services are a radical, counter-intuitive, controversial, and at the same time enlightening topic. In my opinion, the debate around them focuses too much on technical aspects like code and DevOps complexity. Often overlooked is that micro-services increase the efficiency and agility of human organizations.
A common theme across all projects and companies I have worked with was that most of the challenges on technology projects come from the human part of the system and not the technology side. Company-wide dependency gridlock slows every initiative in a large organization down to molasses. Endless meetings take up most of the working hours and leave little room for actual work.
This happens because human organizations scale much worse than codebases. Humans work very well in teams of no more than 10 people and organizations of up to 100. Such small groups allow direct relationships and communication between all members. Go beyond that and things inevitably become bureaucratic, inefficient, and political. Communication needs grow exponentially but communication capabilities don’t grow much at all. This makes it hard for centralized management to have a sufficiently comprehensive and nuanced understanding of what is happening in a large organization at any time and place and respond both timely and thoughtfully.
Conway’s law describes that human organizations tend to produce systems that mirror their communication structure. If, for example, an organization has one big data department, it will end up with one big database system that contains all the company’s data. With two data departments, you’ll end up with two database systems.
Traditional enterprises organize people by function. In such setups, the product group develops ideas for new features or business capabilities. To build it, the data department must first add new fields to the company’s data model. Once that is done, the server team can add the needed backend systems and APIs. Once those are in place, the front-end team can add the feature to the web, desktop, and mobile applications. Before we can deploy anything, the operations team must provision the needed server capacity, and we need sign-off from the InfoSec department.
Each work item spends orders of magnitudes more time waiting in queues than it takes to implement them. Such delays and bottlenecks quickly compound into widespread gridlock throughout the organization. Keeping so many stakeholders from so many different parts of the company engaged, aligned, and supportive requires countless meetings.
Most individuals in the organization see, understand, and empathize stronger with people and things in their direct vicinity than with those further away. Team members sit in the same room, know each other personally, and easily get on the same page. Teams within the same department usually have decent cohesion. Relationships between departments are often tainted by politics and competition for resources. Collaboration between companies is even more difficult.
Tightly interlock departments that have limited awareness and empathy for each other and you get an organization that cannot execute fast despite throwing money and talent at market opportunities.
The solution to both problems — tight coupling with limited visibility — is to deliver each business capability by a single team. To remove the direct dependencies on other teams, each team contains all functions needed to plan, design, build, operate, and course-correct on their own: market research and user studies, performing database changes, server and frontend updates, designing new interfaces, and expertise to make the solution secure and resilient. Supporting functions like operations and InfoSec have roles in these vertically integrated teams, supported by enabling teams that provide self-service infrastructure. This gets them closer to the action and makes their solutions more pragmatic. Meetings become small and more dynamic. Such vertically integrated human organizations can develop business capabilities a lot faster. They are substantially more agile and efficient.
Following Conway’s Law, the IT architecture must match this highly modularized layout. We organize the architecture into small sets of independent, vertically integrated code bases. Each codebase delivers one business capability, is managed by a dedicated, vertically integrated team, and is separately deployable — micro-services.
Product management can compose the generic business capabilities provided this way like lego bricks into a variety of products and solutions. Modular organizations are easier to reorganize, split, and merge. Ramping up to work on such “micro-capabilities” can happen faster than ramping up to work on a large monolith that implements hundreds of capabilities. This mitigates the mythical man-month problem somewhat. The smaller and simpler codebases allow using a wider range of developer talent and experience levels.
To summarize, one of the largest benefits of micro-services is that they bring human organizations to manageable sizes. This enables agility and efficiency in large organizations by fostering collaboration while leaving space for self-organization. In part 2 we use inner-source to maintain collaboration in a heavily compartmentalized micro-service oriented organization, and in part 3 we use a monorepo to make collaboration economical.
