什么是架構師?？項目階段與軟件文檔分析

一、什么是架構師

架構師本身是設計人員，但是與設計人員最大的區(qū)別在于，前者必須更加注重：（1）通用，（2）重用。這依賴于（1）豐富的行業(yè)實踐經驗，（2）廣泛的技術認識。當設計人員有著較多的行業(yè)實踐體驗時，就會比較強烈感受到需要提煉、總結需求與解決方法的共性，而追求產品通用性與重用。架構師必須是技術高手，但是首先側重技術廣度，其次才是技術深度；也可以說是首先要求對技術如何恰當使用的理解，其次才是技術的具體使用。

架構師對于具體項目或者模塊任務，主要是關注建模與算法，然后予以分割，為分配實現任務作準備。模型、算法、分割任務一般都應該表達為系列化的文檔，還常常以講解的形式與相關人員溝通，來逐步達成共識。模型與算法在需求分析階段也需要，所以會使用UML、OOP、E-R等等專業(yè)圖形。架構師還常常習慣性地，把實際項目的需求部分，甚至整體向共性問題的層次上升，對于設計模型也追求“優(yōu)雅”，而把工期拉長，呵呵。

架構師編寫需求分析，也會常常側重對研發(fā)的指導，就是說文檔的技術性強，而使得客戶感到抽象與枯燥，這也是個特點！

在一些公司的職位設置里，可能讓架構師偏向管理工作。但是要注意，架構師是協助項目經理，而不是代替項目經理的整體或者一部分。

把軟件團隊幾個高層職位做個比較，可以這么概括：普通設計師要達到“能使用”的要求，而系統架構師是“重用與通用”，技術架構師是“足夠用”，技術專家“會的多”，領域專家對特定領域“精深”，項目經理是“協調、管理”，業(yè)務專家“對業(yè)務精通”而不論技術。

總之，架構師的基本職責是建模、算法、分割，并且提高層次來追求通用與重用。

二、項目階段與軟件文檔分析

軟件項目前期工作中常常會有這些文檔：行業(yè)解決方案、需求分析說明書、概要設計說明書、詳細設計說明書，可能還有可行性論證等等。這些文檔顯然各有區(qū)別。

當軟件公司人員接觸客戶時，客戶首先會向前者索要解決方案，或者是行業(yè)解決方案，要求項目/任務目標（產品）描述：（1）實現那些功能與流程，（2）可以解決那些問題，（3）達到什么樣的效果。

接下來，可能雙方確立解決方案的可行性；當然也可能認為簡單，而直接跳過可行性論證階段。

然后，客戶可能故作專業(yè)的向軟件公司索要需求分析。需求分析說明書，又叫產品規(guī)格描述，它是用來描述，也是限定產品的外觀指標（要實現的功能與流程，操作說明，等等），及可能的性能指標、外擴接口協議、部署配置要求等等。總之，需求分析階段是要確定軟件研發(fā)要實現的目標，“說明要實現什么”；至于怎么實現，則是設計階段與編碼階段的任務。

設計階段“定義如何實現”。設計文檔：表達系統模型與算法的模塊劃分、模塊部署/配置、單元規(guī)格及接口規(guī)范，以及算法（有復雜度的部分）描述。設計階段又細分概要設計與詳細設計兩個階段：概要設計文檔需要從概念層次來表達以上內容；詳細設計文檔則是側重以上內容的技術規(guī)格以及確定算法，要求準確性及標準性。

編碼階段則是具體的實現。

