有關軟體業與商業方面的筆記-I

1.使用者需求在哪裡,商機就在哪裡.
2.不預先考慮競爭者的可能做法根本是找死.
3.建立門檻才能夠堅固領先優勢.
4.任何事業的建立都需要一個過程,任何一步登天的想法或是以為自己有三頭六臂能處理一切的事情,只會招來失敗.
5.最重要的不是資源有多少,而是如何能把資源做最有效的發揮.
6.能夠把資源的分配盡可能做好,預留應付未來惡劣環境(競爭,市場變小)的空間,才有機會成功.

仔細探究軟體的市場價值，其實是在於「滿足應用」而非「工程技術」。「技術」並不是一家軟體公司成功最關鍵的要素。反倒是：應用領域的選擇、獨特性或較高競爭障礙、CEO的經營能力與性格彈性，才是軟體公司三大普遍性的成功法則。

主要原因是「軟體的價值在於應用層面，而不在於技術本身」。用最好的技術所開發出來的軟體有可能一文不值；但是用最笨方法所寫出來的程式，如果能符合使用者的需求，此軟體仍具有價值。

有些前瞻性技術產品的確有高度的技術瓶頸，產品具有不可取代性，但是我必須提醒：這種軟體的成功關鍵在於該項技術最後是否被採用為產業標準，這個決定權不在開發者本身，而在於IBM、Motorola、Nokia、Microsoft、Sony等平台大廠。

到目前為止，台灣比較成功的軟體公司有80% 均屬此類，例如：趨勢、思源、友立、訊連等。這些公司找到世界軟體市場的特定「非主流領域」，集中資源、全力投入搶進世界前三名，這樣可以獲取一定的利潤空間。

何謂利基市場（niche market）？說穿了就是「大廠不想進入的領域」。我曾經參觀過美國一家中型軟體公司（營收在三億美元左右），在其公司政策宣言中就明列：「如果微軟做，我們就不做」。也就是說：當某一領域大到足以吸引具壟斷性廠商介入時，這個領域就變得沒有小廠利潤。趨勢科技是一家很不錯的公司，它的成功就在於選對了領域。當年趨勢開始進入防毒軟體領域時，電腦病毒還沒有那麼普及，先馳得點固然是關鍵，但是「微軟沒有進入防毒軟體市場」卻更是趨勢成功的真正要素。為什麼微軟不做防毒軟體呢？原因可能是在於如果將防毒功能整合到作業系統內，一旦企業客戶中毒，一定會有很多公司控告微軟，要求高價的賠償金，因此微軟基本上對於跟生命或財產安全相關的領域都不會輕易介入。也就是因為微軟不做，所以趨勢才有機會長大。

愛爾蘭是當時全世界惟一軟體外銷可以擠進全國十大外銷商品的國家，當時台灣軟體業的平均生產力(產值 / 從業人數) 為4萬7仟美元，愛爾蘭則為30萬美元，約為台灣的6.5倍。根據這項數據，很多人會誤以為原因是台灣工程師的軟體撰寫能力比較差。事實上台灣的軟體工程技術並不輸給愛爾蘭，真正的原因是在於愛爾蘭開發出來的軟體「被重覆使用的次數」是台灣的6.5倍；同樣一套軟體在台灣有5個人使用，在愛爾蘭卻有33人使用，軟體產業生產力的差距原因在此。為何愛爾蘭開發的軟體有33人使用，台灣卻只有5個人使用呢？原因在於愛爾蘭更專注於了解使用者的需求，而不是花時間在發展軟體工程技術。

如果我們把軟體的生產銷售過程分成三階段：(I) 將使用者需求轉換成軟體規格，(II) 將軟體規格變成產品，(III) 將已完成的產品推銷出去

