如何瞭解熟悉業務

標籤：

在這裡想談下對於一個原來沒有接觸過的新行業的新業務系統切入的方法，當然談這點的時候首先是需要已有有一定的IT行業其它業務系統的工作經驗，包括業務和技術雙方面的積累，那麼在這種情況下如何快速的切入一個新的業務系統，就需要注意相關的方式和方法方面的問題。

粗粒度的全域瞭解

接觸一個全新的業務系統，首先要搞清楚這個業務系統主要是支撐什麼樣的業務？而對於支撐的業務本身又有兩個核心內容，即核心的商務程序是如何的？核心的業務物件模型是如何的？在這個瞭解清楚後可以繼續瞭解這個業務系統大致會有哪些核心的業務功能模組，業務模組之間的相互關係是如何的？已經如何銜接的。

有時候瞭解到這個層面可能還不夠，你還需要瞭解這個業務系統可能是支撐端到端商務程序或共用業務資料的一部分，那麼還需要瞭解到這個業務系統或支撐的業務在端到端流程中所處的位置，該業務系統和上遊業務和下遊業務的關係，相互間的協同和介面。

業務系統支撐了什麼樣的業務，儲存了哪些核心業務對象和資料，這是對一個業務系統最基礎的全域理解。

動態瞭解-流程模型

在對業務系統有了一個全域的理解後，需要開始進一步考慮流程模型方面的內容。注意在這裡指的流程模型不是指工作流程或人工審批流模型，而是指商務程序模型。或者說瞭解業務系統本身在分析設計中所涉及到的業務建模方面的內容。

業務建模或商務程序模型的瞭解需要解決的問題是，一個業務系統為何會存在這些業務模組，這些業務模組之間是如何進行協同來支撐商務程序的。任何業務模組都會有輸入和輸出，瞭解清楚業務模組的輸入輸出後就能夠比較清楚業務模組之間是如何串接和整合來支撐上層的核心業務的。

如果一個業務系統按SOA思想來建設，你可能會看到有哪些上層的核心業務模組，核心的領網域服務層和底層的資料模型層，核心的業務模組本身是如何調用核心領網域服務來進行協同和銜接的。只有清楚了商務程序才可能理解清楚業務模組之間的協同和整合關係，否則你看到的是孤立的業務模組，業務模組和商務程序之間出現斷點而無法真正想清楚業務模組間如何協同來支撐業務的。

如果一個業務系統本身是流程型的業務系統，這些流程又大量是審批流為主，那麼即使審批流定義再複雜，整個業務系統本身也是簡單的，因為不存在上面所說的大量業務模組間協同情況。

靜態瞭解-資料模型

對於一個業務系統的複雜往往體現在兩個方面，一個方面是本身業務模組間的協同和互動複雜，一個是底層的資料模型和關係複雜。在解決了第一個層面的動態分析問題後，就需要開始考慮第二個層面的資料模型瞭解層面的問題。

任何商務程序，模組間動態協同最終都將持久化到資料庫中，成為資料庫中的資料表和資料表之間的關聯依賴關係，映射關係。業務系統前面談到過或者是以流程為中心的業務系統，或者是以資料為中心的業務系統，對於資料為核心的業務系統必須理解底層的資料模型。這種資料模型的理解首先是要理解元模型結構，這種結構不是簡單的單個資料對象，而是多個資料對象之間的關聯關係，映射關係，層次關係等。正是由於資料之間有這些關係，而形成了一個複雜的資料網路。

對於資料模型的理解基本可以分為如下幾種，一種是單對象的結構，包括主從，層次等各種結構；然後才是對象和對象之間的關聯依賴結構，如一對多，多對多結構等。對於較為複雜的業務系統，你可能還會看到為了保證底層資料模型的可擴充性和靈活性，往往在資料模型層會根據物件導向的思路做進一步的抽象，那麼在這種情況下還必須等將OO的物件模型和面向結構的資料庫模型共同來參考理解，以分析和瞭解清楚最終資料存放區的方式，資料存放區後最終呈現的方式。

動靜結合-關鍵業務分析

個人理解，對於新切入一個新的業務系統，如果能夠理解到這一步，基本就可以對一個業務系統有一個比較全面的理解和認識。首先是瞭解商務程序和模組間協同，然後是瞭解資料模型和資料間關係，最後則是真正的根據核心業務來進一步理解在流程協同過程中最終資料的落地儲存。由動態商務程序驅動的最終待用資料的儲存落地和關係的建立。只有這樣流程和資料的分析最終才會融合為一個整體。

對於關鍵業務的分析你會看到，對於這些關鍵業務需要理解清楚究竟涉及到哪些模組的協同，在模組的協同過程中最終會產生哪些核心的資料，或者說會更改哪些核心資料的狀態或資料間的關係。真正你需要關注的往往不是單個資料對象中某些資料熟悉的變更和修改，而更多的是關注核心商務程序驅動下，資料對象狀態的修改，資料對象間關聯關係的修改，資料間映射模型的調整等。

對於一個完整的業務系統，按道理只要有基本的資料對象維護功能即可，但是要真正能夠支撐業務，你會看到資料對象中的關鍵屬性，關鍵依賴關係的變更，最終都是由上層的業務模組和流程來支撐的，那麼你就必須要能夠真正的理解所有的核心商務程序最終對底層資料模型造成的影響。

如何瞭解熟悉業務