明確架構目標

在MMN的宏觀視圖中，包括了三個過程環節：定義架構概圖、架構全局分析以及構建概念模型。這是一個按部就班的過程，是系統架構總體分析的逐步細化。這個過程的關鍵是找準架構分析的切入點。這正是定義架構概圖所要解決的問題。定義架構概圖須要明確架構目標、調查架構資源和分析用例場景。這三個活動能夠是並行的，至少彼此之間是相互影響、相互做用的。以下圖所示：

雖然這些活動是並行的，但從一開始明確架構目標纔是最佳的選擇，由於架構目標是整個架構過程所要努力達到的方向。不瞭解架構目標，搭建出來的系統架構再好，也可能不符合客戶的需求。架構目標來源於需求，主要指客戶或其餘利益相關人提出的項目（產品）願景。願景表達了客戶的目標以及對系統的指望。從願景中咱們能夠得到許多架構分析所須要知道的知識，例如明確客戶最指望達到的目標，以此能夠肯定場景與風險的優先級；瞭解客戶的不一樣目標，能夠由此識別系統客戶的不一樣角色，明確不一樣的利益相關人的態度。

經過需求的願景和範圍，就能夠肯定架構的實現目標。識別架構目標，就須要瞭解是誰須要使用架構，理解架構的約束（技術約束、使用約束和部署約束）。如同架構在軟件開發中起到的做用，架構目標一方面是業務需求和客戶的要求，另外一方面也是技術和應用系統的要求。架構目標是需求分析師、架構師和客戶達成的一致共識，而一旦確立了架構目標，該目標就會成爲團隊的一致共識。

架構旨在爲業務需求和技術需求之間搭建起相同的橋樑，並找到合適的方式實現這些需求。好的架構必須可以減小與技術解決方案相關的業務風險。它最好是靈活的，可以處理軟硬件以及業務需求等的變化，考慮總體影響設計決策的因素，在質量屬性之間權衡，並努力知足用戶、系統和業務的需求，如圖所示：

在瞭解用戶的目標時，首先須要明確用戶的分類，由於不一樣類別的用戶，他們的關注點是不相同的。例如投資者或者管理層關注的目標，可能更多地是考慮組織因素，例如項目成本，週期與收益。若是是系統的使用者，則主要考慮業務因素，關心的是與本身工做相關的功能是否知足需求。若是是系統的運維成員，則主要考慮技術因素，例如系統的可維護性、健壯性、可擴展性、可伸縮性等質量屬性。

在明確架構的業務目標時，咱們並不須要瞭解每一個細節功能的需求，而是關注業務的指望值。瞭解業務目標，不是要識別業務流程、業務規則或者業務所要處理的數據。例如業務目標提出了提高工做效率，改善工做質量的要求，肯定了應該由系統自動完成的功能，明確對業務需求變化的處理。

系統的目標和技術直接相關，尤爲是架構的質量因素。系統目標可能包含對系統規模、用戶數、併發量等的要求。系統目標也可能對軟硬件平臺提出了約束性要求。

總體而言，架構應該：
1）公開系統的結構，但隱藏實現細節。
2）實現全部的用例。
3）試圖知足不一樣涉衆的要求。
4）知足功能需求和質量需求。

我曾經爲一個集團公司開發相似ERP的系統。這個集團從事軟件外包業務，它但願可以搭建一個平臺，實現人力資源、客戶資源與項目資源的整合。系統包括人力資源管理、客戶關係管理和項目過程管理等主要模塊。系統用戶爲集團的全部員工，但角色的不一樣，決定了他們關注點之間的區別。

在提出方案的開始階段，咱們注意到管理層用戶對於系統的預期目標，那就是避免「信息孤島」，實現資源的可控，以免資源浪費，或者避免由於資源的缺少而致使業務的流失。例如，客戶方須要集團提供20名各個層次的Java開發人員，則市場部門在肯定是否簽定該合同以前，就須要經過系統查詢集團的人力資源庫，瞭解現有的人力資源是否匹配客戶需求。若是匹配，還須要判斷人力成本，以決定合同的標的。若是不具有，則須要人力資源啓動招聘流程。管理人員可能還須要瞭解開發人員的閒置率，跟蹤項目的進展狀況，以及開發人員在項目中承擔的職責和完成質量。

在進行需求調研的過程當中，咱們又瞭解到系統最終用戶的訴求。例如人力資源部門的普通員工對於系統的要求很是簡單，就是但願系統的操做方便快捷，最好可以提供導入Excel文件的支持。市場部則須要系統提供合同文件的管理功能，包括文件的上傳下載。

經過對用戶、業務和系統的需求分析，咱們就能夠初步肯定架構目標。例如： 1）系統主要分爲人力資源管理、客戶關係管理和項目過程管理模塊；三個模塊共享同一個數據庫；爲達到重用目的，須要在這三個模塊中抽取出公共模塊，例如員工信息管理； 2）系統應達到輔助決策的功能，以知足管理者對資源的控制、分析、跟蹤與查詢功能； 3）系統具備良好的可用性；提供設計簡潔的導航功能與菜單；可以與Office進行集成。系統需快速搭建原型，以更快地瞭解用戶的反饋； 4）系統應基於角色與組織進行權限控制； 5）爲部署的簡單性，系統應採用B/S應用架構； 6）系統的業務組件應該是鬆散耦合的；