這三個階段以第一階段的價值最高，其次為第三階段，最後才是第二階段，此與施振榮先生的微笑曲線不謀而合。不過即使是價值相對最低的第二階段，印度卻仍可以透過軟體工廠生產概念、標準化的作業流程，獲取利潤。目前台灣軟體開發產業正面臨全球集中化生產（印度、中國大陸）的直接衝擊與威脅。

綜合上述，我認為軟體產業成功的法則可歸納如下：

一、know-what 比 know-how 重要，選擇領域大體已決定了成敗。
二、藉由建立進入障礙(如智財權)，形成市場寡佔，最後享有長期超額利潤。
三、主事者的廣泛經營能力與個性彈性，決定了企業的最終格局與發展。
四、企業是否抓住正確的經營模式與掌握關鍵性資源。


台灣發展軟體產業策略的迷思

一、 以「數位內容產業」取代「軟體產業」並不正確

軟體是協助個人、企業或組織提昇其生產力或增進滿意度的工具；數位內容則只是強調其中content部份，兩者性質相差甚遠，數位內容產業永遠不可能取代軟體產業。政府希望以「台灣意識」為主軸，全力推動數位內容產業，並把它列為「兩兆雙星」重點之一，事實上這是不會成功的。韓國的數位內容產業發展成功，韓劇大量外銷亞洲各國，關鍵在於其掌握全球性的內容要素：愛情與俊男美女的組合。這兩個要素是普世性的，不受地域限制。美國好萊塢的成功也是同樣道理，數位內容產品如果其中國家或種族文化色彩太重，是不易銷售到其它國家市場的。因此，希望將台灣文化、自然生態做成數位內容產品行銷全世界，這種觀念並不會成就顯著的商業價值。

二、 嵌入式軟體並非容易發展的產品

台灣是個人電腦的製造大國，為什麼不將軟體搭配硬體一併銷售全世界呢？其實嵌入式軟體並不好做，必須至少符合兩項條件才有可能與硬體一併搭售，第一：軟體必須具備與硬體共同銷售的附加價值，第二：搭售軟體必須簡單易學。硬體銷售公司最不希望的，就是承擔附贈軟體的售後服務。如果賣出硬體同時還必須教導客戶使用軟體，這將會增加硬體廠商極高的服務成本。因此，嵌入式軟體必須是傻瓜型產品，符合不學即用原則，如果要花上二小時來學習的軟體，是不能做為嵌入式軟體搭售的。

三、 以中小企業市場為目標的發展策略並不正確

中小型企業其實是最捨不得投資在資訊軟、硬體設備的族群，將資源投入在這個領域是不正確的做法。反倒是大型企業較願意導入資訊化以節省人力或提昇競爭力，在效益大於成本的考量下，會很自然增加軟、硬體的採購。

四、 輔導15~20家軟體公司上市的策略並不正確

台灣軟體市場太小，政府不應該再鼓勵軟體公司上市，此將製造更多的競爭者，讓現有經營的業者更加辛苦。


軟體代工的關鍵成功策略

印度軟體代工模式是否可以複製到大陸呢？過去兩年曾經有很多人思考過這個問題，也有不少人實際去做，目前中國大陸號稱有500家做軟體代工的廠商，但目前為止還沒有一家稱得上是成功。

經營軟體代工事業的第一步必須先了解潛在客戶到底是誰？真正客戶在那裏？很多人以為做軟體代工就是替微軟、Cisco、NEC代工，這個觀念其實並不正確。軟體代工分為產品代工與應用開發，為微軟等代工屬產品代工，其商機複製率不高，每次代工都是獨立合約，下一版本不會自動給上一版廠商。這種生意模式，每一個委託案的爭取，都需重複相同的銷售成本，賺錢不易。

