在牛津高階詞典（第7版）中，架構（architecture）一詞的解釋是：the design an structure of a computer system。這個解釋實際上已經描述了架構的本質：架構是關于怎么做（構成系統）的，而非做什么的。更進一步，架構是由人來設計實施，因此架構實際上是一個文化（culture）——我們怎么認識或理解系統/產品的，并且我們準備怎么做，在做的過程中我們認為什么是好的，什么是好的等等。

任何系統都有架構，無論多小的系統都有。區別在于其架構是否是經過明確設計并表達。一個合理的架構無疑是經過精心設計和維護的，而進行架構設計，或者說定義/建立一個架構可以分為如下幾個步驟。 

特別的，本文針對于企業應用架構，其他應用未必適用。

基線準備

如果建立第一版架構（即從零開始）可以跳過此步，但對于建立第n版（n>=2）架構，則需要進行基線準備。通常從上一個架構設計開始，去除不在必要的內容作為基線。

非功能性需求的收集、分析和細化

這步驟非常關鍵，本質上架構關注的是系統的非功能性需求，雖然不是系統的全部，但無疑是最重要的20%，而這也是不同公司/產品的架構差異性的根源。

一個完整的非功能性需求列表不僅僅來自業務部門（系統客戶），還需要包括開發/研發管理層以及開發團隊。實踐中可以如下檢查列表來幫助收集：

l         目標應用，企業應用和互聯網應用就不太相同

l         目標環境，系統部署的硬件環境、網絡環境等，更有云計算環境和傳統服務器環境的差異。

l         常見技術指標

n         穩定性/可用性，主要是MTBF和MTBR指標要求

n         性能，如Web應用下單次操作1/5/10原則，相關并發壓力要求等

n         容量，主要是數據容量，此外有時還要考慮內存的限制

n         實時性，涉及到數據同步/復制/消息傳播/異步操作

n         易用性，這個指標不容易衡量

l         系統/項目/產品自身，來自客戶

l         管理指標，主要來自管理層

n         成熟度/培訓招聘成本

n         產品化/定制化

n         組件化

n         領域化

n         標準性

n         平臺化/小型中間件

n         集成性/兼容/遷移能力

涉及遺留系統，關于兼容需要明確的兼容方式和兼容模式。兼容方式包括：語義兼容/源代碼（語言級/API級）兼容/運行時兼容（運行庫/二進制）；兼容模式：向前兼容/向后兼容。

n         1.4.6 容錯性

包括速錯能力和消除易錯機制（error-prone mechanism）

n         1.4.7 升級性

以上列表略顯草根性，實際過程中也可以從架構評估角度反向進行非功能性需求收集，可以參考《Attribute Based Architectural Evaluation》。

一次性完整地收集非功能性需求并不是件容易的事，因此在架構發布后也要不停的進行改進。

架構定義

完成非功能性需求并明確后，就可以進行架構定義了。架構定義可以分為三個部分：設計、選型以及構建和評估。

架構設計

這個階段相對務虛，但卻是整個架構定義的基礎，決定了所有的后續工作。主要包括如下三個工作內容：

l         確定架構手段，包括架構的原則、規范、模式、工具、框架/平臺和語言，以及這些手段的適用范圍，哪些問題應用工具來解決，而另一些問題采用哪個框架/平臺完成，還有一些通過原則或規范處理。

l         確定組織分工和流程，不同的工作通過組織內不同角色完成。

l         確定結構化范圍，區分系統內和系統外，并非所有非功能性需求都是通過系統的手段解決，適當采用系統外手段甚至更簡單和準確。

技術選型/預研

紙面上的架構其約束性和可操作性非常低，為了讓架構從三萬英尺的高空落地有兩種辦法：流程和平臺。其中，流程是由組件分工完成，而平臺構建通常不會從零開始，實踐中會盡可能利用已有成果：商業產品和開源產品。因此技術選型以及預研工作則顯得非常重要。

進行技術選型需要注意兩個關鍵點：

u       評估單項技術的有用性（技術功能）和可用性（非功能性需求，即使用成本）

有用性是指相應的技術功能點是否解決架構所面臨的功能性和非功能性需求；

可用性是指是否滿足整體的非功能性需求，如性能、容量和穩定性。以及管理層關注指標（使用成本），如技術成熟度、標準性、培訓招聘成本以及產品的生命周期，以及License費用等。

u       保持全局視角

關注全局，木桶理論的再次應用，避免某項技術存在的缺陷影響整體。

主要的選型內容如下：

l         語言，不同語言所能提供的開發能力是不同。而且開發語言直接影響到后續技術的選型以及人員的招聘。

l         框架/平臺，提供運行環境和集成環境。

l         工具，古話說：磨刀不誤砍柴工。但要注意避免工具中心論，正確認識工具的用于——工具是幫助我們解決一些臟活累活的，除此外無它。在整個架構中，工具的作用是大大低于語言和框架/平臺。

除去技術選型外，對于一些不確定的內容，還需開展預研工作，驗證其可行性或者進行性能測試。

架構構建和評估

如前所述為了使架構落地，在技術選型后完成后進行架構構建，包括了定制化設計和開發，并進行質量保證。

架構構建的結果通常分為三個層次：

l         集成環境，提供一個開發的腳手架，這個是最低層次。

