Do you have a central "architect" team? If so, I have lots of questions! 🧵

This is not really an answer to what you are asking, but I have found that the DORA capabilities do a good job of threading the line bt business speaking and technical speaking. They provide a good outline that everyone can follow and get on board with. https://dora.dev/devops-capabilities/

We have a team of Architects. They come from all of the various disciplines represented in our org - Front End, Platform Eng, SRE, other flavors of SRE, etc. When large projects requiring changes across multiple of these teams get proposed, the architects review and make sure that it aligns with the business, that the technical architecture all makes sense, etc. The individual teams themselves are still doing the design and the implementation, but the architects get the overall high-level objectives and generalized "how would this work" stuff done and agreed upon.

I think it depends on the skillset of the team - If they are communicators then what Kirk said, but if they are builders, they can help with • Bootstrapping new products / features (or the tooling to make bootstrapping easier) • Jumping between teams to work as a fire-fighter / fixer • Work as mentor pool for developers / teams • Build the monitoring / standards / tooling to improve architectural attributes The anti-pattern would definitely be the architecture review board / approval gate

Thanks folks! This is helpful to hear how you all are doing it.

The anti-pattern would definitely be the architecture review board / approval gate

This is precisely what I want to avoid. It sounds like there are two patterns you all have explored: 1. The Sage pattern - Architects that review technical strategies for large scale changes to provide guidance and feedback on alignment with business goals, sound principles, etc. These architects may also provide mentorship or training to less experienced developers. 2. The Master Builder pattern - Architects that get "hands-on" to invest in areas that require achieving outcomes quickly, keep risk manageable, or resolve a complex problem.

I think depends a lot of the org size. Some big orgs needs multiple central arch teams mostly focused on governance, standards, etc

How do you balance the need to have standards and the need to ensure those standards are adhered to in some meaningful way? If you put too much authority in the arch team (i.e. a review board) development can grind to a halt, or people will circumvent the reviews. The opposite (no authority) makes the arch job feel purely theoretical. Generally my thinking here is that there needs to be a strong agreement between architecture and the technical staff (technical leads and possibly eng management) that standards will be used. Ideally even linting or other tooling can be implemented to validate for some parts.

I think linting / scanning is a requirement for ensuring standards are being adhered to - orgs have too much churn / diversity to expect people todo it on their own. PR blocking tests for the standard security / compliance but it can also be used for enforcing encapsulation principles by blocking imports of specific packages. And then post deployment scorecards for things like PR review compliance / quality, reliability, performance, network dependencies, data access patterns etc..

Thanks for the insights everyone!