在SOA中應用業務術語表模式的價值

在SOA或數據集成項目中,關鍵業務術語可能會造成混淆,對其含義進行反複的爭論會導致延遲、推遲修改甚至産生錯誤。本文是 “SOA 設計的信息透視圖” 系列的第二篇文章。本文介紹業務術語表的概念,幫助您消除術語方面的誤解。了解在SOA中應用業務術語表的價值,學習如何定義和使用它以使同事之間的交流更加清晰。

簡介

在開發面向服務體系結構(SOA)或數據集成項目期間,常常缺少一個定義與過程、服務和數據相關的術語的統一業務術語表。術語含糊不清會使許多數據集成活動更加複雜,爲業務術語提供統一的定義對于解決這個問題非常重要。如果 “客戶”、“成員” 等術語表達的含義不一致,就無法正確地實現與這些概念相關的服務,甚至無法確保所有相關人員對組成這些概念的數據有一致的理解。對于業務分析師和技術人員來說,對過程、服務和數據(包括語義、結構和數據結構的格式)使用的術語形成一致的理解非常重要。

本文討論 SOA 環境中對業務術語表的需求,講解如何定義和使用業務術語表。

動機和問題

糟糕的是,業務人員和 IT 專家常常對同一術語有不同的解釋,甚至在不同的業務線之間也有這種現象。在許多情況下,企業中常常有相似或相同數據元素的多個拷貝,這些拷貝的上下文只在其數據存儲庫中有效。當把這些元素向外部客戶公開時,就會丟失它們的上下文;更糟糕的是,它們甚至可能導致誤解或失效。業務術語表的根本價值就在于此。它統一了數據元素的定義,讓數據的上下文對于數據的所有消費者都有意義。

業務術語表不但應該包含數據元素的公認定義,還應該包含與這個元素相關聯的任何變體或依賴性。這會幫助驅動概念和邏輯數據模型的定義。最終,這使 SOA 解決方案中的組件和參與者能夠獲得一致的業務信息定義。

在某些場景中,一個服務需要從多個信息源獲得信息,這些信息源可能包含同名的重複數據元素,數據元素還可能有隱含的定義。這些數據元素的定義或上下文可能差異很大,它們的含義只在自己的數據存儲中有意義,很可能只有被相關的程序檢索時才有意義。對于這些情況,業務術語表爲企業中每個實體提供一個一致的統一的業務定義和依賴性,從而幫助識別和解決這種沖突。當來自不同部門的用戶談到 “客戶” 或 “收入” 時,每個人都知道這些術語指的究竟是什麽。

不指定業務術語表可能導致的影響包括:

*無法掌握業務的基本信息需求

*由于沒有充分理解信息需求,項目的成本增加

*需要花時間對不清晰或被誤解的需求進行調整

在SOA環境中,提供這些統一的業務定義對于順暢的討論非常重要,這些討論不僅針對數據元素的語義,還針對可以跨多個業務領域重用的數據集。例如,多個業務線很容易發現它們都需要通過一個服務訪問客戶的詳細信息。但是,在不同的業務線之間,很難就與客戶的業務概念相關的數據元素取得一致。在完成這個任務之後,還有一個難題:確定可重用的客戶數據集合由哪些數據元素組成,需要通過後續的服務調用獲得哪些輔助元素。如果沒有業務術語表,討論就會陷入到對命名和業務術語的爭論中。更糟的是,這些討論可能根本無法進行下去,因爲業務術語缺少精確性就意味著存在分歧。

對于企業主數據管理(MDM),也有相似的問題。爲 MDM 存儲庫提供信息的多個源系統與多個業務線相似,它們對主數據的語義、結構和集合有不同的解釋。如果沒有清晰地理解這些數據集的語義差異,就很難把它們映射到單一的主數據存儲庫。同樣,業務術語表可以減少這個上下文中的歧義,這使單一業務定義集可以跨多個源系統。

