Solution Design概述
Solution Design是IBM歷史上一個知名的方法論，其設計的初衷始於售前的解決方案設計，因其對龐大複雜的UMF框架做了精選，相對簡單又不失完整，在項目實施過程中也廣受架構師歡迎。前幾年，隨着用戶體驗的崛起，客戶越來越注重體驗，IBM開始大力推行Design Thinking作爲解決方案設計方法論。但是架構師、開發工程師和運維工程師難以使用Design Thinking方法論，所以Solution Design仍然在項目實施階段被廣泛使用。
如圖所示，IBM Solution Design定義了整個解決方案設計流程中的活動，每一項活動都會產生或者更新一些工件，最終形成的解決方案是由一組互相關聯的工件共同組成的：
注意，雖然工件構成的解決方案是最終的成果，不要錯誤的認爲Solution Design方法論是由工件驅動的，應當是由活動驅動設計過程，按需創建並及時更新工件。下面，結合IBM傑出工程師Dr. Marcel Schlatter在蘇黎世大學的講義和IBM傑出工程師蒂拉克·米特拉的大作《實用軟件架構：從系統環境到軟件部署》，講解一下方法論中的關鍵環節和工件。
0. 理解客戶業務
要設計符合客戶需要的解決方案，需要對客戶當前的業務和IT做適度的瞭解。包括：瞭解客戶的業務方向，組織架構，IT技術環境和標準。將這些資料形成規範的文檔，有助於實施團隊和未來的解決方案團隊更好的瞭解客戶，提供更優質的服務。
1. 定義客戶需求階段
1.1 定義項目
活動“定義項目”是回答這個項目要做什麼、爲什麼做，並且得到項目發起人的簽字認可。定義項目活動的主要產出工件是《項目定義》，其中包括了目標、背景、目標方案和整體方法、範圍、計劃框架和組織等。
1.2 識別和羅列需求
在此活動中定義一組基本的用例以描述用戶如何使用系統，理解額外的功能需求並以需求矩陣的形式記錄。相較於用例，需求矩陣更適合於羅列大量的需求，同時建立好需求列表以後，也便於評估套裝軟件的適用性和開發工作量。
1.3 描述系統上下文
“描述系統上下文”活動，通過繪製系統上下文，設定了所設計系統的邊界，同時表現了新系統和已有系統之間地關係。如下系統上下文圖，描述了要構建的電子商務系統需和客戶端、外部實體以及遺留系統交互（即這些系統不屬於電子商務系統），同時表現了系統間的調用方式和通信協議。
1.4 識別非功能需求
非功能性需求也被稱作系統的“質量指標”，常見的非功能性需求包括：性能、可擴展性、可用性、可維護性、可管理性、易用性、數據一致性等。
1.5 定義高階數據源
在此項活動中，架構師將識別組織所關注的主題（即主題域），然後建立主題域模型（Subject Area Model），下面的例子是一個航空公司的主題域模型：
1.6 記錄架構決策
在整個架構設計活動中，架構師和團隊要做出很多的決策，Solution Design方法論強調要將決策規範的記錄下來，一方面可以提高決策的質量，另一方面也可以作爲未來需要調整時的參考依據。如下所示，架構決策主要包括問題、假設（或限制條件）、動機、選擇（包括優缺點）、決定等內容。
需要注意的是，及時記錄架構決策是一項貫穿整個解決方案設計的活動，並非限於某一時間進行，也不宜等方案設計完成後再補記。
1.7 進行可行性評估
在充分了解了客戶和項目需求後，下一步可以對項目的可行性進行分析，分析項目對於干係人有價值。在分析可行性時，需對在前期工作中發現的風險、假設、問題和依賴做一梳理，並制定應對措施和可能的行動計劃。
本文下半部分請看：揭祕IBM架構設計方法論 —— Solution Design II
參考資料
1. CCRA 4.0 Overview_20140918_non_conf
2. [印]蒂拉克·米特拉. 實用軟件架構：從系統環境到軟件部署. 機械工業出版社, 2017
3. https://wenku.baidu.com/view/4c21d7b1ee06eff9aff80768.html
4. https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/it_architekturen_hs10/
5. https://wenku.baidu.com/view/d77dcd32cf84b9d528ea7adb.html
6. http://walderson.com/IBM/Practices/ScalingAgile