那誰才是軟體代工的好客戶呢？企業規模排名全球前1000大企業的MIS部門！如：可口可樂、嬌生、P&G等。這些公司內部MIS系統有非常大的需求要將程式轉換成新的軟體架構、網路線上管理 ….。這些國際級企業近年來傾向外包解決這些問題，這就是軟體代工最大的市場。為了爭取到訂單，代工廠必須做好嚴謹的製程管理、穩定的品質、準確的交期、嚴密保護客戶機密..等，一旦取得這些大公司的信任後，後續的訂單就很穩定。

根據國際發展軟體代工的經驗，我歸納出幾個成功要訣

一、 客戶信心是接單關鍵，最好採用具公信力的標準工具

國際大公司MIS部門在委外下單之前，最重視的是軟體代工廠的整體作業流程。我參觀過許多台灣、大陸的軟體代工廠，大多有一個共通點：那就是以自行研發的製程為傲。其實客戶希望代工廠採用國際標準的軟體開發工具，然而代工廠卻常認為這些現成工具並不好用，最好按自己的經驗自行開發新工具，其實這是最令客戶害怕的地方。像可口可樂這樣規模的大企業，基本上是不會相信代工廠自行開發的工具，只有使用國際的標準工具才能與客戶建立溝通平台。

二、 CMMI Level 4 是進入國際軟体的代工門檻

軟體代工廠取得客戶信賴的另一個方法就是通過CMII 認證。CMII 認證分為五級，過去有19家通過CMII Level 5認證，其中有15家是印度公司。台灣目前為止也只有資策會通過Level 2認證，因為CMMI認證每個階段都很複雜，如果用一般的方法走一遍，達到Level 5可能要一、二十年。但是惟有通過CMII Level 4認證，才有機會取得國際大廠訂單，如果達不到這個等級只能接些小訂單。

如何快速提升到CMII Level 4認證水平呢？設立之初即聘請國際大師級人才來輔導，寧可付出高額代價，藉由這些國際大師的背書，直接跳上Level 4門檻。這對代工廠而言是高度的進入障礙，一旦擠進這個門檻，就得以享有超額利潤。

三、 管理「白領工廠」，維持嚴格的工作紀律與品質

成功的軟體工廠要有嚴謹的工作流程與作業方法，必須是一個口令、一個動作。中國工程師大都有個毛病--你要他做個杯子，他連茶壺都做給你，這些多餘的創意在軟體工廠是嚴重的致命傷。軟體工廠的運作原則基本上違反中國人的本性，如何能使中國工程師放下自我的小聰明，完全服從不畫蛇添足是一件很困難的事，這裏面隱藏很多的管理方法與技術需要突破。

四、 建立05/95人力結構，集中訓練種子領班

人力結構是做好軟體代工的關鍵步驟，軟體工廠內不需要有自做聰明的工程師，但是業務及服務部門卻需要有5% 懂得新技術、新觀念、能夠與客戶溝通、立即處理客戶問題的專案經理。把人力結構弄對，已跨出成功的一步。

五年內要建制一家二千人規模的軟體工廠，當然要先從二百人做起

一次大戰後，盟軍限制德國軍隊數目在十萬人以內，因此希特勒就決定訓練十萬名軍官，等到作戰前再去招募二百萬士兵，所以德國軍隊數目可以在很短時間之內擴大。同理，一個軟體工廠的經濟規模如果是2000人，前三年應該集中訓練100位種子領班、做好SOP (標準作業流程) 設計，建立正確之IT架構，等到種子部隊與營運模式完成後，就可以將成功經驗大量複製。

FY: ASP.NET MVC Official Release#Getting Started with ASP.NET MVC

節錄自 ASP.NET MVC Official Release By: Michael K. Campbell

開始使用ASP.NET MVC

至於ASP.NET MVC本身,如果你現在想等它成熟一點再玩它(或者只是還沒開始玩),現在是一個投入時間來試看看的很好的時間點.現在它在www.asp.net有一個新的入口網站頁面.也有一些很棒的介紹影片來幫助你對於它怎麼運作以及它做了什麼快速進入狀況.事實上,如果你想快速的對於MVC應用程式如何作用有概略的了解,確定你去嘗試過Stephen Walther的新影片,它示範了從頭到尾完成一個MVC應用程式.