l         編程模型，提供一個統一的編程模型，包含了自定義框架和類庫，并對底層技術提供了一定封裝和隱藏。當前的趨勢是：提供一個POJO一致性的編程模型。

l         運行平臺，提供了一個運行平臺，（勉強）可以算做一個中間件產品。

架構構建過程中應注意如下內容：

l         應用區分平臺系統和應用開發接口

應用開發接口是給后續產品開發使用，接口一旦設計發布應當保持問題性和兼容性；而平臺系統對后續系統開發不可見，避免兼容設計成本，有利后續升級和變化。

l         簡單的API，強大的功能，類似于高級語言

l         可以擴展的SPI，另一種形式的API

l         消除易錯機制（error-prone mechanism），避免當錯誤使用后的修正成本太高

l         適應變化和二八原則，避免在需求變化時后調整的成本過高

l         隔離具體技術，保持未來的遷移性和可升級性

l         提供調用接口和模型應具備一定抽象性

l         分離關注點，縱向的層次化抽象，以及橫向的模塊與切面

l         提供申明式定義（如XML），由反向解析映射到具體技術，關注于做什么而非怎么做。

架構完成構建后，進入架構評估。

架構評估是確保架構有效性的重要步驟，需要針對所收集到的非功能性需求——工作上形成一個閉環，確保工作的有效性——因為架構涉及系統中最重要的20%，應該盡早驗證，而不是簡單地希望一切都好。

架構評估包括兩個工作：進行驗證和協助。

可以根據非功能性需求列表來制定驗證點，這里列舉下主要的驗證點：

l         技術點驗證

l         性能壓力驗證

l         穩定性驗證

更正規的評估方法可以參考《Attribute Based Architectural Evaluation》。

協助是架構評估的另一項工作。架構不是幾個人關在一個房間里整出來的與世隔絕的東西。需要項目/系統/產品的等相關利益者理解它。這項工作不應是發布幾份文檔宣稱架構如此如此（見后續《架構發布》），它應當在架構評估時進行（雖然可以在架構構建時進行，但是由于此時架構并未成形，此時的效果有限）。

架構發布

當架構構建完成并通過評估，架構就可以正式發布了。

框架/平臺和工具

毫無疑問，框架/平臺和工具是架構發布主要內容之一。

文檔

除去框架框架/平臺和工具，還有其他重要的內容需要發布，文檔無疑必須的。但文檔也存在尷尬的情況，已知的工程實踐中已經發布了太多無用的文檔、過期的文檔。

應努力保證所發布文檔的必要性和有效性，建議文檔如下：

l         架構介紹，可以參考RUP4+1視圖，部署視圖、運行視圖、開發視圖等

l         快速入門

l         開發指南

l         服務配置和使用介紹

示例代碼

完整可用的代碼，運行腳本、注釋。完整豐富的示例代碼在很多時候比文檔更直接，尤其在展示細節問題上。

培訓和指導

很多時候，培訓和指導被忽略了。相對于文檔和示例代碼，培訓和指導更有互動性，可以更深入討論，并可以深入到架構設計背后的故事。

架構改進

如前所述，通常無法一次收集完整地非功能性需求；而隨著時間發展，更新更細節的非功能性需求會不斷的涌現和被發現；還有一部分之前已識別但被暫時擱置的非功能性需求開始變得重要。因此架構需要不斷發展，而此時的改進通常是以小步快跑的方式進行。

下一個周期

不能期望10年前的架構能夠滿足今天的需求（它可能依然可以工作）。架構發布后到一定階段，已經無法通過小的改進滿足新的要求，重新進行架構設計成為一個必然。而當前的架構設計可以轉為下一次設計的基線。

常見的問題

l         試圖創建一個私有的編程模型標準

很少有人這么干，不過有時還遇到這樣的做法。通常在封裝一些商業或開源產品，美名其曰——隔離實現，這是一個危險的做法，其實質是創建一個私有編程模型標準，如果業界沒有紙上標準或實際標準，基于某個產品實現所建立的私有標準無法真正的遷移到別的產品實現；如果有，那就根本不需要建立私有標準。

另有一種封裝，其目的是為了簡化商業或開源產品，這種封裝不打算屏蔽底層的實現——它只是讓工作更簡單。

如果一定要創建一個編程模型的話，應該是POJO。

l         不那么正確的二八原理

二八原理通常很有效，然而它有缺陷——他是基于統計的，這意味著是事后應對。如果沒有已有實踐經驗，那么在一開始很難做出正確判斷。

而一旦做出錯誤的決策導致的問題，很可能出現“玻璃裂紋”現象——不斷的擴散并破壞架構設計——直到玻璃碎掉。

更槽糕的是，很多時候所謂的二八劃分，基于的是感覺而非統計。

l         過分關注在技術模型上

雖然架構針對的非功能性需求，關注在技術模型沒有問題，但是實際上更應關注的是信息模型。而在多數情況下，信息模型是以層的形式來表示。

這里面最典型的是所謂的N層（n-tier）模型，實際上，N層（n-tier）模型就是一個技術模型，描述的一個分布式系統結構。

而真正的N層（n-layer）設計卻被忽視，分層Layer模式才是一個架構模式（見POSA vol1），ISO-7層網絡協議是一個典型示例。