審查程序

架構審查的執行方式必須一致,採行鼓勵深入探索的無譴責作法。應為輕量程序 (數小時而非數日),屬於一種對話而非稽核。就架構進行審查的目的是找出可能需要解決的重要問題,或是有改進空間之處。審查的結果是一套行動,應能提升客戶使用工作負載得到的體驗。

如同「論架構」一節所討論,建議由各團隊成員對其架構的品質負起責任。我們建議建置架構的團隊成員使用 Well-Architected 架構以持續審查其架構,而非舉行正式審查會議。採取持續作法可讓您的團隊成員隨著架構演進更新答案,並隨著您遞送功能而提升架構。

TRANSLATION REQUIRED

TRANSLATION REQUIRED

TRANSLATION REQUIRED

開會時的一些建議項目如下:

在您完成審查之後,應列有問題清單,可根據業務環境排列優先順序。也建議考量這些問題對於您的團隊之日常工作有何影響。若您及早解決這些問題,即可空出時間創造商業價值,不必忙於解決重複發生的問題。隨著您解決問題,可以更新審查,了解架構改良的情形。

雖然審查完成後,其價值所在自然明朗,但您可能會發現新的團隊起初可能會有所抗拒。經由對團隊教育審查的益處,可解決下列幾項反對說法:

在您與組織內的團隊實施多重審查之時,可能會找出主題上的問題。例如,可能會發現一群團隊的問題集中在特定支柱或主題上。建議以全面方式審視所有的審查,並找出有助於解決這些主題問題的任何機制、培訓或首席工程設計對談。