Microservices and Conway’s Law

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.  But 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, first you must 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.  And 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.  And if you want to avoid chaos you better consider whether or not you want a complex multi-dimensional mapping or 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 you 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.  And 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 as 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.  But 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.