1引言
有一名專業的規劃師（Jack）說過，一名工程師的20%時間應該用於做規劃。隨著我們經驗的增加，對這一論斷的相信程度也在增加。通過規劃來很好的組織工作，生產率和效率都會得到極大的提高。不幸的是很多公司機構都試圖把過多的規劃活動形式化。規劃在由個人來推動和利用時最有效，時間管理專家的一個減少壓力的關鍵要素就是通過規劃讓生活中的各項活動保持均衡。隨著這種實踐活動的成熟，時間國立系統的形式和使用方法越來越個人化了。
2實現主體架構
本反模式的特點是開發中的系統缺乏架構規范。一般負責項目的架構師都有以前系統
架構經驗，因此認為文檔是不必要的。這種過度的自行導致在影響到系統成功的關鍵區域中風險劇增。比如下面某些區域往往會缺失架構定義：
1)包括對語言和庫的使用、編碼標准、內存管理等在呢你的軟件架構和規范。
2)包括客戶端和服務器配置的硬件架構。
3)包括網絡協議和設備的通信架構。
4)包括數據庫和文件處理機制的持久性架構。
5)包括線程模型和信任系統集的應用安全架構。
6)系統管理架構。
3帶來的後果
1)缺乏架構規劃和規范：對軟件、硬件、通信、持久性、安全和系統管理架構的定義不足。
2)由規模、領域知識、技術和復雜性導致的隱藏風險隨著項目的進展暴露出來。
3)由於性能不足、過度復雜、需求理解錯誤、可用性問題和其他系統特性導致項目將要失敗或系統不成功。例如；大約1/3的系統在開發和運行中會遇到嚴重的性能問題。
4)不了解新技術。
5)缺乏後備技術和應急計劃。
4產生的原因
1)沒有風險管理。
2)管理人員、架構師或開發人員過於自信。
3)依賴於過去的經驗，而這些經驗與現實在某些關鍵區域有區別。
4)由於系統設計活動中的缺口導致隱含的和未解決的架構問題。
5重構方案
重構方案要求以有組織的方式進行系統定義，並依賴於系統的多個視圖。每個視圖從一個系統利益相關者的角度對系統進行建模，這裡的利益相關者可能是真實的也可能是假象的，可能是個體也可能是一群人的聚合。每個利益相關者負責一組搞優先級的問題，每個視圖都代表了整個系統並回答了這個關鍵的問題。這些視圖包括一些圖、表和規范說明，被連接到一個保證一致性。一般而言，視圖是輕量級的說明。架構文檔的作用是交流架構決策和其他問題的解決方案。文檔因該易於理解，維護成本低廉。
只有完整理解一個架構的人才能夠成功定義實現它。不過，現實往往並不是這樣，因為很多項目采用了一些沒有被很好理解的新技術。因此，從頭開始建立良好的架構是一個迭代式的過程，大家都應該認識到這一點。起初的參考架構應該具備可以在第一個產品的開發期間被實現的強大策略。然後，可以使用將來的參考架構版本以增量的方式精煉他，並使用第一個產品或新版本來驅動這個過程。
具體流程如圖：
