註：這陣子參與撰寫一本專為下個月在上海的 BEAWorld 大會所準備的 SOA 專書，以下將我負責寫的部分整理摘錄。

SOA 承諾許多美好的願景，IT 體質經過調養，轉變成敏捷、靈活，能快速回應業務需求的有機體。但如果只有一個崇高的目標願景，卻缺乏一套有效的體制和方法，千頭萬緒不知從何下手，那麼願景將持續是高遠的願景，依然是那麼地遙不可及。

建設一個企業級的服務導向架構，不論在規劃、施工、維運，乃至於治理 (Governance) 這些關鍵課題上，都能從多年來在城市建設領域所累積的經驗和教訓中，得到許多借鏡。

在一個城市裏，現存了許多商業大樓、公寓等建築物，就像一個企業，多年下來累積了許多應用系統，而各式各樣的建設專案，仍持續地在進行著。這樣的城市，必須考慮兼顧擴增建設與改造既有的問題 － 既要新建一批重大基礎設施專案，加強現有能力，又要注重對既有設施的更新改造，功能完善和最佳化，整體提高基礎設施服務的效率和水準。如果任由這些建設各自隨性發展，將難以確保他們日後的一致性和協調性，各棟建築物的水、電等能源系統，排水、衛生下水道，以及社區巷道是否都能一一與城市的供水、供電、下水道，主要道路等順利接軌，都將是個問號。此外，城市本身的交通、治安、能源供應、衛生、空氣品質、休閒設施，乃至於生活機能，能否符合城內居民和企業的期望，使其居住愉快，進而充分發揮生產力，將決定一個城市的興衰成敗。我們因此可以說，城市建設的成功關鍵，在於是否能建立一套通用的框架 － 包括原則、制度、和規範，來確保城市發展的過程，能持續不斷地朝著市民所期望的發展目標，逐步邁進。

城市規劃

城市規劃確立城市發展的框架，劃分工業區和住宅區，並制定供水、供暖、供電以及交通流量等規劃。城市規劃是一項社會協定，透過由城市居民與企業導入的各項地方專案，推動城市的合理發展。

如果沒有城市規劃，城市就有陷入混亂的危險－缺乏凝聚力，對於交通和基礎設施的投資，亦將缺乏一致性。城市規劃是一種行政手段，經過對一般性決策中，需要反映的各方利益進行通盤考慮後，來為建設和發展目標設定界線。

各個城市在地理位置、人口、歷史、商業與能力結構等方面的先天環境和條件，都不盡相同。因此，它們需要制定不同的規劃，儘管這些規劃在外行人的眼中可能大同小異，但是它們實際上反映了差異極大的現實情況，因此規劃出來的內容，也可能存在著很大的不同。

城市規劃有全國、地區和本地規劃之分（同樣，SOA 也可能在不同的層級來規劃和導入），例如：

• 國家級
• 部門/社區級
• 單一機構/機關級

城市規劃的制定要經過許多階段，各階段的持續時間可能是數周（簡單的修繕等）也可能是數十年，它們需要各種層級的規劃。

施工和驗收

規劃完善的城市設施和建築物，當施工專案一一發包給各個團隊去落地的時候，必須要有一套方法來貫徹規劃時所制定的標準規範和進度，除了確保施工品質之外，還得兼顧專案間的協調性和一致性；此外，樓房建造和各種公共基礎設施（道路、公園、自來水管線…）的建設專案，關注點各有不同，在落實和驗收時必須兼顧所有重要的環節。

城市維運

高效的城市建設管理，能真正將專案的決策、施工、營運全流程與規劃目標的實施關聯起來，透過評價指標體系和資料模型的建立，將專案從規劃、決策，到營運中發生的行為和實施效果，進行有系統、科學化的量化評價；並能逐步樹立對城市建設和城市基礎設施的效果評價指標體系，注重效率分析，加強階段性評估。同時圍繞專案決策所提出的目標、功能、工作、組織，進行事後評價，重點是對預期的專案決策效果和專案導入後的實際效果進行比對考核，分析變化原因，總結經驗教訓和feedback，以作為下期規劃時的重要參考。

