Microservices and Conway's Law
Microservices and Conway's Law
As powerful as new tools are, they pale in comparison to the power of the status quo — even for those who believe they are high-minded enough to avoid such traps.
Join the DZone community and get the full member experience.Join For Free
The new Gartner Critical Capabilities report explains how APIs and microservices enable digital leaders to deliver better B2B, open banking and mobile projects.
Microservices seem to be all the rage right now, and for good reason. Breaking down a large monolithic application, particularly a Java application, into lots of smaller independently deployed pieces makes a lot of sense for a cloud system. I'm not going to list all the benefits here, since they have been discussed ad nauseum elsewhere, and any developer who's been around awhile ought to know them by now. I'm also not going to list all of the technical drawbacks — and there are some — for the same reason.
Instead, I will focus on something I have not heard much in the discussion. Perhaps I've missed it. However, in our rush to implement microservices and transform our suddenly obsolete monoliths into nimble microservices, I fear we have ignored an important aspect of the movement: how the organization must evolve to match.
Let's start by talking about Conway's Law. You can read about this in many places, but you can boil it down to this idea: If you want to change your architecture, you must first have a reorg. Some engineers may protest this, saying that architecture ought to be orthogonal to organization and any decent engineer can rise above it. The advent of Agile teams, desks without cube walls, and social networking online are all pointed to as evidence. How can an organization be siloed when something game-changing like Slack exists, one may ask?
Well, after spending the last 30 months of my life focusing on moving complex large systems to the cloud and directing the strategy for a development team of many hundreds of people, let me assure you that as powerful as new tools and methods are these days, they pale in comparison to the power of the status quo — even for those who believe they are high-minded enough to avoid such traps.
Sure, if you are starting with a greenfield application and have a small team of developers, you are free to start building using microservices and never look back. You don't have organizational constraints because for all practical purposes, you don't have any organization. In such a situation, it's easy to focus only on the software engineering side of your architecture, because the human engineering side is trivial, obvious, and intuitive. It's easy to think that such will be the case for any organization of any size — an easy mistake.
What if you already have a huge team and a large monolithic application? What if you want to move towards microservices? Enter Conway's Law. Put simply, there is no way for you to succeed unless you change your development team such that individual teams of developers are responsible for each microservice. If you want to avoid chaos, you better consider whether or not you want a complex multi-dimensional mapping, a simple hierarchy, or some combination. The accountability has to be clear and someone has to own the overall design. Otherwise, you will end up with a mush of itty bitty services that are redundant, inconsistent, and ultimately of poor quality.
Likewise, for you greenfield developers who think this is only a big company problem, let me ask: What you think your company is trying to become? You might ask your CEO that question because the architectural decisions you make now will not just affect how engineers down the road work, but it will put constraints on how the organization down the road can be structured. That, like all architectural decisions, will constrain the business on how quickly it can change strategy and pursue new opportunities.
So, in our rush to put on the latest software engineering fashion (whatever it is), let us also as professional architects take a step back and look at the big picture before we pull the trigger. No single technology is nirvana, and all choices have advantages and disadvantages that should be considered part of the architectural decision-making process. It's often been said that an architect who doesn't code is an architectural smell, and I wholly agree. However, just as stinky is an architect who doesn't understand organizations and the business context in which their technical decisions are made. The best architect is someone who can do both.
Opinions expressed by DZone contributors are their own.