本文旨在探討解決方案架構設計過程的方法，原則與邏輯思想以及根據經驗提煉出的一套解決方案架構的方法。
這是我前一段時間幫公司面試解決方案架構師時的感慨。跟幾位 10+ 年經驗的技術軟件架構師面試下來，感覺技術能力都很過關, 尤其是對新技術，能從架構師的角度思考問題，對架構設計有成體系的理解與輸出。
但是，當我在圍繞着一些比較宏觀靈活的解決方案架構方法與思維上的問題時，比如：
-
跨領域發展的解決方案架構設計方法與模型
-
從模糊的商業問題或抽象的業務願景落到解決方案的方式
-
如何治理解決方案架構設計，從抽象到具體的思路
我發現，多數人停留在“技術架構，或軟件架構的層面。少有能做到“開放性思維”，能從商業問題的本身出發， 帶領團隊讓“理真的越辯越明”。
爲什麼會這樣？原因在哪裏？
結合自己從工程師到企業架構師的經歷，主要的原因是：構架師在解決跨領域複雜問題是的方法真的不多。這主要是因爲大多數的架構師都是技術出身，他們解決問題的思維與方法主要來自之前技術領域的積累。
大多數架構師的思維模式是”專家模式“. 這種思維模式是習慣於把已熟悉的 " 解決方案 "(比如: 微服務等) 對接商業問題.。這種單一視角就類似查理·芒格說的：手裏拿着錘子的人，眼中滿世界都是釘子。
本文旨在探討解決方案架構設計過程的方法，原則與邏輯思想以及我將分享根據過去的經驗提煉出的一套解決方案架構的方法。
該方法曾在我工作過的世界 500 強公司，國際 4 大諮詢公司，以及政府部門，銀行，電信，航空, 金融等行業中使用。所以，無論你已經是架構師，還是目標成爲一位優秀的架構師，這篇文章都與你有關。
讓我們先了解什麼是解決方案架構以及從我踩過的”坑“開始。
什麼是解決方案架構設計？
解決方案架構設計是使用解決方案架構師的豐富的知識與經驗，從紛亂複雜的問題中，應用科學的解決方案分析方法，進行定量和確有論據的定性分析，找出企業要解決問題的核心原因，提煉能被實施的解決方案與設計架構，進而指導方案實施的過程。
需要解決方案架構師解決的問題，大多數都是是由現狀和期望的差異產生的，如下圖：
有人會疑惑：我拿到需求後進行確認，再進行分析設計，輸出框架方案。我也不需要設計解決方案架構啊？當然。不是所有的問題和項目都需要解決方案架構設計。
在分析處理問題時，解決方案架構師會從兩方面思考問題：
我要解決的是什麼類型的問題？
在不同的問題類型中，由於問題本身具備不一樣的複雜度，認知問題和解決問題的方式也是不同的。
一般來說，解決方案架構師會把問題分成 4 類：
Cynefin 框架 -IBM 在 21 世紀初開發
對於簡單（Simple）問題，一般是可預測的、可能已經有最佳實踐方案，或者你已經解決過類似的問題。問題和解決方案相對穩定；有已知的解決方案。例如有已知框架模型，可複用的方法和步驟，流程，組件。
這類問題不需要解決方案架構設計。比如，給產品需要添加新功能模塊。
對於繁雜類型（Complicated) 的問題，一般是可預測性大於不可預測性，可能有多種可能的解決方案，但是無法確定哪一個解決方案是最佳實踐。這類問題你知道存在哪些未知問題域，你需要用系統的分析過程把因果關係整理清楚，再診斷和找出適合的解決方案架構。這類問題一般是需要解決方案架構分析的。
當然，問題本身不是非常繁雜，可以進行“輕”解決方案架構設計，或者直接進入系統設計。
對於複雜問題（Complex），我們需要通過建立一系列的假設，在多個備選方案中反覆對比驗證，從反饋中篩選出最符合實際情況的方案架構。再把複雜問題切割成若干個簡單或輕度繁雜的問題進行詳細架構設計。這個過程可能長達幾個月或更長。
因爲對於未知的問題，方案架構分析過程就是一個學習的過程。下面是一個對複雜問題認知的模型：
在方案架構設計初期，架構師通過分析，驗證，反饋學習逐步更加認真範圍，最終完成架構工作。
但反之，如果框架師判斷錯了問題的類型，使用錯誤的方法，就可能會輸出與問題不匹配的方案架構。
對於混沌問題，無法通過解決方案架構設計過程找到答案。這類問題只能選擇解決問題的一部分，或者爲問題專門設計套創新的方法。
我之前航空公司就曾經被公司要求解決過這類型的問題：如何把業務，數據和功能從一個已經跑了 60 多年的航空系統（Astral- 是愛爾蘭第一個 IT 系統，1960 年上線，目前還在使用中）遷移出來的方案。
1960 年,IBM1440 Astral 系統在 Aer Lingus IT 系統部
解決方案架構與問題是否匹配?
通常在一個解決方案架構設計過程中，架構師需要在 4 個層面和階段思考架構是否匹配，如下圖
1 問題與願景需求匹配
在開始階段，架構師需要清晰的定義問題，確保問題與願景，需求，期望相匹配。這裏還包括確定問題的類型，複雜程度等。
2 解決方案架構與問題匹配
在方案概念架構設計階段，在多個假設或備選解決方案中，哪些是與問題相匹配。這裏概念架構不需要包含太多的技術細節。概念架構應該做到對業務方人員，非技術背景人員友善易懂。這樣我能確保最大程度的獲得不同部門人員的參與與反饋。
這裏架構師一般從 2 個基本維度去考慮問題與解決方案的匹配：
-
問題的複雜度與解決方案的複雜度相匹配
-
問題的類型與構架設計方法步驟相匹配
3 解決方案架構與企業能力匹配
在總體（或概述）方案架構設計階段，需要確保方案架構設計與企業的能力相匹配。這個很好理解，總體架構設計需要與企業能力對齊。意思就是能做的出來，而且沒有太多的阻力。
舉個經典的例子，如果你的架構設計中需要使用微服務技術，容器技術支撐。但企業實際沒有這些能力，要實現這些能力就會變成方案架構本身的阻力（要解決問題 A 就先解決問題 B 和 C）。在方案中解決這類能力依賴的方法有很多，本文就不具體展開。但最直接高效的方法就是儘量避免選擇這類與企業實際能力差距較大的解決方案架構，選擇企業能駕馭的折中架構方式。
4 解決方案架構商業運營合規匹配
商業與運營相匹配確保方案架構設計達到質量標準，能被商業使用。包括功能需求，非功能需求，運營支撐。同時，方案架構是否符合法規，政策也需要在這個階段考慮。我踩過的解決方案架構與問題不匹配的 5 種“坑”如下圖：
-
“坑 1”：解決方案架構只解決了部分問題，這種坑可能是最常見的。如何避免? 做好問題分析定義，在構建設計初期確保架構方案與問題匹配。
-
“坑 2”：解決方案架構只解決了問題的表象。而真實的問題或更深層的核心問題被忽略。如何避免? 確定問題類型，做好深入的問題分析定義。
-
“坑 3”：這種坑也是常見的。解決方案架構雖然解決了問題本身。但同時也生產出新的問題。如何避免? 這種坑一般是應爲架構設計質量沒有把控好。
-
“坑 4- 巨人解決方案”。這種情況會造成資源的浪費。所以，我在需要架構設計過程中對比，評估篩選不同備選方案。如何避免? 架構成本效益分析 (Cost Benefit Analysis) 是一個很好的方法。
-
“坑 5- 國足問題” 。這類坑的意思是解決方案可能就不存在。就好比有人要你去解決“中國足球”的問題，你的標準答案是 - 這個我做不了，能力有限。如何避免? 做好問題類型分析，避免直接去解決混亂類型的問題。
解決方案架構分析過程漏斗模型
根據上面的解決方案架構關注與思考點，我們能形成一個系統的方案架構分析過程漏斗模型。如下圖：
我們先把解決方案架構過程分成 2 個域：問題域與 方案架構域。
問題域
大部分問題解決者專注於解決方案域，而容易忽視問題本身，那麼問題解決的一半就已經被你丟棄了。
愛因斯坦說：如果我只有 1 個小時來解決問題，那麼我將花 55 分鐘在問題本身和定義它，剩下的 5 分鐘來找解決方案。“
作爲解決方案架構師，我覺得選擇正確的方向比一個完美的技術架構重要。去篩選出有價值的問題（找到 20/80 裏的 20）遠比一個大而全的解決方案架構重要，因爲：
-
不是所有問題都是真正的問題
-
不是所有問題都有方案
-
問題與問題之間本就是不平等的。抓住主要矛盾，解決關鍵問題
所以在問題域裏，我們去定義問題，分析問題類型，搞清楚因果關係，價值與重要性，然後 輸出清晰的問題陳述文檔（Problem statement）。
方案架構域
在解決方案架構域裏，架構師專注與分析尋找可能的備選方案架構。評估，對比篩選出可行的總體架構設計。之後，再進一步切割劃分技術架構領域，輸出詳細的技術架構設計方案。
從技術角度來說，架構的風格有由抽象到具體。思維過程遵循：爲什麼做 - 做什麼 - 怎麼做。
從業務的視角，架構的風格從初期使用業務易懂的語言到後期使用具體的技術設計語言。原因是在方案架構設計的初期，我們希望有業務知識的人員都能參與其中，提供反饋。
方案架構的概念設計的目的是與架構利益相關者的高效溝通。所以，我會避免使用軟件系統架構設計語言。比如：UML，Togaf Archimate。
上面方案架構分析漏斗模型也是架構概念設計的一個例子。
這裏，我希望讀者能能直觀的理解這個概念，達到交流的目的。如果我使用更專業的架構設計語言來呈現，這就給大多數人帶來理解上的門檻。再比如，對於一個不懂建築的人，下面哪種架構呈現方式對你更友善呢？
好的，現在我們有了漏斗模型作爲概念骨架。
接下來，我們來看在骨架模型之上建立的方案架構設計體系。
企業解決方案架構設計框架
如下圖：解決方案框架設計框架體系包括 3 個主要模塊：
-
模塊 1－企業解決方案框架設計方法
-
模塊 2－解決方案架構原則。
-
模塊 3- 解決方案架構工具箱。一些在方案框架分析設計過程中，能用得上的經典工具，方法與模型。
模塊 1：解決方案框架設計方法
與上文中介紹的架構漏斗骨架模型對應，我們把架構分析設計分成 3 個階段。
1 發現階段
在發現階段具體的步驟是:
1.1 確定願景與目標
具體步驟：
-
清晰業務的願景
-
確立項目的目標
-
創建業務案例（business Case）- 項目立項原因，以及項目存在價值的分析。可以理解爲：項目論證，項目理由，或項目價值分析。
-
確定效益指標 - 如何衡量成功或是失敗
上面大部分的工作都有業務分析師和項目經理負責。但作爲方案的架構設計師，我會參與其中，確保重要的信息不會被遺漏。
1.2 定義分析問題
具體步驟：
-
明確問題
-
驗證問題價值以及解決的範圍
-
問題分析（問題的類型與因果關係）。結構化梳理問題可能的原因
-
問題陳述文檔
這些工作由業務分析師與方案架構師共同完成。業務分析師關注與業務需求，而方案架構師則要從更全面的思考.
在解決方案的範圍選擇上，架構師需要根據技術，時間，成本，風險等角度全面分析。確定一個問題的方案架構覆蓋的範圍（同時考慮深度和廣度）是否合理，在預算及計劃期範圍限內能否實現。否則，架構師需要與業務溝通，做出取捨。
這裏作爲解決方案的架構師要區分一個概念：“業務想要的方案”VS ”業務需要的方案“。在解決方案的立場，架構師應該專注把“業務需要”從“業務想要“ 範圍裏區分開來。
一個區分的技巧就是問 “如果不… …做會怎麼樣?” 例如 ，“如果解決方案不提供功能 xxx，對業務有什麼影響？”“如果功能 xxx 不是自動化的，需要人工處理，對業務有什麼影響？” “如果功能 XXX 不能在解決方案上線的第一天出現，只能在 3 個月後才能上線. 對業務有什麼影響？”
如果方案架構覆蓋的範圍過廣，則有可能成爲項目的風險。
1.3 設計方案 & 假設
具體的步驟是：
-
確定解決方案的分析方法
-
提出假設
-
驗證假設
1.3.1 確定解決方案的分析方法
根據要解決問題的實際情況來明確解決方案的分析方法和步驟，計劃到底要做哪些事。
1.3.2 提出假設
在架構師探索問題解決方案的過程中，一個最重要的工具就是提出假設與驗證。
建立假設的目的就是找到問題存在的核心原因。然後去證明假設的正確性。事實上假設驗證不是什麼新的方法，這種方法一直都在各行業中廣泛使用。
舉個最常見的例子，醫生治病的過程就是要出的假設與驗證的過程：
-
醫生會根據病人表現出來的症狀做出初步診斷 - 這是提出假設
-
然後醫生會對病人去進行各種化驗，檢測 - 這是驗證假設
-
在根據數據給病人確診 / 確定病因 - 這是確定問題的核心原因
-
最後根據病因提供治療方案 - 這是提出解決方案
這個過程也是我們經常聽到的 “大膽假設，小心求證，對症下藥”但解決方案架構師常犯的錯誤就是根據過去經驗，作出了過分簡單假設，並經過少量的驗證之後，就把它當作了問題的核心原因。
所以，我們需要一些方法幫助我們進行假設分析。結構化思維就是其中一個最常用的工具。
結構化思維就是面對問題的時候你可以通過某種結構（例如，一定的範式、流程順序進行），把它拆解成一個個你能解決的部分。
結構化思維在這裏就不展開討論. 一些我常用的結構化思維工具有：5Why，魚骨分析，MECE，邏輯樹分析。方法有很多，大家選擇自己比較熟悉的使用就可以了。
1.3.3 驗證假設
驗證假設就是找到支持你分析假設結論的證據。驗證假設的方法有很多，我最常使用的有：
-
通過數據驗證假設 - 這種是最常見，大家都懂。
-
通過事實，案例 - 看看過去相同類型的問題是怎麼解決的案例作爲證據。例如，我們的競爭對手也是這麼做的哦。
-
通過實驗，不行做一次就這知道了。例如，軟件開發的 POC
-
通過專家意見，還可以通過專家的意見反饋作爲證據。比如我之前所在的一家科技公司做過一個非常複雜的解決方案架構，我們就是聘請第三方諮詢公司對方案進行論證的。當然，這裏不是教大家都去聘請外部專家或諮詢公司。不要忘記，對你公司業務最瞭解的專家就在自己公司裏面。所以，記住要善用公司裏的專家資源。
1.4 概念方案架構
在驗證完假設，找到問題核心原因後，我們就可以根據核心原因提出概念方案架構設計，包括：
-
提出概念解決方案架構設計
-
評估概念設計
1.41 解決方案概念架構設計
做概念方案架構時，概念方案儘量少使用技術語言。不要設置過高的理解門檻，儘量做到通俗能懂，能交流就好。概念架構的受衆主要是業務人員與解決方案的利益相關者。
概念架構的目標是推薦與”推銷“概念方案與架構願景給決策者。目的是獲得決策人員與方案利益相關者對方案的認可。
所以，概念方案架構不需要提供具體的設計，只需要與業務的願景，目標，核心問題做出對應。
例如概念方案架構不需要回應下面內容：
-
對業務的深入分析
-
解決方案架構的完整藍圖
-
解決方案架構的詳細設計
-
如何滿足詳細需求
1.4.2 評估概念解決方案架構設計
評估概念解決方案架構設計。如果有多個備選概念設計，需要評估對比。
在實際情況中，出於節省時間的考慮，或者想敢項目進度，我們也可以把備選方案帶入下一階段的設計。在下一階段的總體架構設計時，我們再根據更細緻的分析做出對比評估後，篩選出更合適的架構。
2 架構設計階段（總體架構與詳細設計）
方案架構設計分成 2 個階段：
-
總體方案架構概要設計。在宏觀的角度勾勒出整體解決方案的輪廓與脈絡。
-
詳細解決方案架構設計。如果對於龐大的解決方案架構，例如跨越多個領域（如，信息與數據，基礎技術，安全，服務，甚至方案會影響到多個業務應用， 甚至引入新廠商產品…）時，我們需要對總體方案進行領域分割。在對每個單獨的領域進行詳細架構設計。這時我們可能需要多個解決方案架構師或技術架構師共同協助完成工作。
實際情況中，不同公司會對架構設計的交付物要求不同。這裏我們根據一般性的方案架構設計進行討論。
針對於不同類型的方案架構，例如有些偏向外部用戶，有的偏向企業本身，有的偏向技術領域的解決方案。下面步驟可以根據你的實際情況做加減法，步驟的次序也可以進行調整。
2.1 總體解決方案概要架構設計
具體的一般步驟是：
-
解決方案業務架構設計
-
總體解決方案架構設計
-
確定解決方案架構設計範圍
-
總體解決方案架構設計可行性評估
-
解決方案架構規劃（計劃，線路圖）
2.1.1 解決方案業務架構概要設計
我個人的習慣是遵循業務第一的原則，從業務架構開始。
什麼是業務架構（business arcihtecture）？InfoQ 之前有一篇（The Subject and Discipline of Business Architecture）文章介紹過在這裏就不多太多的解釋。
從企業價值與能力視角，作爲解決方案架構師我一般會關心：
-
價值流 - 描述在企業中價值是如何創造與傳遞的。把企業創造價值的過程分解爲一系列互不相同但又相互關聯的活動，或者稱之爲“增值活動”。
作爲架構師，我希望明白在業務的層面，解決方案架構在宏觀視角將會影響價值鏈 / 價值流中哪些些環節（節點）。
從這些被方案影響的環節出發，研究哪些業務能力（business Capability）被解決方案使用，哪些業務能力將被解決方案影響或改動。這裏我會使用業務能力圖（business Capability Map） 幫助我進行下一步更具體的分析。例如使用類似下面的模板：
-
業務能力圖（business Capability Map）- 能幫助我瞭解一個企業爲了創造價值而做的事情 What，而不是如何去做（其業務流程）How。目的是在業務能力的成面，我希望明白解決方案將複用和改變哪些業務能力，影響改變將在哪裏發生。如下圖：
-
業務服務（business Service) - 我還希望知道解決方案會複用或影響到哪些業務服務。
從業務運營 / 運作視角，作爲方案架構師我一般還會關心：解決方案將影響或改動哪些業務流程 。
爲什麼最後才分析業務流程。這是因爲業務流程相對於業務能力，業務服務，是變化比較頻繁的元素。
根據解決方案架構從穩定到變化原則，和從宏觀到具體的原則。我會把業務流程留到最後。還有，在總體解決方案架構階段，總體方案也不需要對所有詳細的業務流程與需求做出一一對應。
爲什麼我先從業務架構開始分析？
首先是因爲，這些是業務部門人員能看懂，也是他們最關心的事。同時也符合解決方案設計業務第一原則。
其次，這些業務元素是相對穩定，與技術無關的。我希望解決方案是從穩定的元素開始分析，然後從穩定的元素映射到更具體變化的元素。例如下圖：
所以，我一般會從解決方案業務架構入手，用 Top-down 由上而下的方法推進到總體方案架構設計。
上面的業務架構是以企業爲中心的視角（即，企業需要什麼）的分析方法。
根據不同的解決方案類型，例如，以用戶爲中心的解決方案（即，用戶需要什麼），方案架構師還能使用例如：
用戶旅程圖，event storming 等工具，分析價值流向以及在價值節點上如何調用企業業務能力, 服務與流程。下圖是一個用戶旅程與企業服務調用的例子：
2.1.2 確定解決方案架構設計範圍
根據解決方案業務架構的分析，下一步我們來確定總體解決方案架構設計的範圍。
總體解決方案架構設計範圍就是確定究竟哪些領域需要“變動”。解決方案架構設計範圍可以參考下面架構設計範圍圖：
一般情況下，一個解決方案至少會影響一個以上的範圍，以及改動多個企業能力。如，改變多個應用系統。
一般對應於複雜的方案架構設計方法，我們還可以使用“熱力圖”把變動的類型標註出來。例如：
-
用不同的顏色顯示：添加新功能，修改已有功能，刪除已有功能，遷移功能等。
-
用便籤來提示變動的大小：XL－變動非常大， L- 變動大，M－變動一般， S－變動小
2.1.3 總體解決方案架構設計
在總體方案架構設計階段，我會根據上一步確定的解決方案範圍去指導總體方案架構設計的工作。
一般會使用下面的架構設計步驟對每一個變動領域進行分析：
步驟 1：描述現狀
步驟 2：描繪目標狀態 - 從企業已有的參考架構（reference architecture）開始，到邏輯架構（logical）再到物理架構（physical )
步驟 3：差距分析，勾勒出存在哪些差距
步驟 4：對存在的差距進行分析。對複雜度，優先級別進行評估
步驟 5：初步估算複雜度和工程大小。這裏我們只能是進行粗略估算，一般我會用 T-shirt size：XL,L,M,S.XS 進行估算。
步驟 6：在變動模塊之間標註依賴關係。
也可以使用其他的架構設計方法如：TOGAF ADM 方法進行設計。
2.1.4 總體解決方案架構設計評估 / 分析 / 對比
總體解決方案評估在前文已經討論過，這裏就不多做介紹了。
如果你有多個備選架構，你需要在這裏進行評估：如，可行性評估，成本效益對比評估等。然後做出選擇決定。因爲我們不會再把備選方案帶到下一步的解決方案規劃，以及後面的詳細架構設計階段。
2.1.5 解決方案架構規劃（計劃，線路圖）
我們還需要提供解決方案的實施規劃。例如：下一階段的領域詳細架構設計架構師人員需求、工作計劃、線路圖 等。
同時，PM 也可以根據總體方案架構向相關實施的負責團隊索要起始階段實施工作量成本初步估算（Order of Magnitude）以指導下一步項目實施計劃。
2.2 詳細解決方案架構設計
在詳細設計階段，總體方案已經把架構設計範圍劃分清楚，切割成不同的領域。
因爲各自領域都有不同的特點，設計方法與設計流程也不盡相同。所以，各領域的詳細架構設計在這裏沒法具體展開。各領域架構師通過使用總體方案架構設計，詳細需求等文檔進行詳細設計。
3 架構評估與驗證階段
架構評估與驗證階段我們可以進行下面 2 種類型的驗證：
-
商業運營匹配驗證評估
-
合規性架構驗證評估
3.1 商業運營匹配驗證評估
商業運營評估可以進行下面驗證：
-
詳細方案架構質量評估
-
架構技術評估
-
方案架安全評估
作爲總體解決方案的架構師，需要參與全部評估，確保領域詳細架構設計與總體架構設計相匹配，滿足功能需求與非功能需求，以及與解決方案架構的願景一致。
3.2 合規性架構驗證評估
合規性架構評估驗證的範圍包括：
-
對內合規性架構評估 - 符合企業的政策，原則。例如，企業架構原則，安全原則，與企業戰略框架一致。
-
對外合規性架構評估 - 符合地區區域，國家，行業等的法規，政策。如果你設計一個跨國，跨洲際的解決方案架構。對外合規尤爲重要。方案架構需要符合所在國家，地區，行業的方案。例如：安全法案 (如：GDPR,…），個人隱私方案 (PCI,… )，行業方案 (PSD2…)
部分 2：解決方案架構設計原則
什麼是架構原則？參考 InfoQ 這篇文章 架構設計原則的力量
下面提供一些幫助方案架構師在工作過程中做出設計決策的指導原則：
1 業務第一原則：“理解業務領域優先與理解技術領域”
理解業務的願景，問題，痛點，需求是解決方案架構師要優先關注的事情。
2 溝通優先原則：“可理解優於大而全”
解決方案架構的首要目的是溝通和獲得反饋。溝通的前提是別人願意看 / 聽，和看 / 聽得懂。
業務部門人員及方案利益相關者是不會去閱讀一個兩百頁滿是專業術語的方案架構文檔。架構師需要去平衡方案的專業性與可讀性，用讓人能懂的方式去呈現專業的技術方案。解決方案架構師的溝通做到簡潔，易懂，是高段位架構師的體現。
3 建立關係，建立信任感
解決方案架構師需要花大量時間與非技術人員及業務部門打交道，包括“推銷”你的解決方案，獲取反饋，獲得他們對你工作的支持。
這一切都建立在他們對你的信任與關係之上。信任感與關係的建立來自於你的溝通，這包括你對業務的理解，你提供的價值，你對承諾的兌現，你用適當讓他人感覺舒服的方式呈現你的方案與想法，還包括讓人舒服的着裝與談吐。
4 從分析穩定的開始再到理解變化
解決方案架構分析設計應該從相對穩定的元素開始入手，然後纔去理解變化。
5 從宏觀再到微觀具體
從宏觀入手，然後纔去處理微觀具體。
6 解決方案與問題匹配原則
解決方案與業務問題匹配優與業界領先的解決方案.
7 即時（Just in Time）、夠用就好（Just Enough）
方案架構設計做到在重要的時間點上爲最重要的決策者與利益相關者提供價值，夠用就好。
8 80/20 原則
解決方案架構師應該去思考方案中哪些部分屬於最重要的 20%。然後在必要的時候做出取捨。
部分 3：解決方案架構工具箱
下面是一些在方案框架分析設計過程中，方案架構師能用得上的經典工具。排在每類最前面的是我認爲最好用或者用的最頻繁的工具。
架構設計工具
白板－這是我認爲最好的架構設計工具
架構研討會 Architecture Workshop - 這是我認爲第二好用的架構設計工具
架構師訪談 Interview - 我認爲第三好用的架構設計工具
頭腦風暴 -Brainstorm
TOGAF 與 ADM 方法
由上到下設計 Top Down 設計法
領域驅動設計 DDD
事件風暴 Event Storm
領域故事 Domain Storytelling
架構設計建模語言工具
不需要多，用好一個就好。
Toagf Archmate 企業架構建模語言
UML
C4 模型
問題分析方法與結構化思維工具
這裏許多工具都是我在諮詢公司企業戰略與架構分析項目中使用過的。一般公司架構師會使用一兩種工具就能應付絕大多數情況。
麥肯錫 MECE
麥肯錫邏輯樹分析
5W2H 分析法
魚骨分析法
CATWOE 分析法
SWOT 分析法
設計思維方法工具
客戶和用戶旅程圖
斯坦福設計思維 design thinking
架構評估方法
Togaf 架構合規性驗證方法
卡內基·梅隆 - 成本效益（CBAM) 分析評估
卡內基·梅隆 -ATAM 評估法
卡內基·梅隆 CBAM 與 ATAM 整合分析法
決策樹 Decision Tree
風險管理
TOGAF 架構風險管理
卡內基·梅隆 - 軟件風險管理
卡內基·梅隆 - 風險管理框架
決策矩陣
寫在最後
實際的企業環境中，解決方案架構還會與企業架構（Enterprise Aarchitecture) 與架構治理等其他的企業架構能力互相配合。但因爲文章篇幅有限，也考慮到這篇文章主要的目的是討論可以複用的解決方案架構設計過程，方法與模型。所以，在這裏不做展開。
感興趣的朋友可以參考下圖各類型架構能力間的作用關係。
作者介紹：
俞躍（Nick Yu），萬事達都柏林（Mastercard）Principal Enterprise Architect(企業框架師)。在此之前，在 Aerlingus 愛爾蘭航空與母公司國際航空集團 IAG 解決方案框架設計師與企業框架師，從事所在公司數字化與商業部門的解決方案與企業框架管理。更早之前，在德勤諮詢都（Deloitte）從事技術，架構與戰略諮詢經理。曾爲多家銀行，多個政府部門提供解決方案框架與企業框架諮詢服務。
文章來自：架構師