The AWS Well-Architected Framework Document (November 2017) has an updated section about “On Architecture”, which describes the federated architecture team setup approach in their large scale enterprise.
“ In Amazon, we prefer to distribute capabilities into teams rather than having a centralized team with that capability. There are risks when you choose to distribute decision making authority, for example, ensuring that teams are meeting internal standards.
We mitigate these risks in two ways.
- First, we have practices1 that focus on enabling each team to have that capability, and we provide access to experts who ensure that teams raise the bar on the standards they need to meet.
- Second, we put in place mechanisms2 that carry out automated checks to ensure standards are being meet.
This distributed approach is supported by the Amazon leadership principles, and establishes a culture across all roles that works back from the customer.
Customer-obsessed teams build products in response to a customer need. For architecture this means that we expect every team to have the capability to create architectures and to follow best practices.
To help new teams gain these capabilities or existing teams to raise their bar, we enable access to a virtual community of principal engineers who can review their designs and help them understand what AWS best practices are.
The principal engineering community works to make best practices visible and accessible. One way they do this, for example, is through lunchtime talks that focus on applying best practices to real examples. These talks are recorded and can be used as part of onboarding materials for new team members.”
Especially I like their “architecture" expectation to the delivery teams, which on the one side is an obligation but on the other side a real empowerment and expression of confidence to the team capabilities.
No central overhead but distributed team empowerment, which is lacking sometimes in other large organisations.