在數據聯邦和數據整合中也有相似的問題。在這些情況下,需求是相同的:必須理解業務術語中數據的含義,從而確保産生的解決方案能夠滿足項目原來的業務目標。

案例研究

衛生保健行業的一家 IBM 客戶遇到了一個很常見的問題:在每次會議上,都要爭論誰的數字或報告是正確的。問題並不是這家公司需要一個數據倉庫。實際上,他們有若幹個數據倉庫。但是,這些信息源在生成報告時導致了混亂。例如,執行官無法讓不同的業務部門(比如醫療管理部門和銷售部門)對健康維護組織(HMO)服務的成員數量取得一致。

這家公司請 IBM 幫助他們分析這個問題的根源並提出糾正措施。公司使用數據倉庫集中存儲來自業務系統的數據,但是沒有爲 “成員” 提供統一的業務定義。對于醫療管理部門,成員是潛在的患者、訂戶和他們撫養的所有家屬。對于銷售部門,成員是訂戶和他們撫養的所有家屬(如果訂戶需要續簽合同的話)。已故的訂戶撫養的家庭成員會從統計中排除。這意味著,雖然醫療管理部門和銷售部門的成員統計數量對于一個計劃(比如本地 HMO)是相同的,但是對于另一個計劃,數量就不一樣了。這些差異隨年份變化,從來都不相同。這給執行官帶來很大困擾,因爲他們無法相信報告的可靠性。

統一的業務術語表可以有效地解決這個問題,因爲它爲術語確定了單一的公認的業務含義。這樣,所有報告就可以使用公認的術語,跨各個報告上下文保持一致。

業務術語表的概念

業務術語表有時候稱爲數據詞典,它們定義與業務相關的術語和數據。根據業務的範圍和類型不同,業務術語表的範圍也不一樣。它們的範圍可以是一個小範圍(産品或業務線)、一個信息領域或整個企業。最理想的情況是在整個企業的上下文中定義業務術語,這會促使業務術語在所有項目之間保持一致。

但是,不同的部門或業務線常常對同一術語有不同的語義上下文。例如,對于配送部門,“地址” 元素可能是指送貨地址。但是,對于財務部門,它可能是指郵寄帳單的地址。對于銷售和市場推廣部門,它可能是指聯系地址。這是一個非常簡單的示例。使用名稱前綴或者使用三個不同的地址字段,很容易解決這個問題。但是,需要有辦法記錄和識別要處理的地址的類型以及它們各自的含義。

業務術語表定義業務的語言和項目的語言。因此,業務術語表中定義的術語必須完全符合要求,並提供特定的描述性定義。應該盡可能提供應用于整個企業範圍的定義。如果不同的部門以不同方式使用同一術語,那麽應該捕捉這些定義並與適當的上下文(部門)相關聯。

在構建企業範圍的業務術語表時,可以同時包含術語的語義定義和表示定義。語義定義(semantic definITion)主要爲每個術語提供精確的含義。表示定義(Representational definition)主要定義在 IT 系統中如何表示每個術語,比如整數、字符串或日期格式(參考數據類型)。業務術語表是爲組織創建精確的語義和表示定義這一過程中的一個步驟。

在任何 SOA 或數據集成項目中,業務術語表都要捕捉在任何探索活動(比如過程分解、重用分析或對現有資産的分析)中出現的術語。術語可以與過程活動和業務目標相關,也可以只由確定的單個源的定義組成。

由此産生的術語表模型映射到在各種結構化分析期間出現的工件 —— 業務模型、數據模型、需求模型等等。如果組織中還沒有術語表,就要考慮構建一個術語表。實際上,無論企業是否有術語表,或者是否有多個分散的術語表,模式是非常相似的。

由誰創建業務術語表?

現在討論哪些人應該參與創建業務術語表。在一些組織中有業務分析師,他們了解數據的業務定義。在其他組織中,有一些非正式的專家了解數據的信息含義。在許多情況下,公司的大多數數據都缺少正式的定義和相關的依賴性。在越來越多的公司中設立了數據管理員(data steward)這種新職位。他們通常負責創建和維護業務術語表。

