一、開篇

      上一篇《HRMS(人力資源管理系統)-從單機應用到SaaS應用-系統介紹》我們已經詳細的分析了HRMS系統具備的功能，並且從HRMS系統的概念、系統功能、HR行業管理現狀及痛點、發展趨勢及行業前景、行業內的服務提供商情況、HRMS系統的建設意義及價值等方面進行了系統化的分析梳理。我想大家已經對於HRMS系統的大體情況有了初步的瞭解，本篇將對HRMS系統的需求進行全方位的梳理（功能性需求、非功能性需求、系統約束等），這對於HRMS系統的架構設計來說是核心關鍵，是架構能否成功的前提。這也是衡量一個架構師是否稱職合格的關鍵。

       本篇主要想通過HRMS系統與大家分享下架構設計環節中非常重要的基礎環節-架構準備-的關鍵工作內容，請大家務必該環節的工作內容，這是所有成功架構設計的前提，為能夠系統的闡述清晰該領域的注意事項及工作方法，所以篇幅會較長，請大家細細看完，如果有闡述不清晰或遺漏的地方，還請大家指出。

      在闡述具體的架構工作方法之前，請大家先檢視以下三方面的內容：

     1、HRMS系統的介紹？（涵蓋哪些功能？價值和作用是什麼？行業什麼情況？）

      2、本章分析的內容將圍繞4類企業代表的業務場景，（區分不同規模企業的關注點，規模將決定系統的設計方案）

      本篇將圍繞4類企業代表來闡述不同規模企業對於HRMS的需求及應用

•       A、100人以下的中小企業
•       B、500人以下的大中型企業
•       C、1000人以上的集團化大企業
•       D、全球型別的公司體系（幾萬人）

      3、架構師在設計該系統時的職責及具備的核心能力是什麼？

二、為什麼很多系統架構的設計會失敗？

       在這10多年的工作經驗中見過也參與了不少失敗的架構專案，基本上總結下來發現了有很多種原因可能導致架構設計失敗，所以說一個系統的架構設計是一個系統化的工程，不是隻進行模組設計或功能設計那麼簡單，需要不斷學習和積累經驗，站在巨人的肩膀上思考問題，讓我們少走彎路。成功和失敗的經驗都值得我們去總結和思考，那麼基於之前總結的內容，我梳理完可以歸納為以下幾個方面：

A、架構師不懂需求

B、非功能需求、關鍵約束、關鍵功能等沒有找到

C、缺少關鍵實踐及方法論

D、未能驗證架構的可行性並作出調整

2.1、架構師不懂需求

       技術是為業務服務的，請每一位架構師或系統的設計者謹記該理念，不知道大家有沒有總結過目前出現的各類技術的特點，我發現每一次的技術更迭就是為了解決前一主流技術存在的不足或某些領域的缺陷而產生的，所以，我們在選擇一項技術或選型時，需要結合業務的實際情況靈活選擇，一定要選擇最好、最優的，考慮未來的變化、不確定、擴充套件性等非功能性需求

2.2、遺漏或未找到非功能需求、關鍵約束、關鍵功能等

       在系統架構設計的過程中最害怕的就是遺漏關鍵功能或非功能性需求、系統約束等方面沒有考慮，這將直接導致架構失敗，前面做的所有的準備工作基本上都是白費了，往往在架構設計的過程中一個點就會導致整體失敗，我們必須找到關鍵需求。這將需要一整套的方法論，我們往往在分析功能、非功能性需求、系統約束時缺乏方法論和梳理思路，這將會讓我們陷入一系列的迷茫中，就會出現抓不住重點內容。具體某個需求在不同的行業領域、不同的使用者場景等往往重要性可能不同，這就需要架構師必須進行充分的調研梳理。

2.3、缺少關鍵實踐及方法論

       我們在實際的架構工作中往往不去學習和參考前人總結的工作經驗，這樣是阻礙個人成長和進步的，我認為99%的場景下我們遇到的問題前人都遇到了，只是我們沒有遇到對的人，只要我們找到對的人，只要這個人肯分享，一定會幫助我們解決我們遇到的問題的，再舉個例子，如果我們做網際網路，那麼技術問題可以試想下，我們遇到的問題我想（BAT）都遇到了，所以我們為啥不站在前人的肩膀上去思考問題呢？這讓我們能夠有更多的時間去總結和思考解決問題的方式，全面提升我們自身的能力。

       另外，千萬不要認為自己設計的架構方案就是最好的，要不斷的質疑架構的合理性及最優性，經得起大家的質疑及實際的考驗，並且為確保架構的有效落地，需要持續的跟蹤確認，確保方向不會出現偏差。

