實施敏捷方法和設計企業架構之間彷佛老是存在某種衝突。數據庫
從表面上看，敏捷開發強調隨着對業務領域的深刻理解，逐步調整設計和計劃。數據結構
架構設計則要求創建起技術架構（technology stack）。它能夠知足質量屬性（quality attributes），也能夠向感興趣的利益關係人進行展現，做爲一種溝通的途徑。架構
通俗來舉個例子，出去旅遊，敏捷開發則是走一步看一步，看到哪好玩就去哪玩，而架構則是先考慮好各類因素，選擇一條最優的路線出行。工具
然而敏捷開發是一種軟件過程方法和工具，敏捷開發自己並不能表明架構設計。這就比如建築架構設計和建築工程管理之間的差異同樣，二者是建築的兩個方面。相同的軟件行業也是相似的狀況，軟件架構設計描述的是事物自己，而敏捷開發描述的是建立這個事物的過程。因此敏捷開發和架構是沒有直接替代關係的兩個範疇。學習
敏捷 Architect網站也給出了一些具體的建議：網站
敏捷開發方法試圖改善軟件開發過程，使得咱們能夠更頻繁地、更快地交付有效的解決方案。然而，儘管存在着一些成功案例，大型企業和項目在採納敏捷上仍是很是緩慢。其中一個緣由是，不少敏捷方法被認爲在架構方面比較弱，與複雜企業環境中交付大型系統的現實徹底脫節。同時，許多架構流程被視爲緩慢、笨拙和官僚。他們將從一個更敏捷的方法中受益。本網站經過把敏捷帶給架構和把架構帶入敏捷，來找出解決這一困境的方法。
該網站討論了敏捷架構師的角色和一些敏捷架構的原則。編碼
停下來想想，架構只是一種知識的表達方式。軟件開發做爲一項知識性工做，須要學習技術、學習客戶需求，學習和提出產品需求的人交流，學習從設計實踐中選取最佳方案，學習合做等等。總而言之，知識源自學習，學習須要時間，而時間正是過程的組成元素。架構設計
不管是整個產品開發仍是簡單發佈，開始時知識最少，也最無知。牢記一點，提早作完全部的重大決策的作法既不明智也不負責。另外一方面，項目結束時知識積累最豐富，但踐行機會卻所剩無幾。一言以蔽，架構但願從過程當中獲得學習的空間和時間，這就要求開始時不能像結束時那樣蓋棺定論。也能夠說它是一種經驗性活動，其中的每項決策都應視爲假設，加以驗證並使之影響下一個決策。設計
敏捷的要素是響應性、不斷學習和充分。敏捷表現爲軟件及其開發過程的可持續和高質量，非持續的低質量開發有悖于敏捷。敏捷宣言中寫道「對卓越技術和良好設計的持續關注有益於敏捷」，這爲架構指明瞭敏捷開發中扮演的角色——無需大量預先設計。code
敏捷開發後軟件架構設計的方式產生了變化：敏捷開發把原先軟件過程前期的架構設計，分散到了整個敏捷開發軟件過程當中。
敏捷開發中架構設計的內容
傳統的架構設計，包括架構和設計兩個方面、其中設計能夠包含詳細設計，如詳細的UML圖（詳細的類圖，順序圖等），詳細的API設計以及接口描述，存儲層數據庫表字段設計等等。
出於下面兩個方面的考慮，敏捷開發不適合這種架構設計內容：
（1）在當今的快速變化的社會中，業務需求和技術也都快速變化着，在軟件過程前期花費30%（甚至更多）的時間進行架構設計，要麼開發出來的軟件不符合市場需求，要麼就是一旦需求變更，形成較大的改動成本。如，做者瞭解的一個電子商務產品，當前所作的功能都是兩年前規劃設計的，並且若有新需求發生，須要下個版本纔會採納，致使整個產品脫離市場和客戶的需求。
（2）架構設計包含兩個方面，一是：架構，二是：設計。其中設計中的詳細設計須要大量的時間，包含詳細的流程，API，數據結構等設計。但軟件開發階段的Code編碼階段，一樣蘊含了不少詳細設計的內容，因此兩者之間存在着Repeat Yourself的狀況。換句話說，如今敏捷開發提倡Code is design，而之前是Design is code。但問題是，軟件開發人員維護一套Design，外加一套Code，不堪重負，效率低。因此，如今是Code is Design盛行，敏捷盛行。
基於這兩種緣由，敏捷中將傳統的架構設計分紅：架構 + 設計：
（1）敏捷開發的架構保留架構部分
（2）轉移設計到Code編碼階段、重構階段、Unit Test階段等。
分離後，敏捷開發中的架構就輕裝上陣，內容能夠包括：
（1）軟件的架構層次，層次化是軟件產品架構中很重要的一部分。
（2）產品和技術選型
（3）各個組件的結構，以及的關係
（4）重要模塊，和重要類的說明。但無需設計所有的類，和類的方法。