背景，需求不很明確，工作量大，開發人員有限。
項目爲在線汽車實時監控系統，採用在線google Map
1. 架構和選型
1) 基礎架構：
業務上分爲幾個子系統，各個子系統是相互獨立的Java webapp可以單獨部署，也可以一起部署到tomcat，並通過一個ROOT webapp， portal來訪問，並通過一個簡單的SSO來登錄；每一個子系統可以單獨部署在自己的數據庫schema；各個子系統之間通過Camel數據集成，
實時數據通過Router（socket前置機，通過互聯網/GPRS/3G/4G等網絡將汽車GPS及其汽車總線信息數據傳送過來）發送到Camal再通過一個Java app將接受到的數據寫入Hbase。
2） 技術選型：
a) web: HTML5, Jquery/kendo, Spring MVC/Restful
b) 後端：Spring, Spring-data, JPA
c) 數據儲存：SQL Server/Oracle（基礎數據），Hadoop/Hbase（實時數據）
d) 系統集成：Camel/Spring,Active MQ
3）架構3宗罪：
本身的架構沒什麼問題，但是問題在於放錯了坑，一個蘿蔔一個坑，但胡蘿蔔和紅蘿蔔是有區別的，把紅蘿蔔往胡蘿蔔坑裏放就不合適了，總體總結：
a ) Camel 濫用：camel本來很好用，其Camel架構也本身也沒有問題，在系統集成也很簡單，問題在於把Camel用爛了，其主要問題是濫用導致了代碼調試和維護的難度增加，從而使工作量成倍增加。很多camel接口爲了做到所謂的通用，而很刻意的通用，接口的定義和開發很自私，只考慮了接口本身，並未考慮接口調用方的便捷和可靠。接口定義簡單，接口定義的返回結果太過結構化的。雖說結構化的數據很明瞭，但就是這樣太結構化的數據導致了跟多的工作量。同樣的事情使用JPQL或者SQL 2個小時即可完成，而使用結構化的數據等於在重複數據庫select語句所要完成的工作，跟爲可悲的是這些功能用結構化的數據來過濾很容易出錯，且調試困難，從而導致開發時間數10倍增加，甚至幾十倍，有些查詢功能甚至前後超過2周的時間（2*5*8=80個小時，40倍）。結構化數據和扁平化的數據： 這裏的結構化數據指類似JSON/XML式的數據，扁平化數據指類似關係數據庫的行數據。結構化的數據的好處是對開發人員友好，不需要文檔說明或者只需要程序doc，做一般的過濾和輸出很不錯，但做複雜的過濾和查詢就比較費時，如果是多層數組或list數據就要嵌套N層循環，比較考驗開發人員的細心和耐心了，所以這種情況不可取，而該項目中卻用了這樣的方式。扁平化的數據簡單明瞭，很多時候需要文檔說明各個字段或offset所代表的意義，但做複雜的過濾和查詢比較容易，一般一次loop就可以。
i) 爲用二用，而不是爲需二用。ii) ESB接口的定義和實現不太科學，重複和交叉（笛卡爾積）查詢太多，能自定義的查詢條件很有限。iii) 查詢結果多爲結構化數據，不易處理，並且沒充分發揮數據庫的威力，這種結構化數據造成了80%的無用數據，也浪費了80%的性能，通過一項日誌觀察，數據庫查詢佔了整個應用性能的80%，導致慢的原因也是這種太多無用查詢，而這些直接是Hibernate導致的。其中一項功能單體查詢竟然需要1~2s，同樣的需求使用SQL語句只需要幾十MS。
b) 第二個敗筆就是拿Hbase來做實時數據的監控，Hbase需要運維的支持，並且在大請求下性能很差，內存暴漲而溢出，從而Hbase集羣奔潰無法使用，還有Hbase沒有關係數據庫那麼友好的SQL查詢語言和性能，hive實際上不好用且性能差。c) kendo 框架的錯誤使用，kendo提供了很豐富友好漂亮的UI組件，並且基於jQuery，本來是好的，但卻非要拿把BS的程序搞成C/S就無語了，這就造成了在使用kendo中遇到了該遇到的不該遇到的問題，而且界面死慢不夠流暢，多窗口多文檔的方式並沒有在該項目體現優勢，事實上每次只能操作一個窗口，其他窗口被屏蔽，這個和傳統的web頁面方式沒有什麼區別，但它卻需要更多地JS工程師時間和更多地經驗，從而開發時間增加：i） 需要專門的JS工程師，而且要熟悉HTML5，CSS3。ii） 從事過傳統B/S項目的 Java工程師（ 前端 ）無法勝任，或者需要花較多的時間學習纔可以做前端開發。iii）出現的BUG機率比較高，複雜頁面需要花費更多時間。
4）架構師幾宗罪：
a）架構師經驗不足，架構沒有很好的評估，看了quick start 覺得好就敢拿來用。
b ) 架構師太追求新事物，不考慮健壯性。
c）架構師追求自己學習新鮮流行技術，不考慮項目實際情況。
d ) 架構師不考慮項目組對技術的熟悉度，以及新技術的學習曲線，導致沒有系統的學習就來用，從而使使用中bug超多，修復bug花費了大量時間。
e ) 架構師不夠nice，把握自認爲是核心的技術，不予共享。
f ) 架構師太自負，寫代碼不自己測試，導致其他人調試程序花費更多時間，事實上架構師所寫代碼問題多多。h) 架構師太面向對象化，對於SQL/JPQL/HQL等的拼接和使用很是不看好，也看不起這種做法，這就導致瞭解決一個需要幾分鐘能修改的查詢問題，需要花很長時間來解決，另一個問題就是架構師在選型JPA時，並未事先考慮這種查詢的通用組件來支持這種缺陷。g) 架構師書本主義，看本o'reilly，然後就本本主義大幹一番，匹配式應用，不考慮需求和業務，中國式教條主義。
5) 程序員幾宗罪：
a. 做外包項目培養的懶惰性: 以完成工作而做事，而不是以自己想法而做事。
b. 對架構師的抵觸心理：軟件設計經驗差距、軟件思想的差距較大。
c. 對項目管理者的抵觸心理：工作安排不合理，評估差異太大。
d. 程序員責任心不強。
e. 程序員太自負。
f. 程序員編程技術興趣不同。
6）項目管理幾宗罪：
a. 工作安排不合理
b. 工作量評估差異太大
3. 需求、需求承諾幾宗罪：
1） 需求不明確
2）需求管理不同步，需求參考不一致
3） 需求沒有確認時間，項目結尾時還在提需求。
4）無意義的需求。