那麽架構設計說明書怎麽寫呢？本手冊應包含哪些內容？我們知道，架構設計規範描述了系統架構的具體內容。根據我之前的文章《我的架構觀——架構的未來發展》，我們理解架構的本質是呈現三大能力:系統如何為最終用戶提供支撐能力，如何為外部系統提供交互能力，如何為企業數據提供處理能力。因此，從這個角度來看，架構設計手冊的章節設置和章節內容安排應該能夠清晰地說明系統架構是如何呈現這三種能力的。讓我們逐壹分析:
系統如何為最終用戶提供支持能力？這是從系統自身能力的角度，即系統應該具備哪些功能，如何相互配合才能滿足支撐終端用戶的需求。其實就是要講系統的功能架構或者邏輯架構，回答系統從功能粒度上劃分為多少個功能模塊或者子系統，各個模塊或者子系統之間的內部接口關系如何等問題。當然，還有壹個問題需要考慮。在縱向維度上，隨著架構設計理念的不斷發展，邏輯架構模型從最初的顯示-數據兩層模型，到顯示-邏輯-數據三層模型(即所謂的MVC)，甚至到顯示-調用接口-邏輯-數據接口-數據五層模型，在不同層面上展現了系統內部設計的精細程度。因此，有必要根據實際情況將這種分層設計添加到邏輯架構設計中。特別是對於瀏覽器/服務器架構模式的MIS系統，這個層次更為常見。此外，用戶對系統相對於機器所提供的能力有個人偏好，這就要求系統不僅能提供支持，而且更加穩定、方便、靈活、快捷，這就需要在架構設計規範中加入所謂的非功能性設計，即描述系統的性能、高可用性、可擴展性、可維護性、安全性和可移植性。
系統如何為外部系統提供交互能力？這就是把系統看作壹個完整的整體，說明它與外部系統是如何產生調用關系的，外部系統為它提供了哪些開放接口，它為外部系統提供了哪些對外接口和能力。同時在這種相互調用關系中，處於整個it架構的位置，實際上就是系統的整體架構。另外，如果我們把操作系統和硬件服務器看作壹種特殊的外部系統，我們需要解釋系統如何基於操作系統使用硬件服務器提供計算、存儲、網絡等能力，以及系統如何把自己拆分成不同的部分部署在服務器上。這實際上是部署架構。
如何為企業數據提供處理能力:信息系統最初的驅動力是人們需要利用計算機強大的計算能力來輔助處理大量數據，從而形成可理解的信息，最終形成掌握的知識。所以數據處理是系統的根本目的，非常重要。在架構設計規範中，需要單獨描述系統的數據處理能力，也就是我們所說的系統數據架構。這個還是可以從外在和內在兩個角度來看的。對外，需要說明本系統處理的數據在整個企業數據流中的位置，與相關上下遊數據的關系，本系統需要從數據上遊的外部系統獲取哪些數據？需要為數據下遊的系統提供什麽數據；對內需要說明哪些關鍵數據表是系統根據業務需求設計的，它們之間是什麽樣的主鍵和外鍵關系，是否需要從外部導入數據來初始化系統。當然還有對數據管理的描述，包括如何做數據冗余設計，備份機制，數據安全管理機制等等。
？？好了，分析完這三種能力，我們差不多就找到了架構設計規範中應該包含的內容，包括總體架構、邏輯架構、數據架構、部署架構、內外接口、非功能性設計等。如果建築設計是純粹的理論學習，這些就夠了。但是現實中我們編寫的架構設計規範是用來指導我們後續的系統開發的，需要真正的實現，那麽會用什麽樣的技術來實現呢？有哪些關鍵技術？使用了哪些成熟或開源的技術組件？以前有哪些技術成果被重用？等等，還包括對技術風險和防範措施的考慮。這些都是技術架構的內容。
綜上所述，我們可以得到壹個完整的架構設計規範結構和應該包括的內容，壹般章節應該是這樣的:
文檔概述:包括項目背景、項目目標、文檔版本信息、目標讀者、參考文檔、名詞解釋等壹般文檔中常見的章節；
總體架構:主要從整個it層描述系統的位置以及與周圍關聯系統的調用關系；
邏輯架構:系統內部功能模塊的劃分，各模塊功能的介紹以及相互之間關系的表達；
接口設計:包括系統之間的接口設計和內部功能模塊之間的接口設計；
數據架構:系統與上下遊系統之間的數據流關系，以及系統的關鍵數據表設計和數據管理策略；
技術架構:實現這個架構需要哪些技術能力、復用能力和風險；
部署架構:系統如何部署，網絡拓撲中有什麽要求，對硬件服務器有什麽要求，需要多少臺服務器，是否需要優化服務器參數；
非功能性設計:性能、高可用性、可伸縮性、可維護性、安全性、可移植性等。
其他說明:如特殊約束、風險考慮、進度要求、政策限制、環境影響等。