作者：文／John McDowall 譯／潘得龍
將系統架構的重點放在針對現有服務資源進行重新設定以 強化企業能力，而不是單純的重新建置整個系統。
不論我們願不願意承認，資訊 系統架構方法是持續演化的。從過 去幾十年以來，系統架構的建置方 法，就有如在蓋建築物一樣：首先 決定需要什麼樣的系統，然後確認 需要那些重要的子系統以及這些子 系統互動的方式。接著，持續以這 樣的方式拆解，直到所規劃的系統 足以讓開發團隊做出這些個別的子 系統，然後將這些子系統整合以建 立出理想中的系統。不過這樣的方 式最近幾年來已經有些改變，而且 變化的比率逐漸增加。
網路的影響
隨著網路系統從1990年代普 及之後，系統架構開始有了改變。 主從式架構的出現成為當時的主要 設計類型，網路能力成為架構中必 要的元素。系統不再是放在一個諾 大房間中的一組巨大機器，然後使 用終端機操作。取而代之的，是許 多能夠散佈於任意地點的一般個人 電腦。 未來受到網路影響系統架構改 變，則是系統的整合。我們很容易 就發現，讓操作者在不同的系統 中輸入相同的資料，是非常浪費時 間，同時也很容易出錯的。所以我 們開始嘗試做系統整合的事情，讓 資料能夠共享。這樣的趨勢，就產 生了「以服務為導向」(SOA)的架 構。SOA的基本觀念，是讓提供服 務的供應者，在網路上以可用服務 的方式提供資源，網路上的任何應 用程式都可以直接提出要求而獲得 服務。所謂的「服務」就是針對想 要提供的能力定義出完整的介面。 SOA讓系統走入動態程式碼的時 代，出現能夠根據新的業務需求自 動調整，而不需要修改程式碼的應 用程式。
服務的普遍應用
跟許多吸引眾人目光的新科技 一樣，SOA一開始並沒有能夠表現 出符合大家期待的能力。也與許多 其它熱門科技一樣，當經過十多年 之後，熱潮退燒，SOA的真正效益 才慢慢地開展出來。如我們現在所 見的，許多的功能都以服務的方 式呈現，並且也普遍被許多企業採 用。例如，Facebook和Goolge所提 供的驗證服務。如果你開啟了一個 網站，然後想要在先驗證使用者允 許使用網站上的所有功能，你並不 需要自己建置驗證子系統－只要使 用這些這類公司所提供的服務。相 同的情況，評論留言區、社群媒體 整合、使用者統計，以及其它許多 的功能也都能以服務的方式提供。 整個雲端運算的革命，事實上是一 種將運算硬體轉移到隨選服務。
雖然目前的面貌不是當初設想 的方式，SOA革命確實是明確發生 的。大部分的企業目前在整合上 的努力，讓系統介面能夠公開使 用。這通常是指「應用程式介面」 (API)的基本哲學理念。API基本哲 學的最有名的事件，或許是「the Steve Yegge rant」這段文字中的描 述，其中作者責怪Google沒有採用 Amazon以API為優先設計的哲學。 這篇怒氣衝衝的言論，基本上是強 烈期待所有的系統功能都應該藉由API的方式在網路上顯示出來，一 方面可以有助於，另外一方面則是 能夠減少企業功能重複開發（以及 付費）的數量。
API如何影響系統的架構
到目前為止，以API為優先作 法的主要效果，已經讓開發人員習 慣於他們所設計API規格製作文件 並公開化。不過對於Amazon以API 為優先作法的主要信念，是建立於 能夠減少因為在多個系統重複開發 相同功能的程式，所 帶來的成本降低。因 為大部分的企業都要 好幾年才會更新一次 系統，但隨著時間的 推移，這些影響將會 讓人感覺到，特別是 當以API為優先作法與 建置前重複使用的作法結合，會需 要系統開發人員重複使用在企業中 已經存在的功能然還才開發新的。
當越來越多的系統讓他們的功 能可以經由API分享出來，而開發 團隊也被要求必須在開發之前確認 有沒有可重複使用的子系統，這將 會出現一個現象，就是原本想要建 立的新系統，會被以現有功能整合 的新功能的方式重新設計。由於各 種不同的目的，在整個系統之間重 複的數量是令人驚訝的。大部分的 系統需要一種儲存與讀取資料的方 法，又大部分的系統需要驗證與使 用者授權的方法，同樣的大部分系 統需要有能力顯示文字與繪製圖 形。這些列出來的功能或許都能夠 從企業已經存在的資源中，不斷地 被重複使用。對於早期的系統開發人員，開發人員會需要自行設計屬 於自己系統中的上列功能，成為系 統中的一個迷你功能系統。但隨著 這些基本的功能都可以採用服務的 方式提供，系統設計者的工作就從 必須設計整個系統，演化成在系統 生態系統中設計增加邊際能力。
趨向以功能為中心的架構
我們目前都必須面對企業生態 系統，所需要各類的功能快速擴 張，並且都逐漸以服務的方式設計，尤其在雲端的環境更是如此。 雲端供應商之間也以提供更多的功 能作為與對手之間競爭籌碼，並且 也已經可能藉由整合新的服務與一 些現有軟體或是描述性與語言，而 開發出一些基本的系統。如此一 來，開發人員就只需要幾個星期的 時間建立出許多不用自己設計功能 系統，這在以往可能需要好幾個月 的時間。雲端供應商所提供的基本 系統，可以透過加入所需要使用的 新服務而快速提昇功能，如果還沒 有服務可以使用，則可以安裝額外 的模組補充。想要在實際建置之 前，就嘗試找出系統的所有細節是 沒有意義的，我們需要新的方式思 考系統架構與設計。
大部分的情況下，在一個企業 中，已經存在有許多服務可以使用，建立新的系統應該要先清楚定 義出所需的系統需要那使用些功 能，然後與目前已經存在的所有服 務功能清單進行比對。這樣的作法 可以顯示出在企業內部已經存在多 少可用的理想系統，並且也清楚有 多少功能是需要另外開發的。現有 可以使用的功能與需要再定義能力 的功能，這兩者之間的差異，正是 企業目前的能力與想要達到能力之 間的差異。當我們走向未來，系統 架構的主要任務就會從設計整個系統轉移成確定目前能力差異，然後 設計縮小差異的最佳方法。 我們目前還不是很清楚，這種 以功能為中心的架構是否會比較容 易進行。我們能夠掌握整個企業 中所有可用的服務，事實上是有很 嚴厲的限制。任何誠實的網路管理 員，都會承認他們無法掌握在他們 所管理的網路上，所有可用的完整 服務清單。他們可能知道有什麼機 器連接到網路上，這些機器運行什 麼軟體，以及這些機器開啟那些通 訊埠與通訊協定。不過這些資訊只 能告訴我們這類內容網路層級的觀 點，而無法披露這類項目的實際 使用方式。例如，在網路上使用 著8443通訊埠，並且接受HTTP連 線，有可能表示只是單純提供簡單 的網頁資料內容，但也可能實際上藉由該介面提供許多REST服務。 當然目前有方法可以顯示出這 類內容，不過大部分都是採用手動 的方式。例如，維護一份企業中所 有可以使用的服務清單百科，不過 這就必須要求開發人員在每次建置 新的或是異動服務的時候，就需要 同步更新這份清單。當然採用自動 化的方式，表示能夠以即時識別並 且建立服務介面的目錄，這樣是更 有效率，不過這已經是另外一個主 題了。
例外情況
某些地方還是需要使用傳統的 系統架構處理，因為這些環境需要 這樣的系統才能運作。當在營運 環境中將功能公開於整個企業會產 生問題的時候，就需要採用傳統的 方式，也就是整體設計新的系統。 例如，航空飛行控制系統就真的無 法以呼叫由地面所提供的服務或是 相關的功能，因為這會影響飛行安 全。類似的情況，衛星系統以及其 它類型的內嵌型軟體，都需要在系 統本身提供重要的功能，而無法以 呼叫外部服務取代。
傳統的系統架構並不會整個消 失，不過那的確已經是舊的方式， 而我們現在應該要開始思考如何實 際上改善系統架構的效率，以便更 能支援目前企業快速演化的情況。