如何了解熟悉業務

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

粗粒度的全局了解

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

有時候了解到這個層面可能還不夠，你還需要了解這個業務系統可能是支撐端到端業務流程或共享業務數據的一部分，那么還需要了解到這個業務系統或支撐的業務在端到端流程中所處的位置，該業務系統和上游業務和下游業務的關系，相互間的協同和接口。

業務系統支撐了什么樣的業務，存儲了哪些核心業務對象和數據，這是對一個業務系統最基礎的全局理解。

動態了解-流程模型

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

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

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

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

靜態了解-數據模型

對於一個業務系統的復雜往往體現在兩個方面，一個方面是本身業務模塊間的協同和交互復雜，一個是底層的數據模型和關系復雜。在解決了第一個層面的動態分析問題后，就需要開始考慮第二個層面的數據模型了解層面的問題。

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

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

動靜結合-關鍵業務分析

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

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

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