面向服務(SOA)的面向業務基礎

2019-11-17 04:36:38

字體：大中小

來源：轉載

供稿：網友

　　簡介　　隨著Web服務的出現，面向服務成為最新推出的技術解決方案，其目的是實現業務活動的自動化。(如要全面地了解Microsoft連接系統策略中SOA及相關概念的信息，請參閱《面向服務及其在連接系統策略中的角色》。)面向服務體現的概念是通過長期的努力發展演變而成的，它們可對復雜的計算機系統進行模塊化處理和分布，這些計算機系統能夠反映和支持分布式業務世界的實體?！　∫勒彰嫦蚍漳壳暗亩x，這些服務通過標準的、已發布的、可發現的接口提供了可訪問網絡的功能。這些核心的特征至少保證了協議(在語法方面)的互操作性，而無須考慮平臺、提供者和位置的限制?！　∪欢?，在目前，解決技術集成問題本身并不足以證實面向服務投資的正確性。為了強化它的論據，針對面向服務對于業務靈活性的支持，正在做出各種不同的聲明，這是因為此論據存在于面向服務的環境中，在此環境中，通過公開服務、重新配置服務、重新使用服務等措施，更輕易創建解決方案。也許如此，但是根據面向服務的上述定義，許多業務在某種程度上都已經實現了面向服務，可它們仍然要努力提供業務需要或要求的IT支持。　　為了證實面向服務投資的正確性，我們需要解決以下問題，它們在新體系結構原則的每個部署項目中都會出現：　　•我們如何防止面向服務在今后將要進行的相似計劃中出現與過去相同的體系結構錯誤?　　•我們如何確保選定的實現體系結構與業務要求相關聯?　　•我們如何在不斷變化的環境中最大限度地延長期望的實現周期?　　就像我們將要看到的，這些問題的答案是相互聯系的。面向服務僅僅體現了系統的一個特定方面;它并不是系統的起始點，而且有缺陷的基礎將導致不完善的實現。此基礎是解決實現問題所缺少的一個重要環節，實現的難點在于，如何通過正式化的、可重復的、創新的方式提出上述的業務要求并將它們與面向服務的模型相關聯?！　⊥ǔ＃诿枋龌蚰M業務要求所使用的方法與它們的最終技術實現之間并沒有明確定義的關系。目前，大多數獲取和體現業務要求的工作都使用了業務流程建模方法和技術。對于任何將業務要求及策略與IT策略和實現相關聯的嘗試，正式的業務流程建模都是必不可少的一部分，但它并不能滿足需要?！　I務流程需要以實現業務目標所需的活動為核心，而無須考慮傳統的“磚瓦泥灰(實體)”筑成的邊界——你今天內部進行的工作明天也許就會外包。通過靈活的業務模型，我們的設計必須能夠支持這些協作要求，并考慮到邊界、網絡的作用、不斷變化的責任等因素，同時還要順利地穿越這些邊界，而不會受到系統、公司或其它邊界的影響。傳統的業務流程建模沒有將業務要求與技術結構和投資相結合。它并沒有邊界、部署、封裝等問題的概念?！　Q句話說，除了具有活動表現功能之外，一個較好的模型必須支持業務之間的依靠性以及對它提供支持的服務的獨立性?！　?STRONG>進入業務功能映射圖　　為了實現這些目標，我們建議將業務設想為功能網絡。功能模擬了業務功能的行為(指它的外部可以看到的行為，相對于它的行為方式和內部行為)和期望的性能標準。Pay Employees(向員工支付薪水)和Ship PRodUCt(發送產品)就是兩個功能實例。這些功能一般具有“所有者”和“客戶”，它們被要求按照一定的標準(比如每個時間段的工作單位，或某些質量度量標準)進行工作。這指的是做了“什么”(行為)以及行為的期望或約定的標準。功能的內部包含了此功能的具體信息，介紹了它是如何在指定的時間點針對人、過程步驟、技術等因素而實現的。在這種虛擬的標準下，我們僅關注外部情況，它們是如何實現的并不重要。這種功能在本質上是一個“黑盒”?！　」δ芫哂谐浞值拿枋鲂?，可以說明某個功能是如何滿足業務要求的以及與它交互需要什么，另外它們也進行了充分的概括，從而能夠提供所需的穩定性，并藉此提供穩定、持久的基礎。網絡方面則描述了各項功能在執行業務所需的工作時是如何互連的?！　∥覀円呀浿貜娬{了可觀察、可度量的外部行為以及它們與其它功能的聯系，現在我們可以馬上看到功能和面向服務之間的平行關系。在它們大多數的抽象含義中，業務功能和Web服務都是黑盒，它們的聯系非常重要，它們與內部工作相關聯，但又與其相分離。直觀上，這種平行性對二者之間的緊密結合進行了充分的預示?！　?STRONG>變動的邊界　　在了解業務功能的具體信息之前，我們需要徹底地理解通過IT滿足業務要求的問題，這一點很重要。IT是改善體系結構和重新進行項目的原因和結果。究竟，在對我們使用新技術的工作提供支持之前，業務需要獲得明確的投資回報率(ROI)和價值策略?！　τ诖蠖鄶禈I務而言，IT基礎結構都是一個復雜的互連系統，它會隨著時間的推移有機地發展，以滿足各種持續變化的需求。每項新技術都推動了體系結構的變化，只要提供足夠的資金，它們就一定能夠將現有的系統重新設計為一個有組織的、靈活的、由各種部件組成的整體，這個整體將業務需求、系統和數據流結合在了一起。然而，即使你可以對體系結構進行完整的重新設計，在共享所有數據且不存在復制的應用程序的情況下，隨著時間的推移，該基礎結構還是會逐漸變回與原來相似的組織結構。這種情況為什么會發生?它是如何發生的?這里牽涉的問題是什么?

　　連接的業務　　在全球化和競爭力的推動下，標準的線性供給鏈已發展為復雜的價值網絡，該網絡由參加公共業務的合作伙伴組成。圖1和圖2演示了從線性價值鏈到復雜的價值鏈網絡的發展過程。這些網絡正在不斷地擴展，以包含不斷增多的合作伙伴(客戶、政府、金融服務組織等等)提供的附加服務。對于系統或應用程序的投資需要考慮到這種不斷增強的互連性所帶來的需求或機遇?！　r值鏈的發展 - 業務成為連接的合作伙伴網絡　　

　　圖1. “當時”—傳統的供給鏈

　　圖2. “現在”—合作網絡　　當我們在考慮公司、公司的客戶、政府以及他們合作實現業務目標的發展過程時，形成了三個主要的模型，這些模型互為補充，以實現業務目標：
　　•傳統的價值鏈合作伙伴主要從事以下工作：獲得材料，將它們轉化為半成品或成品，將這些成品分配給客戶?！　?#8226;業務流程外包商(BPO)能夠針對材料轉化或產品分配之外的業務要求提供服務，從而擴大了價值鏈。人力資源服務(比如制作工作單)的外包商長期以來一直都可以提供服務，但是他們提供的服務正變得越來越復雜，而且更多地集中在要害業務活動方面。例如，更好的通信技術為軟件開發、求助電話等供給服務打開了低成本的海外勞動力市場。　　•另外，自助服務正逐漸成為協作過程中的一個重要組成部分。從客戶或合作伙伴要求與供給商進行更加靈活的交互，到供給商為客戶和合作伙伴提供獎勵，以便通過不同的方式進行交互，自助服務包括了交互過程的各個方面。通過提供或要求進行特定的在線活動(比如填充表格或財務報表)，即使政府也加入到了自助服務的潮流中。　　換句話說，現代的業務在多個方面跨越了傳統的公司邊界，我們的建模技術和解決方案要體現出這個特點，這樣才合乎情理。在進行計劃時，公司邊界與公司的財政年度正變得越來越相似。二者都屬于重要而相關的邊界，但是業務必須跨越這些邊界進行計劃和預算?！　?STRONG>系統的發展 - 連接的業務功能環境　　假如你對任何指定公司的系統進行檢查并觀察它們的行為，你通常會發現，這些系統或應用程序能夠支持特定的功能或用戶團體，例如，用于金融機構的財務系統，用于營銷、銷售和援助性機構的客戶關系治理(CRM)系統，等等。假如它們全部連接在了一起，那么它們之間的連接將不會非常完美。最終，客戶將不得不忍受分離的功能豎井。他們不滿足的地方在于，在新的業務開展方式的出現速度快于集成的進行速度時，現實情況很可能還是會保持這種方式。　　既然我們無法“跟上潮流”，更無法走在變化的前面，當創新以各種不同的方式繼續推動業務和客戶的發展時，應用程序就要遵循一條不同的路線。我們不能大張旗鼓地將業務功能集中到現有的解決方案中;相反，我們應該接受這樣一個事實：排除基礎體系結構的所有成果，現實和經驗告訴我們這種可能并不適合發展。由于業務行為通常本身就不穩定，再加上迅速變化的技術的影響，所以從某種程度上來說任何體系結構都將發生變化。不過，知道了這點之后，我們就可以著眼于我們的體系結構，在它的構建過程中盡可能地去適應這些變化，從而將體系結構方面的投資轉化為永久的資產。　　我們可以對它做什么?　　對于如何延長體系結構二次設計的使用周期，這些觀點都不錯，但是細心的讀者會注重到，它們其實都取決于是否能夠獲得我們的第二個問題的正確答案：實現體系結構如何與現實的業務相關聯?我們回答這個問題的準確性將決定我們實現這些觀點的效果?！　‖F有的業務改善技術都集中于流程的改善，在應對目前的業務挑戰的過程中，它們做出了巨大的進步。然而，我們第一個要關注的重點——“怎樣”完成工作是以完成“什么”為前提的。其次，解決方案的限制在于如何提高技能——而不是挑戰工作的基本前提?，F在，大多數人在嘗試解決業務問題時，都使用了這種慣例。為了對其進行改善，我們需要挑戰這些前提，并提出不同的問題。

　　業務功能 – 一個更穩定的基礎　　因此，我們發現真正的問題是：“在你為客戶構建一個解決方案時，該體系結構的哪些元素真正的具有持久性并答應你應對各種變化?”這是因為，對于體系結構的陳舊化，這個問題的答案顯然提供了最佳的投資回報率(ROI)和最好的保險?！　∥覀儼l現，穩定的元素不僅僅包括業務的實際行為(例如創建采購訂單、生成發票、發送產品等等)。我們將這些業務活動稱為業務功能，它們比較穩定，但是業務如何通過人、過程和技術來執行這些活動，以及這些活動如何組合成流程，還遠不夠穩定。因此，現在我們需要調查清楚業務能做什么以及它的功能是什么?！　≡谖覀兝^續之前，讓我們介紹幾個與我們的討論有關的定義：　　•業務功能是一種非凡的能力或性能，業務可以掌控或交換這種功能，以達到特定的目的或結果。功能描述了業務為客戶創造價值的行為(結果和服務級別);例如，向員工支付薪水或發送產品。業務功能對人、流程/過程、技術和信息進行了抽象化，并將它們封裝到了基本的構造塊中，這些構造塊可促進性能的提高，為重新設計分析提供便利。　　

　　圖3. 功能是“黑盒”，其輸入和輸出是根據明確的服務級別要求而定義的　　•功能連接器表示業務功能之間存在的鏈接。連接不僅僅是簡單的消息;它們包含了豐富的語義信息。它們是功能模型中存在的各種連接器，此功能模型主要負責信息交換(輸入/輸出、支持信息)以及政策的控制或制訂(規章制度的影響)?！　?#8226;業務流程描述了業務如何執行或實現指定的功能，或功能如何進行連接，以提供預期的結果。Hammer和Champy是上世紀90年代的業務流程運動的創始人，并因此而享有盛譽，他們將業務流程精心定義為：提升在過程之上的端到端的工作。流程跨越了組織部門和功能?！　?#8226;業務功能映射圖是功能及其連接的定義，也是它們清楚的結構略圖，這些功能和連接能夠促進一個典型公司的各項活動。業務功能是業務體系結構的構造塊，因此將功能視為體系結構藍圖是一個很好的類比，同時流程在任何指定的時間都是這種體系結構的實現。一旦建立了這種更客觀、更穩定的業務觀點，公司就可以更深入地了解功能之間的依靠性，并更好地理解業務：在一系列業務之內，跨越業務單位，超越時間?！　?STRONG>功能 – 最佳的問題解決層　　我們建議將業務建模為一種結構化(與物理集成相對)的功能網絡。這主要著眼于“豐富的互連性”，通過它，其它方面(比如應用技術的方式)可以從開始就進行分層，而不是作為昂貴、麻煩的補充措施而添加。就像你能夠看到的，這緊密結合了類似黑盒的面向服務模型：業務功能屬于結構元素(黑盒)，它們提供了一個穩定的基礎，將面向服務項目與它們的業務驅動程序結合在了一起。
　　業務功能映射圖和面向服務提供了一套全新的免費工具，它們將業務的概念擴展到了公司的物理邊界之外，從而將整個價值鏈或業務功能生態系統包含到了此映射圖中。業務模型的這種抽象性使治理人員可以在關注具體怎樣完成工作之前，調查什么在工作、它們為什么會以某種特定的方式工作?！　」δ苤饕P注“什么”，它產生了更穩定、更客觀的焦點區域模型。如上文所述，簡單的業務功能實例包括“發送產品”和“向員工支付薪水”。無論此功能的業務實現屬性(“怎樣”)是什么，無論它是內包還是外包，無論它是手動還是自動，“向員工支付薪水”的基礎功能都是相同的?！　∫允称冯s貨店的結帳系統為例：出納員確定一個新客戶，在傳送帶上掃描此客戶購買的產品，最后客戶通過某種方式支付顯示的付款總額。上述的所有步驟都是食品雜貨店的必備功能，其目的是為客戶結帳并收取貨款。在美國，食品雜貨店正開始使用自助結帳系統，在世界其它地方，這種情況也越來越普遍。乍一看，自助結帳似乎表現出與 “操作式”(由出納員執行)結帳明顯不同的特點，可將它視作一個新的功能集。但事實上，客戶仍可以執行與上述完全相同的步驟——確定一個新客戶/購買需求，掃描產品，最后付款。不過，自助結帳需要一個附加的功能，這也是它的不同之處：為了避免不老實的客戶濫用此系統，自助結帳需要一種真實性檢查功能。(將掃描過的產品放在秤盤上，比較已掃描產品的重量和稱重系統獲得的產品重量，即可完成檢查。)因此，盡管功能集的差異僅此一項——驗證已售出的產品，為客戶結帳的流程仍然具有很大的區別。在流程或業務實現過程發生改變時，業務體系結構構建的這些功能仍然能夠保持穩定。

　　功能公開了接口　　功能最重要的方面之一是它們如何聯系其它功能;在生態系統的環境下考慮功能其實就是考慮它們的連接。因此，盡早檢測出它們與其它功能的連接，或者從根本上定義互聯的生態系統，也是實現以下目標的要害步驟：理解哪些邊界是可以跨越的，而哪些不可以;最大限度地強化所有重新設計的體系結構成果。事實上，發現連接與定義功能可能一樣有價值，這是因為，在功能保持基本不變的黑盒狀態時，你需要操作和治理這些連接。連接器可能與將一個功能的輸出轉換到另一個功能的輸入的方法一樣簡單，例如，某項活動通過電話呼叫獲得客戶請求(“獲得訂單”功能)，并將此客戶請求發送到另外一個部門，以處理訂單(“處理訂單”功能)。另外，可能有一個連接器來控制另一個功能，比如與“處理訂單”功能(此功能需要對新的客戶事件進行通知，這樣待辦訂單才能進行合并)的連接?！　≡跇I務級別，服務級別期望(SLE)對連接具有強烈的影響。因此，功能模型也是以特定的服務級別分析和以下概念為基礎的：假如改變工作人員可以實現服務級別的變化(即，評估不同的來源選擇，在它們之間進行外包)，那么就可以跨越公司內的所有功能在平等的基礎上做出決策。這樣業務就可以交換服務，而無需糾纏于執行流程的細節。例如，可以利用ADP公司提供“向員工支付薪水”的功能，但是卻無需了解ADP處理工資單的所有具體信息——是達到還是超越了已定義的服務級別，這是唯一需要關心的問題。　　只要知道功能的服務級別差異，治理人員就可以基于提高業務績效所需的功能配置做出決策。這樣，可互換性就成為了一種可比較的功能。通過了解封裝業務功能的規則(以一種可信的方式調用和完成服務的規則)，你就可以有效得多地完成功能的技術集成?！　?STRONG>簡捷的說明　　只要了解他們應該提供的功能和他們應該達到的服務級別，你就可以治理你與能源或電話提供商的關系。你只需要關心他們做什么，而無需關心他們怎么完成它。他們提供了有限的功能，并立約承諾達到一定的務，你可以將業務轉移到能夠更穩定地滿足你的服務級別要求和實際的供給條件的其它地方。　　你并不了解向你的移動電話傳遞撥號音的過程的細服務級別。對你來說，運營商是可互換的，這完全以他們提供的服務級別為基礎。假如他們不能完成任節，但是你仍然可以非常有效地治理關系和性能目標。這對功能同樣適用，功能代表了一種抽象級別，你可以通過它們交換服務，交換和治理性能規則。　　功能模型概覽　　業務功能模型是業務功能的嵌套層次結構。它公開了跨越相關生態系統的所有業務功能。由于業務流程跨越了整個價值鏈，業務映射圖很難覆蓋與實體公司映射圖相同的信息。例如，UPS和ADP都是與其它公司合作構建整體“業務”的公司?！　I務功能模型是一種分類圖示，它描述了業務使用的功能網絡。　　

　　圖4. 業務功能模型分級　　第1級基礎功能　　基礎功能服務于整個業務生態系統。它們分兩類表示：操作功能(在公司的物理業務邊界之內的東西)和環境功能(與業務互相作用的所有其他人員和公司，他們位于業務的物理邊界之外)?！　?IMG height=399 alt=. src="http://www.knowsky.com/UploadFiles/20080323/20083231622160977805.gif" width=500>　　圖5. 第1級基礎功能模型：操作功能和環境功能　　操作功能　　無論每個指定的功能是由哪個提供者提供的，這些功能都需要提供確定為業務目標的價值。操作功能屬于業務擁有或控制的功能，它們包含了以下的業務活動：　　•開發產品和服務?！　?#8226;為這些產品或服務產生需求。　　•生產或提供產品和服務?！　?#8226;與合作伙伴進行協作和通信?！　?#8226;計劃和治理業務。　　這些操作功能可以接受特定行業和/或業務的名稱(例如，“開發產品/服務”也可以稱作“研究和設計”)，但是基本的設置幾乎在每個業務中都是一致的。　　環境功能　　環境功能定位于業務基本操作之外的功能，這些基本操作或者影響了價值的傳遞(例如，客戶的期望、政府的合規性要求或目前的供給商或新興的供給商的競爭力)，或者提供了利用生態系統(包括客戶)的機會，以便實現價值傳遞/差異化。它們包括：
　　•客戶　　•面對客戶的渠道　　•物流提供商　　•基礎結構和合規性　　•財務提供商　　•供給商　　•政府和其它監管機構　　請注重，該業務模型包括了整個價值鏈，因此它能夠對所有的虛擬業務進行建模?！　?STRONG>第2級功能組　　功能組是功能模型中的下一級。舉例來說，在核心功能“1. 開發產品/服務”內，通常會有一個稱作“1.1 規劃產品/服務”的功能組。負責規劃產品的“產品工程”組可以進一步包含第3-n級的各種功能，它們描述了特定的功能及其屬性?！　」δ芙M通常是一種重要的分析初始級別，這是因為它位于功能組級別，在此，服務級別、障礙和約束、組織所有權/責任都可以首先進行抽象化，并獲得可操作性?！　?STRONG>第3級業務功能　　功能組分解為業務功能。業務功能是業務功能映射圖的構造塊。業務功能可以分解為更細粒度的業務功能。在業務功能級別，可以捕捉到具體的屬性。在分析中，你可以將一些業務功能分解到非常細微的級別(第4級以上)，并在第3級聚合其它功能。無需將所有的功能都分解到相同的級別。　　結論　　開始時，我們問了以下問題：　　•我們如何防止面向服務的體系結構在今后有望實施的相似計劃中出現與過去相同的體系結構問題?　　•我們如何確保選定的實現體系結構與實際或期望的業務狀態相關聯?　　•我們如何在不斷變化的環境中延長期望的實現周期?　　結合Web服務的面向服務只是特定模型的實現，這是要把握的要害點。它是決定這些問題答案的模型的質量和基礎。業務功能為你提供了一個參考框架，這樣你就可以針對業務中的各種不同的互連觀點提出和回答這些問題。它發現了穩定的業務元素，可圍繞你的體系結構進行建模，同時，它也提供了一個緊密結合面向服務的要害層。另外，面向服務提供了一種既分隔又連接的結構，以實現這些功能，這樣IT就能夠滿足實際的業務要求，并提供真正靈活的業務。

上一篇：軟件架構淺談：問題域及其解決方法

下一篇：軟件項目可行性分析和需求分析(1)