組織與監管／治理

成功的城市經營管理，往往借助於專責機構的建立。專責機構對領導小組負責，負責建設專案的研究策劃、具體工作的組織與實施，和政策的跟進與落實，進而統籌、協調、檢查、督辦各項工作任務完成情況，透過建立監管制度和定期簡報制度，落實工作進度，同時代表政府，行使監管職責。

和城市建設相同，SOA的發展也要歷經類似的規劃、施工、營運階段，而且需要一個專責的組織來執行一套治理框架。

SOA 三大階段

SOA 是一個旅程，其中有三個關鍵的流程和階段，各自有不同的 iteration（迭代），由不同的角色參與（如下圖）。在策略和規劃的流程中，由高階管理者 (VP, CIO, CTO 等) 所組成的籌畫指導委員會，以及負責向他們報告的業務策略師、業務架構師、規劃師、分析師、和專案管理辦公室 (PMO) 中的相關人員，定期（例如每半年）進行 SOA 策略規劃。SOA並非萬靈丹，因此規劃應始於辨識出企業中有哪些迫切的業務和IT問題，最適合借重SOA來解決。策略師、架構師首先就 SOA 的價值驅動力（即value drivers，例如：整合客戶資料、業務流程最佳化、降低維護成本），進行分析，針對目前的業務能力和 IT 現狀，根據 SOA 對各項業務和 IT 驅動力的正面影響力，來選定重點方向；然後再朝向未來的目標願景，分析差距，並排定導入 SOA 的優先順序，和若干個專案計畫，及相關的評價體系，在舉行下一次策略規劃之前（例如半年後），分別導入相應各價值驅動力的解決方案。這些專案不宜過大，而應該切割成較小、容易掌控的大小範圍。每個專案遵循共同的服務工程框架規範和流程，各有各的iteration，然後逐步從每個解決方案的開發流程中，同時選定、提煉出有共用價值的業務服務。在專案導入的流程中，參與的角色包括業務架構師、服務架構師、資料架構師、安全架構師、解決方案（應用）架構師、程式設計師、專案經理，和 QA 測試人員等。

圖說：SOA 的三大階段

有別於傳統的軟體發展流程 (SDLC)，服務的生命週期，並不隨著開發活動告一段落，解決方案和服務上線而落幕；而是進入另一個階段，由 IT 中心營運人員，依據先前在每個服務工程專案之初所定義的服務契約中的各項指標，對各個業務服務，透過儀表板等界面進行生產監控（包括業務活動監控，BAM），並且定期將生產資料以報表的形式feedback給 SOA 規劃指導委員會的成員，進一步分析已執行的各個 SOA 專案的目標達成率，並計算其投資回報 (ROI) 等，作為下個規劃週期中，修正、調整目標的重要參考。

要強調的一點是，策略規劃或專案導入的流程，都是週期性、iterative（迭代）的流程，系統化地運用 IT，來一步步地緊密配合業務目標。而生產營運則是持續性地對服務的各個世代，不斷追求最佳化的歷程。

服務生命週期

SOA 中各個服務所經歷的生命週期，與傳統用來開發應用系統的軟體發展生命週期 (SDLC) 概念 ，有很大的區別。如附圖所示，服務的生命週期，實際上更接近於產品生命週期管理 (PLM)，一個服務可能歷經多個世代，多次「輪回」，最後進入退休、除役狀態。服務在多次iterative式的流程中，也可能因業務需求的改變，而被調整、或與其他服務進行重組、功能合併，此外如服務契約的調整，以適應不同的安全和服務水準協定 (SLA) 要求等情況，都可能催生新版本的服務，而透過服務基礎設施中 ESB 所提供的路由服務，我們可以有效地讓多個不同版本的服務，同時執行，服務不同時期所建立的服務消費者，讓消費者和供應者之間的耦合更為降低，而不需要強迫所有消費者配合某個供應者，同時進行升級。

圖說：服務生命週期和其中主要的階段

專案導入與服務工程框架

