什么是架構(gòu)師?？項(xiàng)目階段與軟件文檔分析

一、什么是架構(gòu)師

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

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

架構(gòu)師編寫需求分析，也會(huì)常常側(cè)重對(duì)研發(fā)的指導(dǎo)，就是說文檔的技術(shù)性強(qiáng)，而使得客戶感到抽象與枯燥，這也是個(gè)特點(diǎn)！

在一些公司的職位設(shè)置里，可能讓架構(gòu)師偏向管理工作。但是要注意，架構(gòu)師是協(xié)助項(xiàng)目經(jīng)理，而不是代替項(xiàng)目經(jīng)理的整體或者一部分。

把軟件團(tuán)隊(duì)幾個(gè)高層職位做個(gè)比較，可以這么概括：普通設(shè)計(jì)師要達(dá)到“能使用”的要求，而系統(tǒng)架構(gòu)師是“重用與通用”，技術(shù)架構(gòu)師是“足夠用”，技術(shù)專家“會(huì)的多”，領(lǐng)域?qū)＜覍?duì)特定領(lǐng)域“精深”，項(xiàng)目經(jīng)理是“協(xié)調(diào)、管理”，業(yè)務(wù)專家“對(duì)業(yè)務(wù)精通”而不論技術(shù)。

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

二、項(xiàng)目階段與軟件文檔分析

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

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

接下來，可能雙方確立解決方案的可行性；當(dāng)然也可能認(rèn)為簡(jiǎn)單，而直接跳過可行性論證階段。

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

設(shè)計(jì)階段“定義如何實(shí)現(xiàn)”。設(shè)計(jì)文檔：表達(dá)系統(tǒng)模型與算法的模塊劃分、模塊部署/配置、單元規(guī)格及接口規(guī)范，以及算法（有復(fù)雜度的部分）描述。設(shè)計(jì)階段又細(xì)分概要設(shè)計(jì)與詳細(xì)設(shè)計(jì)兩個(gè)階段：概要設(shè)計(jì)文檔需要從概念層次來表達(dá)以上內(nèi)容；詳細(xì)設(shè)計(jì)文檔則是側(cè)重以上內(nèi)容的技術(shù)規(guī)格以及確定算法，要求準(zhǔn)確性及標(biāo)準(zhǔn)性。

編碼階段則是具體的實(shí)現(xiàn)。

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

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

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

第一天部門領(lǐng)導(dǎo)說，做個(gè)方案，實(shí)現(xiàn)通用的權(quán)限管理，等等。筆者以前實(shí)現(xiàn)過基于角色-功能的權(quán)限許可，也靜態(tài)代碼實(shí)現(xiàn)過依賴組織結(jié)構(gòu)的資源許可（當(dāng)然僅僅依賴于組織結(jié)構(gòu)的上下級(jí)），有實(shí)踐感受，欣然開工了。

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

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

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

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

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

（2）也許該公司曾經(jīng)有想法搞個(gè)高級(jí)的通用模型/產(chǎn)品，但是還是針對(duì)眼前火燒眉毛的需要，不能像我上面方案那樣太高級(jí)而需要太長(zhǎng)時(shí)間。所以讓我簡(jiǎn)化，別考慮字段級(jí)權(quán)限，別考慮通用的資源范圍定義與分配，只要實(shí)現(xiàn)對(duì)組織結(jié)構(gòu)依賴的就可以了。

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