Part 2: Microservices: Technical, Organizational, or Business Architecture? Yes

Organizations which design systems…are constrained to produce designs which are copies of the communication structures of these organizations.
— M. Conway

In a previous post, I covered what microservices are and their benefits. My aim was to help non-technical executives understand what microservices are and the role they play in supporting business objectives. Implemented correctly, a microservices architecture allows technology to move at the speed of the business. Today, that can mean reacting to customer needs in seconds and minutes as opposed to months and years.

Imagine it’s possible, with a snap of a finger, to take that gnarly mess of a system that powers your business capabilities and break it up into individual modules that can change independently. The question that often comes up is, How do you break it up? How do you decide what the individual components are? Who does the work?

Let’s start with an example where the components appear somewhat obvious: an ecommerce site. To make it more real, let’s use the example of Amazon.com. To start, I’ve highlighted some natural seams in the product detail page.

If you group the red boxes by their function, you’ll observe things like product images, product detail, promotions, shopping cart, inventory availability, recommended items, delivery, search, account, categories, product family items, etc. Notice these groupings are not technical in nature; rather, they describe business functions or domains. These business domains are typically independent of each other but of course interplay, interact, and interface to create an online shopping experience.

Here’s a thought experiment: If you were to peer into the organization and business functions behind any company’s ecommerce site, what would the organization look like? Would all these functions be tied up in a large ecommerce team? Conway’s law would predict that the ecommerce site would map to an ecommerce organization. The site would likely be a welded-together amalgamation of all the functions called out earlier. If a company operated in several parts of the world, Conway’s law would predict there would likely be several sites, each with its own organization.

What’s the potential drawback? What if the search function wanted to improve how results were displayed to users? Or the promotions team wants to change how information is displayed on the website for an upcoming holiday sale? The way I’ve seen it work with most companies is that each of the business functions would send a list of requests to the technology team, who would then have to prioritize and manage the changes across the site. This means it could take a while to implement desired changes, requiring business stakeholders to submit requests far in advance.

Let’s go back to the point after we snapped our fingers and the ecommerce site is broken up into individual modules that can each change without coordinating with other business domains. What would those organizations look like now? If the desire is for each business domain to evolve, innovate, and change their respective functions, it’s reasonable to assume each function would need the business owner of that function to work very closely with their technical counterparts—they might need to be on the very same team. If each business function, of which there could be hundreds, needed this same ability to innovate, then you’d end up with an organization of hundreds of independent teams.

As someone who has led application and technical architecture teams, I’ve spent a fair amount of time designing systems using domain driven design principles. The idea is that if systems are designed reflecting how the business is architected in its functions (e.g. payment, delivery, etc.) and objects (e.g. customer, items, etc.), then the system will be more durable and flexible. We would agonize to make sure the system was as modular as possible, but what we often did not consider is who and what team would be driving those changes in perpetuity. But if the systems are a reflection of an organization, which should be a reflection of the business architecture, as stated by Conway’s law, then why don’t we start systems by designing the organization and business architecture first?

If you believe in the value of modular components to build agile, innovative, and scalable systems, why not start with modular teams who can drive the necessary innovation from both business and technical perspectives? It’s why I argue that microservices is not just about a technical approach but an approach to business and organization architectures.

Never stop innovating,

Joe