Landing Zone 提供的是一份可以參考的架構範本，而 Well-Architected Framework 則說明了這份範本背後的設計思維。

為什麼不同企業的架構會這麼相似？

前面的章節介紹了 Cloud Adoption Framework（CAF）與 Azure Landing Zone，了解企業如何建立一個具備身分管理、網路、安全、治理、監控與自動化能力的雲端平台。

如果把視野放得更廣一些，就會發現一個有趣的現象。Microsoft、AWS、Google Cloud 等主要雲端服務供應商，都提供了各自的參考架構。雖然採用的服務不同、名詞不同，甚至部署方式也不盡相同，但最後呈現出來的平台能力卻十分相似。

例如，通常會最先思考身分管理怎麼設計；網路架構、安全控制、治理能力以及監控機制，也都會在平台建立初期就納入規劃，而不是等到系統上線後再逐步補強。

這些安排並不是因為某一家雲端平台提供了哪些服務，而是大量企業在長期實務中累積出來的共同經驗。企業在不同產業、不同規模、不同技術環境下，都曾面臨相似的問題，因此也逐漸形成許多共同的設計原則。

Landing Zone 可以說是將這些設計原則具體落實在平台架構上的一種做法，而這些設計原則本身，正是 Well-Architected Framework 希望整理與傳達的核心內容。

Well-Architected Framework 提供了什麼？

（在微軟官方的文件會簡稱為 WAF，但為了避免跟 Web Application Firewall 混為一談，在這個系列都不另行使用縮寫，不是為了要灌水）

Landing Zone 與 Well-Architected Framework 經常一起被提及，因此不少人會認為兩者都是架構設計的方法，甚至將它們視為可以互相取代的內容。

事實上，它與 Landing Zone 所扮演的角色並不相同。

Landing Zone 著重的是平台應該具備哪些共同能力，因此提供了一份可以參考的架構藍圖；Well-Architected Framework 則整理了這些平台能力背後所依循的設計原則，協助架構師在設計、檢視或調整架構時，有一套可以持續參考的思考方式。

因此，它關心的重點並不是企業採用了哪些 Azure 服務，也不是系統是否完全符合某一份架構圖，而是希望協助架構師回答另一個更重要的問題：目前的架構，是否仍然符合企業的需求？

這也是 Well-Architected Framework 與一般技術文件最大的不同。

架構設計從來沒有唯一的答案。相同的需求，可以採用不同的技術；相同的平台，也可能因為企業策略、風險承受能力、法規要求、預算限制或組織文化不同，而建立出完全不同的架構。

因此，Well-Architected Framework 不是另一套新的架構，而是一套協助架構師檢視架構品質與設計取捨的原則。

如果將兩者放在一起理解，可以把 Landing Zone 視為一份平台架構的參考範本，而 Well-Architected Framework 則說明了這份範本背後所依循的設計思維。前者回答的是「平台應該建立哪些能力」，後者則回答「這些能力為什麼重要，以及如何持續檢視它們是否仍然符合企業需求」。

架構需要持續調整

架構完成部署之後，並不代表設計工作就此結束。

企業策略會改變，法規要求會更新，使用者規模可能持續成長，新的技術與新的威脅也會不斷出現。即使一套架構在建置當下完全符合企業需求，也可能因為外部環境改變，而逐漸失去原本的適用性。

因此，成熟的架構並不是一次完成，而是需要持續檢視與調整。

很多人在檢視架構時，容易把焦點放在技術本身，例如是否採用了最新的服務、是否符合某一份最佳實務，或是否依照原本的設計方式完成部署。這些都很重要，但從架構設計的角度來看，更需要思考的是：這些設計決策是否仍然合理。

例如，目前的安全控制是否仍然符合企業的風險需求？網路架構是否仍然適合目前的系統規模？平台是否仍然容易管理？當新的業務需求出現時，是否還具備足夠的擴充能力？

Well-Architected Framework 希望建立的，就是這樣的思考方式。它並不是在檢查架構是否完全符合某一份標準，而是透過一套共同的設計原則，協助架構師持續檢視目前的架構是否仍然適合企業，並在需要時適時調整，而不是等到問題累積到無法改善時，才重新設計整個平台。

如何看待架構品質

不同的 Well-Architected Framework，都有自己的分類方式。Microsoft、AWS、Google Cloud 等雲端服務供應商，雖然採用不同的名稱，也有不同的架構支柱（Pillars），但背後關注的核心其實十分相似。

它們都希望協助架構師持續思考：架構是否仍然安全？是否仍然可靠？是否容易管理？是否具備足夠的擴充能力？以及是否仍然符合企業的需求。

如果把這些理念整理在一起，我認為一套成熟的企業架構，至少應該從五個面向來思考：

• 機密性（Confidentiality）
• 完整性（Integrity）
• 可用性（Availability）
• 規劃（Planning）
• 持續改善（Continuous Improvement）

其中，機密性（Confidentiality）、完整性（Integrity）與可用性（Availability），也就是大家熟悉的 CIA，是所有資訊系統最基本的品質要求。無論系統部署在地端、雲端，或採用任何技術，都必須思考如何保護資料、確保資料正確，以及維持服務持續運作。

然而，對企業架構而言，只滿足 CIA 並不足以支撐系統長期發展。 一套架構除了符合目前的需求，也必須具備因應未來變化的能力，因此我認為還需要再加入兩個重要的面向：規劃（Planning） 與 持續改善（Continuous Improvement）。

規劃代表架構設計不能只滿足目前的需求，而是必須預留足夠的彈性，讓未來可以持續擴充、整合與演進。當新的需求出現或系統持續發展時，架構不需要推倒重來，而是能夠建立在既有基礎上逐步調整。

持續改善則代表架構不是一份完成後就不再改變的設計文件，而是一個持續演進的過程。透過持續觀察、持續檢視與持續調整，企業可以不斷修正原本的設計決策，讓架構始終維持在符合企業需求的狀態，而不是等到問題累積之後，再重新規劃整個平台。

因此，對我而言，一套成熟的企業架構，不只是滿足 CIA 所代表的基本品質要求，更需要具備面對未來變化與持續演進的能力。

這五個面向並不是另一套新的框架，也不是要取代各家雲端平台提出的 Well-Architected Framework。我只是希望用比較容易理解的方式，整理出不同框架共同重視的核心理念，作為後續討論企業架構時的一個共同觀點。

小結

Landing Zone 提供的是一份經過大量企業實務驗證的參考架構，協助企業建立共同的平台能力；Well-Architected Framework 則進一步整理了這些平台能力背後所依循的設計原則，讓架構師在不同的設計取捨之間，持續檢視目前的架構是否仍然符合企業需求。

對我而言，Well-Architected Framework 最值得學習的地方，不是記住每一項架構支柱，而是建立一套思考架構品質的方法。因為真正成熟的架構，不會因為系統完成部署就停止演進，而是會隨著企業需求、技術發展以及外部環境的變化，持續調整與改善。

因此，一套好的架構，不只是今天能夠安全運作，更重要的是未來仍然能夠持續支撐企業的發展。