這樣看來，解決方案與需求分析說明書應該有著以下區(qū)別：解決方案更像是繪制美好的藍圖，更加趨向市場人員的領域；而后者從理論上來說，需要在“實現什么”這個目標上，可以同時指導客戶與軟件研發(fā)人員，比解決方案要專業(yè)技術性強的多。實踐中幾乎找不到客戶人員與軟件技術人員來較長時期的研究UML圖，所以實踐中更是側重指導研發(fā)人員。實踐中，在解決方案之后客戶要求需求分析時，真有不少軟件公司仍然不讓技術人員介入，還是讓市場人員把解決方案改改，就當成需求分析說明書，然后非常協調、溝通能力強的把客戶給解決掉了。當項目簡單時，軟件研發(fā)人員傾聽市場人員轉達，憑經驗基本上能把項目完成。但是項目復雜時，研發(fā)人員的不到市場人員的需求分析說明書，自己也不可能憑空生產這東西，大多數時候會成為“弱勢人群”。

三、筆者最近入職一家軟件公司做架構師，發(fā)生了一些適應期的問題，這里寫出來，與大家共勉。

本人從事行業(yè)多年了，感受到了許可共性的需求及對應解決方法，迫切地需要分析、總結，并且規(guī)劃、設計并實現為成品系統或者子系統，最低也是模塊重用或者模版套用。而這家公司也可以算是本地業(yè)內首次招聘架構師，呵呵，看來有共同的感受，與公司領導接觸也是如此，就入職了。

第一天部門領導說，做個方案，實現通用的權限管理，等等。筆者以前實現過基于角色-功能的權限許可，也靜態(tài)代碼實現過依賴組織結構的資源許可（當然僅僅依賴于組織結構的上下級），有實踐感受，欣然開工了。

新人，時間也太短，入手后發(fā)現了通用的資源權限是個關鍵難點不好設計，就來不及編撰完整文檔了，忙著畫了些主要的類圖、關系圖，計劃講解主要設計思路。三天后第一次研討（有些評審性質），與會兩種人：行業(yè)解決方案部（應該是技術性的業(yè)務人員）、研發(fā)部。我并沒有做到提前在會下的溝通！

行業(yè)解決方案部：我們需要看到你說明能實現什么，解決什么問題，怎么實現？

研發(fā)部：看不懂你畫的UML圖，你用數據表更好說明問題！這次會議到下班時結束，沒有結果，沒得到認可。這時候，我還沒搞清楚原因。

我思考是不是因為我關鍵問題沒把算法理出來，寫的文檔不完整，講解表達也不夠清晰、條理？然后在公司又寫了2天，清明節(jié)放假3天在家里加班，搞了一套基于SOA后臺集中認證與提交時許可驗證、配置條件式資源范圍定義用于向角色分配的通用權限管理子系統模型，初步形成了文件，包含子系統界面，中間SOA后臺，后端數據庫，以及相應驗證案例。當然，這樣的東西在一周時間不可能把所有細節(jié)都理出來，除非盜用現成的。而且這樣的產品有實力的公司最少需要半年來實現，國家級公司更是嚴慎、完善到規(guī)劃至少一年時間。

再次開會研討與評審，還是不能得到全面認可。但是我終于反應過來了，包含2點：
（1）本公司研發(fā)部門首先要向行業(yè)解決方案部“出方案”。行業(yè)部人員向研發(fā)部口口聲聲要的“需求”，其實是他們習慣了的解決方案類的文檔，不是專業(yè)的需求分析說明書，所以“需要看到你說明能實現什么，解決什么問題，怎么實現”。而我真把自己當成總結提煉共性需求的架構師去畫UML圖，所以難于溝通到一個共同點上。

（2）也許該公司曾經有想法搞個高級的通用模型/產品，但是還是針對眼前火燒眉毛的需要，不能像我上面方案那樣太高級而需要太長時間。所以讓我簡化，別考慮字段級權限，別考慮通用的資源范圍定義與分配，只要實現對組織結構依賴的就可以了。

接下來，我按照解決方案的規(guī)范，分析實際需求，簡化要實現的目標，用2天多時間編寫出來《簡單通用權限管理模型技術解決方案》，中間與部門領導研討幾次，自感這個文件可以定下來了，但是相關人員沒時間審閱。我就繼續(xù)推進設計吧。