同樣的,對於MVC的開發很棒的一件事就是它近乎偏執的可擴充性並且極為適合客製化以及內部調校.我已經巧妙用了這些延伸的功能在我自己的專案中.而且我這麼作的時候有巨量的資源可以協助我,在ASP.NET MVC本身就有實際的原始碼可以存取使用-你可以在Codeplex網站上仔細瀏覽(或者下載)

如果你對於MVC開發有興趣,另一項資源你可能會注意到的就是MVCContrib.這是一個可延伸的開放式原始碼擴充組件,它的成長可以被用來改進MVC的開發.我已經發現Phil Haack與Rob Conery的Blog有些很棒的資源;他們提供了一些有關MVC特性與功能的文件.但更重要的是,在解釋為何某些特性被實作這些方面的問題時,這些部落格提供很棒的資源.這些部落格提供清楚易懂的結論(以我的觀點)有助於在眾多的創新潮流中扮演吃重的角色,這些部落格也讓人知道來自於微軟MVC與其他最新的發行產品有多麼令人驚訝與創新.

原文連結

反駁有關CSLA.NET的問題(Rebutting some questions about CSLA .NET)

最近我收了一封信,我想與大家分享我的回應.

Rocky,

我們的公司將要在開發軟體的方式上轉型.我們是一間非常大的公司,辦公室遍佈全球.目前只有我所在的地方使用CSLA.如今公司其他人打算建立一個認可過的方法論"工具箱",現在我們必須保護使用CSLA的決定.從一般情況看來,我覺得這是個好主意.但就現有情況看來,似乎提供建議方案的人來與我們面談,不是為了找出我們有沒有作對什麼事,特別是我們用的東西來自於CSLA.

現在,我了解我能很好的提出質疑...但是,我認為你的幫助將非常有價值.這裡有一些有關CSLA意見的列表,我覺得我必須清楚的反駁.就個人立場我知道他們客觀上是錯的,然而,他們似乎對於CSLA有著普遍的誤解.你認為呢?再提醒一次,這些都不是我的意見,只是我從公司其他人聽來的誤解,我需要把它弄清楚.以及,有一項關鍵性的誤解是我們應該使用Enterprise Library以取代CSLA,再一次強調,他們不了解到底CSLA.NET是什麼東東.

誤解

1. CSLA .NET 是一個移轉到.NET的舊觀念,不像Enterprise Library是為了.NET而寫的.

2. 許多CSLA的功能可以用Enterprise Library達成.

3. 跟廣泛被接受的Enterprise Library相比, CSLA .NET只是一個特定應用(niche)的架構

4. 從觀念上CSLA .NET就不是為了新技術像是WPF或WCF等建立的.

5. CSLA .NET乃是以軟體元件為基礎的,而這些軟體元件並非設計來利用或是適應SOA架構的.

6. CSLA .NET 緊密的與舊架構結合,對於面臨.NET的未來而修改與適應SOA的調整都只是後知後覺.

這些是我覺得應該要釐清最關鍵的幾項錯誤想法...你能對於我形成中的論點提供任何協助,我將大大的感激.

感恩!

Jimbo

我的回覆如下:

Jimbo,

1. CSLA .NET 是一個移轉到.NET的舊觀念,不像Enterprise Library是為了.NET而寫的.

這絕對不是事實,在COM-based CSLA與CSLA.NET有非常多且完整的更動.沒有程式碼被搬移過來,事實是CSLA .NET中的概念已經被.NET自己使用了,參考COM的部份是很有限的.

長久以來,CSLA的確到處都使用了某些OO概念.這些概念經歷了許多時間的測試都保留下來了,也證實對於設計與建構軟體非常的有價值.只因為它們由來已久就拋棄掉好的觀念是很愚蠢的.就如同因為輪子是舊有思維而把輪子丟掉一樣.

