我直接先說結論好了,SA 根本不需要懂 “領域知識(Domain Knowledge)” !!

SA 所需要具備的知識與技巧是,如何與領域專家(Domain Expert)溝通,並懂得如何將其領域知識轉化為抽象的軟體模型。

請記得,是與領域專家的溝通與討論,而並非僅是操作系統的操作員(Operator),從操作員所得到的,大部分是零碎片面的需求,卻非是從企業經營的角度來看待整體企業的流程(Business Process)。

專案經理或IT 主管要求 SA 需要研究,或者起碼需要懂一些 Domain Knowledge,這似乎是業界根深蒂固的觀念,正因如此,SA 根本就沒有花太多時間在 “純” 軟體設計的學習與研究上。當然,會有太多的人質疑,若 SA 不懂領域知識,如何能建構最起碼所要求的 E-R Model 呢?畢竟,E-R Model, Class Diagram 的組成單元幾乎是從領域知識的專業術語而來。

這問題的答案,其實說起來,也不難回答,答案就是如前所述: SA 要能具備 “純” 軟體的技能與技術。
那麼,什麼是 “純” 軟體的技術? 答案又是很簡單:抽象(Abstraction)、封裝(Encapsulation)、介面(Interface)與相依性(Dependency)分析的觀念 …等。

以抽象為例,當 SA 懂得抽象的技巧後,會發現到,各類的領域知識,其核心的本質是源自於 “交易(Transaction)”,交易即為事件(Event),會因而延伸出與該交易所串連的人、事、時、地、物等。所以 SA 在與領域專家溝通討論時,就會用心在尋求該領域上的各類交易,以此為核心,逐漸延伸,而能建構出領域的物件模型。

簡單的實際例子,網路購物系統中,訂購(Order)即為重要的交易事件,顧客(人)會下訂購;下訂購的地點(Place)如超商需要被記錄下來;訂購需要出貨,可能會分次出貨,而出貨,又是一個重要的交易事件,它又可能會串連至出貨人員與出貨地點...等。

Peter Coad “Object Models” 一書中,早於 1997 年該書即已揭露出以交易為核心的 “Transaction Pattern”,來指導與協助 SA 以此來建構領域的物件模型。

這很有趣,有別於 SA 以為要經過需求的訪談後,透過需求文件的紀錄,才可能找出 “Entity”,建構領域模型。當 SA 是與真正精通的領域專家溝通時,運用抽象的技巧,反而可以不先需要透過片段局部的需求文件,就可以建構核心的領域模型。

但,問問看,又有幾個 SA 會去看如 Peter Coad 這樣的著書呢? 更為悲哀的是,SA 根本就是花很少的時間在軟體設計的根本學習與思考上,去看各類 Domain 相關的書籍,反而還比較多。說難聽點,我到覺得有點不學無術。

你要問我,SA 有沒有可能成為好的領域專家,說什麼我都不可能相信。

答案又是很簡單,若可以成為專業的領域專家,那根本沒有必要擔任 SA,因為,領域專家的待遇比 SA 好上太多啦。

又,有沒有可能同時很懂領域知識與軟體設計的? 我是聽過幾個自稱兼通的,但,這我更不相信。要專精每一個專業領域,最起碼沒有花上 5~10 年,是不可能成為專家的。請記得啊,軟體設計,也是一門專業的領域,而這一門領域,其門檻絕對不會來得比其它領域還要容易,對工程、管理、邏輯、心理、藝術等等,均需用心研究思考與學習,你還能有其它時間研究其它領域?

有些 SA 可能有心向學於純專業的軟體設計,但,回到現實面,環境卻不許可。

舉一個實際的例子,我一位目前任職於外商軟體公司的朋友,前兩年他去應徵國內某家大型有線寬頻電視的 MIS 部門,該部門的 IT 主管,出的考題,竟然是要我那位朋友寫出人事出缺勤管制系統的企業流程。 這... 我實在很難以想像,這是 IT 主管!! ?

大環境確然不佳,但這仍端賴於 SA 個人目標的選擇。你要往其它的專業領域,例如 ERP,那麼,就應該要用心成為該領域真正的領域專家;或者,你仍情有獨鍾於軟體設計,那麼,就應該用心在軟體設計的思考與學習上,成為真正的軟體專家。你不可能雌雄同體,是 ERP 專家,又是軟體專家,這樣,是違背大自然法則的,一公與一母的感情結晶下,才有可能生出健康活力的寶寶的。