論架構

在內部部署環境中，客戶經常具備負責技術架構的集中團隊 (而技術架構將疊覆在其他產品或功能團隊上) 以確認其過程遵照最佳實務。技術架構團隊通常包含一組角色，例如技術架構師 (基礎設施)、解決方案架構師 (軟體)、資料架構師、聯網架構師和安全架構師。這些團隊經常使用 TOGAF 或 Zachman 框架做為企業架構能力的部分。

在 AWS 上，我們偏好將能力分散至團隊中，不以集中團隊具備該項能力。選擇將決策權分散有其風險存在，例如為了確認團隊符合內部標準之際。我們以兩種方式降低這類風險。首先，我們演練 (做事方式、程序、標準，及可接受的規範)，目的是讓各個團隊具備該項能力，並且聘用專家，確認該團隊提高所需符合標準的標竿。第二，我們實作機制來實施自動化檢查，確認其符合標準。

這相當於將人為的盡力取代為機制，其能夠檢查是否遵循規則或程序 (經常為自動化形式)。這種分散式的作法受到 Amazon 領導方針的支援，遍及所有角色培養一種返向工作從客戶需求出發的文化。返向工作是我們創新程序的基礎部分。我們從客戶及其期望著手，根據之定義並主導我們的工作方向。以客戶為尊的團隊會因應客戶的需要建置產品。

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

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

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