論架構

在內部部署環境中，客戶經常設置集中團隊負責技術架構，疊覆在其他產品或功能團隊上，以確保其遵照最佳實務。技術架構團隊經常以一組角色所組成，例如技術架構師 (基礎設施)、解決方案架構師 (軟體)、資料架構師、網聯架構師，和安全架構師。這類團隊經常採取 TOGAF 或 Zachman 框架作為企業架構能力的部分。

在 AWS，我們偏好將能力分散至團隊中，不以集中團隊具備該項能力。選擇將決策權分散有其風險存在，確保團隊符合內部標準即為一例。我們以兩種方式降低這類風險。首先，我們演練« [ 做事方式、程序、標準，及可接受的規範。 ] »  專注在使得各個團隊具備該項能力，並且請到專家，確保該團隊提高所需符合標準的標竿。第二，我們實作機制« [ 立意良好是不夠的，需要以良好的機制才能有所實現 Jeff Bezos 言。這相當於將人為的盡力取代為機制，其能夠檢查是否遵循規則或程序 (經常為自動化形式)。 ] »  實施自動化檢查，以確保符合標準。這種分散式的作法受到 Amazon 領導方針的支持，遍及所有角色培養一種文化能起反向作用« [ 反向作用是我們創新程序的基礎部分。我們從客戶及其期望著手，根據之定義並主導我們的工作方向。 ] »  出自客戶。以客戶為尊的團隊會因應客戶的需要建置產品。

對架構而言，這表示我們期望每個團隊皆有能力建立架構，並且遵照最佳實務。為協助新團隊獲得這些能力，或使現有團隊提高標竿，我們促成與首席工程師的虛擬社群聯繫，委請審查團隊的設計，並協助團隊了解 AWS 最佳實務有哪些。首席工程設計社群使得最佳實務成為可見並可取得。例如，他們的一種作法是藉由午餐會報，專講將最佳實務套用至實際範例。這些會報經過錄製，可作為新進團隊成員的到任參考資料。

AWS 最佳實務源自我們以網際網路規模執行數千套系統所累積的經驗。我們偏好以資料定義最佳實務，不過也會起用主題專家，例如首席工程師進行訂定。當首席工程師看出有新的最佳實務出現時，會以社群形式工作，確保團隊遵守這些實務。假以時日，這些最佳實務會正式列入我們內部的審查程序，以及成為落實合規的機制。Well-Architected 是我們內部審查程序面向客戶的實作版，經過我們遍及領域角色例如「解決方案架構」和內部工程設計團隊，將首席工程設計思維予以編撰。Well-Architected 是可擴展的機制，讓您能夠善用這些學習成果帶來的優勢。

依循這種對於架構的責任採取分散形式的首席工程設計社群作法，我們相信 Well-Architected 企業架構能因應客戶的需要而成形。技術領導者 (例如技術長或開發經理) 遍及您所有工作負載執行 Well-Architected 審查，能讓您更了解技術組合所具的風險。採行此方式之下，您可看出遍及團隊的主題，您的組織能以機制、培訓或午餐會報妥善顧及，如此一來首席工程師可向多個團隊分享對於特定領域的想法。