HRMS(人力資源管理系統)-從單機應用到SaaS應用-架構分析(功能性、非功能性、關鍵約束)-上篇

1、開篇

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

       本篇主要想經過HRMS系統與你們分享下架構設計環節中很是重要的基礎環節-架構準備-的關鍵工做內容，請你們務必該環節的工做內容，這是全部成功架構設計的前提，爲可以系統的闡述清晰該領域的注意事項及工做方法，因此篇幅會較長，請你們細細看完，若是有闡述不清晰或遺漏的地方，還請你們指出。

      在闡述具體的架構工做方法以前，請你們先查看如下三方面的內容：

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

      請閱讀《HRMS(人力資源管理系統)-從單機應用到SaaS應用-系統介紹》

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

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

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

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

      請閱讀《系統架構系列-開篇介紹》

 

2、爲何不少系統架構的設計會失敗？

       在這10多年的工做經驗中見過也參與了很多失敗的架構項目，基本上總結下來發現了有不少種緣由可能致使架構設計失敗，因此說一個系統的架構設計是一個系統化的工程，不是隻進行模塊設計或功能設計那麼簡單，須要不斷學習和積累經驗，站在巨人的肩膀上思考問題，讓咱們少走彎路。成功和失敗的經驗都值得咱們去總結和思考，那麼基於以前總結的內容，我梳理完能夠概括爲如下幾個方面：

A、架構師不懂需求

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

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

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

2.一、架構師不懂需求

       技術是爲業務服務的，請每一位架構師或系統的設計者謹記該理念，不知道你們有沒有總結過目前出現的各種技術的特色，我發現每一次的技術更迭就是爲了解決前一主流技術存在的不足或某些領域的缺陷而產生的，因此，咱們在選擇一項技術或選型時，須要結合業務的實際狀況靈活選擇，必定要選擇最好、最優的，考慮將來的變化、不肯定、擴展性等非功能性需求。讓咱們的架構設計有必定的擴展性及健壯性。架構也是持續迭代的（請你們有空網上看看阿里巴巴、騰訊、百度、京東等互聯網公司的架構迭代過程），非一蹴而就的。

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

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

2.三、缺乏關鍵實踐及方法論

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

       另外，千萬不要認爲本身設計的架構方案就是最好的，要不斷的質疑架構的合理性及最優性，經得起你們的質疑及實際的考驗，而且爲確保架構的有效落地，須要持續的跟蹤確認，確保方向不會出現誤差。

2.四、未驗證架構的可行性並做出調整

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

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

●高開高走落不到實處

● 理想與現實須要折中

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

● 爲虛無的將來埋單而過分設計

● 過早作出關鍵性決策

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

● 埋頭幹活兒缺少前瞻性

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

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

 

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

3.一、EA架構方法論體系

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

       上述圖片中呈現了EA方法論的5類具體的實踐，因爲篇幅有限，我這裏不挨個展開介紹概念及具體內容。若是想了解詳情請你們自行搜索。

       能夠說咱們在作一個複雜系統的設計及規劃時，正確的方法論會知道咱們正確的作事，作正確的事，因此這對咱們每一個架構師來講很是重要，請你們務必瞭解，固然對於EA理論的具體實踐也有不少具體的方法實踐模式，這裏也能夠概括爲幾類，後面咱們將詳細闡述。

 

3.二、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.二、質疑驅動架構設計（始終抱着質疑的思想來思考架構設計方案）

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

以HRMS系統爲例：

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

 

3.三、多階段/多視圖

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

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

       3.3.一、架構設計過程（3個階段）

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

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

實踐要點：摒棄「需求列表」方式，創建二維需求觀

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

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

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

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

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

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

最大誤區：架構=模塊 + 接口

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

思惟工具：包圖、包-接口圖、灰盒包圖、序列圖、目標-場景-決策表

 

         3.3.二、架構設計5視圖

         5視圖法分析的意義：

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

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

3.四、內置最佳實踐(經驗總結)

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

      總體來講咱們能夠概括在邏輯架構、業務建模、關鍵約束、非功能性需求（質量需求）等幾方面的經驗。

3.4.一、邏輯架構設計過程當中的10條經驗

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

2) 劃分子系統：分區的引入

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

4) 接口的定義：協做決定接口

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

6) 包-接口圖：從結構到待辦的橋

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

8) 按部就班的螺旋思惟

9) 設計模式：包內結構

10) 設計模式：包間協做

       在實際的邏輯架構的設計過程當中，上面的10條經驗會很是有價值，咱們僅需參考上面的原則來設計系統的邏輯架構，基本上架構成功的概率很大。再結合其餘的4個架構視圖便可獲得最優的系統架構。

3.4.二、基於魯棒圖進行初步設計的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.三、約束的4大類型--轉化成圖片

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

上線時間？預算限制？集成需求？

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

法律法規或專利的限制？

更多……

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

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

是否存在網絡較弱或延遲狀況？設備移動的狀況下？

更多……

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

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

開發管理程度？源代碼保密？網絡環境？

更多……

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

技術平臺、中間件、編程語言的流行度，認同度，優缺點？

技術發展趨勢？

更多……

 

3.五、非功能及約束貫穿整個設計過程

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

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

        咱們能夠採起-「目標-場景-決策」表來輔助咱們系統化的梳理非功能性需求內容：

         

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

 

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

1、架構分析階段主要作什麼？

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

二、發現遺漏需求

三、肯定關鍵功能

四、肯定關鍵質量

五、肯定關鍵約束

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

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

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

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

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

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

一、結合HRMS系統的綜合分析，最後得出結論？

二、肯定關鍵功能

三、肯定關鍵質量指標

四、肯定關鍵約束

4、架構分析階段總結

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

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

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

四、知識提高（除了BAT及大的互聯網公司可能會遇到技術瓶頸，咱們如今基本上遇到的問題，你們都遇到了）

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

 

5、更多信息

關於更多的系統架構方面的知識，我已創建了交流羣，相關資料會第一時間在羣裏分享，歡迎你們入羣互相學習交流：

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