軟體的模組化(Modulize)設計應該要徹底實踐!

在上個月看 Discovery 節目時,該節目很有趣,是介紹有史以來,前 10 大受歡迎與戰鬥力強的坦克車。

嗯,還是從二次大戰開始介紹的呢,其中,包括德國的虎式與豹式坦克,都名列上榜,而更為驚人的是,蘇聯的 T34,當時在德蘇大戰中叱吒風雲,令德軍第一次感受到他們的武器不如人,是名列 10 大中的第三名。而至於第二名的坦克,則是活躍於波灣戰爭中,但卻也有令人苦惱的問題,太過龐大與吃油量太重、維修不易等問題。

嗯,這要與我談軟體模組化有何關係呢? 嘿,當我看到榮登 Discovery 第一名排行榜的坦克時,實在驚訝與讚嘆不已。榮登第一名的是:改良過的德國製坦克 — 豹式二代。

話說原來,當時二次大戰中,德軍鑑於蘇聯 T34 的優異與靈活又兼顧火力的性能,而加以參考並改造他們的坦克,當時就有豹式坦克的出現。但是,豹式坦克雖性能優異,且砲火猛烈,但是,太容易故障了,而德國人龜毛完美的性格也反映在該坦克上,加上太多不必要的束縛與修飾,而這些,是在激烈的對戰中,大部分是不需要的。

而今的豹式二代,仍然呈現著豹式一代優異的性能與保持了德國人求完美的設計性格,但卻改善了最重要的一點 — 快速維修與保養的能力。怎麼作呢?在所有前 10 大坦克中,也只有豹式二代具有現今結合硬體與軟體的彈性設計 — 模組化!

我看了節目的展示,嘴巴合不攏嘴,實在驚訝不已。豹式二代一旦發生故障,維修人員只要拿出筆記型電腦,連結坦克的介面,即可以診斷出坦克的那一部分出了部分,再來呢,不是去拆開出問題的那一部份,而是,整個模組抽出來,就好像診斷出 PC 的顯示卡或記憶體模組出問題後,拔出來,再把新的給置換進去即可。我第一次看到,坦克的模組化設計,也能造成這種 P&P(Plug-and-Play) 的可抽換效果。

回歸軟體,看到好多產品都號稱是 “模組化” 的設計,每次呢,我到世貿軟體應用展,只要問展示販售 “進銷存” 產品的廠商,能否將 “進貨” 模組,與某家或是本來公司內部既有的 “存貨” 系統給 “兜” 在一起呢? 嘿,得到的解決方案就是利用 “資料庫” 來作系統整合。

而以資料庫為整合的解決方案,我就很清楚了,這些號稱是模組化,根本只是在業務層級的邏輯面,卻沒有確實在實體的系統面,達成模組化的設計。若要能達成在實體系統面的模組化設計,必然是首重於介面(Interface)的設計與溝通,至於資料庫,只是各個模組的 “私有倉儲(private storage)” 罷了。以資料庫為主的整合,是屬於 “草本植物” 式的整合,雜草叢生,而根卻早已彼此糾纏不清,剪不斷、理還亂了。

連龐然大物般的坦克車都可以確時達成模組化的設計,怎麼這些軟體產品,談模組化這麼久了,卻仍是用幼稚的資料庫整合方式,而無法確實分隔每個可被抽離與置換的模組,並且可以很容易地利用測試工具找出是那個模組出問題,乾脆就直接把壞的模組給 “抽換” 掉呢?

文章導覽

   

