Openbiz將引領PHP開源框架的革新

 筆者自述

我從事軟體開發行業至今已經將近十二年，經歷了從Windows 3.2第一次登陸中國到蘋果安卓統一移動應用市場的一場場變革。著這場商戰中，把握住未來發展的方向才是確保再競爭中生存的硬道理。由此發起本文。

 
引文

多年來一直在探尋企業級應用的未來發展方向，發現對於技術的積累與重用是這個行業的提高競爭力的重要因素之一。

（當然這並不只是成功的唯一條件）讓我以技術的重用性為視角來看一下這個行業的發展興衰。
 
很多小型軟體開發團隊在創業初期，往往承接外包軟體開發工作為主要業務來源，在面對市場競爭時，
大部分人不斷將客戶需求中的共性積累起來，設法將帶有共性的業務邏輯分立出來用於在其它項目中重用，這樣可以逐漸降低未來的開發人力成本，聽起來是個不錯的邏輯，但在實際應用中卻很少真的見到效果。
 
是什麼導致這個美好的設想實施困難呢？

•     客戶的需求過於制定化，

•     系統在設計過程中被多次徹底修改（而非所期待的“擴展”）

•     客戶對時間要求的緊迫，對費用預算的苛刻，讓你無法停下來去思考架構，只能一個功能一個功能的修改完整個項目
 
這種外包開發的商業模式，遇到的最常見的尖銳問題是什麼呢？

•     客戶的費用承受能力，他會不斷的拿給你的開發費和某國際500強企業的成熟產品的零售價格去比較

•     客戶的對周邊業務邏輯的不認可，如果他的需求是開發一個制定的產品數據管理系統，他決不會願意去為一些貌似和產品管理無關的周邊業務邏輯去付出費用和時間，例如：處理用戶登陸邏輯，用戶會話管理，找回密碼，用戶許可權控制，數據緩存和性能優化。

•     客戶對細節的無限的完美化的要求和原則上不可能增加開發預算，

•     客戶很難理解一個沒有用戶界面但必須存在的功能特性。不理解當然不願意買單了。

•     例如：客戶問“你說的那個用戶會話管理和高級緩存功能，我點哪能看到？”
 
天哪，怎麼辦？！想生存，要麼你想辦法解決問題，要麼被問題解決掉。

如果你對上述我曾經遇到過的問題也有同感，那麼“兄弟”，我們一起來看我是如何應對的這些矛盾的。
 
如何平衡核心業務邏輯與周邊業務邏輯的比重

讓我們以某大企業需要開發一套企業內部的資源共享平台為例：

這個項目的核心業務（被用戶最關注的部分）是：如果通過系統來共享公司的各種業務資料，並且可以確保數據的訪問許可權安全可控。

如果你承接了這樣一個項目，你要面對的周邊業務呢？按我的經驗分析這些工作肯定不能少，（就算你減少了客戶也會在付款驗收前要求你加上）

1、用戶管理，如何創建，刪除，編輯用戶，找回密碼，會話控制，登陸日誌

2、許可權管理，誰可以訪問某個模塊某個功能，某個文件夾某個文件，如何多人同時對某個文件都有不同級別的訪問許可權

3、部門管理，如何創建，刪除等，而且能夠在系統內重現客戶公司的組織結構，還要考慮一些極端情況，例如某位高人同時在多個部門任職。

4、用戶界面設計與模板引擎，即便客戶說軟體的美觀性無所謂，你也是需要一個表單不少的把他們都設計製作出來，

5、站內導航與菜單模塊，這些功能都在哪如何訪問肯定需要一個菜單樹

6、電子郵件通知模塊，例如我共享了一個數據，怎麼自動通知對方
 
90％以上的客戶只關注他們的核心業務邏輯，而往往對於中小系統的開發核心業務邏輯最多只佔整體項目工作的不到50％。

以這個範例來說，核心業務似乎簡單的僅相當於整體項目的20％.
 
哇現在你認為這個項目不管費用多少，就這些工作怎麼也要開發個半年吧。

但客戶認為這個功能就相當於FTP軟體或者Openbiz的文檔管理，人家免費的軟體都有，我就是在其基礎上增加一點點小小的適應我公司的改動為什麼，找你這樣的小軟體公司，你看1個月時間，一共2萬開發費能搞定么。
 
如果你說對這樣客戶說Lets see(看吧)，哪只能寄希望與你的高級談判和斡旋能力了，可你通常是技術團隊啊一般不是外交和談判專家

