技術 Day 13 - 架構師如何閱讀一張架構圖？

同一張架構圖，開發人員看到的是功能；架構師看到的是資料、關係，以及背後可能存在的風險。 一張架構圖，是架構分析的起點 在實務工作中，架構師每天面對的情境，...

技術 Day 12 - 理解 Shared Responsibility：建立正確的責任邊界

雲端最大的改變，不是責任轉移，而是責任重新分工。 雲端改變的不只是技術，也改變了責任邊界 前面的章節介紹了架構設計的方法、平台能力以及架構品質，也逐步建立...

技術 Day 11 - 從架構到原則：理解 Well-Architected Framework

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

技術 Day 10 - Azure Landing Zone：從參考架構理解平台設計

真正成熟的平台，不是先部署系統，而是先建立一個能夠承載所有系統的平台。 Azure Landing Zone 解決了什麼問題？ 上一章介紹了 Landin...

技術 Day 9 - Landing Zone：一套可參考的架構藍圖

好的架構，不是從一張白紙開始，而是站在前人的經驗之上，建立適合自己的架構。 Landing Zone 解決了什麼問題？ 前面的章節介紹了 Cloud Ad...

技術 Day 8 - 架構設計是一個持續規劃、實踐、驗證與優化的生命週期

成熟的架構，不是完成一次建置，而是建立一套能夠持續規劃、治理與改善的管理方式。 架構設計不是一次性的工作 很多人剛接觸雲端時，容易把上雲視為一個專案：需求...

技術 Day 7 - 從 Cloud Adoption Framework（CAF）理解雲端架構

當企業策略逐漸清楚之後，真正的挑戰，才是如何一步一步將它轉化成可以落地的架構。 企業如何建立一致的架構思維？ 前面的章節，我們談到了架構師的思考方式，也介...

技術 Day 6 - 如何在企業中落實架構原則

架構原則告訴我們應該往哪裡走，而框架（Framework）則提供一套共同的方法，讓整個組織朝著相同的方向前進。 光有原則，還不足以支撐一家企業 前面的章節...

技術 Day 5 - 好的架構，都有共同的特質

沒有任何一套架構可以適用所有企業，但所有成功的架構，都有一些共同的特質。 不同的架構，卻有相同的方向 前一篇提到，架構原則承接的是企業的策略、治理要求與風...

技術 Day 4 - 架構原則，如何把企業需求轉化成架構設計？

架構原則不是限制技術，而是將企業的策略、需求與價值，轉化成所有人都能共同遵循的設計方向。 從企業需求，到架構設計 前一篇提到，成熟的架構師在開始設計之前，...

技術 Day 3 - 架構師思考的，不只是技術

技術可以解決問題，但真正困難的，往往不是技術本身，而是如何在眾多選擇之中，做出最適合企業的決策。 開始設計之前，第一個想到的是什麼？ 如果今天開始設計一套...

技術 Day 2 - 架構從來不是一張圖，而是一連串設計決策

真正的架構，不是畫出一張漂亮的架構圖，而是讓系統在五年、十年後，仍然能夠持續演進。 我們常常誤會了「架構」 提到「架構（Architecture）」時，許...

技術 Day 1 - 為什麼需要架構思維

架構師不是一個職稱，而是一種面對複雜問題的思考方式。 一個角色的出現，反映的是環境的改變 如果把時間拉回二、三十年前，大多數企業的資訊部門並沒有「架構師（...

技術 多 agent 開發領悟出 discovery 流程的重要性

最近因為除了自己買的 claude pro 方案之外，也有公司的帳號提供 teams 方案，所以嘗試在開發中多開幾個 agent window 來進行開發，而我...