2.4、未驗證架構的可行性並作出調整

       整體的架構方案並沒有進行充分的評審及實踐驗真，俗話說實踐是檢驗真理的唯一標準，這需要架構師在架構設計完成後準備各檢視場景下的驗證方案，確保整體架構的可行性，一旦在過程中發現遺漏及風險及時干預並調整架構設計方案，如果已經進入到開發階段，需要制定平滑的設計方案，儘可能的規避工作量損失並保證系統功能的全面支撐。

另總結了一些軟體架構設計過程中存在的誤區

●高開高走落不到實處

● 理想與現實需要折中

● 遺漏關鍵性約束與非功能需求

● 為虛無的未來埋單而過度設計

● 過早做出關鍵性決策

● 客戶說啥就是啥成為傳話筒

● 埋頭幹活兒缺乏前瞻性

● 架構設計還要考慮系統可測性

● 架構設計不要企圖一步到位

三、架構設計成功的關鍵方法

3.1、EA架構方法論體系

       對於企業或提供行業的產品及服務時，我們需要一整套的系統化思維去思考和設計業務流程。特別是業務越來越複雜及業務範圍越來越廣時，這就需要我們有一整套的方法論去指導我們去設計及規劃系統，一個大家都明白的共同語言來分析和解決問題，這個共同語言就是EA所提供的。EA的真正意義是告訴你怎樣去思考，怎樣去溝通，怎樣去做決策，以及怎樣去控制專案。EA保證不同層面的人看到一個更巨集觀的檢視，從而避免“ 只見樹木、不見森林”的無效工作。 EA是一個把戰略、業務與IT進行有效匹配的方法論，從而使 IT真正為業務和戰略服務，從而使戰略能夠有效執行。 EA就是現代企業的DNA，它是一個能夠整合各種方法的機制 ，從而解決各種挑戰和問題。

       上述圖片中呈現了EA方法論的5類具體的實踐，由於篇幅有限，我這裡不挨個展開介紹概念及具體內容。如果想了解詳情請大家自行搜尋。

       可以說我們在做一個複雜系統的設計及規劃時，正確的方法論會知道我們正確的做事，做正確的事，所以這對我們每個架構師來說非常重要，請大家務必瞭解，當然對於EA理論的具體實踐也有很多具體的方法實踐模式，這裡也可以歸納為幾類，後面我們將詳細闡述。

3.2、ADMEMS（Architecture Design Method has been Extended to Method System）

       ADMEMS是Architecture Design Method has been Extended to Method System的簡稱，是由CSAI顧問團架構設計專家組於2009年11月在第六屆中國軟體大會上公開發布的一個軟體架構設計方法。作為方法體系，ADMEMS通過3個階段和1個貫穿環節，來覆蓋“需求進，架構出”的架構設計完整工作內容。其中“3個階段”是指預備架構階段（PA階段：把握需求特點，確定架構驅動力）、概念架構階段（CA階段：根據重大需求，確定概念架構）、細化架構階段（RA階段：細化架構設計，關注不同檢視），“1個貫穿環節”是指對非功能目標的考慮。

       PA階段的任務是全面理解需求，從而把握需求特點，進而確定架構設計驅動力。其中，ADMEMS矩陣居於方法的核心；CA階段必須考慮包括功能、質量、約束在內的所有方面的需求，ADMEMS方法有自己的概念架構設計步驟和做法；RA階段的總體方法為5檢視方法，涉及邏輯架構、物理架構、開發架構、執行架構和資料架構。

       後面我們將主要參考該架構方法來落地實踐HRMS系統的架構設計過程。

3.2、質疑驅動架構設計（始終抱著質疑的思想來思考架構設計方案）

架構師需始終保持質疑的意識來不斷驅動整個架構設計的過程，這是一個架構設計成功的關鍵，通過質疑可引入更多的“質量屬性”，同時結合“特殊功能場景”驅動後續架構設計，最終形成最優的架構設計方案。

以HRMS系統為例：

上面我們發現在架構設計的過程中，我們需要從多維度去思考架構設計考慮的內容及方式，我們需要從不同的方向去考慮架構過程中出現的各類問題，通過質疑並不斷解決質疑的方式來設計出最終的解決方案。我們的終極目標是設計出一套先進有持續競爭力的HRMS系統，滿足各類企業在經營過程中對人力資源管理所需的各類需求（功能、質量屬性、約束），架構師需要用挑毛病的方式來去評估當前的架構設計方案，直到挑不出毛病（架構師自己先質疑問題並解決了），這個架構基本就成型了。

