Chapter 6. Architecting Autonomous Applications

The point of microservices is to unblock independent queues of work. Both in the system of services and the system of people.

Andrew Clay-Shafer

Organizations cannot achieve high autonomy if there are couplings in the software. Couplings in software will result in couplings between teams. Consequently, all of the rich domain and business knowledge has to be taken into account when architecting boundaries. Software architecture should be a collaborative activity involving not only technical people, but a variety of stakeholders from product managers, to user experience designers, to business analysts. So regardless of your skill set and job title, software architecture is relevant to you.

Making Software Architecture Cross-Functional

To make software architecture a more cross-functional activity that includes a diverse range of people, start with the obvious: if you’re a developer/architect, invite others to your sessions, share your diagrams, and make sure they at least have access to the information and an opportunity to contribute. Ask them for their opinion, and encourage them to have an opinion. Obviously, remind them there are no stupid questions. If you’re on the other side of the fence (i.e., if you’re not involved in architecture), try showing an interest. Ask if you can come attend workshops and view the diagrams.

The biggest hurdle to achieving a more cross-functional influence on architecture is clarifying details. If ...

Get Designing Autonomous Teams and Services now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.