各位必須要認知到非常重要的一點,CSLA .NET與Enterprise Library是完全互補的.CSLA .NET提出一套解決方案解決了Enterprise Library未對付的問題,而Enterprise Library則提出一套解決方案解決了CSLA .NET未對付的問題.

2. 許多CSLA的功能可以用Enterprise Library達成.

再提一次, EntLib與CSLA .NET是互補的.像是日誌,快取,資料存取,系統設定.而日誌功能便在CSLA .NET的範圍之外.

而像是資料驗證,身分認證,資料繫結的支援與針對資料n-tier的位置通透性則是CSLA .NET關注的重點.

當然EntLib也有資料驗證模組,在架構上並不穩固,把商務邏輯放進使用者介面層還不如封裝到獨立的商務層.(譯者註:本人認為這兩者應該都需要,UI跟Business都需要資料驗證)

3. 跟廣泛被接受的Enterprise Library相比, CSLA .NET只是一個特定應用(niche)的架構

無疑的使用一個特定應用的架構是一種風險.在此事項上,任何使用CSLA .NET的組織必須清楚了解架構的本質.

然而,要明白另一點也很重要,CSLA .NET是一個使用.NET類型而被廣泛使用的架構.雖然EntLib的確更廣泛被使用,但並非複製或取代CSLA .NET所提供的功能.

如果你未使用CSLA .NET,你仍需要解決它所對付的相關問題.無論喜不喜歡,在.NET中到處都是資料繫結,資料驗證,身分認證與等等需要跨越的障礙. CSLA .NET排除了這些障礙.如同其他產品像是NetTiers, LLBLGen, Ideablade與其他的產品.有些是商業產品,有些則不是.

但目前沒有一個擁有像CSLA .NET這樣廣泛的使用者基礎.

已經有好幾個人在研討會上找我討論並指出他們寫了CSLA .NET的複製品.他們已經閱讀了我的書,不想要使用所謂"特定應用的架構"並且開始自己弄自己的東西.幾個月以後,觀察應用程式並發現到他們又重複解決了所有的同樣的問題.處理所有的同樣的障礙.並且他們用更多程式重建了CSLA .NET.通常他們因此很難過,了解到他們浪費了多少時間去重建一套已經存在的架構.

4. 從觀念上CSLA .NET就不是為了新技術像是WPF或WCF等建立的.

這顯然不是事實.抱歉,但是CSLA .NET 2.0在觀念上特別是為了WCF與WPF而開發的.我在微軟的技術先驅團隊中,並提供許多協助以形塑許多這些開發者導向產品的本體.我在.NET 3.0完成多年前就了解其基本的型態與架構,因此在2005年CSLA .NET已經為這些新技術作好準備.

儘管在對此產品評估的言論裡面,其他大部分尖銳的批評是合理的且考慮周詳的(雖然我清楚的反駁某些結論),這一項質疑卻完全是荒謬的且漠視了我已經花在過去四年多的幾百個小時的工作.也忽視了這些年來確保CSLA .NET提供無縫與簡單的更新路徑,從Windows Forms, Web Forms 到 WPF,以及從Web Services 或 Remoting 到 WCF.

我想提出一項挑戰,看看有沒有人能找出另一個架構能讓使用者透過簡單的修改設定檔就能從Web services或Remoting切換到WCF.並且藉由我為這些技術準備的方法我在2004與2005就在CSLA .NET中完成了這些功能.

5. CSLA .NET乃是以軟體元件為基礎的,而這些軟體元件並非設計來利用或是適應SOA架構的.

此處有兩個觀點.

第一, CSLA是一個品牌. 無論是"以元件為基礎可調較的邏輯架構"是否仍能正確的描述(這不能)都不再重要,因為這個品牌就是它自己.換句話說,不要太鑽研它的名字 - 我被它搞的很煩.

