The context of this article is kept at a more technical execution level. I'd like to bring up some thoughts on the requirements and communication that can be involved. In reality, this is more of a Rorschach reaction to the pretty awesome images that they had on their article.
Generally, three things a software development team thinks about are:
- What is my Deliverable?
- How is it going to change over time? What are my requirements?
- Who are impacted of my changes? How do I coordinate with them?
However, there's another question that, surprisingly, a lot of IT organizations are still extremely immature at handling:
- What deliverables need to be changed for my needs? How do I get those changes to happen?
Here's a pic from the article discussing a functionally siloed organization and the corresponding Architecture that tends to occur.
Because of Conway's law, the architecture reflects the org structure, and this is also a representation of how requirements flow. The UI folks have some user-facing use case and they need a service change from the middleware folks, who in turn, need something of the DBA guys. One common disadvantage to this is the further away you are from the original requirement, the more you get some odd telephone game situation going where the API isn't exactly what the UI guys are looking for or the DBAs decide to ignore the middleware guy's model design. This can lead to a lot of churn and rework.
With a cross functional team, you have teams that are more focused on the use-facing use case, rather than entire groups of people who are only focusing on their immediate deliverable. One excellent point that is also made in the article is that large monolithic architectures can be organized "too many contexts." The article posits that this tends to be a result of cross-functional teams in a monolithic architecture, but I think this happens regardless of how your teams are organized. This is a big reason why we can get a lot of spaghetti logic, where a module may be trying to satisfy too many things at once, as opposed to being split into separate modules.
Something that these pictures also accurately depict is that your cross-functional teams would have fewer people of each function focusing on particular business logic and can likely be working on a particular microservice. Looking at this from a requirements flow perspective, you can potentially get resource constraints (or managers imposing them), which is one of the main reasons why functionally siloed organizations exist to begin with.
This comes back to the questions:
- What microservices need to be changed for my needs? How do I get those changes to happen?
Do you make requests to a microservice's backlog to be prioritized? How do you deal with that team's resource constraints? How do your requested changes impact other teams consuming that microservice? These questions aren't specific to microservices, but with more granular teams, this amount of "red tape" may seem daunting to more traditionally managed organizations.
In addition, with that many more deliverables in the form of microservices, ensuring that the consumers of your deliverables are prepared for the changes you're making.
In addition, with that many more deliverables in the form of microservices, ensuring that the consumers of your deliverables are prepared for the changes you're making.
In the left side for monoliths, consumers of modules have the option to choose which version of the module to include in their process at build/deploy time. On the right side, the consumers have the option to choose which module to utilize by communicating with the appropriate service at run-time. Fundementally, there isn't too big a difference in these dependencies, but operationally, in terms of identifying your dependencies and working with your sys admins on deployments, it is pretty different in terms of how you're communicating changes, dependencies, and to whom you're communicating to.
It all boils down to how well your organization can communicate across your teams. For a small organization, physically talking or chatting on email or a chat service works out. However, with large geographically distributed teams with potentially different cultures and whatnot, this gets unwieldly very quickly.
This post is getting long so I'm going to cut it here. I'm not just talking about microservices, I'm talking about any organization that has multiple internal deliverables across teams. How can a large geographically distributed organization, consisting of multiple teams, meet customer expectations while ensuring smooth operation from build, to test, to deploy? I'll run through some thoughts on the challenges and solutions that may fit your given culture.