在各個組織中,業務術語表的所有者各不相同,甚至在同一組織的不同領域中也不一樣。在理想情況下,應該在企業數據/IT 管理結構中定義信息領域及其所有關系,而且這些信息領域和所有權層次結構可以應用于業務術語表。如果還沒有這樣的管理結構,那麽在 SOA 項目期間,很可能由數據架構師擔任管理的角色,負責確定長期的所有權策略。強烈建議項目包含或使用管理流程。如果公司中還沒有這種流程,那麽項目應該實現這種管理流程。

通常,每個信息領域有一位業務分析師或數據管理員,甚至可以采用更細的粒度,比如解決方案涉及的每個操作性數據源、領域或實體。在某些情況下可以由同一個人負責,但是在其他情況下可能涉及來自 LOB 或擁有數據的部門的人員。一個數據源可以有多位數據管理員,每個管理員都精通某個特定領域。甚至一個術語也涉及多位數據管理員。以 “客戶類型” 這個術語爲例。市場推廣或財務領域都有客戶,與客戶相關的數據集可能由一位來自部門或功能領域的數據管理員負責。在上面的示例中,“地址” 可能需要添加一個限定符或者擴展數據結構,從而識別 “地址” 的類別。數據架構師可以幫助設計符合邏輯的識別 “地址” 類型的方法。這個示例說明在建立這些定義時需要多種技能。如果只讓業務分析師負責,那麽産生的定義可能無法滿足後續階段中各種活動的需要。

對于任何數據源或數據源的任何部分,必須指定一位適當的主題專家(subject matter expert,SME)擔任數據管理員。這個人應該熟悉項目可能涉及的所有業務術語的業務用法。根據數據量和專家知識水平的不同,可以由一個人負責,也可以指定多個人。他們還應該了解(或能夠學習)所有這些實體之間的依賴性和關系。

讓數據架構師參與這個過程常常非常有幫助,因爲他們通常了解數據源的物理約束和結構特性。他們還可以幫助判斷數據之間的關系和依賴性。

指定了 SME、業務分析師和數據管理員之後,這些人必須與業務專家充分交流,詢問他們對于術語的業務定義的意見,讓所有相關人員都認可術語的最終定義。這個任務並不輕松,常常要花費大量時間和精力。項目不但需要獲得核心信息需求的定義,而且要在整個企業上下文中定義這些術語。正如前面提到的,業務術語表應該在整個企業範圍內就每個數據元素或術語的精確定義取得一致。這樣就可以建立一種統一的語言,數據的所有消費者都使用這種語言進行交流。實現這一目標的方法因公司和項目而異。

什麽時候應該創建業務術語表?

您必須記住,必須及早創建業務術語表,而且它不只是在早期探索階段進行的一項活動。可以而且應該盡早考慮業務術語表,甚至在需求收集階段和項目定義階段就開始這項活動。業務術語表並不限于現有的數據源或數據庫;它還包含用來描述 SOA 中業務過程和服務的所有業務術語的定義。越早開發術語表,就能夠越快地爲整個項目或企業提供一致的術語定義。

無論項目采用什麽開發方法,都應該在初始探索階段開始創建業務術語表。隨著項目的發展,業務術語表應該不斷更新和優化。

如何創建業務術語表?

在創建業務術語表時,應該考慮采用以下步驟:

1.收集信息源

術語表中的業務術語可能來自多種來源,例如行業標准或 IBM 的 Industry Models。其他常見來源包括需求文檔、現有的數據詞典和遺留解決方案。

現有的系統或行業標准可能已經定義了業務術語表。如果已經有術語表,那麽可以審查它並把它融入統一業務術語表中。

2.提取業務術語

