什么是企業軟件
還記得我們一開始寫程序的時候嗎？那還是在學生時代，因為興趣，或者你做畢業設計的時候，寫出幾行代碼，實現了一個簡單的功能，如計算出一個數學結果，或者彈出來一個窗口，你的心情是那么激動，你充滿了成就感！好像看到世界掌握在你的手里了，后來你慢慢實現了很多的功能，一個比一個酷，覺得寫一個軟件不過如此，但當你畢業了，找工作的時候卻遇到了困難：沒有工作經驗！我可以做軟件啊？我可以實現很多功能啊？他們為什么說我不行呢？為什么說我沒有經驗呢？我和經驗老道的工程師有什么區別呢？
我們現在就來探討這個問題，為什么你寫的東西幼稚？為什么人家不敢用你辛苦寫的軟件？當然，我們在這里討論的是大部分普通學生，那些天才的高手不屬于這個范圍。當你以后逐步成為中國軟件行業的主力軍后，你會發現，你當年寫的東西只能屬于自娛自樂的“個人軟件“,而行業內需要的是正規軟件。就如那個文化站站長(尊龍飾)搞的那個”關中女俠“，在小范圍內大家樂樂還可以，放到全國電影院線恐怕就不行了！達到我們所說的”企業軟件“，這個進化過程，是一個需要大約2年的歷練，當然，有人會更短，有人會更長。
企業應用軟件，一般指的是那些為商業組織、大型企業而創建并部署的解決方案及應用，這些大型企業級應用的結構復雜，涉及的外部資源眾多、邏輯復雜、事務密集、數據量大、用戶數多，有較強的安全性、可靠性等考慮。
注意企業應用系統和通用商業軟件的區別，商業軟件一般是具有通用性的產品，比如金碟、用友的財務軟件，它們作為產品，質量要求非常高，非常具有專業性，能滿足多數客戶的需求；而企業軟件系統作為項目，常常是為一個企業定制的，業務比較復雜，直接面對需求多變的用戶，需要良好的架構以滿足需求的變化。通常會有較多的售后支撐工作。
企業軟件的特征
我們現在先列出兩種企業軟件，來讓你對企業軟件有個感性的認識。
有一種企業軟件的特征是訪問量特別大，那些大型的門戶網站，比如新浪，就是個例子，很多上班族到公司第一件事情就是打開新浪網，全國范圍，全世界范圍的華人，假如某個時刻有0.0001%的人在訪問它的首頁，那也是一個不得了的數字！這樣的網站硬件要過得去，軟件架構也絕對是非常出色的！
還有一種是業務邏輯特別復雜，要在某個大型的企業內部署，來解決一類業務問題，我們知道，企業內的業務不是孤立的，而是在不同層次上互相關聯的，需要和企業已有的系統來建立聯系，也可能需要外面的用戶、供應商從中獲取、輸入數據，等等。而且這種軟件的需求是不斷變化的，你的軟件需要適應這種變化。滿足這樣需求的軟件肯定也是非常了不起的！
我們現在來探討一下企業應用系統具有那些要求或者說特征，一般來說，它在如下的方面要求很高：
l 性能
l 可靠性
l 安全性
l 可用性
l 伸縮性
l 擴展性
l 管理性
這些苛刻的要求都是長時間以來用戶提出的，他們希望我們能做到這些，才敢用我們的軟件，才敢把他們重要的數據和業務放到我們的軟件系統之中！想想那些重要的數據，我們銀行存款，我們的手機費用記錄，當然還有什么國防機密、衛星上天等數據，我們自己都想象不出來，如果出錯，或者丟失，后果會怎樣？？？
用戶對我們IT界提出挑戰，我們要應對這種挑戰，我們要讓他們信任我們，使用我們的技術，所以，IT技術一直發展到今天，IT的價值已經廣泛被人們認同并應用。我們IT人員不斷的努力，努力去滿足用戶的要求，給用戶更好的體驗。這種努力包含大體可以分為硬件技術和軟件技術，硬件技術發展很快，那是我們同行努力的結果，我們在這里不多談，但要給他們敬意！這里談的是我們軟件方面。
軟件又分為系統軟件和應用軟件，系統軟件一般為國外的大廠商所擁有，比如微軟，IBM等，系統軟件和硬件結合的比較緊密，而且很多前沿技術還處于研究階段，學術范圍之內，距離我們普通的程序員還比較遠，我們這里也不多談，我們只談和我們關系比較緊密的應用軟件，它的發展，它的技術和用戶對它的理解！
每個特征的分析
我們來逐個討論一下每個特征的解釋和軟件界應對這些挑戰而發展的技術。其實，回顧軟件技術發展歷史，我們可以看出，很多技術就是來解決以上幾個方面的要求（另外的技術用于解決軟件行業的生產率提高問題），技術應需求而來，用戶提出了這么苛刻的要求，我們軟件行業就要想方設法來滿足他們——因為他們是上帝，是我們軟件從業人員的衣食父母！
性能
性能的概念很好理解，從用戶角度來看，這個軟件系統運行快，反應時間短，就說這個系統性能高。而從系統上來說，用的是事務吞吐量和資源使用率等指標。
為了提高性能，我們可以進行如下方案的選擇：
分布式計算，和硬件結合，用若干個服務器，把軟件系統也相應分為幾個模塊(層)，一般為表示層、業務層、數據層，更復雜的還可以多加幾個層。每個層在不同的服務器上運行，上層調用下層計算，下層把計算結果返回上層。這樣就避免了使用性能更高的服務器，控制了成本，實現了分布式計算。
需要進行文件 IO 或繁重的數字處理的應用程序可能將繁重的工作卸載到另一個或更多的層上，這些層可以方便地伸縮以滿足峰值負載需要。比如生成大報表、創建文檔或發送 SMTP 郵件的組件就是這樣一個例子。
分布式系統學習曲線比較陡峭，只有在一些大型系統中用到，Java平臺上的RMI 與 .NET中的Remoting都為分布式計算提供了良好的支持，我們可以從案例研究來學習和實踐分布式軟件開發，比較出名的案例是“寵物店網站”，java版本和net版本都有。
緩存，以空間換時間，把將來會重復調用的數據、對象預先加入內存或者第一次使用后不銷毀，而是緩存到內存中。這樣可以節省很多數據生成或者銷毀的時間，換來響應速度的提高。常見的緩存有：
l 線程池。節省了大部分線程創建和銷毀的時間。典型的例子是Web服務器軟件，每個用戶訪問進來，則線程池會提供一個線程來處理請求。在Java和.Net都提供了創建線程池的機制。
l 對象緩存池。如果某些對象的創建很費時間和資源，則可以當這些對象使用完后先不銷毀，而是緩存起來，以備以后使用。J2EE架構中的EJB就是一種典型的對象池技術（圖1）。
圖1 EJB容器的對象池
對象池如果不是為了研究或者學習，請直接用運行平臺提供的成熟實現來完成。
l 資源連接池。最常見的是數據庫連接池，一般的商業運行平臺都實現了此技術，我們只要進行一些簡單的配置即可，比如下面的ADO.net數據庫連接字符串：
server=localhost;user id=test;password=test;database=Sample;min pool size=4;max pool size=40;
這里設置了數據庫連接池中連接的最大數量為40，最少數量為4，ADO.net按照此字符串的設置來提供連接池功能。
l 頁面緩存。如果一個B/S系統用戶訪問量非常之大，我們就可以把某些web頁面計算結果緩存起來，當眾多客戶訪問此頁面時，將不再計算，直接把結果放到輸出流中，從而極大的提高響應速度。比如我們在asp.net頁面上直接設置頁面緩存：
<%@ OutputCache Duration="60" VaryByParam="type" %>
上面的指令表示緩存此頁，緩存期限為60秒，并且根據傳入參數type來緩存不同的版本。
并行計算，用多線程技術來達到并行計算，java和C# 都為多線程提供了語言層的支持。多線程可以讓響應速度提高，特別是在多用戶并發訪問時，最常見的是Web服務器軟件。每個用戶訪問到達時，Web服務器會為此用戶提供一個線程來處理用戶的請求。并行計算可能在企業軟件中用的并不多，多數是用在一些系統軟件中。但我們需要有清晰的了解，所以你還是有必要自己寫點程序來實現一下。
對技術方案的選擇，我們舉一個例子：事務，事務對性能影響較大，減少使用事務可以提高性能。在開發中使用事務有級別上的差別，比如：
1. 自動事務，由容器（如EJB容器或者Com+）實現，一般你只需做個事務標記，容器會幫你實現。這類事務一般處理復雜的、分布式事務。
2. 手動事務，比如直接在業務層的代碼中實現的事務。
3. 數據庫腳本事務，直接實現在數據庫系統內嵌模塊，比如在存儲過程中。
從性能上說，事務級別越高級，對性能影響越大。性能最高的事務是在數據庫系統中直接實現的事務。微軟提倡數據庫操作一般寫到存儲過程中，很重要的一方面是為了性能的考慮。
系統和代碼優化，優化你寫的代碼和后臺數據庫系統的性能，優化數據庫訪問，比如只獲得你需要的數據，可以減少數據傳送量從而提高性能。我們這里說一個常見的分頁的例子：
假如一個分頁的web頁面，頁面展示的數據非常龐大，需要分為好多頁面，初學者經常會寫一個固定的查詢語句，如：“Select * from Users”，這樣用戶每次只查詢一頁的數據，但我們卻每次都返回了所有的數據。浪費很多服務器和網絡資源。我們可以寫成這樣：
select top 20 * from Users where id>lastId
其中lastId 可以根據上一頁最后一條記錄得到。
圖2 只返回每頁的數據
還有一個相似的例子是值對象模式，我們把訪問的相關數據打包成一個對象，傳送到客戶端，客戶端代碼可以從容訪問此對象的各個屬性，而不是每訪問一個屬性就去和服務器交互一次，這樣可以減少網絡訪問次數，從而提高性能。
可靠性
可靠性衡量應用程序能正常運行的程度，更正式的定義為平均故障間隔時間 (MTBF)，即應用程序在發生故障前運行的平均時間長度：
MTBF = 小時數/失敗次數
還有一個我們經常用到的指標，即一年中正常運行時間的比率。我們說某個系統的可靠性達到了幾個”9”,指的就是這個，如果系統在一年中失敗了3個小時，那么可以達到：
(1-3/(365*24))=0.9997
大概是三個9。電信網絡一般可以達到5個9，你想想它的失敗率有多低！
提高可靠性是一個復雜的系統工程，涉及到硬件、操作系統、運行平臺、開發人員和操作人員的培訓等等，因為有人為和環境因素，要一個系統達到100%的可靠性是不可能的。可靠性與其他特征緊密相關，如安全、性能、擴展性等，安全性不強，任何人都可以進去搗亂，你還有什么可靠性？
提高可靠性需要考慮成本，不能一味地去追求。對于我們開發者來說，除了盡可能的優化你的代碼外，還需要進行如下的考慮：
數據冗余，主要就是備份，包括各種冷、熱備份。備份已經是企業軟件系統不可缺少的措施，有條件的還需要異地備份，來防止自然災害等。美國的911襲擊過后，世貿中心里的一些金融機構可以馬上恢復業務，主要就是他們的完善的異地備份措施。
服務冗余，集群具有容錯性，在集群中，同樣的服務可以由多臺服務器實現，每臺服務器的硬件和軟件配合提供同樣的服務（特別是軟件）。當一臺服務器因為某種原因而崩潰后，一個監測機制會及時發現失敗的機器，迅速用另外的機器來接管它的工作。從而保證業務正常進行，這個過程就是故障轉移。
圖3 用集群的故障轉移技術
圖4的第一臺服務器 (Database01) 是處理所有事務的活動服務器。 僅當 Database01 發生故障時，處于空閑狀態的第二臺服務器 (Database02) 才會處理事務。 集群將一個虛擬 IP 地址和主機名 (Database10) 在客戶端和應用程序所使用的網絡上公開。
事務，提高可靠性的一種典型方法，在對數據進行一組連續操作時，為了防止意外，如中間的某個步驟出現錯誤，某個操作不能運行，甚至系統癱瘓、網絡突然斷掉等，我們就要使用事務。事務保證了數據的正確性、完整性、一致性，從而提高了可靠性。
重試機制，當一次操作失敗后，會重復運行命令，重試次數可以設置，如果最后仍然失敗后，可以給管理員發出警告。通常用在后臺程序、異步執行等情況下。
減少計劃內停機時間。比如要把數據庫連接字符串放到一個文件中動態讀取，才能不至于當數據庫有變動時重啟系統。
要有錯誤日志，系統出錯后能迅速發現，迅速改正，使故障時間達到最小。
一個增強可靠性的例子是ASP.net中的會話狀態存儲。Asp.net提供了幾種存儲會話狀態的機制：
1. 進程內模式，會話狀態存儲在進程內，一旦Web服務器失敗，狀態將丟失。
2. 狀態服務器模式，會話狀態存儲可以存儲在另外的服務器上，一旦Web服務器失敗，狀態將不會丟失。
3. SQL Server 模式，會話狀態竟然可以存儲在SQL Server服務器中。
選擇后兩種模式的應用軟件，很明顯就可以增強它的可靠性。
安全性
如果你自己寫了一個好玩的游戲，并且放到自己攢的電腦在家里玩，你的電腦沒有聯網，這是幾年前我們做過的事情，那個時候，我們根本不用考慮安全性，不用為它寫一行代碼。而當今的企業應用系統基本上都是網絡系統，若干用戶從網絡上訪問系統，得到他們所需要的計算結果，安全性考慮隨著網絡因素空前的被重視。
應用程序的安全性受很多因素的影響，如網絡、操作系統、軟件運行平臺，你需要進行綜合的考慮，要進行各個因素的分析和針對的應對措施，我們開發人員要干什么呢？我們應該多了解一些知識，在其他配置完備的情況下，如數據庫備份，操作系統設置，防火墻設置等后，根據系統對數據的安全性要求選用一些技術，如SSL、VPN等，盡量利用軟件運行平臺的安全設置，如Net平臺提供了很多的安全性設置，選擇平臺提供的驗證模式，而不要自己去寫一套驗證的代碼。
初學者還要了解如下的幾點：
數據的加密,一些重要的數據，用戶的密碼都應該加密，尤其是密碼，可以用不可逆算法加密。請不要寫自己的加密代碼，無論你覺得寫的多么好，在黑客的攻擊下完全沒有作用，徒增笑料而已。一般我們要使用成熟的、已經實現好的加密API,這些在Net和Java類庫中都存在。
不信任用戶的輸入，這點初學者尤其要注意，要過濾掉一些特殊的字符，這里順便說一下我剛開始寫代碼犯的一個典型的錯誤，它是初學者容易犯的錯誤：登錄。我們看這個語句
Select * from User where name=’aa’ and password=’11’
其中”aa”,”11”是登錄窗體用戶名和密碼兩個文本框輸入的數據，假如用戶在密碼框中輸入：1’ or ‘1’=’1
則上面的SQL語句變為：
Select * from User where name=’aa’ and password=’1’ or ‘1’=’1’
結果是什么？無論用戶名輸入的是什么，他都可以通過驗證！
使用最小授權原則。給用戶和代碼最低的資源訪問權限，初學者最容易犯的毛病是SQL Server數據庫連接字符串中用的是”sa”，要知道sa的權限有多大？你敢用嗎？
我們還舉上面的例子，假如有個聰明的人輸入了：1’ drop table user，天哪，你的用戶信息被清空了！假如你用的不是sa，而是一個沒有刪除權限的用戶，那起碼可以避免這樣的攻擊。
應用分層。相當于設立幾個隔離層，你攻破web服務器，但后面還有應用服務器，最后面有數據庫服務器，層與層之間設立嚴格的權限認證。從一層到下一層的通信應只通過特定信道來進行。每一層都為攻擊者進入添加一道額外的屏障。電子政務系統所要求的內網和外網分離，也是基于這個思路。
可用性
可用性在有的地方定義為：一個系統可以為用戶所使用時間的百分比，即正常運行時間的百分比。我這里說的可用性和它不太一致，這里的可用性主要在用戶體驗方面。可用性當然和其他的特征，如可靠性、安全、性能聯系非常緊密，也可以說包含所有的其他特征，這些都會在用戶使用中體現出來。
為什么現在對可用性越來越重視呢，在我看來，可用性是以用戶為中心來考慮問題的，我們去問用戶：這個軟件用的怎么樣？他們或者滿意的回答：好，或者會給你一大堆抱怨。我們當然希望得到一個簡單的“好“字，但這個”好“字卻得來不易，它一般包含如下的要求：
l 系統不出錯；
l 系統運行穩定；
l 操作簡單、實用、功能全面；
l 容易上手，不要讓我一直打求助電話麻煩你。
后面兩點尤其要引起我們注意，經常有朋友說工作煩死了、煩死了，其實是因為這個系統的可用性不高，所以客戶天天找你麻煩，你難道以為客戶無聊找你嗎？為了減少售后服務成本，使我們的軟件利潤不至于消耗殆盡，我們應該重視可用性。
提高可用性，需要從開始就要以用戶為中心，及早了解用戶的需求，從設計到測試，從界面到功能，都盡可能考慮到用戶，或者讓用戶來參與。下面是比較常用的做法：
人性化、標準化，比如一個良好的、模塊化的工作界面，不搞一套花哨、另類的界面以致用戶找個菜單要找半天，界面元素一般有標準化的Window風格，你需要盡量用標準化元素。初學者往往在這里做的很差，比如隨便寫一個窗體，窗體標題沒有設置；一個表單上的表單元素很不整齊，這些是事情看來很小，但卻是一個優秀系統不可缺少的，能盡早養成這樣的習慣，對以后有很大好處的。
用戶友好的消息，記住一些錯誤、警告消息要包裝成用戶理解的語言，不要出現一大堆技術消息。當用戶操作成功時，請不要畫蛇添足的去告訴用戶：操作成功，只在錯誤發生時提示用戶。
“推”信息，不要讓用戶去查找，要把下一步的操作自動的推到用戶面前。比如很多系統的“待辦事宜”功能，比如很多郵件通知服務。如果你把這點做到，那就有點專業的味道了，呵呵。
自定義信息，不要自以為是，要讓用戶來決定，比如查詢，要讓用戶來選擇查詢條件，讓用戶來對數據進行他們想要的過濾和排序。
向導機制，對于復雜的操作，需要幾個步驟，你可以做個向導來引導用戶，這樣會深得用戶的歡心。在一些大型的針對大眾的商業網站，經常有這樣例子，我們也可以應用到企業應用系統中。
另外我們說說關于用戶習慣方面的事情，你不去現場是考慮不到他們的做法的，我印象深刻的一個教訓是剛參加工作寫一個增加記錄的表單，用戶在按“增加”按鈕出來一個表單頁面，我在表單頁面執行的開始生成一個ID ，用戶填寫完畢后按“保存”按鈕，把記錄保存到數據庫中，誰曾想軟件使用的第一天就出現麻煩，原來用戶按“保存”按鈕保存完畢后，添加第二筆記錄時，并不是再按“增加”按鈕，而是按IE的“后退”按鈕，重用剛才的“過期”頁面進行操作（他們倒也懂重用），這樣不出錯才怪呢！
伸縮性
可伸縮性就是通過增加資源使服務容量產生線性（理想情況下）增長的能力，也就是說，當你的業務發展一日千里，用戶每天都在增加，訪問量每天都在破記錄時，伸縮性好的系統只需要增加幾臺服務器，或者換一臺性能更高的服務器即可，而不用讓程序員來修改代碼！
伸縮性和性能密切相關，提高伸縮性，實質就是在負載增加的時候使性能不下降。對于伸縮性，我們采取的措施一般有：
負載平衡技術，這是一個經典的提高伸縮性技術。利用服務器群和負載平衡(Load Balancing)技術,當負載增加的時候，我們增加幾臺機器，進行適當配置后，負載平衡會自動把一部分計算任務遷移到新的機器上，從而使性能保持。
圖4 負載平衡
這將得到一個標準的負載平衡設計。硬件設備或運行在主機上的軟件將虛擬主機名 (AppServer20) 和 IP 地址分配給 AppServer1、AppServer2 和 AppServer3。負載平衡的群集向網絡公開此虛擬 IP 地址和主機名，并在組內的正常運行服務器之間均衡地分配傳入請求的負載。如果 AppServer1 出現故障，則只需將請求定向到 AppServer2 或 AppServer3 即可。取決于提供此功能的技術，可以將一定數目的額外服務器添加到負載平衡的群集中，以最大限度地提高可伸縮性，并超前滿足不斷增長的需求。
負載平衡技術和故障轉移技術很相似，強調的是兩個不同的方面，一般會結合起來使用。
隔離事務性方法，盡量使事務性方法和非事務性方法分開，因為事務的整個運行過程都需要系統開銷。事務一般由容器實現(如EJB服務器或者com+)，你如果標示你的組件需要事務，而把一個非事務的方法也放進去，顯然是愚蠢的。
盡量使組件無狀態，保持狀態需要耗用資源，多一個用戶訪問，就需要消耗一點內存。所以你需要少用Session，少用有狀態的ejb。
“池”的技術。同提高性能的緩存是一樣的道理，池中的對象可以為任何客戶端所使用，你可以設置池中對象的最大值和最小值。池中的對象也需要仔細的設計和權衡，如池中的對象一般會頻繁使用，而且對象的創建時間長、使用時間短；對象不允許保存客戶端狀態。Windows平臺上的Com+就提供了一個很好的對象池基礎服務。這里你只要進行一些簡單的設置，就能建立自己的對象池，而且利用com+管理窗口，我們還獲得了很好的管理性。下圖是在com+中配置對象池的一個窗口：
圖5 在com+中配置對象池
異步和消息隊列，如果一個動作需要很長時間運行，可以用異步調用，或者用消息隊列技術，而這個用戶會話也可以立即返回。只有那些用戶并不需要立即看到結果的操作才可以設置為異步，異步執行過程中如果發生錯誤，我們要找一個合適的方式來通知客戶，因為這個時候用戶可能在做其他事情，或者已經離開系統了。是否用異步方式也需要權衡和考慮用戶的需求。
擴展性
擴展性主要針對需求更改頻繁的應用程序，這樣的應用程序，我們開發人員都碰過不少，我們也不去討論是因為需求沒有做好，還是其他的問題，我們可以在其他地方做出自己的努力，比如提高它的擴展性！
我們這里討論的重點不是開發者自己的工作，而是指用戶的二次開發。把開發交給用戶自己！我們豈不省事多了？說起來容易，但做到用戶完全自主去擴展一個系統是很難的，這需要你小心的去設計你的系統，要有足夠的靈活性，預留足夠的接口，這樣才能提高系統的擴展性。
動態編譯，提高擴展性的常用方法，經典例子是微軟的Office系列軟件，你甚至可以用VBA代碼自己寫程序！Office太復雜了，我們說一個簡單的東西：簡易的腳本解釋器。在一些工作流軟件中經常會嵌入這樣一個模塊。因為用戶的流程很復雜，而且經常隨業務發展而改變，我們不可能每次都去為它改寫代碼，所以我們把這些工作交給用戶，讓用戶自己去設計流程！比如原來一個帳單超過1萬元需要總經理審批：
If money>10000 then 發送至總經理
現在公司有錢了，總經理只審批超過或等于5萬元的帳單：
If money>=50000 then 發送至總經理
用戶只要改一個數字和一個邏輯符號，系統會自動的更改這個流程！
松散耦合，提高擴展性要記住一個原則：代碼（或者功能、數據）之間關聯越松散，擴展性、靈活性就越高！你需要經常做一些看起來羅嗦、煩瑣的事情，比如：
l 一個數據表變為兩個數據表；
l 一個類分為兩個類來寫；
l 在兩個模塊間加另外一個模塊來關聯；
l 用事件和消息來關聯。
其實設計模式通篇講的就是這個道理，多走一步會給以后帶來多幾倍的收益。軟件開發我們提倡松耦合，也是這個道理。松散耦合系統保證了以后擴展工作的高效率，提高了客戶進行二次開發的可行性。
配置參數，不要寫死到代碼里，要寫到一個配置文件中，目前多數系統都用一個一定格式的xml文件做配置文件，配置的數據可以是數據庫連接字符串，可以是資源變量，甚至可以是組件的位置和名字，在運行中用另外的組件來代替現在運行的組件，這就是軟件的熱插拔。著名的ERP軟件SAP功能完備的一個原因就是它強大的參數配置模塊。
Web服務，提供web服務接口，能極大的提高系統的擴展性，用戶可以用自己的技術和編程語言來為系統擴展功能，使系統能夠和其他應用系統交互，完成一些原先沒有的功能。
管理性
你還記得微軟公司的那則廣告嗎：”一個人在兩個小時內可以升級200臺機器”，說的就是Windows 2003 server的易管理性，軟件部署后，在運行期間，可能需要對它進行管理，如升級、打包、配置更改、遷移等。一個成熟的企業軟件，需要有很好的管理性。管理一個企業應用程序是這個程序的總成本中相當重要部分。現在企業軟件也越來越重視軟件的部署、配置、升級、監視等過程。
現在軟件技術，如Java和.net平臺為我們解決了很多的基礎問題，如部署和升級，都可以不用注冊，直接拷貝，.net還提供了很好的版本管理策略。這些都讓我們開發者歡喜不已。很多人覺得J2EE部署和配置還是很復雜，我們期待J2EE產品商能進一步提高他們產品的管理性。
我們除了了解我們軟件運行平臺提供的功能，并正確的運用外，自己在開發軟件也可以為減少管理員工作而做出自己的努力！比如：
管理模塊，需要和業務系統模塊分開，單獨做一個管理模塊，用戶可以在這里直接配置數據。管理模塊只有管理員可以進去，這樣避免了每次更改配置需要跑到機房的麻煩，但也要注意需要極高的安全性設置。
移植性，系統遷移的容易程度，除了你的運行平臺為你提供之外，你還需要在開發中注意移植性。比如在Web系統開發中，請用相對路徑，所有與周圍資源相關的代碼和設置請放到一個配置文件中。這是一個基本的技巧，比如在Asp.net中的web.config中，你可以進行大量的這樣的配置。
補丁管理，尤其對于C/S系統，每臺客戶機都跑去打補丁無疑是一場惡夢。對于補丁更新的方便性，我們開始就要考慮好方案，讓補丁能夠自動下載和安裝，而不影響程序的運行，這是最完美的。
系統監視功能，監視系統的運行情況，提煉出有用的數據，從而為管理提供幫助。
提醒和報警，使用郵件或者其他提醒方式，使管理員更快的掌握系統運行情況，通常在重要的事件發生后，寫一個郵件發送程序，把事件信息發送到管理員郵箱中。
企業應用系統開發中的權衡
因為企業軟件范圍很廣，有不同的用途，有不同的考慮和重點，所以某個企業軟件不一定滿足所有以上特征的要求，而只強調其中幾個方面。比如一個面向個人的通用的產品，如Office方面的軟件，就要在可用性方面下工夫，而在伸縮性方面就可以不太考慮。但如果是一個大型的商業網站，隨著用戶的逐步增加，他就必須有很高的伸縮性，而且還要有極高的安全性。
達到某些方面的要求是需要付出成本的，而且可能與其他方面的要求相矛盾。例如我們要提高可伸縮性，可以用集群，但集群是一個相對復雜的技術，需要復雜的部署的管理，這就和提高管理性相矛盾。易管理性就是越簡單越好，最好是把東西拷貝到客戶那里，馬上就OK了，也就是我們說的”交鑰匙”工程，但一般的大型的系統是達不到這樣的要求的，否則，也就不用雇傭系統管理員了！我們需要怎樣來設計軟件，這就需要權衡的藝術，軟件的設計，相當程度上都是一種權衡的結果，你可以想想，如果沒有權衡，軟件還需要設計嗎？
企業應用系統發展的趨勢
隨著互聯網應用的逐漸普及，企業、政府業務的信息化，電子商務的快速發展，用戶對軟件系統的要求也在不斷的提高，我們這里討論三點：互聯，可訪問性和智能化。
互聯
原來單機上的一個應用，原來解決一塊獨立業務的應用系統被應用系統互聯、應用系統集成所代替，而且范圍也從一個部門、一個企業到整個產業鏈，到與政府的信息互聯，比如可以分為企業對雇員(B2E)、企業對企業(B2B) 和企業對客戶(B2C)等應用。
用戶不想讓原有的投資打了水漂，他們不想重新開發一個大而全的系統，更要命的是，很可能原來的每個應用系統都建立在不同的平臺之上，它們是“異構”的。企業應用集成（Enterprise Application Integration，EAI）就是應對這些挑戰而發展而來的熱門技術。EAI深得企業用戶的歡心，就在于它很好的考慮了用戶的利益。
現在很熱的Web服務技術，就是一種很好的互聯技術。Java平臺上的JCA(J2EE Connector Architecture)架構也是為了應用系統之間集成而做的一個技術標準。EAI雖然比較復雜，但是我們在開始工作的時候經常會碰到一些情況，比如用戶在這個系統把一些數據輸入，還需要在另外的系統中再輸入一遍，其實用戶最反感這種工作，我們就可以抓住這種機會來實踐自己的EAI了！
可訪問性
應用系統是互聯了，可如此眾多的系統，使用它們就不是一項簡單的工作了。我為了某項工作要進幾個系統，為了達到一個報表，要進行多次的數據搜集，用戶就又提出要求了：能不能讓我更容易的訪問它們，更簡便的使用它們呢？有！那就是現在同樣熱門的“門戶”概念。
門戶對公司內所有應用系統提供一個統一的認證和操作平臺，它的后面一般都是各個應用系統之間已經有效的集成了，用戶可以在這個平臺上操作自己所需要做的全部工作，不用再登錄到每個應用系統上做了，甚至還可以把這個平臺按照自己的意愿改變它的界面風格！而且客戶端可以是瀏覽器，也可以是手持設備等。公司可以規定員工可以使用哪些內容和應用程序，并可以根據員工的職位定制這些內容
智能
商務智能（Business Intelligence），是現在正在興起一個熱門領域，有人說，商務智能是IT應用系統的歷史終結者。其實商務智能是企業軟件自然發展的必然結果，從簡單的數據整理，到結合企業業務的各種應用，再到目前的智能決策支持，用戶不斷增長的需求，已經使企業級軟件歷經了三個階段的演化。
用戶希望軟件系統為他們整理出有用的數據和統計報表，幫助企業管理者決策，并且可以利用工作流技術，重新設計他們的流程，優化他們的管理，利用軟件技術，使更多的手工勞動交給軟件系統。
常見的一個商務智能技術是數據挖掘，SQL Server里包含了這項服務，它可以幫助公司篩選大數據集，借以發現隱藏的變化模式，對未來商業趨勢做出有價值的預測。
我們的修煉之路
上面我們談了企業軟件的特征、企業應用的發展趨勢，以及初學者在開始開發中的一些失誤，其實這都是一些經驗之談，提出來希望能給初學者的一些幫助，但修煉主要還要靠自己，別人永遠代替不了你！
我覺得修煉過程要注意如下的幾點
1. 開始就要建立以用戶為中心，站在用戶的角度看問題的習慣，不能鉆到某個技術深層去花費太多的時間，你的技術再深也不大可能超過學術界那幫人的水平！對于每一項技術，尤其是你第一次接觸時，你要問一下，它要解決什么問題？為什么會出現這項技術？很多時候你會一通百通、豁然開朗的。
2. 盡快讓自己成為專業人員，建立一個“工程”的思維，不要被一些小家子氣的成就感長久的占據你的頭腦，要知道，你的成就感應該來自于客戶的贊揚和傳頌！
最后是提倡多看看一些現成的企業級軟件的案例（寵物店），多研究一下它們，它們為什么要這樣去寫？為什么那么的繁雜？開始看不懂也沒關系，因為它們很多是為了技術的demo的，不要讓這些干擾你，你看的是他的設計和架構，以及思維。