- 架構師爲什麼需要管理實踐
- VRAPS組織管理原則有哪些
- VRAPS概念框架的基本概念
- 構想原則如何形成統一併應用到實踐中
- 節奏原則是什麼，怎麼應用到實踐中的
- 基於良好的節奏，應該怎麼預測、驗證和調整
- 協作原則是什麼，怎麼進行應用
- 簡化原則是什麼，怎麼進行應用
1.架構師爲什麼需要管理實踐
答：在實踐過程中，軟件架構師主要障礙往往在於組織方面。
2.VRAPS組織管理原則有哪些
答：構想原則，說明如何向架構的受益人描述一幅一致的、有約束力和靈活性的未來圖景；節奏原則，刻畫一種在整個組織範圍內協調程度，即定期地根據可預測的速度、內容、質量對製品生產進行檢查和規劃；預見原則，要在預測未來與檢查並適應現狀之間做平衡；協作原則，解決如何識別對架構成功關鍵的團體，以及如何確保這些合作伙伴的有效支持；簡化原則，要求理解組織的結構，瞭解架構最小的基本特徵並最小化架構。
3.VRAPS概念框架的基本概念
答：準則是把廣泛的原則翻譯成是否和如何執行原則的細節。每一項原則都附有一組模式，模式描述開發或者使用軟件架構時可能遇到的常見問題解決方法。模式更注重於解決特定情況下的問題，傳達在給定背景和多方競爭因素下針對常見問題的解決方案。返末世描述組織在實踐中可能遇到的陷阱，描述了不該做的事情或者用在錯誤背景下的解決方案，可以幫助理解原則。
4.構想原則如何形成統一併應用到實踐中
答：構想描述了架構的未來，提供了框架使用的環境和動機。構想是未來價值到框架約束的映射，必須把它所能提供的價值與客戶的約束向對應。構想需要維持一致性和協調性，一致性是受益人各種期望之間的妥協以及它們與現在和未來的架構之間需求滿足程度，靈活性是受益人在不破壞架構的情況下，基於現有架構完成事先沒有預料到的需求難易程度。
形成架構構想的三步方法：清楚明確地闡述一條迫切的客戶價值；將客戶價值映射爲少數特定的能解決的問題；將以上問題轉譯成一組特定的約束條件。
驗證構想原則是否生效的標準如下所示：架構師的構想與發起人、用戶、最終客戶期望實現的目標是否保持一致；實施人員是否信任並使用框架；關於架構和構件的潛藏知識對其用戶是否是可見的、可以獲得的。
在構想中存在着反模式：風險置後，因臨時要求變動原先的設計構件引入新功能，後患不斷；牆頭草，因沒有良好構想，迫於壓力不斷更改架構，導致架構不穩定，接着引起人心不穩；一葉障目，具體開發人員只專注於自己部分的任務，不瞭解其他部分，最終導致臨時解決方案堆積架構難以承受。解決這些構想中的反模式可以使用以下對應的方法：前後一致，積極維護構想，防止因短期壓力變動，具體變動內容應仔細覈實確認後纔可以變動構想；三個臭皮匠，架構設計不僅只是需要架構師，還需要同客戶一起協商溝通，同時不能將問題擴大化要針對業務問題；輪流工作，推薦開發人員之間資源知識共享，讓開發人員接觸並熟悉架構的其他部分，定期挪動其工作範圍。
5.節奏原則是什麼，怎麼應用到實踐中的
答：節奏是一個框架團體內部及它與客戶和供應者之間反覆出現的、可預測的工件交換活動。節奏有三個要素：速度、內容、質量。速度是一個團隊與另一個團隊之間同類型交接的頻率。內容是指一個團隊向另一個團隊提供的價值。質量的含義是遵循開發過程確保架構沒有缺陷。
節奏準則生效的體現有三個特徵：經理們定期地再評估、同步和調整架構；架構用戶對架構發佈的進度和內容具有高度的信心；通過節奏協調可明確活動。第一個特徵的反模式是一部成功，一旦項目複雜程度或者超過掌控者的能力，失敗是不可避免的；正確的方式是採用定期評審發佈，每一次發佈做一次迭代。第二個特徵的反模式是超敏捷，通過降低質量減少內容抄近路等方法維持穩定發佈節奏；正確的做法是舍兵保帥，將不確定以及不重要的特性移動到下一個發佈週期，保證發佈質量穩定團隊信心。第三個特徵的反模式是銷售未檢驗的產品，包括長時間不進行維護更新；正確的做法是產品要定期的運行一次，以防止運行環境或者其他更新的信息未支持同步，每次發佈的產品都應該同步發佈。
6.基於良好的節奏，應該怎麼預測、驗證和調整
答：預見是建立和實現架構的人員根據變化的技術、競爭和客戶需求預測、驗證和調整架構的程度。驗證不僅侷限於傳統軟件工程的測試和檢查技術，也包括對架構基礎假定的預測。軟件架構的長期成功依賴於對假定變更和通過預測及驗證獲取信息的適應程度。調整是對架構計劃及架構本身修正以加入新的特性，適應新環境和新市場。
預見原則生效時的特徵如下所示：不斷增強架構的響應能力，預見到風險、架構客戶、客戶需求，市場驅動的標準和演變技術，戰略性業務方向的改變；通過快速複審和開發週期，評估技術和業務上的風險與機會；當認識到關鍵的評估或假設有錯時，及時調整功能特性和預算。
預見原則的模式是示範區、架構複審、外包，對應的反模式有遺漏細節、品嚐未熟的果實、創造奇蹟。遺漏細節是提供架構的新功能時未考慮到一些關鍵的基礎細節，導致存在功能缺陷；品嚐未熟的果實是將不成熟或者是試驗階段的架構應用到商用或者生產場景，導致新架構質量不能承擔使用場景的需要；創造奇蹟是在有足夠證據顯示基礎假設和估計已經完全偏離目標是，對架構開發和實現計劃不做任何修改將發生的情況，這不是奇蹟，是空想造物脫離實際需要。
7.協作原則是什麼，怎麼進行應用
答：協作原則解決了如何識別對架構成功起關鍵作用的團隊，以及如何確保這些合作換班的支持等問題。協作是指架構受益人保持明確的、合作的角色並將其提供和獲得價值的最大化程度。合作是受益人彼此之間存在一些共享的預期，應明確表示出達到或未達到預期會有哪些獎勵和懲罰。
協作原則生效的特徵有：架構師不斷努力瞭解誰是最關鍵的受益人，他們如何貢獻價值以及他們需要什麼；受益人之間達成明確和強制性契約；通過社會行爲制度和非正式規範強化合作。
協作原則的模式是瞭解你的受益人、互惠互利、杜絕意外、和HR密切合作，與之對應的反模式有光說不做、不記錄討論結果、非正式時間做正式工作。光說不做是需要架構是知道用戶需求卻沒有將這些信息清晰的轉接給相關的協作人員，或者協作人員和架構師知道而用戶不清楚；不記錄討論結果，沒有辦法將討論的關鍵點集中在有效範圍內或者轉換話題到指定的討論點上；非正式時間做正式工作，最終導致工作內容無法把控，存在質量隱患。
8.簡化原則是什麼，怎麼進行應用
答：簡化原則要求對價值非常堅定和專注，以及對架構所生存的組織的理解和支持，爲了實踐這個原則，架構師必須瞭解架構最小的基本特徵，並將這些特徵傳達給實現架構團隊的每一位成員。簡化是指做作用的組織和環境都進行巧妙地理解和最小化，組織形成架構並思考架構。在簡化架構之前必須澄清組織和架構。
簡化原則生效的特徵有：開發人員長期使用架構，減少了總成本和複雜性；架構小組明確理解關鍵最小需求，並且將其構造成多應用共享單車額核心元素；通過長期的預算和行動確保相關元素沒有被共享、增減不必要的複雜性時或者有明確業務理由時，可把相關元素從核心移走。
簡化原則的模式有由慢而快、遷移途徑、統計構件變更，與之對應的反模式有簡單複製並修改、缺乏有效抽象、編碼大於架構。簡答覆制並修改描述了當程序員學會使用或重視架構之前被強迫迅速完成任務時發生的情況，容易引入重複性代碼和冗餘實現，當然bug也不例外；缺乏有效抽象在於前期還算簡潔，後期引用規模擴大會導致單點解決方案強制性糅合，缺乏足夠的共享性導致應用的平臺越來越大但是運行效率越來越低；編碼大於架構主要是防止架構師成爲架構的實現者，在這種情況下，架構師的職責無人承擔，最終架構崩盤。