共有 37 則迴響

  1. 「模組化」只是系統的自我切割。不同系統的切割結果,彼此間是否有替代性,便是「標準」的作用範圍。也就是介面的設計是否存在著標準的問題。有標準,便有整合(替代)的依據。

  2. Hi 阿不都拉:

    還是要記得喔,程式也是 “設計”,在當你把 OO 利用 UML 表達設計思維時,不要忘了,”實踐” 的最具體仍是 “Coding”。

    只是隨時提醒,寫程式要能有 “想法”,為什麼是這樣的表達,而不是只以 “寫出來” 為滿足。

  3. 看了您這篇文章,蠻有同感的,我想軟體也應該要做到這種程度,之前我們有設計過戰車的模擬器,我也是用這種概念來做硬體的規劃設計,說來我是做機械設計的,這樣什麼元件有問題就整組拆換,這樣會增加設備的妥善率,有問題的組件拆回公司再做整修。
    最近覺得機械設計沒什麼意思,想走軟體設計的路,算是自己踏錯的一步,不過也從中學習到不少東西。但想要再重新開始,目前也打算從OO和UML開始學習設計,而不是直接從程式語言來學,我想這樣的方式學習應該會是比較紮實的吧!
    話說回來,看看公司內部作軟體的人員,程式碼也是一塌糊塗,牽一髮而動全身,我也認為好的程式不應該是這樣的。也應該是所有模組都可以抽換,只是這可抽換模組的大小。
    上過您的課後,更篤定這一點了,希望未來我也可以做到這一點。

  4. 軟體設計並不昧於專案現實
    專案現實不但不會侵蝕我們的能力,而是讓我們能力與時俱進,因為軟體設計是不昧於專案現實的,所以專案前期面對現實的規劃(管理面)與分析設計(技術面)是必須的

  5. Hi M:

    看了你多篇文章越來越有一種感覺:有可能你越來越走火入魔了!

    >我對流程感興趣,我對讓所有人的程式『自動』模組化更感興趣,我的目標是軟體工廠,所有的程式元件就像螺絲一樣,看看有多少種標準的螺絲、木材、鋼架、鐵釘等等,有這些東西才有大樓,當這些都還沒有標準想要侈言軟體工程不易啊。

    所以,M,你想想,那似乎是一個 “美好新境界”,但,M,你是否是擔任自動化的螺絲之一? 還是,你原來是螺絲,然後想轉型成為螺絲起子?

    問題是:螺絲本來就是螺絲。如何能轉型成起子呢?

  6. 對不起最後一篇了,我有些走火入魔了。
    我二十多年的寫程式經驗來說,我服膺的是射擊、瞄準、射擊的理論,所以對各種事先的設計嗤之以鼻,不過除非本身的實力夠,而且願意不停的重寫程式,不然很難做到。我之前提到的那個東西,平均每兩年我會全部重寫,不過還是保留向下相容性,畢竟底層是不停的變動的,光是xml parser,在jdk內建的定版前,我們這些先行者就有許多不同

    的格式,想起以前的xml4j 1.x多好用。也因為最底層修改了,上面也要修改,通常我會重新寫、重新設計一回。射擊、瞄準、射擊是在有的東西上持續改進,別忘了沒有實做的設計有很大的機率會因為底層不支援而不能照想像的來搞

    ,沒有真的去作不會想到jdk有那麼多限制,想起以前C的美好時光,甚麼都能作。畢竟還是要賺錢,大多數的人都不想要這樣作,寧願上班打msn,非正式統計60%的時間被msn佔據。和一個成功的案例談天,他一個人統領了一百人團隊,團隊成員全都是contract的,隨時會走,就是靠紀律與標準的文件來做事情,他只負責決定程式的pattern,文件化後找別人作,我說pattern是程式寫多了自然會有的,他回答根本pattern是用來溝通的,就像我們的UML相同的意思。我的第二個問題是如果裡面的程式有問題,或是寫的看不順眼怎麼辦,因為我只要程式不順眼一定重寫,他說根本不該注意細節,只要結果對的就好,畫面、效能都在預期,文件固定產出,提供的介面可用,其他都不管,不然怎麼能帶領這麼大的團隊,事實上這個團隊還要同時支援大陸和台灣,每年收入極為可觀。
    也因為我看到了紀律的美好,程式的設計似乎不重要了,背後的意思是你的人只要是free-lancer,一個人月的固定人力成本應該是150k-200k左右,但是free-lancer只要50k-90k。我們程式的設計可以交由像是WayPointer這種東西幫忙,世界似乎不同了。
    事實上我沒有不要模組化,我對流程感興趣,我對讓所有人的程式『自動』模組化更感興趣,我的目標是軟體工廠,所有的程式元件就像螺絲一樣,看看有多少種標準的螺絲、木材、鋼架、鐵釘等等,有這些東西才有大樓,當這些都還沒有標準想要侈言軟體工程不易啊。

  7. 同人大哥還是我,應該用e-mail的,不過你的網頁也沒看到,我也不想公開,所以只好用這裡,真是對不起基地主人了,麻煩把我的意氣之爭在同人大看過後刪掉吧。
    我知道流程和設計無關,不過怎麼讓不會設計的人做出好的設計是我真正想做的工作,這也是Iva Jacobson現在做的事情,我們引進流程工具就是要落實好的設計並且知識分享,總不能出問題都要指明少數人出動。
    每個人要好的設計。我認為程式寫多了自然有pattern出現,高手的程式看多了,自然設計就會出現。只是我不厭其煩的教人還是有人不照作。所以要流程了,不用寫多程式、也不用看多高手的程式,我想用紀律、規範、check list來達到好的設計(Iva Jacobson就是賣這個,那個工具會讓你達到好的設計,很神奇吧,我雖然不相信也在嘗試中,在EA人的網站說別的工具應該沒關係吧)。因為設計不只是核心的介面而已,在邊緣元件也要設計,總有一天寫那些程式的人也會寫不同的核心。

  8. 還是回同仁大哥
    因為已知成功的例子都是小案子,這也是你介紹的那間成功案例的公司被質疑的地方。我去聽的是Iva Jacobson(真的大師,說得我也大多數都信服)的演講,他也說小案子只要實做少部份的RUP,也比較容易落實,他認為TCS的RUP還太沈重,應該更靈活。我倒是認為老闆就是要TCS生產線式的大量開發,而這種就是要錢的。
    我們從來沒有投資過這種事情,所以我希望如同你說的會落實並且成功。

  9. 同仁大哥,
    這就是現實的問題,有專案在身上的時候,就很難做到。只有沒有專案的情形下才能真正落實,沒有專案就是要花錢,事實上我們老闆只是把上個專案賺的錢決定不要再接著賺,不是很有錢(我們手上有了三個專案都是10M以上的,全都暫時用政治力量擱置),要落實真的流程,當然目的是想未來能否賺更多錢。
    我最近到處找這些流程的文章,包括英文的,就是想要知道要如何作才是對的,已知我們實做了XP不是很成功,在時程的壓力下回到以前的作法,所以決定換RUP,或是Essential UP。公司的目標是TCS(RUP最成功的案例)。

  10. 看了M君寫了那麼多,給我的感覺是您的老闆很有錢,而您也很有設計能力及實戰經驗,所以如果沒有像您有個有錢的金主,模組化、物件導向等設計理念是不可能落實的,是嗎?

    我完全相信您是軟體開發的高手,但從William’s blog到這裡,您所談的都是所您對專業技術與應用工具多麼有經驗,如果這些都行不通,那麼我們所討論的設計者的理念與設計原則心法,是最直接而有效不必外求的東西,我實在想不通為什麼這些要花大錢。

    看來我們的討論一直都在雞同鴨講,我們該怎麼解決這個困擾呢?

  11. 我當掉的那篇還有寫最近最好的程式介面就是我每天玩的「魔獸世界」。
    真正的plugable的東西,建議大家玩一下,不要只玩遊戲,看一下他的AddOns怎麼做的。
    我的程式就是要做到那樣。

  12. 特別指明的一定回,我的firefox當了兩次(原因其實是酷音輸入法的問題),只好用上班偷打。
    MOA,模組化程式驅動架構。
    軟體界沒有新鮮事,我配合大家才用這些名詞的。前些日子和某金控資訊長聊,他認為好的軟體就是成本變少(單指人力,因為人力比較貴)、架構速度變快、效能更好。現在那些流行的話SOA, ESB, MOA和以前的程式也沒甚麼不同,但是透過那麼多層只是更慢,以前的一個系統只要不到半個人力就可以維護,現在相同的系統比較慢不說,還要兩三
    個人來維護,因為有太多介面要學了。
    相依性在UML不是那麼好追蹤,所以我們才用RequistePro+RSA來作,我提到的10M還不包括這些license,單就人力而已。
    我寫了很多年程式,毫無疑問我也喜歡寫程式,我的專案可以符合客戶需求,甚至於不惜對jdk, tomcat, websphere, weblogic動刀,因為我重視現實,但是太累了。正好老闆有錢,所以我們要學個業界最有名的,沒有用EA的是因為反正要花大錢,乾脆用最貴的網路上最多資源的。我們找大家說最好的工具、最棒的顧問、最佳的老師、最棒的流程來作,因為我決定走向虛的那一面,雖然我不是很認同這些用起來難用的工具(說不定EA的很好),那些沒作過大專案的學術顧問老師,那些花時間的流程,不過因為我不懂,所以人家怎麼說我們就怎麼作。
    我也寫很多介面,甚至於有個像spring的架構我六年前就寫過了,連xml定義都差不多,在spring還沒出現的時候就在業界跑了,而且我們絕對用介面溝通資料庫,沒有人可以直接對到資料庫,我個人覺得比spring好,因為資料庫總有許多問題,那些新進的programmer照書寫出的東西通常都是不行的(比如說大多數90%的書上寫的jdbc直接用在db2 v5-7上面保證會memory leak,oracle, ms sql也有別的問題),乾脆不要他們去碰就好了。
    我也寫EAI,整合多個系統,不過如果後端系統要換掉你非要整合資料庫不可,我們的SOW永遠有回應要在一秒內的需求,這裡面有無數的資料讀取與最少兩次的寫入資料庫,當然可以很多用介面來多個系統存取,那就不現實了。我曾經跟BEA的勞虎先生與有名的蔡學鏞先生問過這個問題,他們的回答相同,這樣設計後未來的機器會快到解決這個問題,不過我六個月後就要上線,而且機器早就買了。可以為興趣,那只能作open soruce的。
    倒是我的老闆(金主)很有雄心,我作過太多現實的東西,所以我們要搞個大的,就要完全是 plugable、可以抽離,看看理論是不是真的可以做到,最後還是想要賣錢的就是。

  13. Hi M:

    用那種工具來管理需求,與牽一髮動全身也沒啥關係,系統的變動性,需求是其中之一環節而已,況且,這是設計思維的問題,工具可以輔助,但卻不是絕對性的。

    我並不瞭解什麼是 MOA,我也不知它是否又是什麼流行的新名詞。反正,軟體業的術語,永遠沒有新鮮事。我只知道,模組化要嘛就是徹底實踐介面的溝通。

    模組也會有共用的東西,這是必然的,所以軟體設計師必備的一種專業技巧與素養,即是相依性(Dependency)分析,這是我在多篇文章一再提及的,但,我看過太多的設計圖與文件,卻很少有軟體設計師重視於此,這我蠻納悶的。

    EJB 所做的事是資料庫的模組化? 我到第一次聽及,可能需要再請 M 解釋一番,我有點不瞭解 M 的意涵?

    “至於資料庫的整合是絕對重要的,每個模組都用自己的資料庫,那也不用玩了”,這兩句話我蠻肯定問題多多。

    1. 整合絕對不是從資料庫入手,而是系統,就是應用系統!! 千萬不能搞錯。資料庫的整合是導致應用系統複雜的主因,內文提及,這是 “草本植物” 的整合,在現今 e化時代的應用系統整合,再以此種方式來作,是相當幼稚的作法。
    2. 後續這句 M 似乎仍無法分辨 “虛” 與 “實” 的設計觀點。各模組在實體上當然可以使用同一資料庫,這沒有問題。但在 “邏輯” 層面上,各模組之間的溝通,絕對是透過 “介面”,不以 “跳線” 的手法連結資料庫,而讓模組之間糾纏不清。

    公司有沒有資源作模組化? 我從來不會寄望這類的事情,再說明一次,軟體設計之道,是與自己的目標與興趣有關的,可與公司沒啥關係。

    還有,我從不覺得所謂的模組化是希望做到無關資料庫的功能,可以完全是 plugable、可以抽離。軟體設計,絕不是忽略現實與現狀,而是懂得應用現實的技術來達成目的,嗯,我個人可是很注重 “現實” 的,做不到的話,我不會只在這裡唱高調、曲高和寡。

    我想,M 你可能要好好思考在 “軟性的虛” 與 “現實的實” 之間的互補與設計相依之道。也蠻謝謝你提供很多不錯的意見,不過也讓我感覺到,一般軟體人員的設計思維實在太偏向工程與技術面了,那些技能是 “實”,但還不足,更需要 “抽象” 的創意性思維,那是 “虛”,兩者是互補,缺一不可。

  14. 我們用RequisitePro來管理需求,就是為了不要怕牽一髮動全身,當然舉dll的例子不好。
    我知道大家想做的是流行的MOA架構,別忘了那些模組間也會有共用的東西,解決共用的東西也很重要。
    資料庫可以模組化,也就是EJB做的事情。不過資料庫的整合絕對是重要的,真正的專案一定要動到資料庫,如果每個模組都用自己的資料庫,那也不用玩了。
    真的要設計到極限要看公司有沒有資源做下去,同人大哥在Willian’s Blog有提到的「好的軟體來自於軟體工程」那間公司,可靠消息指出即將被併購,我認識的人都這樣說那公司是不是做的很好等併購後再說吧。
    我現在做的工作正是模組化所有功能,希望做到無關資料庫的功能都可以完全是plugable,即使抽離升級也不會對系統有影響,當然公司也願意投資大於10M來作,有多少公司有這個錢來作,而且即使我的公司也說一般的customized專案還是不會這樣作,因為只有一次的專案沒有投資價值。

  15. 模組與耦合
    其實國內的workflow engine廠商其實都聲稱符合WfMC工作流程標準,但一般人很難了解它們各模組間是否有做到真正的分離。曾問過幾家workflow engine要如何整合其應用程式,所得到的答案多半是「

  16. Kenming,你好!很久之前我就开始看你的Blog了,收获很大,尤其是个人目标管理,我也很感激你介绍了很多好书。

    我在上海读书,所以不太了解台湾的状况。工业领域有各种各样的硬性标准,这也成为了厂商和客户之间的中介(类似于界面)。而在软件的开发过程中,普遍缺少合适的“中介”--即使有,也可能会被忽视。所以说,软件开发是一种私有的、被(驱)动的过程。

    能模块化是再好不过了,如果有一天软件能彻底的P&P了,那我们就可以好好休息了~

  17. Hi 各位:

    對所謂模組化仍有疑問的話,建議各位可以參考 WFMC 組織對 Workflow 的模組規格的定義,非常詳盡與完整。

    http://www.wfmc.org

    以該組織 Interface-1 為例,Process Definition 是與 Workflow 核心分離的。各位可以以此來審視國內的 Workflow 產品,是否有哪一套產品確實可以做到這一點,這還只是 Interface-1 而已喔。

  18. Hi 111:

    國內軟體業業務出身的老闆係走短線的心態,我在好幾篇(包括本篇)均已提及,這是不容置疑。但是個人若以軟體設計之道為職志,可不會因為現狀與現實如此,就甘之妥協的。

    至於你所提及國內某家搞軟體元件公司倒閉,我想我應該知道是那一家,我也有朋友在哪裡。問題是,111 怎麼會認為那家公司在走軟體元件化設計呢? 我可從來都不以為的。

    道理很簡單,該公司推出所謂的 “軟體元件” 是作為其它軟體公司的 “Business Framework”,問題是,當用了你的 “元件” 後,就要被你給綁住,這怎麼會是元件化呢?

    對了,國內至今為止,確實沒有一家公司搞軟體元件。國外呢? 嗯,微軟的 .NET Framework 就是最標準的元件框架。但它是屬於系統層面的範疇。

    我到寧願把所謂的元件化再 “擴大” 一點,稱之為 “模組化”,模組之間必須透過介面溝通,這是現今系統整合首重之道,無庸置疑!!

  19. 軟體的模組化設計思維
    軟體開發比一般的產品開發還要困難,一開始使用者並不清楚他們所需要的軟體需求,所以也無法告訴軟體設計者,而這些需求也很難預測出來,同時還有需求變動的風險。
    因此,針對需求

  20. Hi Nick:

    >先克服各各軟體間的資料庫是否也模組化吧。

    那根本是沒有必要的。
    文已提及,資料庫是各個應用系統的資料倉儲,各應用系統要如何存取資料庫,那是各家的事。

    Nick 你的思維還是仍停留在資料庫整合的觀念,才會有如此的問題。

  21. Hi M:

    正因為要擔心 “牽一髮動全身”,所以才需要更徹底的模組化。

    另,Windows DLL 實在與模組化牽扯不了什麼關係,不同的位階,不能被拿來相提並論的。設計中,模組之間的相依性關係,是首重的考量。

    我想,可能我對模組化的定義應該是與你所認知的不一樣吧。

  22. 模組化後最大的問題還是在牽一髮動全身,看看windows的dll hell就知道了,現在雖然也會模組化,最好還是不要共用比較好,這樣改版的影響也會比較小。

  23. 如同 Fred Brooks 所言,設計軟體最重要的,就是找出它的 conceptual integrity,也就是該軟體的隱喻(metaphor),搞清了一套軟體的定位,其它的都只是枝節問題,甚至外包時都可以讓別人幫你設計。軟體做為真實世界硬體的附屬物,其 conceptual integrity 跟 domain 息息相關,除非做的是純資訊服務例如 Google,這也是程式設計師最可以不受限於 domain 之處(程式設計師跟 user 溝通後,常想改 domain),因為這類 domain 很單純,重點在於將它做到最好。

  24. 關鍵在於”利益”二字,
    基於利益就會產生私心,
    德國與美國的坦克可能模組化互相使用嗎? 不可能!
    不只是軍事上的機密, 更重要的是在於利益上的衝突, 兵工廠的利益多驚人啊!!
    相同的, 軟體可能模組化到互相抽換使用嗎?
    只要牽扯到利益, 事情就永遠不會這麼單存.

  25. 在概念、設計跟後續的使用上,硬體跟軟體都有著本質上的不同。坦克跟軟體比起來,不算是複雜的東西,看過幾部電影跟幾個模型的孩童,都可以對坦克的功能說上幾句,但他對稍具商業用途軟體的理解就完全不可能如此,這點大人也好不到哪裡去。

    坦克的演化也比軟體久得多,功能介面大抵都已經很清晰,變動性跟軟體完全不能比。一部坦克開始服役後,也許可以用個 10 年甚至更久,如果沒有大 bug,中間幾年僅會『小改版』,跟汽車一樣(尤其這類硬體都有安全性考量,所以更不輕言改版)。但軟體,尤其是客製化產品或專案,極少可能這麼久都不變動。

    軟體模組化(元件化)是典型知易行難的問題,說穿了還是成本考量,而且要各方配合:

    必須要有最高管理階層長期的支持(這一句是政治廢話,以下才是真章);
    必須要有專職的元件總設計師、元件程式設計師、元件測試工程師、說明文件設計工程師(到 104 找找看有沒有這種職務,到各大補習班找找看有沒有這種課程);
    必須要有客戶或使用者長期而頻繁的參與(這一點最難掌握,但效益最大,可以用減價當誘因,因為客戶參與也要花他們自己的成本);
    必須要培養程式設計師樂於使用元件的習慣跟文化(不要文人相輕);
    如果有蓬勃的商用元件市場,那就更好了(國外有,但本地很多程式設計師的英文不夠好)。

    在國際級的軟體大廠中,上述條件或許都成立,但克明兄逛到的國內進銷存軟體廠商,大概只有第一條成立 — 而且極可能成立在大老闆的口惠上,亦即,嘴巴上說支持,但完全沒有做到。

    大老闆一定也會跟你說,生存都不易了,還搞這些東西幹嘛?他說的也沒錯,所以,到底是哪個環節出了問題呢?我對此現象也一直感到困惑。

    我以前有個朋友在一家轉搞軟體元件的公司,但該公司在軟體元件這一塊沒幾年就銷聲匿跡,銷聲匿跡之前也沒聽過接到什麼像樣的軟體元件訂單。

    所以最後的結論,就會是你現在看到的這個樣子,大家整合都用資料模型而不用物件模型,一份資料,各自表述,各取所需,搞到最後 SQL、XML 變成王道,就跟有些網站根本多數只用 HTML 而不用 ASP/JSP/PHP… 一樣。其實想想,規模不大的軟體用這種方式,好像~也沒什麼錯啦!殺雞何必用到牛刀呢?

  26. 整合並非不可行,重點您是以什麼觀點來看設計。如果您把方便整合的觀念溶入設計中,您會設計減震點(Decouple point),把模組化與差異化的部分巧妙地隔開,這種設計策略就是所謂的延緩策略(Postponement),好處是可能待需求確認後才開始實始生產差異化的部分,而共用的模組則可以重覆使用增加開發績效,縮短開發時間及成本。其實就是所謂的(DFx,Design for XXX),例如克明兄所說坦克的例子就包含了Design for maintenance的設計概念。

    所以軟體開發能如果做到元件模組化,服務差異化,那整合一點都不困難。可惜大部分的公司都是反其道而行-元件差異化,服務模組化。結果反而造成系統變得更複雜,整合更加困難。

    其實不做整合的主要的原因還是市場利基及公司策略方向,如果人家很容易把我整合進去,那我還有什麼搞頭,當然要把系統弄得別人很難整合進去。但標準化,同步工程及整合是不可擋的趨勢,如果忽略它們,那未來將被新的浪潮所淹没。

  27. Hi:

    請問是我認識的那位賢智嗎? 若是的話,請留個 Email 給我,好久不見啦。

    我沒有說「整合兩家公司的模組」不可行,是那些賣進銷存系統公司所號稱的模組不可行喔。

    後面你那句話太過牽強了,”讓德國的坦克用美國的模組行嗎”,你應該反過來說,美國的廠商是否有意願推出符合該坦克所需的料件?若有利可圖,那就需依循該坦克的模組規格。

    這句話,”模組化,有時還是很抽象的東西”,就因如此,才會導致許多軟體公司所推出號稱的模組僅位於業務層面的泛稱而已。

    實在感嘆,業界至今仍舊不重視介面的設計。

  28. 就如你所說的,整合兩家公司的模組不可行。同樣的,你讓德國的坦克用美國的模組行嗎?模組化,有時還是很抽象的東西。因為設計理念的複雜性,以及延伸整合,都會影響模組規格的設計。到最後,你會發現0,1是最後的可以被用的模組,但是已經沒有多大的用處了。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *