We Cannot Forget Conways Law
Fast forward to 2015: Many organizations are staring at monolithic applications and architectures, and are wondering how they got there. And, perhaps more importantly, where do they go from here?
Guest author Sarah Novotny is a technical evangelist and community manager for Nginx.
A wise person once said that you build what you know, and you know what you build. While these weren’t the exact words uttered by computer programmer Melvin Conway in 1968, the sentiment is there.
His sociological observation, dubbed Conway’s law, posited that any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communications structure.
I’m a firm believer that very few technological problems are actually related to the technology. Whether you want to evolve from a monolithic and vendor-dependent model, or are ready to embrace microservices, it’s time to take a look at how your internal culture, people, and systems are impacting application development speed and performance.
Here are five ideas to get you started.
Put A Cap On Your Pizza Order: Create Small Teams
Many organizations fall into the trap that the more people on a team, the better. In the early 2000s at Amazon, founder and CEO Jeff Bezos challenged teams to work more efficiently, communicate better, and move faster. He believed that a team shouldn’t be larger than two pizzas can feed, creating what is now known as the “two-pizza team rule.”
The idea is to have small and agile teams that work together through strong agreements—such as requirements documents and APIs. This empowers teams to make needed changes to pieces of code, as long as they don’t violate the contracts that bind the teams and the code together.
Even moving a single service out of a monolithic application can create major cultural challenges. Indeed, while it’s important to build small teams across the organization, start, well, small.
Technologies such as microservices are one extension of this idea. In
the microservices model, complex applications are composed of small,
independent components. This modular approach to development decreases
the chances that an issue with any one service would cause the whole
application to fail to meet the expectations of its end user or
consumer—or more formally, a service-level agreement (SLA). Designing
for failure makes for a more positive customer experience, a better
developer experience, and internal teams that move more freely and
rapidly.
Begin with a single pioneering team before you go broad. Select individuals who are natural leaders, who have an innate sense of curiosity and problem-solving abilities, and who have a very low tolerance for lack of clarity. You want employees who aren’t afraid to say, “It’s not clear right now how we will accomplish this particular task, but I’ll figure out a way to figure it out.”
Keep in mind that it’s ideal to anoint pioneers with diverse experience. You want a team that includes people with deep backgrounds in existing monolithic architectures; some who come from the outside with fresh eyes and perspectives; and others with less experience but the confidence to ask the “dumb” questions about why development is moving in the current direction. But make sure it is a team that has the ability to work together without personality clash!
Reinforce The Mission
Take care not only in selecting those who will serve on your pioneering team, but also in communicating with those who were not selected. Reinforce with all stakeholders that the new team is a model for the way that everyone in the organization will eventually build, conceive of, and deliver software. Involving the whole organization in the transformation, if only through early “field reports” from the pioneers, will help increase buy-in and encourage transparency as a weapon against the risk of new and different siloing behaviors.
Be careful, though: This is where the potential danger of having the team dragged into the company’s traditional monolith lies.
Build A High-Trust Culture
Along these same lines, it’s important to develop a culture of failing and sharing. In the transition to this new model, not everything will go smoothly. You need to encourage individuals to learn from the inevitable mishaps and challenges, and to feed that learning back into the development cycle. Be proactive about building an introspective culture—one in which the team can feel empowered to take risks and to acknowledge mistakes without placing blame.
Take It Slow
Underestimating the amount of social change needed is a common trap I’ve seen among organizations. After all, you’re not just changing code but how the organization works—from top to bottom.
It may be that a major change isn’t right for your organization. It’s too much for some organizations to make multiple cultural and technology changes in a rapid manner; perhaps you simply don’t have enough space or capacity or sense of prioritization to take such change on right now. For example, if going from one big application to 100 small ones in a 12-month period is unrealistic, it may be better for your organization to break out code and services into little groups, piece by piece by piece.
In order to break the cycle of constrained processes, and formalized, top-down command and control that leads to rigid, monolithic apps, borrow practices from the original pioneers. Go back to the days of chopping wood and carrying water in order to create a shared journey and a sense of growth. Have fun with it, trust your people, and remember Conway’s Law. Aim to create a flexible, powerful, and autonomous organizational structure—with software to match.
Comments