|
|
相關文章：MMN實用架構過程概覽
在MMN的宏觀視圖中，包括了三個過程環節：定義架構概圖、架構全局分析以及構建概念模型。這是一個循序漸進的過程，是系統架構整體分析的逐步細化。這個過程的關鍵是找準架構分析的切入點。這正是定義架構概圖所要解決的問題。定義架構概圖需要明確架構目標、調查架構資源和分析用例場景。這三個活動可以是并行的，至少彼此之間是相互影響、相互作用的。如下圖所示：
雖然這些活動是并行的，但從一開始明確架構目標才是最佳的選擇，因為架構目標是整個架構過程所要努力達到的方向。不了解架構目標，搭建出來的系統架構再好，也可能不符合客戶的需求。架構目標來源于需求，主要指客戶或其他利益相關人提出的項目（產品）愿景。愿景表達了客戶的目標以及對系統的期望。從愿景中我們可以獲得許多架構分析所需要知道的知識，例如明確客戶最期望達到的目標，以此可以確定場景與風險的優先級；了解客戶的不同目標，可以由此識別系統客戶的不同角色，明確不同的利益相關人的態度。
通過需求的愿景和范圍，就可以確定架構的實現目標。識別架構目標，就需要了解是誰需要使用架構，理解架構的約束（技術約束、使用約束和部署約束）。如同架構在軟件開發中起到的作用，架構目標一方面是業務需求和客戶的要求，另一方面也是技術和應用系統的要求。架構目標是需求分析師、架構師和客戶達成的一致共識，而一旦確立了架構目標，該目標就會成為團隊的一致共識。
架構旨在為業務需求和技術需求之間搭建起相同的橋梁，并找到合適的方式實現這些需求。好的架構必須能夠減少與技術解決方案相關的業務風險。它最好是靈活的，能夠處理軟硬件以及業務需求等的變化，考慮整體影響設計決策的因素，在質量屬性之間權衡，并努力滿足用戶、系統和業務的需求，如圖所示：
在了解用戶的目標時，首先需要明確用戶的分類，因為不同類別的用戶，他們的關注點是不相同的。例如投資者或者管理層關注的目標，可能更多地是考慮組織因素，例如項目成本，周期與收益。如果是系統的使用者，則主要考慮業務因素，關心的是與自己工作相關的功能是否滿足需求。如果是系統的運維成員，則主要考慮技術因素，例如系統的可維護性、健壯性、可擴展性、可伸縮性等質量屬性。
在明確架構的業務目標時，我們并不需要了解每個細節功能的需求，而是關注業務的期望值。了解業務目標，不是要識別業務流程、業務規則或者業務所要處理的數據。例如業務目標提出了提升工作效率，改善工作質量的要求，確定了應該由系統自動完成的功能，明確對業務需求變化的處理。
系統的目標和技術直接相關，尤其是架構的質量因素。系統目標可能包含對系統規模、用戶數、并發量等的要求。系統目標也可能對軟硬件平臺提出了約束性要求。
整體而言，架構應該：
1）公開系統的結構，但隱藏實現細節。
2）實現所有的用例。
3）試圖滿足不同涉眾的要求。
4）滿足功能需求和質量需求。
我曾經為一個集團公司開發類似ERP的系統。這個集團從事軟件外包業務，它希望能夠搭建一個平臺，實現人力資源、客戶資源與項目資源的整合。系統包括人力資源管理、客戶關系管理和項目過程管理等主要模塊。系統用戶為集團的所有員工，但角色的不同，決定了他們關注點之間的區別。
在提出方案的開始階段，我們注意到管理層用戶對于系統的預期目標，那就是避免“信息孤島”，實現資源的可控，以避免資源浪費，或者避免因為資源的缺乏而導致業務的流失。例如，客戶方需要集團提供20名各個層次的Java開發人員，則市場部門在確定是否簽訂該合同之前，就需要通過系統查詢集團的人力資源庫，了解現有的人力資源是否匹配客戶需求。如果匹配，還需要判斷人力成本，以決定合同的標的。如果不具備，則需要人力資源啟動招聘流程。管理人員可能還需要了解開發人員的閑置率，跟蹤項目的進展情況，以及開發人員在項目中承擔的職責和完成質量。
在進行需求調研的過程中，我們又了解到系統最終用戶的訴求。例如人力資源部門的普通員工對于系統的要求非常簡單，就是希望系統的操作方便快捷，最好能夠提供導入Excel文件的支持。市場部則需要系統提供合同文件的管理功能，包括文件的上傳下載。
通過對用戶、業務和系統的需求分析，我們就可以初步確定架構目標。例如：
1）系統主要分為人力資源管理、客戶關系管理和項目過程管理模塊；三個模塊共享同一個數據庫；為達到重用目的，需要在這三個模塊中抽取出公共模塊，例如員工信息管理；
2）系統應達到輔助決策的功能，以滿足管理者對資源的控制、分析、跟蹤與查詢功能；
3）系統具有良好的可用性；提供設計簡潔的導航功能與菜單；能夠與Office進行集成。系統需快速搭建原型，以更快地了解用戶的反饋；
4）系統應基于角色與組織進行權限控制；
5）為部署的簡單性，系統應采用B/S應用架構；
6）系統的業務組件應該是松散耦合的；
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