為什麼SOA需要一套新的工程框架？首先，如上所述，服務生命週期的涵蓋範圍，遠比傳統以專案為單位的應用系統開發週期來得長。傳統的軟體交付方法，如 waterfall 及 UP，當放到 SOA 的情境中的時候，則顯得有些不足，因為傳統的軟體交付，往往局限在個別專案的範疇，而交付的對象，則以應用為目標，而沒有一套流程，能將功能拆分成適合在企業層級重複使用的服務模組。在 SOA 專案的流程中，我們除了和以往一樣，需要開發出某個應用／解決方案之外，在此同時，還需要辨識、並建置出若干個在未來能重複使用的服務模組，也可能利用既有系統中現成的功能進行重構 (refactoring)，把他們封裝成服務。這些都需要對傳統以個別專案為基礎、應用導向的工程方法流程，加以補強，來配合 SOA 中服務生命週期的特性，和前面提到的，漸進式、iterative的策略規劃和專案導入。

一套適合 SOA 的專案工程框架，應將視野從個別專案及應用的層級，上升至整個企業的高度，在多個專案之間掌握關鍵的共通性；同等重要的是，它應該不需要推翻、顛覆企業現有的開發流程，而是能在原有的基礎標準之上，建置、增加服務交付所需增加的關鍵步驟，來進行 SOA 需求管理、服務選定、辨識、服務契約 (contract) 的定義、介面設計，和專案發佈計畫等，並且能支援漸進式、一個接一個專案的執行方式，來逐步導入 SOA 參考架構中所制定的目標和願景。

公共服務和基礎設施

繼續城市規劃的比喻，城市規劃必須包括建立提供公共服務的原則，使所有建築、房產能順利地連結到這些服務：

• 供水、供電、供暖等
• 衛生下水道和垃圾處理系統
• 電話、有線電視、網際網路等

服務的建立是公共投資，而服務的使用則需要得到控制、管理和監督。在此同時，這些公共服務必須能以合理的價格，提供給房產的屋主和住戶。

就像城市需要這些基礎設施，SOA 的建設的過程當中，同時需要建立橫跨各級服務和系統間的基礎服務，包括legacy系統整合服務、資料整合服務、服務訊息路由、服務流程編排、用戶界面展現服務，服務登錄等。我們將這些 SOA 的基礎服務集合統稱為服務基礎設施 (service infrastructure)。廣義的服務基礎設施，可定義為 SOA 架構下，支援所有業務服務執行的基礎，因此除了上述的SOA 中介軟體外，舉凡應用伺服器、資料庫、虛擬機、硬體、儲存、網路等，皆可視為基礎設施中的各個環節，即所謂的 SOI － Service-Oriented Infrastructure。隨著虛擬化 (virtualization) 和網格計算技術的快速發展，在部署方式上也將更為敏捷、靈活，從而更進一步強化 SOA 快速回應業務變化的能力。

SOA治理

除了規劃參考架構和服務工程框架之外，企業在規劃導入SOA時，還必須全盤考慮治理／監管 (governance) 的問題。

SOA的導入需要從文化上轉變人們在一起工作的方式，在 IT 和業務職能部門之間建立更加密切的協調關係，將注意力更加集中在為整個企業提供價值，而不僅是silo式地集中在單一職能部門。

儘管許多導入SOA的公司可能已經參考某些標準（如 ITIL、COBIT）在進行某種 IT 治理計畫，但是SOA不管對服務生命週期、技術標準、團隊組織角色，和技能等方面，都有許多新的要求，換句話說，SOA帶來了很多傳統 IT 治理範圍外的新課題。從這個意義上講，為了確保SOA的成功導入，應該將SOA治理，當作一個專門的學科來對待。

SOA治理框架的建立，能夠幫助機構深入、通盤地瞭解本身的組織結構、營運流程、工具、標準，和指導原則。

圖說：IT 治理、SOA 治理，和企業架構 (EA) 各自的涵蓋範疇

參考資料及建議的延伸閱讀：

• Danish White Paper on Enterprise Architecture
• BEA Consulting Service 相關資料
• Agile & SOA: Like Structure Building and City Planning
• Enterprise Architects, Professional Escalation, and City Planning

照片來源：倫敦城市模型 by Flickr 用戶 megapiksel