如果你對這樣的客戶說NO，這意味著你大約會失去70％以上的同類同級別客戶需求，由於你的競爭力薄弱，丟掉機會和市場

如果你說對這樣客戶說YES，你確定你不是在自虐？
 
到現在為止，解決這個矛盾和提高你團隊競爭力的關鍵因素在於，如何最小代價的消化掉這些周邊業務邏輯所帶來的看不見的成本。
 
重用性！把這些你能想到在每個企業的開發需求中肯定都會出現的業務邏輯抽象分離出來。例如，用戶、部門（組）、許可權管理這些。

現在我們可以說誰能用革新的辦法把這些周邊業務邏輯解決，誰就可能成為以後的老大。
 
對象化與框架化開發模式，實現業務邏輯重用

面向對象開發和框架這些概念從被提出到今天大約已經有8年以上的歷史了，這不是一個新的話題。

目前市面上的任何一種語言都已經完美實現了面向對象這種語言特性，而框架呢，例如微軟公司的.Net Framework，Java的hiberNate, Spring，PHP語言的Zend, ThinkPHP, 還有在美國比較流行的CakePHP和 Openbiz 等。
 
而就我研究，這些框架級解決方案主要解決的是，從數據底層到業務邏輯曾的抽象化，例如各種框架中均實現了如何創建抽象數據對象以簡化對資料庫編程操作的，如何實現高速緩存例如Zend_Cache, Openbiz 的CacheService等
 
好吧，這樣確實能減輕我門的核心業務邏輯開發工作，可是真正具有重用價值的是例如用戶管理，許可權管理這樣的模塊級的部件。

那麼這麼說，也許誰通過這些高級框架技術，將這些常見業務邏輯開發成可通用化使用的私有平台，誰就可能成為以後的老大。
 
新的極致化“模塊重用”思想，平台式應用系統開發

思考到這裡我們先停下來，看一下美國的小型軟體公司是如何解決這樣的問題的。

軟體這個行業美國的水平還是很有參考價值的。這兩年突然發現一種新的開發模式叫平台式應用系統開發。

就是說一個系統，用戶管理，許可權劃分，部門劃分，高級緩存，多語言化等這些你能想到的周邊特性都給你設計好了。

在這個系統之上你只需要去做你20％比重的核心業務邏輯就好了。而出來的系統是一個界面特別專業，周邊功能又豐富整體系統。
 
這種平台特性最先進的是美國 Openbiz Cubi平台，還有早期Xoops也先後提出了 Web Application System這一概念。雖然Xoops的概念提出的比較早，比較了一下底層功能模塊的豐富程度，還是Openbiz Cubi的更豐富一些，而且個人而言認為Openbiz的UI比較親蘋果風格，特別細膩。
 
在早期具有同樣級別完善程度的私有應用平台在美國已經產生了一些，例如，Joomla,Druple,Magentoo的私有應用程序框架，也有一些開發團隊基於CMS系統，或這種Shop系統的用戶許可權模型的基礎去“改裝”，不過可想而知，一個是楞改出來的，一個是設計的目的就是為了重用的。

特別對於中文用戶來說，Openbiz的漢化水平是Xoops所不能及的。據了解Openbiz的創始人團隊中還有咱們海外華人。
 
現在對於軟體公司而言，不用費力自己去開發通用邏輯了，也不用想著怎麼基於什麼系統修改。不管是 Openbiz Cubi還是Xoops選擇一個你看好的陣營，進行平台化開發，來提升你的核心競爭力。

那麼，原來誰先平台化，誰將能稱雄？
 
極致市場化戰略，讓我們app store!吧

當客戶項目的積累到達一定程度，也許你已經開始思考這些制定項目的通用性，

例如前文提到過的資源共享系統，去掉當時客戶提出的制定化的特性，讓它變為一個可以針對某行業應用的軟體。

這樣以來，小型軟體開發團隊就擁有自有的軟體產品。從創業初期的勞動力輸出，到了現在的產品輸出。
 
隨之我們發現，很多當年的創業者成長了起來，形成“諸侯割據”的局面，那麼不如我們一起加入個“聯盟”設想，所有符合Openbiz 標準或Xoops標準的應用程序，可以集中在一個類似安卓市場或者蘋果App store的市場中集中發售這些軟體。

這才是一場真正意義的革新！
 
移動終端上先輩們發明了App store概念，在PC領域中 QQ軟體管家與 360 爭霸天下，Web級企業應用市場怎麼可能無動於衷呢。

如果不想在這場革新中被淘汰，只能抓住時機向平台化進軍