實施敏捷方法和設計企業架構之間似乎總是存在某種衝突。
從表面上看，敏捷開發強調隨著對業務領域的深入理解，逐步調整設計和計畫。
架構設計則要求建立起技術架構（technology stack）。它可以滿足質量屬性（quality attributes），也可以向感興趣的利益關係人進行展示，作為一種溝通的途徑。
通俗來舉個例子，出去旅遊，敏捷開發則是走一步看一步，看到哪好玩就去哪玩，而架構則是先考慮好各種因素，選擇一條最優的路線出行。
然而敏捷開發是一種軟體過程方法和工具，敏捷開發本身並不能代表架構設計。這就好比建築架構設計和建築工程管理之間的差別一樣，兩者是建築的兩個方面。相同的軟體行業也是類似的情況，軟體架構設計描述的是事物本身，而敏捷開發描述的是建立這個事物的過程。所以敏捷開發和架構是沒有直接替代關係的兩個範疇。
敏捷開發方法試圖改善軟體開發過程，使得我們可以更頻繁地、更快地交付有效的解決方案。然而，儘管存在著一些成功案例，大型企業和專案在採納敏捷上還是非常緩慢。其中乙個原因是，很多敏捷方法被認為在架構方面比較弱，與複雜企業環境中交付大型系統的現實完全脫節。同時，許多架構流程被視為緩慢、笨拙和官僚。他們將從乙個更敏捷的方法中受益。本**通過把敏捷帶給架構和把架構帶入敏捷，來找出解決這一困境的方法。該**討論了敏捷架構師的角色和一些敏捷架構的原則。
停下來想一想，架構只是一種知識的表達方式。軟體開發作為一項知識性工作，需要學習技術、學習客戶需求，學習和提出產品需求的人交流，學習從設計實踐中選取最佳方案，學習合作等等。總而言之，知識源自學習，學習需要時間，而時間正是過程的組成元素。
無論是整個產品開發還是簡單發布，開始時知識最少，也最無知。牢記一點，提前做完所有的重大決策的做法既不明智也不負責。另一方面，專案結束時知識積累最豐富，但踐行機會卻所剩無幾。一言以蔽，架構希望從過程中得到學習的空間和時間，這就要求開始時不能像結束時那樣蓋棺定論。也可以說它是一種經驗性活動，其中的每項決策都應視為假設，加以驗證並使之影響下乙個決策。
敏捷的要素是響應性、不斷學習和充分。敏捷表現為軟體及其開發過程的可持續和高質量，非持續的低質量開發有悖於敏捷。敏捷宣言中寫道「對卓越技術和良好設計的持續關注有益於敏捷」，這為架構指明了敏捷開發中扮演的角色——無需大量預先設計。
敏捷開發後軟體架構設計的方式產生了變化：敏捷開發把原先軟體過程前期的架構設計，分散到了整個敏捷開發軟體過程中。
敏捷開發中架構設計的內容
傳統的架構設計，包括架構和設計兩個方面、其中設計可以包含詳細設計，如詳細的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）重要模組，和重要類的說明。但無需設計全部的類，和類的方法。
架構和框架的關係
架構 框架 模式是一種從大到小的關係，也是一種組合關係。架構一般針對乙個行業或一類應用，是技術和應用完美的結合。框架因為比較小，很多表現為中介軟體，框架一般是從技術角度解決同類問題，例如j道資料增刪改查框架就解決了所有資料庫系統中大量資料增刪改查的功能開發，框架是從技術的橫切面去解決實際應用問題。模...
如何敏捷架構
架構和設計是對需求的回應。某位大神曾經說過，超前架構和設計 big design upfront 的問題是將導致浪費很多功夫 一項行業統計 35 的需求會產生變更，且其中超過一半的變更，實際上都用不上。在scrum實踐中，我們因需進行架構設計。那些驅動著架構設計的非功能性需求通常也有比較高的價值，絕...
敏捷開發和微服務架構
一 敏捷開發agile development 極限程式設計xp和scrum scrum 三個主要角色 1.po product owner 產品負責人 制定需求 確定需求優先順序 2.sm scrum master 流程管理員 確定人員 確定時間 組織會議 3.member 團隊成員 5 10為宜...