是什麼讓軟體架構師成功？

July 26 12:10~12:58  14:50~16:32

 

今天繼續介紹IEEE Software的文章，前兩天介紹DevOps，今天換個主題改談軟體架構。在今年1/2月的IEEE Software有一篇名為「What Makes an Architect Successful?」的文章，討論軟體架構師成功的因素。

***

什麼是軟體架構師

在討論軟體架構師（software architect）的成功因素之前，先定義什麼是軟體架構師。文章提到有研究人員幫軟體架構師定義了200種責任、100種技能，以及100種知識領域。這種「規格」太高，一般鄉民無福消受。文中採取《Software Architecture in Practice》一書的說法，先討論軟體架構的定義：「軟體架構是理解系統所需的結構，每個結構包含了元件、元件之間的關係，以及元件與關係的屬性。」

軟體架構橋接了系統商業目的與實作。架構師的主要責任就是確保實作出來的系統可以儘量達到功能與非功能需求。

***

軟體架構師的三種角色

依據不同的軟體生命週期，文中提出三種不同的軟體架構師角色：

• Initial designer（初始設計者）：專案初期從無到有設計系統架構，此時架構師的設計重點著重於如何滿足重要的功能與非功能需求，並且要確保系統架構的概念完整性（conceptual integrity）。架構師還需要考量所設計的架構最好可以和開發團隊的技能與經驗互相匹配、可以用增量方式開發，並且支持持續整合和持續交付。這個階段的架構師可能會參與實作，但其實作的主要目的在於製作雛型與驗證架構的可行性。

為了或得概念完整性，成功的Initial designer需要具備「大處著眼」以及良好的抽象能力。這種能力通常需要結合實務經驗與正規訓練。

• Extender（擴展者）：當系統上線之後，開發團隊還是經常需要撰寫新的功能或是與其他系統進行整合。此時架構師的責任就不是從無到有設計新的架構，而是需要了解現有系統並且尋求擴充與整合方案。因此，架構師需要實際動手操作系統程式碼以便或得第一手資訊。假使增加的新功能不在Initial designer的規劃中，Extender便可能需要犧牲原本系統架構的概念完整性以達到擴充新功能的目的。例如，在系統中加入特殊判斷條件以支援新功能。

Extender的成功則需要仰賴對於現有系統的深入理解、現有系統所使用的技術以及與它有關的週邊系統（例如資料庫、中介軟體、應用程式框架等）。相較於Initial designer從無到有做出設計需要很強的分析功力，Extender對於分析能力的要求比較少。

• Sustainer（維持者）：當系統已經上線好一陣子之後，架構師的角色轉變成Sustainer。此時系統還是持續提供服務但越來越難以維護與擴充。此時Sustainer的責任就變成在避免改變系統的前提之下，儘量將其的價值發揮到最大。例如，原本的系統只可以跑在Windows 98上。在微軟停止支援Windows 98之後，有沒有什麼辦法繼續幫系統「續命」，讓它持續提供服務。

Sustainer最重要的能力是溝通。他要說服有關人等系統依然可以提供價值，並說明要以何種方式持續利用系統的剩餘價值，如何以最小的代價繼續壓榨系統。Sustainer不需要提升自己的設計能力，而且通常只關注成熟或是以經過時的技術。

***

失敗模式

了解Initial designer、Extender與Sustainer這三種架構師角色與其責任和成功要素，作者最後提出三種失敗的架構師模式：

• Wrap-around：將一個成功的既存系統的Sustainer調到新專案中扮演Initial designer。這種狀況在業界很常見，因為既然Sustainer「最懂舊系統」，何不讓他擔任新系統的架構師呢？例如，將原本用VB撰寫的單機版程式改成Web-Based系統。雖然Sustainer很懂VB，但卻不懂Web-Base架構，所以很有可能無法勝任。
• Rising star：一個開發人員在系統上線之後成功扮演Extender角色，完成了幾個系統整合的功能。因為這些成功經驗公司決定讓他獨挑大樑，在新的案子中擔任Initial designer。但是這位開發人員出身的Extender很可能沒有受過正規的分析與設計訓練，例如沒學過物件導向分析與設計（OOAD）和軟體架構課程。在這種情況之下所設計出來的架構可以符合團隊的技能，但卻可能無法滿足重要的功能與非功能需求。
• Overprotective parent：一個Initial designer在系統上線之後持續擔任Extender，但是他不甘心原本設計的架構為了滿足新功能而必須在概念完整性上有所妥協。所以他採取昂貴、大規模修改的方式來擴充功能，因此導致系統無法快速交付新功能而被競爭者追過去。

***

以往談論軟體架構師，總是以「從無到有」的角度來看待這個角色，也就是文中所提到的Initial designer。但實際上在軟體生命週期的各個階段，還是需要架構師協助，只是在不同階段架構師所需要的技能與成功因素不同。忽略這些差異性往往會造成文末所提到的那三種架構師失敗模式，值得留意。

***

友藏內心獨白：人人都是架構師，有可能嗎？