信息化與企業能力

從企業職能分配的角度來看，企業能力包括企業產品開發與設計能力、市場與客戶服務能力、產品與服務提供能力、生產與品質保障能力、供應與物流管理能力、人力資源開發與利用能力、成本管控能力、品牌策劃與運作能力、后勤保障支撐能力等等基礎能力。

圖一 企業職能的分配

這是信息化規劃中，應用架構的關鍵設計依據和指導方向，它給應用架構設計提供了業務架構與IT服務之間直接的對應要求。

應用架構與業務架構之間的支持關系

圖二 三層系統的分層次結構

首先、我們知道業務層是一個系統中最核心的部分，業務層是實現系統業務功能的核心邏輯層。業務邏輯一般是通過分層結構來構建應用系統，在組織業務邏輯功能時大部分的情況下是使用業務層單獨負責相應的業務邏輯來實現的。

其次、很多人認為業務邏輯層并不復雜，可以把問題簡單化，引入一些框架性的東西即可。事實上這種認識與做法會提升系統的復雜度，架構師需要根據業務運轉的邏輯本身來適應性的搭建應用框架。尤其是對規模較大的以及業務邏輯性較強的業務，事先展開周密的業務設計模式給整體企業架構帶來的優越性就顯而易見了。

再者、從單層技術視角來看，業務邏輯層是用來處理領域模型對象之間的邏輯關系。單從整體架構來看，業務層的數據最終是要沉淀到數據庫中形成數據架構，我們在進行業務層設計時一般是在架構中的分層架構模式中出現，但不能忽略與其他幾層架構之間的匹配關系。分層結構的一個優勢是解耦后的靈活性，將領域模型與底層數據訪問、表現層等進行分開組織，這樣可以讓系統結構上清晰，并降低他們之間的強耦合性帶來的不便。

最后、很多架構設計都須最初在業務層完成，比如說用戶的角色權限、數據驗證、業務邏輯初設等一些基本的業務規則。

應用架構支持業務能力構建的關鍵要素

業務架構層面須構建的關鍵要素如下：

全面原則：全面考慮架構設計的專業性要求、業務的拓展性要求以及治理落實要求。以架構開發方法為基礎并按照組織的需要和業務愿景來對架構開發方法所進行定制，并落實到架構治理流程層面。

共識原則：明確業務架構的各類術語，在組織中建立起關于這些內容的共識。

視角原則：明確所有架構實踐所涉及到的企業、業務部門的視角，而針對這些內容的定義工作應由此前被識別出來的架構實踐企業運營級主辦方牽頭業務與IT、供應商協同溝通、展開工作。

規范原則：明確闡述將會由架構實踐所產生的各種架構交付物以及他們之間的交互關系、依賴關系、檢驗關系，同時要說明用于管理這些交付物的設計規則與維護指南。

權責原則：定義清楚架構實踐所涉及到的各種角色，以及為這些角色所分配的關于架構交付物和流程的責任。

度量原則：管理學之父德魯克曾經說過一句名言：“如果你不能測量它，你就不能管理它”。業務架構設計應明確和描述用于與架構實踐愿景和目標進行比對和監督的各項架構實踐性能指標。

治理原則：基于上述內容，系統展現整體架構的治理模式。

應用架構層面須構建的關鍵要素如下：

完整原則：定義應用架構用于立項、需求、開發、設計、維護、上線、維護以及業務支持可擴展性的各種功能。

分域原則：應用架構的構建須要考慮功能區域劃分，一般而言，包括O域(運營域)、B域(業務域)、M域(管理域）,以更明確地指導應用系統的研發建設以及后期的維護方式。但這種區分并不是割裂的而是更為緊密的契合，譬如，恰恰是這種明確的分類使得企業運營活動與業務活動具備了緊密協同的識別基礎，通過整合B域和O域的數據，能夠提升信息共享能力，能夠提升業務洞察能力，出乎意料地通過分域系統建設形成了有數據洞察力的跨域（B域/O域）統一系統架構平臺。靈活原則：對于業務模式、生產模式較為穩定的企業可以考慮企業傳統三層結構，解耦顯示層、業務層、應用層；如果企業應用的復雜度較大，可以從散亂的具象類中明確可繼承的抽象類，考慮在原有三層架構上探索面向企業級的分層架構，這種架構能很好的支持新的技術和代碼上的最佳實踐。

服務原則：應用層具備業務服務解析功能，可強化該層設置以直接隔離顯示層來調用業務層。企業應用的靈活性與結構性平衡不可避免的在借鑒互聯網式的架構解耦融合方式，對業務邏輯的訪問可以不必須在進程內訪問，也可跨越網絡進行訪問。應用層的強設置讓原本顯示層調用業務層的過程變得靈活很多，我們可以添加很多靈活性設置在里面，更為重要的是若顯示層和業務層兩個獨立的層需要完全獨立，那么必須要有一個層來輔助和協調層級之間互動，那就是被強化后的應用層。

接口原則：模塊內部則可以由負責的開發人員自行設計，但不同模塊的通訊接口應該由團隊成員共同負責，一旦接口變化，接口實現成員應該提供相應的實現原型，并通過變更審批后方可執行變更。

對接原則：應用層不僅應包含業務服務定義，還應還包含IT服務的應用邏輯調用，比如：記錄LOG，協調基礎設施的接入等。應用層可負責整體的協調“業務層”和“數據層”甚至“基礎設施層”。

圖三 應用架構層面須構建的關鍵要素

“你的用戶并不關心架構的問題，他們只關心你的應用是否好用”，所以架構師決不能忘記從企業運營視角以及業務視角共同檢討系統架構的設計，當這個時代的企業價值鏈條越來越迥異于以前的被動任務導向的價值鏈驅動時，應用架構支持業務能力的答案不在功能說明書里、不在閉門造車的標準化產品線里、不在強專業導向弱服務導向的專家式自負里，而在應用架構對業務的服務里，在我們對企業需要、業務需要的客戶化服務里，在我們幫助客戶承擔成本、風險、思慮如何實現的煩惱里，當客戶感覺不到架構的存在時，這才是對架構師最完美的評價！