3.3、多階段/多檢視

       業界軟體架構設計的方法論很多，各有各自的應用場景和特點，下文結合ADMEMS（Architecture Design Method has been Extended to Method System）架構設計方法論說明軟體架構的過程：

       架構設計的過程和內容的不是固定不變的，現實中，比如售前提供解決方案中，很多時候需要架構師提供細化架構中才會深思的邏輯架構、物理架構等，這時候，架構師就需要有螺旋思維和跳躍思維的方式，就像武功中，招式是死的，人是活的，要學會靈活運用。

       3.3.1、架構設計過程（3個階段）

A、Pre-architecture階段：架構實踐中最常見的最短板

最大誤區：架構師是技術人員，不必懂需求

實踐要點：摒棄“需求列表”方式，建立二維需求觀

思維工具：二維矩陣（需求層次-需求方面矩陣）

B、Conceptual Arch階段：大型系統成敗關鍵

最大誤區：概念架構=理想設計

實踐要點：重大需求塑造概念架構

思維工具：魯棒圖、目標-場景-決策表

C、Refined Arch階段：團隊大規模並行開發基礎

最大誤區：架構=模組 + 介面

實踐要點：貼近實踐的5檢視法

思維工具：包圖、包-介面圖、灰盒包圖、序列圖、目標-場景-決策表

         3.3.2、架構設計5檢視

         5檢視法分析的意義：

         ● 全面分析軟體系統方方面面的問題         ● 儘早地發現和排除專案風險與不確定因素         ● 從不同角度去展現要設計的軟體系統         ● 為專案進行中不同的干係人提供指導：            -- 邏輯架構描述系統功能，並指導系統測試            -- 開發架構規範軟體的層次及程式碼風格            -- 資料架構指導資料庫的設計            -- 執行架構定義了一些關鍵過程的設計            -- 物理架構明確軟體如何部署與實施

關於架構5檢視的實踐過程：

3.4、內建最佳實踐(經驗總結)

       在我們在做系統架構時，我們應該不斷的學習、總結之前的經驗，就像前面我們講到的架構的方法論、架構模式一樣，我們需要形成一套方法理論體系或者應用場景解決方案去指導我們在後續的系統架構。少走彎路、找到最優的架構解決方案。

      整體來說我們可以歸納在邏輯架構、業務建模、關鍵約束、非功能性需求（質量需求）等幾方面的經驗。

3.4.1、邏輯架構設計過程中的10條經驗

1) 劃分子系統：分層的細化

2) 劃分子系統：分割槽的引入

3) 劃分子系統：機制的提取

4) 介面的定義：協作決定介面

5) 選用序列圖：杜絕協作圖

6) 包-介面圖：從結構到待辦的橋

7) 灰盒包圖：描述關鍵子系統

8) 循序漸進的螺旋思維

9) 設計模式：包內結構

10) 設計模式：包間協作

       在實際的邏輯架構的設計過程中，上面的10條經驗會非常有價值，我們僅需參考上面的原則來設計系統的邏輯架構，基本上架構成功的機率很大。再結合其他的4個架構檢視即可得到最優的系統架構。

3.4.2、基於魯棒圖進行初步設計的10條經驗（業務建模）

       ADMEMS方法歸納了魯棒圖建模的10條經驗要點,分別覆蓋語法，思維，技巧，注意事項等4個方面，建議後續大家在做具體的系統架構時可參考10條設計經驗，少走彎路：

魯棒圖建模的10條經驗:

1.遵守建模規則。

    通過以下4條語句，可以理解該圖的本質：

         1.1 參與者只能與邊界物件交談。

         1.2 邊界物件只能與控制物件和參與者交談。

         1.3 實體物件也只能與控制物件交談。

         1.4 控制物件既能與邊界物件交談，也能與控制物件交談，但不能與參與者交談。

2.簡化建模語法

      ADMEMS方法推薦魯棒圖建模的語法。在實踐中，簡化的魯棒圖語法將有利於集中精力進行初步設計，而不是關注細節。

3.遵循3種元素的發現思路

用例=N個場景。每個場景的實現都是一連串的職責進行協作的結果。所以，初步設計可以通過”研究用例執行的不同場景，發現場景背後應該有哪些不同的職責“

4.增量建模

         首先，識別最明顯的職責。對，就是你自己認為最明顯的那幾個職責--不要認為設計和建模有嚴格的標準答案。

接下來，開始考慮職責間的關係，並發現新職責。繼續同樣的思維方式。