第二, 無疑的CSLA設計用來支援n-tier的主從端架構.這樣的架構目前是使用WPF, Windows Forms與Web Forms介面建構互動應用程式最好的方式.無論喜不喜歡它,SOA有太多多餘工作負荷並且對於大多數互動性應用程式開發來說成本太高.

認為物件導向設計在面臨SOA或者workflow時會被消滅是很蠢的.事實上它們是高度互補的.

一項服務或者一個工作流的活動從定義看來都是基本功能單位.如果他們不是,那麼你就弄錯了.

實際上每項服務與每項活動是"迷你應用程式".它們實際上也是一個使用者案例,從一個物件導向設計(OOD)的觀點看來.

例如:你可以(並且應該常常)使用OO概念設計並實作你的服務與活動.所有有關於讓物件導向設計/程式開發(OOD/P)用於打造應用程式上的相關事宜,CSLA .NET都能夠讓它變的更簡單.

結論是,無論你正在打造消費服務的應用程式或者生產服務及活動的應用程式,CSLA .NET都有很大的幫助.

6. CSLA .NET 緊密的與舊架構結合,對於面臨.NET的未來而修改與適應SOA的調整都只不過是後知後覺.

事實是CSLA .NET已經能夠有大量使用者作為後盾,他們來自於微軟平台上快速增長中的更新與混亂的地帶.藉由清楚的在使用者介面與商務邏輯間的程式碼間強化邊界的輪廓,並藉由支援.NET標準的資料繫結與.NET功能的使用者介面, CSLA .NET持續擔任一個有價值的緩衝區,允許有價值的商務邏輯更容易隨著時間發展,即使使用者介面技術改變又改變再改變.

為了對付微軟平台的快速變革,我會花更多時間替CSLA .NET或者更重要的CSLA .NET的使用者建立"不會過時的技術",但明顯的要抽象化所有微軟發表的變更是不可能的,但是CSLA .NET努力保護其中最重要的以及在維護與建構上最耗成本的:你們的商務規則與邏輯.

原文見此

替人捉刀寫母親節邀請函給家族成員

母親節聚餐邀請

俺客家人愛鄉愛土，重視家族傳統與凝聚力，尤其對下一代孝道的觀念特別注重，一年一度的母親節馬上要到了，今年母親節不用再自己花時間張羅慶祝，因為本人特別在 月 日於 餐廳舉辦母親節家族聚餐，讓家族裡的每一位成員共同來慶祝這個溫馨的日子，希望各位能撥冗參加。

附註：每位參加成員酌收200元清潔費。

比較CSLA.NET 與 Enterprise Library (CSLA .NET compared to Enterprise Library)

CSLA .NET compared to Enterprise Library
比較

在微軟Patterns & Practices討論群組中許多人問過Enterprise Library與CSLA .NET 2.0兩者的對比關係為何?

我所寫的書(例如CSLA .NET 2.0)針對如何建立一個物件導向的商務層,靠著提供正確性檢查,身分驗證,資料繫結,回溯功能與堅固性,此層可使你的商務物件支援各式使用者介面(Windows, Web, Web services, WPF, 等等).這允許使用者介面完全專注處理顯示與使用者互動的問題,把所有商務邏輯與流程都交給商務物件.

Enterprise Library是很棒的應用程式區塊的集合,用以處理有關日誌,例外處理,資料存取等等的問題.P&P團隊建立了多種其他的應用程式區塊到此類別庫(EntLib)內.到目前為止,無論是EntLib類別庫或是其他的應用程式區塊都並未針對商務層的設計與建構.

CSLA .NET與EntLib類別庫是互補的.你可以同時使用CSLA .NET與EntLib的元件,也可以同時使用其他由P&P Group開發的其他應用程式區塊.

P&P Group = MS's Patterns & Practices Group
EntLib = Enterprise Library

原文見此