業務術語表最有價值的方面也是最難實現的方面 —— 業務概念的公認的統一定義。可以通過與主題問題專家進行討論、舉行會議或進行問卷調查來實現這個目標。一個術語使用的範圍越廣,其含義要取得一致往往就越困難。如果一個術語只在較窄的業務範圍內使用,那麽 SME 或業務分析師可能已經掌握了公認的定義。如果整個企業都使用一個術語,那麽要獲得一致的定義就會困難得多;可能需要先收集各種定義,然後與各個 SME 會談,嘗試形成統一的理解和定義。在這種情況下,最初的一個術語常常被分解爲多個術語,從而滿足所有上下文的需要。但在術語表中這不一定是必須的。不同的人員常常用同一術語表示非常不同的東西 —— 這種情況是由術語模糊性引起的,而後者是因爲缺少清晰的業務定義。調查表明,使用同一術語描述多種不同需求的現象很普遍,以術語表形式提供詳細的業務定義有助于區分這些需求。業務術語表比較簡單的方面是術語的物理方面,也就是數據類型定義、約束等等。這方面的信息經常被忽略,但是很容易獲得。值得注意的是,根據術語的不同,物理結構可能不是必需收集的信息,可以以後在開發數據模型時再確定。即使這些信息是在以後添加的,在業務術語表中維護這些信息仍然是有意義的。可以手工添加這些信息,也可以使用市場上的自動化信息分析工具。這些工具有助于了解術語的物理性質,對于評估現有信息的質量非常有幫助。

3.構建術語表

維持術語表的完整性和規範化是很重要的。允許術語表有組織地增長可能會導致業務術語出現大量重疊,這會加劇術語方面的混亂,而消除混亂正是術語表的目標。在業務術語表中添加術語時,應該檢查術語,判斷它們與現有術語的重疊之處,並通過適當的調整避免術語表中出現重複或其他沖突。但是,可以作爲公認術語的別名保留這些沖突。在這樣做時,應該注明別名的上下文,也就是記錄允許使用它的範圍。這樣,即使某些用戶堅持采用他們的局部用法,也不會造成混亂。

4.檢驗

有許多現象可以表明業務術語表已經接近完整了。例如,術語開始收斂了 —— 跨新領域識別出的新術語越來越少了。第二個迹象是,所有關鍵的參與人員已經檢驗了用來構建業務術語定義的數據源的完整性,而且他們的所有術語都已經按照業務概念成功地分類了。業務定義的質量也是一個重要的指標。業務相關人員應該能夠確認術語對于業務是有意義的,分類是適當的,並具有適當的上下文。

良好的業務術語表可以爲規範化數據建模活動提供有價值的輸入,提供在這些模型中創建實體和關系所需的核心定義。盡管業務術語表是規範化數據建模活動的輸入,但是一定要認識到,業務術語表並不能替代規範化數據模型。這兩者在詳細程度、規範化程度和結構方面有顯著差異。業務術語表的作用是提供清晰的業務術語。邏輯數據模型在此基礎上更進一步,分析數據的詳細結構,包括關系、子類型、屬性和包含關系。

更新業務術語表

業務術語表並不是編寫好之後就不再修改的靜態文檔。相反,業務術語表是動態的需要反複修改的工件。無論是文檔形式的術語表,還是在 WebSphere Business Glossary 等工具中維護的術語表,都是不斷修訂、逐漸成熟的工件。

從最初的探索階段直到以後的階段,術語表越來越成熟,用戶也越來越多地引用其中的業務術語。無論這個工件是采用文檔形式,還是在一個工具中維護,它們的基本物理結構是不變的。

示例

下面的示例取自一個以開戶(account-opening)過程爲中心的業務術語表。根據現有定義的成熟程度不同(例如,在識別階段的早期,定義可能還不成熟),術語可能有完整的定義和值,也可能不完整。通過各個開發階段,術語表會隨著項目一起成熟。隨著對業務術語了解的深入,應該不斷更新業務術語表中的信息。

結束語

業務術語表是一個權威性的工件,它控制並定義常用的詞彙、術語的語義和相關的分類法。對于數據集成和 SOA 來說,它是一個重要的起點。業務術語表可以確保組織中不同角色的業務人員和 IT 人員對術語的含義有相同的理解,並在 SOA 上下文中用術語組合成可重用的信息結構。如果弄不清楚提供什麽信息以及這些信息的含義,就不可能提供可信的信息。

