技術在 SOA 是次要的嗎？

「SOA 不只是技術」，是我們常聽到的一句話；然而，SOA 是否與技術無關呢？近日同人看到在 InfoQ 中文站有一篇文章，主題是〈SOA重在技术还是业务？〉，提到了網路上對此議題的相關討論，並表達了該篇文章的看法。

該篇文章引用《An Architectural look at SOA》中的一張圖（如下圖）來說明架構的技術觀點，並認為 SOA 畢竟是一種架構風格，與任何架構性工作一樣，架構者必須先想清楚架構性目標為何，並在作出技術上的選擇後，必須回頭重新審視架構上的決策。在技術、平台等全部到位之後，總有它們自身的一套架構、功能和限制。

該篇文章的結論是，技術是重要的，因為不管是 SOA 或任何專案的設計中，都不可能忽視技術。但對技術的定位而言，該篇文章卻認為，技術應該放在第二位，業務才是第一位的，對此，該篇文章留下了讓讀者思考的空間。

同人對該篇文提到「與技術無關」的說法（It’s not about the technology, INATT）很感興趣，這個名詞是由 Andrew McAfee 提出的，於是進一步地閱讀他的觀點。Andrew 指出 INATT 有兩種不同的意思，一種是正確的，但卻無法傳達什麼訊息；而另一種卻是可以傳達大量的資訊，但是錯誤甚至是危險的觀念。

Andrew 指出第一種正確而乏味的 INATT 說的是「不只和技術有關」，換句話說，技術不會自發且獨立地開始交付價值、產生利益、並且精確地做系統配置者心中想要做的事。要做到以上的事情，必須對技術加以管理，技術本身並不是魔術子彈或是奇蹟療癒。但這還需要說嗎？Andrew 提到他很少看見有人把技術當成魔術子彈，他認為這個版本的 INATT 的好處是可以提醒管理者，專案的成功需要低估管理變動的金額，但實際上，這個想法對他們而言並非新鮮事。

另一個的 INATT 的背後意義則是「為了討論的目的，技術的細節是可以被忽略的」，Andrew 認為如果這個假設可以成立，那對每一個通才真是天大的好消息，因為如此他們就不需要花時間熟悉問題的技術觀點，只要系統安裝正確，他們只要把系統看成黑盒子就可以將特定的輸入轉成特定的轉出就可以解決問題了。

Andrew 認為這樣的觀點是危險的，因為這樣在本質上否定了兩個重要的事實：因為技術會和其它突出的方法的技術會有不同，同時它們能夠一直在變動。這樣做是忽略了不是帶來了混亂就是讓情況惡化的局面，Andrew 認為這個版本的 INATT 是慫恿聽者不注意技術的差異性，所以他認為這種觀點是一個很糟糕的想法。

〈SOA重在技术还是业务？〉這篇文章也提到不同層面的 INATT，指出 Burton 的 Annie Thomas Manes 強調在設計過程中技術是次要的，她指出技術是實現的決策，當專案開始之初，專案經理應該先分析並確認專案需求，然後才選擇適當的技術來滿足專案需求。Annie 認為，技術只是工具，應該為工作選擇正確的工具，但首要之務要先確定專案要做的工作是什麼。

在閱讀了上述文章的觀點後，同人認同技術很重要，在 SOA 的軟體開發專案中，當然不可忽略技術，但專案也不只是技術。除了技術觀點外，專案同時要考慮的問題層面是很廣的，誠如 Andrew 所說的，技術並不會主動產生價值與效益，而是必須妥善地加以管理。但同人對技術在專案中是次要的，業務才是主要的看法卻持保留的態度，為什麼呢？因為關鍵在邊緣而不在核心，我認為業務與技術的地位是同等重要，專案要成功，必須妥善地整合兩者，而非只是讓一方配合另一方。

那麼什麼叫做妥善地整合呢？舉個例子來說，如果把專案的任務分解出來，如果發現我們的任務中只包含單純的技術或是業務的工作，那麼這個單獨的任務就會令人憂心將來可能會有整合的困難。所以，每一個專案的任務都應同時具有業務及技術，甚至要包含更多廣泛的專案不同觀點，並將所有的不同觀點整合起來。這就是所謂的將整體織入部分的全像圖組織理論的概念，每個專案任務都兼具所有專案不同維度的觀點。

同人從個人參與軟體專案的開發經驗中發現，將軟體開發的工作分工雖然可以增加個別工作效率，但卻會在後來的整合上常面許多問題而影響開發效能。在 SOA 軟體專案中，理論上開發的工作可依業務流程建模、企業架構、及軟體設計與實作的方式來做任務分工，但實際上把它們放在一起卻常會產生一些困擾，IBM developerWorks 就有一篇文章提到這些問題：

在業務流程建模方面：

在個別功能性交易之上提供了一對一的對應，但是它們通常都沒有觸及架構和實作領域， 並存在著許多流程建模與開發活動彼此分離的情況。然而現存的系統通常都存放有大量的重要資料和業務邏輯，並且不能簡單地加以替代。

在企業架構方面：

將企業整體規劃的觀點加在解決方案架構之上，並未解決如何找到「易於重用且具有持久性的高品質企業抽象概念」的問題。

在物件導向分析設計方面：

應用程式開發專案，常為問題領域建立單獨的使用案例模型，在許多情況下，在企業的大方向常會變得模糊。同時使用案例模型總是無法與對等的企業流程建模保持同步。

這些都是在同人參與軟體專案的過程中，經常發生的問題。換句話說，不管是以業務為主、技術為輔，或者是以技術為主、業務為輔，在軟體的實際開發過程中，都是會有問題的。所以，關鍵並不在於業務或技術誰是老大的問題，而是充分地運用兩者，達成策略目標，如此，業務與技術都是工具，它們的地位是相同的，沒有誰輕誰重的問題，重點在於企業策略目標如何達成。

以由上而下的觀點來看，會以問題領域分解的方式來識別服務。從組織功能區域與子系統的業務領域中分解企業價值鍊，識別出企業流程、子流程與作業功能。以由下而上的觀點來看，對現有系統分析進行分析並選擇可行的方案，目的是提供較低成本辦法來實現基本服務功能以支援企業流程。最後，還有中間相遇的分析觀點，針對目標服務而建模，對未被以由上而下或由下而上的服務識別方法擷取到的其它服務，予以驗證或挖掘，目標服務關係到服務的主要目標和次要目標，例如關鍵績效指標(KPIs)以及度量標準。

每個 SOA 軟體專案，都會關係到這三種觀點，並在分析過程中，會因應不同的設計觀點與系統目標，交相運用不同的分析手法。事實上，分析並不會是一次性的過程，而是因應需要貫穿整個專業生命期，而技術與業務在分析過程中是缺一不可的，因此，同人認為技術是次要的說法，其實是太過於簡化 SOA 的問題分析的過程呀。

Powered by ScribeFire.

Please follow and like us: