What is it?

An open space where team representatives can bring requests to make architectural changes, make decisions collaboratively, contribute to the architecture’s vision and plans, and share knowledge and updates.

Why a community? What problems does it solve?

• We aim to align our engineering teams on the architecture vision and plans so we can realize them more effectively since we’ll all be driving in the same direction, enabling our business goals. The community creates channels to discuss and communicate these plans, gather feedback, and make necessary adjustments over time, ensuring they reflect the current situation.
• We want to guarantee that we use all the knowledge available in the organization when making significant decisions about our software system. Having more and better thought-out options will guide us to making better decisions.
• We must avoid bottlenecks in our development processes caused by centralized design and decision-making. The community can make these decisions decentralized, removing the strong dependency on architects while maintaining a centralized governance structure and accountability supported by a decision registry.

How does it work? Who are the community members and owners?

The community consists of:

• A channel in Slack, #architecture-community, where we share updates and leverage asynchronous communication as much as possible.
• A recurrent one-hour session every two weeks on Monday, with optional attendance and cancellation when there are no topics to discuss.

There are also some basic logistics:

• At least one engineering representative from the team should attend the meeting and participate in the channel. The team can decide whether to keep the same representative(s) over time or if it’s rotation- or topic-based.
• The software architect facilitates the meeting, but others can also do it in their absence.
• The meeting agenda structure is on this link (we’ll cover this later).
• All sessions will be recorded so others can watch them on demand for information or learning purposes.

When do the rituals happen? How much dedication does it need?

• Apart from the recurring meeting, there might also be ad-hoc sessions to discuss specific topics in more detail (decisions, software designs, knowledge transfer, etc.). Participation remains optional, but depending on the subject, it’s essential that we have a good representation of key stakeholders and experts.
• Ad-hoc sessions will be organized at least one week in advance to avoid disrupting the team’s delivery cycles, except for urgent decisions that may otherwise block teams.
• As a facilitator, the architect will ensure a conscious use of time.