論架構

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

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

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

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

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