在SOA中應用業務術語表模式的價值
  在SOA或數據集成項目中,關鍵業務術語可能會造成混淆,對其含義進行反複的爭論會導致延遲、推遲修改甚至産生錯誤。本文是 “SOA 設計的信息透視圖” 系列的第二篇文章。本文介紹業務術語表的概念,幫助您消除術語...查看完整版>>在SOA中應用業務術語表模式的價值
 
SOA在金融行業應用 業務流程爲切入點
  1.引子  先來講兩件最近發生的事情。  最近有幾次高峰時間上高架被開罰單的記錄,每次去銀行繳費感覺非常麻煩。聽說工行的卡支持電話或網上繳罰單功能,就回家把很久不用的工行卡翻出來,工行的網上銀行做的...查看完整版>>SOA在金融行業應用 業務流程爲切入點
 
紅帽攜手惠普在SOA領域爲客戶增價值
  北卡羅來納州RALEIGH市 - 2009年6月17日 - 全球開源解決方案的領導者紅帽公司(紐約證交所上市代碼:RHT)今天宣布了在面向服務的架構(SOA)管理方面與惠普合作開發的優化解決方案。JBoss企業級SOA平台已經經過...查看完整版>>紅帽攜手惠普在SOA領域爲客戶增價值
 
SOA標准發展混亂 國內業務缺少經驗
  SOA標准發展混亂 國內業務缺少經驗   近年來,SOA已經成爲國際及我國信息技術領域的重大熱點之一。從2005年至今,SOA逐漸成爲影響中國IT系統構建的主導思想。從2006年開始,SOA的建設方法已在我國部分行業信息...查看完整版>>SOA標准發展混亂 國內業務缺少經驗
 
面向服務(SOA)的面向業務基礎
面向服務(SOA)的面向業務基礎
  簡介  隨著Web服務的出現,面向服務成爲最新推出的技術解決方案,其目的是實現業務活動的自動化。(如要全面地了解Microsoft連接系統策略中SOA及相關概念的信息,請參閱《面向服務及其在連接系統策略中的角色》...查看完整版>>面向服務(SOA)的面向業務基礎
 
業務和IT在SOA中的緊密協作
“業務和IT應該合作,尤其是在面向服務的環境中,在這個環境中協作需要超過需求文檔”——麻省劍橋Forrester Research 公司,副總裁Randy Heffner這樣說道。 業務服務在面向服務的架構(SOA)中是根據對業務流程的理解...查看完整版>>業務和IT在SOA中的緊密協作
 
CIO們的記憶: 宣揚SOA的商業價值
位于Boston的Aberdeen集團副總裁兼服務主管William A. Mougayar認爲:當談到面向服務的架構時,CIO們需要不斷關注業務並且讓業務符合自己的想法。 他說,這樣做的一種方式就是讓IT組織成爲面向服務的。根據Mougayar最...查看完整版>>CIO們的記憶: 宣揚SOA的商業價值
 
分析師:簡述五種新興SOA設計模式
  衆所周知,設計模式描述的就是針對軟件設計中的常見問題做出的可重複使用的解決方案。而了解及使用這些模式則是SOA取得成功的根本。下面是Gartner公司的分析師們通過分析得出的五種新興SOA設計模式:  1. 多通...查看完整版>>分析師:簡述五種新興SOA設計模式
 
Gartner公布五種新興SOA設計模式_軟件資訊_企業軟件頻道
  衆所周知,設計模式描述的就是針對軟件設計中的常見問題做出的可重複使用的解決方案。而了解及使用這些模式則是SOA取得成功的根本。下面是Gartner公司的分析師們通過分析得出的五種新興SOA設計模式:  1. 多通...查看完整版>>Gartner公布五種新興SOA設計模式_軟件資訊_企業軟件頻道
 
 
回到王朝網路移動版首頁