規則架構師的角色

 

文檔選項 列印本頁 英文原文 層級： 初級 Arun Chhatpar, 軟體架構師, OmniViz 2008 年 7 月 31 日 商務規則架構師在設計組織良好、直觀的商務規則模型方面扮演著重要角色，以協助技術和商務參與者理解商務規則模型。本文討論該角色的重要性，並使用商務規則開發生命週期來描述規則架構師在建立可靠、可擴充的商務規則實現方面的職責。 商務規則架構師的職責？ 正如在前一篇文章“商務規則入門簡介”（請參見參考資料）中所描述的，商務規則是一種實現和強制業務策略的方法。商務規則管理 (BRM) 系統則基於商務規則來自動化和管理決策。隨著 BRM 系統的日益普及，更多的企業開始大規模實現這些系統，使它們變得越來越複雜。因此前期設計非常重要。商務規則架構師是負責正確地設計這些 BRM 系統的人員。 商務規則架構師與業務所有者和 IT 人員協作以構建組織商務規則策略的整體視圖。規則架構師負責將組織的業務需求轉換為可靠而穩定的軟體系統。規則架構師承擔了通過設計和構建簡單化、可重用的組件來降低建立和維護商務規則的總體成本的任務。 回頁首 高效率的規則架構師的素質 作為規則架構師意味著您不僅需要擁有技術技能，而且需要有效溝通技能。我們來看看規則架構師需要具備的一些最重要的素質： 商務規則方面的專業知識——規則架構師必須擁有設計和開發商務規則和系統方面的經驗，以及使用各種 BRM 工具和系統的經驗。 理解業務的能力——理解商務規則背後的驅動力對於能夠設計強健的系統非常重要。 超越現有系統的遠景——就像企業架構師那樣，規則架構師不僅需要考慮正在設計中的系統，而且需要瞭解它如何適應企業範圍的遠景和組織的整體體繫結構。 強大的溝通能力——與業務和 IT 人員有效溝通的能力對於業務架構師的成功至關重要。 精通技術——規則架構師必須具備開發軟體的實際經驗，才能夠對構建優秀的系統設計的挑戰應付自如。在理想情況下，規則架構師將在 IT 組織中擔任不同的關鍵職位，這會有助於他們瞭解系統瓶頸和限制，並協助他們設計和規劃正確的解決方案。 既然我們已經瞭解了優秀的規則架構師需要具備的素質，現在讓我們看一下規則架構師在商務規則開發生命週期中的各個步驟的職責。 回頁首 商務規則開發生命週期 商務規則系統架構師的目標是將業務考慮從邏輯代碼中分離出來，然後將它們組合到容易管理的系統中，以允許業務使用者使用類似於英語的文法來建立和更新規則。與任何軟體系統開發一樣，商務規則系統具有已定義的生命週期。規則開發中的三個主要步驟是設計、開發和維護。讓我們來瞭解各個步驟，以及規則架構師在每個步驟中扮演的角色。 規則設計 規則架構師在商務規則開發生命週期中的第一步是設計。在設計步驟中涉及的子任務包括： 確定商務規則——規則架構師需要瞭解必須將哪些規則加入 BRM 系統。這是一個漫長的迭代過程，並涉及大量與業務使用者之間的訪談、會議和討論。 對規則分類——規則架構師需要對已劃分到相應類別的規則進行分類。一些樣本類別包括前端驗證規則、後端工作流程規則、淘汰規則和分層放置規則等。 定義模板——規則架構師使用 BRM 工具來定義構件和模板。在這一子步驟中，將商務邏輯的整體結構定義為模板，並使指定模板的一些特定部分可以編輯。然後業務使用者使用 RMA（說明見下文）並根據其業務需求編輯這些值。可以使用適合業務環境的任何控制項和標籤在網頁上顯示可編輯的一組值。在定義了模板後，這些模板將作為業務使用者使用類似於英語的語言在 BRM 系統中編寫規則的指導原則和出發點。幾乎所有業界領先的 BRM 工具都提供的最常用構件是規則和規則集模板、決策表和決策樹。在決策表中，行和列表示不同的條件，而結果操作由它們的交點來定義。決策樹以圖形方式描述導致某項操作的相關條件鏈。 建立使用者介面，將商務規則放入 BRM 系統——規則架構師必須為業務使用者提供用於建立規則的介面，稱為規則維護應用程式 (RMA)， 1 所示。 建立規則——規則架構師然後必須使用 RMA 建立規則。 圖 1 顯示了設計規則的過程。 圖 1. 反白商務規則設計過程的完整 BRM 系統體繫結構 1 所示，IT 人員使用 BRM 整合式開發環境 (IDE) 工具來建立模板，業務使用者則使用這些模板從 RMA 編寫規則。規則架構師在此過程中扮演著重要角色。 在設計過程開始時，規則架構師協助正確地確定規則。正確地確定規則有助於使不必要的規則遠離規則存放庫。規則架構師必須確保通過與業務使用者進行大量訪談並使用一些技術（如需求收集）來捕獲所有規則。架構師還可以使用像 IBM Rational RequisitePro 這樣的工具使該過程變得簡單（請參見“Rational RequisitePro 讓您絕處逢生”側欄）。 Rational RequisitePro 讓您絕處逢生 IBM Rational 軟體產品組合包括名為 Rational RequisitePro 的整合工具，用於管理需求。該軟體的主要功能之一是管理項目相關文檔。您可以管理由不同業務使用者建立的文檔，並組合它們以建立一個大型規則堆棧。您可以下載試用版並通過 IBM developerWorks（請參見參考資料）瞭解有關 Rational RequisitePro 的更多資訊。 在確認後，規則架構師必須確保將規則劃分到適當的類別。正確地對規則進行分類非常重要，因為分類會影響規則生命週期的所有三個步驟（設計、部署和維護）。 規則架構師然後必須使用正確的構件來定義模板。BRM 系統中的構件是什嗎？它們是一些原型或構建塊，規則設計者可用來以邏輯形式建立規則集。BRM 工具中的構件樣本包括規則集、決策表、決策樹和計分卡。您應該使用規則集或決策樹來定義一組規則嗎？規則架構師必須決定使用哪些規則，以定義一組規則並確保使用正確的構件來定義它們。 規則架構師在設計時還必須考慮代碼重用性。這裡體現了架構師所掌握的技術知識的重要性。您設計的規則集必須同時具有可擴充性和可重用性。 當業務使用者在 RMA 中已建立其規則後，下一個步驟是將它們與您的現有應用程式一起部署，下面將對此進行說明。 規則部署 如前所述，規則架構師的視野必須能夠超越當前系統。這不僅與哪些規則進入系統有關。規則架構師還必須考慮正在開發的系統如何與現有應用程式建立串連。大多數商務規則實現或者替換現有遺留應用程式，或者作為大型系統體繫結構的子組件。由此類混合系統引入的複雜性使商務規則系統的整合變得更有難度。描述遺留系統與新應用程式的完整整合過程不在本文範圍之內，但讓我們進一步瞭解部署過程中涉及的一些步驟。 規則架構師必須選擇目標實現的類型。使用目前的 BRM 工具可以為規則引擎使用不同的部署選項。其中的一些選項包括： 內聯 Java 應用程式——將規則引擎作為內聯 Java 應用程式運行。 Web 服務部署——可以將規則引擎部署為 Web 服務，可以通過標準簡易物件存取通訊協定 (SOAP) (SOAP) 介面從其他應用程式進行訪問。 應用程式伺服器中的 Enterprise JavaBeans (EJB)——將規則引擎整合在應用程式伺服器內作為 EJB 運行。 規則架構師必須定義介面來與現有的外部和遺留應用程式互動。此步驟包括將新商務規則應用程式與已經運行了一段時間的其他應用程式和公司資訊系統（通常稱為企業的“遺留”系統）整合。企業無法承受這些遺留系統發生任何中斷。因此規則架構師必須確保新系統與現有應用程式無縫地協作。這可能涉及讓您的新系統向其他應用程式公開，或實現其他系統介面來與之互動。 規則架構師現在必須部署規則引擎。 圖 2 說明了 BRM 系統的規則部署過程。 圖 2. 反白商務規則部署和與外部及遺留應用程式整合的完整 BRM 系統體繫結構 圖 2 顯示的系統相當簡單，因此不可能是現實中的案例。實際上，規則架構師在建立規則引擎和外部及遺留應用程式之間的介面方面應該非常用心。 規則架構師必須考慮規則引擎的效能，而不能讓它變成您的系統整體效能的限制因素。這與在其中部署規則引擎的系統的效能不同。相反，這指的是規則引擎本身的效能，並取決於執行規則和將結果返回給調用應用程式所花費的時間量。有幾個因素會對效能產生負面影響，如資料模型的設計不正確（例如，在您的資料模型中產生對多維陣列的需求）。保持簡單的設計和使用一維數組總是更好的做法。糟糕的介面設計、硬體限制和跨系統整合也會降低系統的整體效能。 從基礎結構的角度而言，規則架構師必須促進規則存放庫的正確管理。可以通過集中組織商務規則和基於任務對商務程序和組件進行建模來實現正確的管理。規則架構師必須鼓勵共用基礎結構和應用程式以降低成本和改進資訊流。正確地管理規則存放庫還可讓架構師將商務規則和組件重用於新的業務領域，快速進入新市場，以及根據需要覆蓋特定組件以解決新需求。 規則部署應該算作 IT 任務，業務使用者不參與其中。在規則維護的最後過程中再次牽涉到規則部署，下面將對此進行說明。 規則維護 規則開發生命週期中的最後過程是規則維護。業務使用者與規則架構師協同工作，在持續的過程中維護規則。該過程使業務使用者能夠對規則變更，而不必請求 IT 人員提供協助。BRM 系統的思想是為業務使用者提供對商務邏輯更改的完全控制，而不必與 IT 人員協作。這裡的關鍵之處是擁有公用規則存放庫。瞭解規則存放庫對於理解規則維護過程的必要性非常重要。存放庫必須能夠供各種應用程式共用和訪問。圖 3 協助說明了這一共用。 圖 3. BRM 系統的體繫結構視圖 正如您所看到的，所有三個組件（IDE、RMA 和規則引擎）使用同一個公用規則存放庫。這裡的理念是提供一個公用基礎，並且仍然允許所有組件獨立訪問商務規則。因此，即使規則引擎在運行時指向相同的存放庫，業務使用者仍然可以對規則做出更改，並且這些更改立即被規則引擎拾取，而無需 IT 人員的幹預。當然，規則架構師仍然必須管理像發行管理和版本控制這樣的操作。但是，這是在理想情況下的工作方式。 規則架構師必須為業務使用者提供更改規則的介面。該介面與在規則設計過程中建立的供業務使用者管理和更新規則的 RMA 相同。建立的模板被打包並通常部署在應用程式伺服器上，從而為業務使用者提供用於管理規則的簡單 Web 介面。 規則架構師必須建立版本控制策略。版本控制提供所有更改的記錄。組合由業務使用者做出的更改同樣非常重要，這樣您就可以在出現問題時復原更改。 規則架構師還必須建立代碼發布策略。雖然業務使用者可能不習慣於發行管理概念，但不允許他們在任何時間做出更改。規則架構師必須執行可行的發布策略，並且必須通知業務使用者遵循該策略。當策略就緒後，業務使用者可以根據發布計劃按需更新規則。 圖 4 顯示了業務使用者維護規則的過程。 圖 4. 反白使用 RMA 維護商務規則的完整 BRM 系統體繫結構 就像設計和部署步驟那樣，規則架構師在維護步驟中也承擔特定的職責。但是在過程中的這一階段，架構師除了確保正確地部署新規則系統並且 RMA 始終可供業務使用者更改規則之外沒有多少工作需要處理。 規則架構師的另一項職責是建立簡單而方便使用的介面。規則開發人員通常建立 RMA 頁，但架構師可以而且應當實現簡單的方法來設計使用者介面 (UI) 的外觀。這一點再怎麼強調都不過分。在我的一次工作中，某個領先的 BRM 工具幾乎被完全捨棄，因為它的現成 UI 非常難以使用。因此，努力讓介面保持簡單。 規則架構師的工作可能聽起來非常簡單而直觀，但它對於當今的 IT 來說很可能是極具挑戰性的工作之一。 回頁首 總結 優秀的規則架構師必須真正充分瞭解商務規則領域，這不僅包括商務規則和遺留應用程式介面，還包括系統的實際內涵。他們在面對需要實現的特定系統時，會提出大量不同的解決方案，並且能夠從中選擇正確的方案。我希望本文能協助您很好地瞭解這一富有挑戰性的角色。 回頁首 致謝 我要感謝我的導師和商務規則系統專家 Deven Samant 為文本提供的指導和專家意見。 參考資料 學習 您可以參閱本文在 develperWorks 全球網站上的 英文原文。 本文的前一篇：商務規則入門簡介（developerWorks，2008 年 2 月）示範了商務規則管理 (BRM) 系統在彌合業務與 IT 差距方面的重要性。 商務規則社區擁有大量的文章和教程，是開始瞭解有關商務規則的更多知識的好地方。 Mukundan Agaram 撰寫的“The Phased Approach to Mining Business Rules”（Business Rules Journal，第 8 卷，第 5 章，2007 年 5 月）提供了有關如何挖掘系統中的商務規則的極好樣本。 Ronald G Ross 撰寫的見多識廣的文章提出了一個有關是否所有規則都是商務規則的很好案例。 建立和部署商務規則（作者：Neil Kolban，developerWorks，2006 年 10 月）是一篇極佳的教程，其中介紹了如何使用 IBM WebSphere Integration Developer 來建立和部署使用商務規則的解決方案，然後在 IBM WebSphere Process Server 中測試該解決方案。 WebSphere Process Server：IBM 為 SOA 提供的新基礎（作者：Wolfgang Kulhanek 和 Carol Serna，developerWorks，2005 年 9 月）是一篇介紹 WebSphere Process Server 和該伺服器的商務規則服務元件的入門文章。 閱讀文章商務規則管理系統，以瞭解商務規則管理系統是什麼，以及在為企業選擇商務規則管理系統之前應該注意什麼。 Business Rules for Everyone Blog 提供了有關商務規則、設計和體繫結構的增進知識和有趣的討論。 Enterprise Decision Management (EDM) Blog 是關於 EDM 的文章和討論的很好來源。 文章 IBM WebSphere 開發人員技術期刊: WebSphere Integration Reference Architecture 簡介（developerWorks WebSphere，2005 年 8 月）提供了 WebSphere Information Integration 體繫結構的概述。 擷取最新版本的 Business Process Execution Language for Web Services Version 1.1 規範。 訪問 WebSphere Business Integration Server 產品網站，以瞭解有關 IBM WebSphere Business Integration Server 的更多資訊。您將找到技術文檔、入門文章、教育、下載、產品資訊等等。 在 WebSphere 業務整合專區：綜述尋找為 IBM WebSphere Business Integration 開發人員準備的參考資料。 利用 IBM WebSphere 培訓和認證資源。 請參閱 Rational EGL 資源頁，以瞭解有關企業產生語言（Enterprise Generation Language，EGL）的資訊，EGL 是用於定義商務規則邏輯的 4GL 的最新版本。 Rational Unified Process 包括業務建模規程，此規程集中於如何有效地瞭解業務域——包括商務規則。瞭解有關 Rational Unified Process (RUP) 的更多資訊。 獲得產品和技術 IBM WebSphere Process Server 將商務規則作為其商務程序管理套件的伺服器組件之一。 試用 Rational Unified Process for WebSphere Business Modeler Plug-in 的測試版，以瞭解可視化地定義任務關鍵型商務程序是多麼地容易。 使用 IBM Rational RequisitePro 的試用版來管理由不同業務使用者建立的文檔，並組合它們以建立一個大型規則堆棧。 Fair Isaac 推出的 Blaze Advisor 是若干個 BRM 工具中的一個。 ILOG 推出的 JRules 是另一個 BRM 工具。 討論 參與 developerWorks Blog，從而加入到 developerWorks 社區中來。 關於作者 Arun Chhatpar 是一位經常向 IBM developerWorks 投稿的作者，擁有 10 多年的軟體設計和開發經驗，所涉獵的領域包括決策分析、商務規則管理系統、核心 Java、使用者介面架構和工作流程編排。他還是一名 Sun 認證企業架構師，目前在 Farmers Inc. 從事諮詢工作，並使用諸如 Blaze Advisor 和 Pega Rules 等企業決策管理 (Enterprise Decision Management) 技術來現代化該公司的遺留系統。