研發(fā)團(tuán)隊(duì)的總體架構(gòu)設(shè)計(jì)方案

1 研發(fā)團(tuán)隊(duì)的總體架構(gòu)設(shè)計(jì)方案 寫在前面 企業(yè)總體架構(gòu)是什么 有什么用 具體怎么做呢 以我曾任職的公司為案例 一起來(lái)探討這個(gè)問(wèn)題 這 家公司當(dāng)時(shí)有 200 位研發(fā)人員和 200 多臺(tái)服務(wù)器 我剛進(jìn)這家公司時(shí) 他們的系統(tǒng)就已經(jīng)玩不下去了 總是出現(xiàn)各種問(wèn)題 例如日常發(fā)布系統(tǒng)時(shí)或訪問(wèn)量稍微過(guò)大時(shí) 系統(tǒng)就會(huì)出現(xiàn)很多故障 而且找不到故 障發(fā)生的根本原因 2 我進(jìn)這家公司后的主要任務(wù)就是對(duì)這個(gè)系統(tǒng)進(jìn)行升級(jí)改造 花了一個(gè)半月的時(shí)間寫了那份企業(yè)總體架構(gòu) 文檔 文檔共有 124 頁(yè) 直接指導(dǎo)了之后的技術(shù)改造 下圖是那份文檔的目錄 一 企業(yè)商務(wù)模型 企業(yè)商務(wù)模型的內(nèi)容主要包括主營(yíng)業(yè)務(wù) 商務(wù)模式 商務(wù)主體 競(jìng)品分析 組織架構(gòu) 商務(wù)運(yùn)作模型和 業(yè)務(wù)流程等 主營(yíng)業(yè)務(wù)即公司做什么業(yè)務(wù) 商業(yè)模式即公司怎么賺錢 商務(wù)主體即哪幾個(gè)人在一起做這門生意 競(jìng)品 分析即了解競(jìng)爭(zhēng)對(duì)手的情況 組織架構(gòu)即公司部門是怎么劃分的 組織架構(gòu)圖中標(biāo)出人數(shù) 根據(jù)系統(tǒng)與 業(yè)務(wù)之間對(duì)應(yīng)關(guān)系 可以了解系統(tǒng)中哪些模塊使用頻率高 以及業(yè)務(wù)與其對(duì)應(yīng)模塊的復(fù)雜度 商務(wù)運(yùn)作 模型即公司是如何運(yùn)作的 售前做計(jì)劃 找供應(yīng)商把東西買進(jìn)來(lái)后 經(jīng)過(guò)服務(wù)和結(jié)算 再賣給我們的經(jīng) 銷商和采購(gòu)商 使我們獲得利潤(rùn) 售后進(jìn)行大數(shù)據(jù)分析最后又指導(dǎo)著我們的售前 整個(gè)過(guò)程形成良性循 環(huán) 可以把一家公司想象成一臺(tái)機(jī)器 輸進(jìn)去的是錢 轉(zhuǎn)一轉(zhuǎn)后 又能夠生出更多的錢出來(lái) 3 最后是業(yè)務(wù)流程和更多業(yè)務(wù)資料下載 業(yè)務(wù)流程包括預(yù)訂流程 訂單處理流程 產(chǎn)品供應(yīng)流程 財(cái)務(wù)結(jié) 算流程 賬戶管理流程 企業(yè)商務(wù)模型的建立 指導(dǎo)著整個(gè)應(yīng)用系統(tǒng)模型的建立 畢竟系統(tǒng)是為業(yè)務(wù)服 務(wù)的 二 架構(gòu)現(xiàn)狀 架構(gòu)現(xiàn)狀的內(nèi)容主要包括 功能架構(gòu) 應(yīng)用架構(gòu) 數(shù)據(jù)設(shè)計(jì)和物理架構(gòu) 功能架構(gòu) 4 功能架構(gòu)主要包括功能 角色和權(quán)限三部分 功能是企業(yè)服務(wù) 用戶使用的每一個(gè)功能 就是企業(yè)的每 一個(gè)服務(wù) 角色是用戶操作的歸類 功能與角色的對(duì)應(yīng)關(guān)系即權(quán)限 了解系統(tǒng)架構(gòu)的現(xiàn)狀 從功能架構(gòu) 開始 應(yīng)用架構(gòu) 應(yīng)用就是處理器 應(yīng)用架構(gòu)的內(nèi)容包括現(xiàn)有架構(gòu)圖 Web 應(yīng)用現(xiàn)狀 作業(yè)小應(yīng)用 Job 現(xiàn)狀和接口架 構(gòu) 其中 接口是應(yīng)用層面的關(guān)鍵 它是一個(gè)程序與另外一個(gè)程序交互的部分 5 應(yīng)用架構(gòu)圖表列出了哪些業(yè)務(wù)邏輯沒(méi)有被重用 換句話說(shuō)業(yè)務(wù)邏輯被多少個(gè)應(yīng)用調(diào)用 就需要被重復(fù)開 發(fā)多少次 一旦改了一個(gè)地方 就要同時(shí)改多個(gè)地方 導(dǎo)致系統(tǒng)開發(fā)效率非常低下 各業(yè)務(wù)邏輯如預(yù)訂 邏輯 雖然被多個(gè)應(yīng)用調(diào)用 但它們與應(yīng)用是沒(méi)有關(guān)系的 業(yè)務(wù)邏輯可以獨(dú)立的存在 也可以寄宿于多 個(gè)應(yīng)用 業(yè)務(wù)邏輯是一個(gè)業(yè)務(wù)操作的抽象 而業(yè)務(wù)應(yīng)用與業(yè)務(wù)部門共同完成了業(yè)務(wù)操作 數(shù)據(jù)設(shè)計(jì) 100 多個(gè)數(shù)據(jù)庫(kù) 一萬(wàn)多張表 能否使用一張 E R 圖來(lái)表示呢 它是可以的 數(shù)據(jù)設(shè)計(jì)依賴于企業(yè) 的數(shù)據(jù) 而不是數(shù)據(jù)庫(kù)的設(shè)計(jì) 對(duì)企業(yè)數(shù)據(jù)適當(dāng)做歸類 會(huì)直接導(dǎo)致數(shù)據(jù)設(shè)計(jì) 最終畫出 E R 圖 數(shù)據(jù) 設(shè)計(jì)完成后 數(shù)據(jù)庫(kù)設(shè)計(jì)就自然而然出來(lái)了 超越庫(kù) 超越表去看這張 E R 圖 可以看出它包括產(chǎn)品 訂單 結(jié)算 用戶 基礎(chǔ)設(shè)施這五類數(shù)據(jù) 低層的 E R 圖可以變 但是高層的 E R 圖一般不會(huì)變化 因?yàn)樗歉鶕?jù)你的業(yè)務(wù)模型而定 業(yè)務(wù)模型穩(wěn)定 高層 E R 圖也是穩(wěn)定的 數(shù)據(jù)庫(kù)只要早期設(shè)計(jì)得好 是可以做到易伸縮 易拆分的 下圖從內(nèi)往外看 一個(gè)框既可以是一個(gè)庫(kù) 也可以是一個(gè)模塊 還可以 6 是一個(gè)表 在業(yè)務(wù)發(fā)展的早期它可以是一個(gè)庫(kù) 里面有 5 個(gè)模塊 中期可以分為 5 個(gè)庫(kù) 后期以更低級(jí) 別可以分為更多的庫(kù) 這與業(yè)務(wù)階段及系統(tǒng)復(fù)雜度相關(guān) 在數(shù)據(jù)的設(shè)計(jì)完成后 數(shù)據(jù)庫(kù)的設(shè)計(jì)也就很容 易規(guī)劃和調(diào)整 以上是數(shù)據(jù)庫(kù) 數(shù)據(jù)表之間的靜態(tài)關(guān)系 接下來(lái)我們介紹數(shù)據(jù)的流轉(zhuǎn)狀態(tài)即狀態(tài)圖 通過(guò)數(shù)據(jù)狀態(tài)圖去 了解現(xiàn)有數(shù)據(jù)流轉(zhuǎn)變遷 如國(guó)內(nèi)訂單狀態(tài)變遷圖 這種圖的價(jià)值不僅在于數(shù)據(jù)庫(kù)層 還在于服務(wù)化 圖 中的從等待支付到支付成功 中間有個(gè)支付行為 通過(guò)這個(gè)支付行為把數(shù)據(jù)狀態(tài)變更為支付成功 否則 繼續(xù)等待 直到超時(shí)關(guān)閉訂單 這個(gè)支付行為可以做成一個(gè)微服務(wù) 然后由不同的應(yīng)用去調(diào)用 7 物理架構(gòu) 物理架構(gòu)的內(nèi)容主要包括 IDC 機(jī)房 機(jī)房之間訪問(wèn)關(guān)系 機(jī)房?jī)?nèi)服務(wù)器物理部署圖 機(jī)房與業(yè)務(wù)分布 網(wǎng)站架構(gòu) 數(shù)據(jù)庫(kù)架構(gòu) 集群清單和域名清單 將這些內(nèi)容以列表和圖形方式整理出來(lái) 就會(huì)很容易了 解和發(fā)現(xiàn)問(wèn)題 只有發(fā)現(xiàn)問(wèn)題才能解決問(wèn)題 特別是在全局體系架構(gòu)方面 這也是表和圖的價(jià)值所在 當(dāng)時(shí)這家公司共有 5 個(gè)地區(qū) 8 個(gè)機(jī)房 雖然只有 200 多臺(tái)服務(wù)器 但分布很散 導(dǎo)致物理結(jié)構(gòu)復(fù)雜 通訊也很復(fù)雜 技改前故障不斷 其主要的一個(gè)原因就是物理架構(gòu)不合理 運(yùn)維要占 60 70 的責(zé) 8 任 當(dāng)時(shí)卻把責(zé)任歸咎為應(yīng)用架構(gòu) 這是個(gè)錯(cuò)誤的方向 物理架構(gòu)的不合理 應(yīng)用架構(gòu)是很難合理的 因?yàn)槲锢砑軜?gòu)是我們的基礎(chǔ)設(shè)施 位于最底層 下層為上層服務(wù) 運(yùn)維要為應(yīng)用服務(wù) 應(yīng)用要為業(yè)務(wù)服 務(wù) 業(yè)務(wù)要為客人服務(wù) 三 領(lǐng)域模型 領(lǐng)域模型關(guān)注概念 關(guān)注職責(zé) 關(guān)注邊界 關(guān)注交互 只有先確定職責(zé)和邊界 交互才會(huì)很清晰 領(lǐng)域 模型是針對(duì)現(xiàn)有問(wèn)題域提出一個(gè)系統(tǒng)解決方案 然后在圖表上建立完整的模型 如同用 AutoCAD 畫的 施工圖紙一樣 領(lǐng)域模型屬于概要設(shè)計(jì)階段 對(duì)于單個(gè)應(yīng)用架構(gòu)設(shè)計(jì) 首先需要了解業(yè)務(wù)和功能需求 用例圖 用例活動(dòng)圖 然后才是領(lǐng)域模型 業(yè)務(wù)流程圖是對(duì)業(yè)務(wù)操作的抽象 領(lǐng)域圖是對(duì)業(yè)務(wù)邏輯代碼 的抽象 9 建立領(lǐng)域詞匯是建立領(lǐng)域模型的第一步 它能統(tǒng)一詞匯明確概念 以減少一詞多義 一義多詞的情況 概念一旦確定 再擴(kuò)展屬性和行為 然后把它當(dāng)作一個(gè)單元與其它事物構(gòu)建在一起 就會(huì)很容易形成模 型 領(lǐng)域模型與企業(yè)商務(wù)模型中的業(yè)務(wù)流程圖有參考對(duì)應(yīng)關(guān)系 領(lǐng)域模型在實(shí)現(xiàn)時(shí)可大可小 在業(yè)務(wù)的 早期 在系統(tǒng)比較小的情況下 它有可能是一個(gè)類 當(dāng)系統(tǒng)做大了以后 它可能是個(gè) DLL 庫(kù) 再做更大 一點(diǎn)的時(shí)候 它可能是一個(gè)服務(wù) 給不同的應(yīng)用去調(diào)用 每一個(gè)方法都有成為服務(wù)的潛質(zhì) 特別是在系 統(tǒng)中后期 領(lǐng)域模型是業(yè)務(wù)邏輯代碼的施工圖紙 它不僅有利于對(duì)現(xiàn)在系統(tǒng)業(yè)務(wù)邏輯的了解 同時(shí)也指 導(dǎo)未來(lái)的架構(gòu)改造 四 架構(gòu)規(guī)劃 當(dāng)我們了解了業(yè)務(wù) 了解了架構(gòu)的現(xiàn)狀 發(fā)現(xiàn)現(xiàn)有架構(gòu)的問(wèn)題 接下來(lái)就可以做中遠(yuǎn)期架構(gòu)規(guī)劃 以及 架構(gòu)的調(diào)整和具體實(shí)施 架構(gòu)規(guī)劃內(nèi)容包括 頂層架構(gòu)規(guī)劃 網(wǎng)站功能規(guī)劃 應(yīng)用規(guī)劃 SOA 規(guī)劃 分 層架構(gòu)規(guī)劃 數(shù)據(jù)庫(kù)規(guī)劃和物理規(guī)劃等 頂層架構(gòu)規(guī)劃 10 上圖是頂層架構(gòu)的俯視圖和側(cè)視圖 第一張圖是俯視圖 坐在飛機(jī)上看 整個(gè)頂層架構(gòu)最外層的是功能 中間的是業(yè)務(wù)操作 內(nèi)層的是數(shù)據(jù) 功能對(duì)應(yīng)業(yè)務(wù)系統(tǒng)的用戶界面 操作對(duì)應(yīng)業(yè)務(wù)系統(tǒng)里的服務(wù) 數(shù)據(jù) 對(duì)應(yīng)業(yè)務(wù)系統(tǒng)的數(shù)據(jù)存儲(chǔ)如數(shù)據(jù)庫(kù) 第二張圖是剖面圖 切一刀來(lái)看 上層是應(yīng)用 中層是服務(wù)和框架 下層是基礎(chǔ)設(shè)施數(shù)據(jù)中心 從圖中的服務(wù)層可以看出 服務(wù)的歸類跟業(yè)務(wù)流程的歸類有很大關(guān)系 11 網(wǎng)站功能規(guī)劃 網(wǎng)站功能規(guī)劃就是功能的重新劃分 對(duì)照著架構(gòu)現(xiàn)狀 未來(lái)的功能應(yīng)該如何調(diào)整 如案例中的國(guó)內(nèi)網(wǎng)站 功能規(guī)劃 分別畫出了全局功能圖 采購(gòu)商功能圖 平臺(tái)商功能圖和供應(yīng)商功能圖 其實(shí)在做網(wǎng)站功能 規(guī)劃的時(shí)候 更多需要考慮現(xiàn)狀 而不是未來(lái)調(diào)整的部分 如果沒(méi)有很大問(wèn)題 則不做調(diào)整 尊重歷史 因?yàn)橛行〇|西 如名稱 用戶已經(jīng)使用很久了 調(diào)整往往比較難 合理大于準(zhǔn)確 應(yīng)用規(guī)劃 系統(tǒng)是什么 系統(tǒng) 元素 關(guān)系 應(yīng)用架構(gòu)是什么 應(yīng)用架構(gòu) 應(yīng)用 架構(gòu) 應(yīng)用就是系統(tǒng)的最小 單元 應(yīng)用分類和應(yīng)用編號(hào)則構(gòu)成了應(yīng)用關(guān)系即應(yīng)用的架構(gòu) 如上圖中的案例 應(yīng)用分類新建了框架 Fx 和公共服務(wù) CBS 原有的應(yīng)用架構(gòu)中并沒(méi)有這兩個(gè)的 而是分布在了不同的業(yè)務(wù)線中 從而導(dǎo)致重復(fù)建 設(shè) 應(yīng)用編號(hào)是給每個(gè)應(yīng)用分配一個(gè)六位的數(shù)字 ID 就如同我們的身份證一樣 頭兩位表示產(chǎn)品線 中 間兩位表示子系統(tǒng) 最后兩位表示應(yīng)用 如 應(yīng)用編號(hào)是應(yīng)用管理 依賴和追蹤的基礎(chǔ) 集中式日志和 監(jiān)控框架都有使用到應(yīng)用編號(hào) SOA 規(guī)劃 12 SOA 規(guī)劃就是接口規(guī)劃 它的歸類與商務(wù)模型中的業(yè)務(wù)流程有參考對(duì)應(yīng)關(guān)系 上圖案例有五個(gè)服務(wù)中心 預(yù)訂服務(wù) 訂單處理服務(wù) 產(chǎn)品供應(yīng)服務(wù) 財(cái)務(wù)結(jié)算服務(wù)和公共服務(wù) 每個(gè)服務(wù)只需要實(shí)現(xiàn)一套自己的 邏輯 我們的前臺(tái) 后臺(tái) 接口 作業(yè)小應(yīng)用等都可以調(diào)用 服務(wù)的邏輯跟我們的業(yè)務(wù)邏輯是一致的 修改代碼的時(shí)候只需要改一個(gè)地方就可以影響到所有調(diào)用到這服務(wù)的前端應(yīng)用 分層架構(gòu) 分層架構(gòu)看似很簡(jiǎn)單 但保證整個(gè)研發(fā)中心都使用統(tǒng)一的分層架構(gòu)就不容易了 那么如何保證整個(gè)研發(fā) 中心都使用統(tǒng)一的分層架構(gòu)呢 以達(dá)到提高編寫代碼效率 保證工程統(tǒng)一性的目的 先簡(jiǎn)單介紹下當(dāng)前 兩種比較流行的分層架構(gòu)體系 一種是領(lǐng)域架構(gòu) 倉(cāng)儲(chǔ)層 Repository Layer 領(lǐng)域?qū)?Domain Layer 應(yīng)用服務(wù)層 Application Layer 表現(xiàn)層 Presentation Layer 和基礎(chǔ)公共層 Infrastructure Layer 請(qǐng) 13 見第一張圖 另一種是相對(duì)傳統(tǒng)地分為三層 數(shù)據(jù)層 Data Layer 應(yīng)用邏輯層 Business Layer 和表現(xiàn) 層 Presentation Layer 請(qǐng)見第二張圖 14 領(lǐng)域架構(gòu)和三層架構(gòu)之間有什么區(qū)別 我們是這樣認(rèn)為的 在早期我們做三層架構(gòu)的時(shí)候 大都以表來(lái) 做驅(qū)動(dòng)的 在做領(lǐng)域架構(gòu)的時(shí)候 大都以業(yè)務(wù)邏輯來(lái)驅(qū)動(dòng)的 兩者的區(qū)別確實(shí)比較明顯 但到了現(xiàn)在 如果都以業(yè)務(wù)邏輯為中心的話 實(shí)際上兩者并沒(méi)有本質(zhì)區(qū)別 當(dāng)時(shí) 我所在公司采用了第二種分層法 我們希望把分層做得極簡(jiǎn) 也就是說(shuō)哪怕剛畢業(yè)進(jìn)來(lái)的員工 在分層時(shí)基本上也不會(huì)亂 而相對(duì)第一種 分層法 第二種分層法簡(jiǎn)單很多 每一個(gè)應(yīng)用的代碼量都不應(yīng)該很大 一旦工程變得過(guò)大 我們就會(huì)把 它適當(dāng)拆分 而不是全部放在一個(gè)單塊應(yīng)用里 總之 我認(rèn)為分層越簡(jiǎn)單 整個(gè)軟件結(jié)構(gòu)就越清晰 代 碼就越容易統(tǒng)一 把工程做得極簡(jiǎn) 才有利于復(fù)制 有利于業(yè)務(wù)的快速構(gòu)建 有利于規(guī)?；?穩(wěn)定可靠 數(shù)據(jù)庫(kù)規(guī)劃 15 數(shù)據(jù)庫(kù)是整個(gè)信息系統(tǒng)中生命周期最長(zhǎng) 最難修改的部分 所以要加強(qiáng)規(guī)劃 數(shù)據(jù)庫(kù)的設(shè)計(jì)至少要提前 兩步 具體根據(jù)高層 E R 圖和數(shù)據(jù)設(shè)計(jì)來(lái)新建數(shù)據(jù)庫(kù) 早建要比晚建好 數(shù)據(jù)庫(kù)調(diào)整的代價(jià)大 周期長(zhǎng) 長(zhǎng)時(shí)間產(chǎn)生的問(wèn)題 需要長(zhǎng)時(shí)間來(lái)解決 先在新庫(kù)里解決新表 再根據(jù)當(dāng)前業(yè)務(wù)和應(yīng)用的需求 逐步調(diào) 整舊表 物理規(guī)劃 16 物理架構(gòu)的規(guī)劃內(nèi)容包括集群規(guī)劃和域名規(guī)劃 首先是集群規(guī)劃 20 倍規(guī)劃 5 倍設(shè)計(jì)和 1 5 倍實(shí)施 規(guī)劃和設(shè)計(jì)要大一些 但實(shí)施時(shí)小一些 這樣不僅便于將來(lái)的擴(kuò)展 也節(jié)省了當(dāng)前的費(fèi)用 兩個(gè)邏輯網(wǎng) 絡(luò) 一個(gè)內(nèi)網(wǎng)和一個(gè)外網(wǎng) 兩個(gè)負(fù)載均衡 兩個(gè)防火墻 安全隔離內(nèi)外網(wǎng) 四條產(chǎn)品線 國(guó)際 國(guó)內(nèi) 新業(yè)務(wù)以及公共業(yè)務(wù) 單點(diǎn)登錄和企業(yè)支付網(wǎng)關(guān)等公共業(yè)務(wù)也屬于一條產(chǎn)品線 六個(gè)集群 Web 集群 SOA 集群 中間件集群 數(shù)據(jù)庫(kù)集群 Job 集群和 ITD 集群 以上橫向集群與縱向產(chǎn)品線形成了一個(gè) 矩陣結(jié)構(gòu) 也基本確定了網(wǎng)絡(luò)基礎(chǔ)架構(gòu) 對(duì)于域名規(guī)劃 對(duì)內(nèi)的域名該改的改 該停用的停用 該合并 的合并 對(duì)外的域名要盡量少改 要改的話也要有歷史繼承性 如跳轉(zhuǎn) 要盡量減小對(duì)用戶的影響 其它 除以上架構(gòu)規(guī)劃外 還有一些其它重要項(xiàng) 如源代碼管理規(guī)劃 文檔管理規(guī)劃 技術(shù)選型和團(tuán)隊(duì)分工 為什么還要做這些呢 因?yàn)榻y(tǒng)一了源代碼怎么放 每個(gè)部門的文檔怎么放 將來(lái)要用什么工具版本 才 利于團(tuán)隊(duì)的協(xié)作 基于統(tǒng)一的環(huán)境才能有更高層次地提升 對(duì)于團(tuán)隊(duì)分工 需要逐步對(duì)齊組織架構(gòu)與系 統(tǒng)的架構(gòu)規(guī)劃 對(duì)于技術(shù)選型 需要注意中間件的引進(jìn) 要有節(jié)奏性 力量要相對(duì)集中 要小規(guī)模試點(diǎn) 找非核心項(xiàng)目 試用成功后再進(jìn)行大規(guī)模推廣 架構(gòu)實(shí)施 17 做完架構(gòu)規(guī)劃后 就是架構(gòu)實(shí)施落地了 我們的架構(gòu)實(shí)施整體思路是 樹目標(biāo) 給地圖 立榜樣 抓重 點(diǎn) 造文化 建制度 整環(huán)境 組建架構(gòu)部 架構(gòu)部?jī)?nèi)招幾名老程序員 外招幾個(gè)架構(gòu)師 內(nèi)部走出去 提高眼界 外部牛人請(qǐng)進(jìn)來(lái) 落地了解歷史和業(yè)務(wù) 具體建議是 SOA 服務(wù)化 基礎(chǔ)設(shè)施平臺(tái)化 公共 業(yè)務(wù)服務(wù)化 加強(qiáng)項(xiàng)目概要設(shè)計(jì) 當(dāng)研發(fā)團(tuán)隊(duì)達(dá)到 200 多人 有了幾百個(gè)應(yīng)用 且在故障不斷的情況下 不能與以前一樣沒(méi)有設(shè)計(jì)就開始編碼 而是做加強(qiáng)項(xiàng)目概要設(shè)計(jì)及評(píng)審 后面的補(bǔ)與前面的防 兩手都 要抓 兩手都要硬 具體計(jì)劃是 Roadmap 分步實(shí)施 改造一期 改造二期 改造三期 近細(xì)遠(yuǎn)粗 實(shí)事求是 逐步細(xì)化逐步完善 不斷立技術(shù)改造項(xiàng)目 不斷將技改與業(yè)務(wù)研發(fā)項(xiàng)目相結(jié)合 技改即是工 單 工單即是技改 避免對(duì)業(yè)務(wù)過(guò)多地影響 并不斷有業(yè)務(wù)價(jià)值輸出 這是架構(gòu)改造得以持續(xù)實(shí)施的關(guān) 鍵 以上簡(jiǎn)單地介紹了總體架構(gòu)的編寫方法 我們的編寫思路是先了解業(yè)務(wù) 建立企業(yè)商務(wù)模型 主要包括 靜態(tài)的商務(wù)主體 組織架構(gòu)和動(dòng)態(tài)的業(yè)務(wù)流程 再了解架構(gòu)的現(xiàn)狀 建立現(xiàn)有信息系統(tǒng)模型 主要