3種CTO要小心的架構技術債

書亞集成技術長曾義峰觀察，最常出現的架構技術債，是系統缺乏延展性，其彈性不足以支撐業務成長，即使想要增加硬體、水平擴充時，系統架構也不允許，導致升級很困難，這時候，導入最小可行性產品（MVP）的觀念是解法之一（圖片來源／iThome）

番茄、黃瓜等作物需要背後支架作為支撐，才能順利往上長，而企業想要繼續蓬勃發展，撐起其運作背後的IT架構，也扮演著類似地位，例如，軟體架構、程式語言的選擇，在數位轉型、產品轉型等重大決策都有舉足輕重的地位。

而書亞集成技術長曾義峰表示，最理想的技術決策是根據團隊、公司需求，搭建出最合適的技術組合，「但現實狀況中，技術組合大多是由技術長、架構師等關鍵人物決定」，如此運作下，一家公司的技術決策，也會跟該關鍵人物的開發偏好有相當關聯。

他表示，不時聽到來自軟體社群、企業或新創公司的開發者，抱怨如此重大決定，卻只透過技術長或是外部顧問所決定，例如一舉決定放棄.NET，改為使用Java；或認為使用PHP開發步調太慢，全部改使用RoR，「這些決策未必錯，但是必須能夠讓人信服。」

而曾義峰認為，執行技術決策時，總共有三大重點。首先，必須視架構為最優先考量，「架構會影響商業文化」，同時，不能只重視技術，而忽略既有內部流程跟人員，他表示，當開發者晉身為技術長、架構師後，思維要超越程式碼層次，「不能只了解技術。」

第二要素是選擇最適合自家的架構，「完美的架構並不存在，更沒有可以套用在所有應用情境的架構」，他表示，當開發者不能列舉某架構存在的缺陷，也意味著對它不夠熟悉。最後一個要素，則是不過早改良架構，「架構必須逐漸演進」，他認為，太早追求一步到位，反而是短視近利。

設計不良的架構，將衍生出後續架構債

而設計架構時，無外乎希望能同時滿足三個條件：節省成本、具有擴展性，以及能快速進入市場。然而，一旦沒有滿足其中的任一條件，都會衍生出後續三種架構債（Architectural debt）。

第一種架構債常常出現在具備實戰經驗的技術團隊，沒有快速進入市場壓力下，通常偏好導入最新、最佳化的架構，因此，在此碰上過於架構過於早熟（Premature）的問題。而曾義峰提醒：「我們都不是AWS、Google或是臉書等大公司」，真正重要的問題在於，現階段組織的營運規模是否適合導入該架構。