5.只對關鍵功能（用例）畫魯棒圖

    基於”關鍵需求決定架構“的理念，功能需求作為需求的一種型別，在設計架構時不必針對每個功能都畫出魯棒圖。

6.每個魯棒圖有2-5個控制物件

     既然是 初步設計，魯棒圖建模時，針對關鍵功能的每個魯棒圖中得控制物件不必太多太細，5個是常見的上限值。相反，若實現某功能的魯棒圖中只含一個控制物件，則是明顯地”設計不足“--這個控制物件的名字必然和功能的名字相同，這意味著沒有對職責進行真正的切分。

7.勿關注細節：

     初步設計不應該關注細節。例如，

     1.對每個物件只標識物件名，都未識別其屬性和方法。

      2.”活期賬戶銷戶介面“，具體可能是對話方塊，WEB介面，字元終端介面,但魯棒圖中沒有關心這些細節問題。

      3.”客戶資料“ 等實體物件須要持久化嗎？不關心，更不關心用Table還是用File或其他方式持久化。

      4.沒有標識控制流的嚴格順序。

8.勿過分關注UI，除非輔助或驗證UI設計。

    過分關心UI，會陷入諸如有幾個視窗，是不是有一個專門的結果顯示頁面等諸多細節之中，初步設計就沒法做了。

   別忘記了，初步設計的目標是發現職責。初步設計無須展開架構設計細節，否則就背上了”包袱“，這是複雜系統架構設計起步時的大忌

3.4.3、約束的4大型別--轉化成圖片

A、業務環境的約束（客戶或出資方）

上線時間？預算限制？整合需求？

業務領域？業務規則或業務限制？

法律法規或專利的限制？

更多……

B、使用環境的約束（系統使用者）

何階層使用者？年齡段和偏好？多個國家？

是否存在網路較弱或延遲情況？裝置移動的情況下？

更多……

C、構建環境的約束（開發者和維護人員）

技術水平，城市分佈，磨合程度？

開發管理程度？原始碼保密？網路環境？

更多……

D、技術環境的約束（技術選型）

技術平臺、中介軟體、程式語言的流行度，認同度，優缺點？

技術發展趨勢？

更多……

3.5、非功能及約束貫穿整個設計過程

       我們知道在系統架構設計的過程中，不能僅僅考慮功能實現，還需要持續考慮非功能性需求（質量）及約束內容，往往這些是系統架構成功的關鍵點，某些時候我們往往因為忽略或遺漏這些內容而導致架構失敗。

       如何設計才能使這個系統高效能呢？場景思維是關鍵。也就是說，我們要明確系統所處於的哪些真實具體的場景，對高效能這個大的籠統的目標最有意義：

        我們可以採取-“目標-場景-決策”表來輔助我們系統化的梳理非功能性需求內容：

         由此可見，通過"目標-場景-決策表"既可以幫助我們引入新的設計（例如表中決策"HTML靜態化"），也可以幫助我們改進之前架構設計存在的問題及痛點，還可以再分析的過程中幫我們找到關鍵非功能需求，所以在後續的架構設計過程中我們需要善用該表。

四、HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-下篇（目錄大綱）

一、架構分析階段主要做什麼？

1、分析業務需求和約束背後的衍生需求

2、發現遺漏需求

3、確定關鍵功能

4、確定關鍵質量

5、確定關鍵約束

二、如何找出關鍵的功能性、非功能性需求、關鍵約束？

1、功能需求影響架構的基本原理：職責協作鏈

2、質量需求影響架構的基本原理：進一步質疑

3、分析約束影響架構的基本原理：直接制約、轉化為功能或質量需求

4、•第1步：需求結構化；•第2步：分析約束影響；•第3步：確定關鍵質量；•第4步：確定關鍵功能

三、HRMS系統的關鍵功能、關鍵質量指標及約束

1、結合Amazon的案例來梳理，最後得出結論？

2、確定關鍵功能

3、確定關鍵質量指標

4、確定關鍵約束

四、架構分析階段總結

1、架構師分析系統的第一步是什麼？

2、找出關鍵點是二維表？

3、如何提升分析能力是關鍵（實踐出真知）？

4、知識提升（除了BAT及大的網際網路公司可能會遇到技術瓶頸，我們現在基本上遇到的問題，大家都遇到了）

5、過猶不及（不要過度設計，能解決業務問題就是最好的，不要鏡中花、水中月）

五、更多資訊

關於更多的系統架構方面的知識，我已建立了交流群，相關資料會第一時間在群裡分享，歡迎大家入群互相學習交流：

微信群：（掃碼入群-名額有限）