SA 需不需要懂 “領域知識(Domain Knowledge)” ?

我直接先說結論好了,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 專家,又是軟體專家,這樣,是違背大自然法則的,一公與一母的感情結晶下,才有可能生出健康活力的寶寶的。

文章導覽

   

共有 11 則迴響

  1. 除了結尾「大自然」「一公一母」的比喻,讓人抖了一下之外(或許這又正好反過來證明懂電腦軟體不等於文思敏捷、常識正確?)是很有說服力的好文章!畢竟,那些名垂千古的歷史人物,也很少有人是因為有兩個專長而被記得的。

  2. 不一定要是專家,但知識領域還是要建立到能夠與專家對話阿!

    不知道「噴子」為何物,如何能溝通,「噴子」的抽象、封裝、介面、相依!?

    到最後你還是得從專家手上推敲出「噴子」的資料,無論你是從專家手上學到,還是事前先把資料準備好,最後都是要建立的。

    • >不一定要是專家,但知識領域還是要建立到能夠與專家對話阿!
      >到最後你還是得從專家手上推敲出「噴子」的資料,無論你是從專家手上學到,還是事前先把資料準備好,最後都是要建立的。

      yes, 這是我所認同的,在與領域專家的溝通過程中,本來就需要對該領域的專業術語能有共識與基礎的了解。

      我所謂 SA 具備 “與領域專家溝通的能力”,對領域術語的定義與解讀,這些是在溝通過程中會建立起來的。

      領域的關鍵知識,我比較主張 SA 不太需要花功夫與心思去學(除非你想當該領域的真正專家);重要的還是在於:解讀與快速捕捉精要 (essential)的能力。

      • 漂亮! 完全贊同!!
        您最後的說明,完全消彌 前文的疑慮.
        5 年之間,應該是有不同境界的體會!

        • 本篇文章至今已事隔多年。

          不過以我們團隊身體力行與至許多輔導單位觀察的結果,仍是與個人在當時所主張 SA 不須懂領域知識並沒有違悖的。

          SA/SD 要了解的最基礎功夫是軟體抽象的能力。

  3. 以前我的老師用了一個相當有趣的比喻來說明 SA 與 Domain Expert 的角色。小孩子要能生出來,總是需要先生與老婆的結合才能生下來,而不是一個人就能擔負生小孩的責任。 ^^

    溝通不是在於兩者的須具備共通的知識,重點卻是在於 “合作”。 這點在軟體開發中,為何會有各類不同專職的角色互補合作就可以知道的。

    在國內的軟體業界諸多公司,的確幾乎都要求 SA 要能具備領域知識。但是相對來說,我個人所看到的 SA,卻幾乎沒有具備軟體分析的能力 (這可是很奇怪的現象)。

    至於個人所主張 SA 不須具備領域知識,此點論點卻也不是空談,而是幾年下來,透過多年來在許多單位的顧問輔導,反覆的實證,更是證明此一論點。

    如果有興趣討論這個議題,歡迎利用假日(星期六)來中國生產力中心找我,早上上完課後,一整個下午我可以陪你討論諸多軟體設計與開發的許多議題。 ^^

  4. 從溝通理論來看,兩個個體之所以可以溝通,是因為具有共同的知識,這雙方都擁有的共同知識是能夠溝通的基礎。如果SA完全沒有Domain Knowledge,而domain expert也不知道SA在做什麼,這個溝通的過程必然會非常辛苦。這是為什麼SA必須有domain knlwledge的原因 — 為了有效溝通,而不是為了變成domain expert直接提供解答。
    現在的企業已經不像上個世紀那麼強調專業分工,而是強調多能工。因為在跨領域的工作場域中,太極致的專業分工造成的專業本位主義,溝通障壁一旦出現,企業就無法敏捷的對外在變化做出反應。
    某些軟體工程學派認為,SA不必然需要了解後面接下來的軟體設計在做什麼,就如同SA不必然需要具備domian knowledge。你認為這真的行得通嗎?

  5. 我觉得SA必然是软件设计专家,而领域建模是从软件设计角度对业务领域专家级认识,所以SA也必然是一个角度的领域专家。
    在做领域分析时业务对象的领域专家固然重要,但是operator同样重要。一个完整的业务系统需要包括各种细节,而业务领域专家是不能提供这些的。
    SA应该比业务领域专家更有价值,因为SA可以在系统分析业务领域的基础上帮助业务领域专家完善业务流程。
    SA应该明确的知道软件的价值。

  6. Hello nick

    其實,我這一篇文章發表出來,就知道會有許多不以為然的批判。 🙂

    不過,藉此思考 SA 該具備什麼樣的基本功夫、所擔任的角色與定位 …等,提供另類的參考。 ~_^

  7. 『軟體設計,也是一門專業的領域,而這一門領域,其門檻絕對不會來得比其它領域還要容易,對工程、管理、邏輯、心理、藝術等等,均需用心研究思考與學習』。有所感。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *