在APP開發(fā)中，業(yè)務(wù)架構(gòu)這個(gè)詞大家時(shí)常提到，但是能解釋得清楚的卻不多，也常有人問起業(yè)務(wù)架構(gòu)師和產(chǎn)品經(jīng)理什么區(qū)別？業(yè)務(wù)架構(gòu)分析和需求分析什么區(qū)別？在APP開發(fā)中如何做好業(yè)務(wù)架構(gòu)。

其實(shí)，業(yè)務(wù)架構(gòu)這個(gè)詞并不新，它隱藏在企業(yè)架構(gòu)（EA）中。企業(yè)架構(gòu)是上世紀(jì) 80 年代的產(chǎn)物，其標(biāo)志就是 1987 年 Zachman 提出的企業(yè)架構(gòu)模型，該模型按照“5W1H”，即 what（數(shù)據(jù)）、how（功能）、where（網(wǎng)絡(luò)）、who（角色）、when（時(shí)間）、why（動(dòng)機(jī)）六個(gè)維度，結(jié)合目標(biāo)范圍、業(yè)務(wù)模型、信息系統(tǒng)模型、技術(shù)模型、詳細(xì)展現(xiàn)、功能系統(tǒng)六個(gè)層次，將企業(yè)架構(gòu)分成 36 個(gè)組成部分，描述了一個(gè)完整的企業(yè)架構(gòu)要考慮的內(nèi)容。

Zachman 模型雖然沒有明確提出業(yè)務(wù)架構(gòu)這個(gè)概念，但是已經(jīng)包含了業(yè)務(wù)架構(gòu)關(guān)注的一些主要內(nèi)容：如流程模型、數(shù)據(jù)、角色組織等，既然沒有提出業(yè)務(wù)架構(gòu)概念，自然也就沒有包含構(gòu)建方法，所以，Zachman 模型應(yīng)該算是業(yè)務(wù)架構(gòu)的啟蒙，同時(shí)，它也表明了這一工具或者技術(shù)的最佳使用場景——面向復(fù)雜系統(tǒng)構(gòu)建企業(yè)架構(gòu)。

TOGAF架構(gòu)模型明確提出了業(yè)務(wù)架構(gòu)的概念，TOGAF 將企業(yè)定義為有著共同目標(biāo)集合的組織的聚集。例如，企業(yè)可能是政府部門、一個(gè)完整的公司、公司部門、單個(gè)處 / 科室，或通過共同擁有權(quán)連接在一起的地理上疏遠(yuǎn)的組織鏈。TOGAF 進(jìn)一步認(rèn)為企業(yè)架構(gòu)分為兩大部分：業(yè)務(wù)架構(gòu)和 IT 架構(gòu)，大部分企業(yè)架構(gòu)方法都是從 IT 架構(gòu)發(fā)展而來的。業(yè)務(wù)架構(gòu)是把企業(yè)的業(yè)務(wù)戰(zhàn)略轉(zhuǎn)化為日常運(yùn)作的渠道，業(yè)務(wù)戰(zhàn)略決定業(yè)務(wù)架構(gòu)，它包括業(yè)務(wù)的運(yùn)營模式、流程體系、組織結(jié)構(gòu)、地域分布等內(nèi)容。TOGAF 強(qiáng)調(diào)基于業(yè)務(wù)導(dǎo)向和驅(qū)動(dòng)的架構(gòu)來理解、分析、設(shè)計(jì)、構(gòu)建、集成、擴(kuò)展、運(yùn)行和管理信息系統(tǒng)，復(fù)雜系統(tǒng)集成的關(guān)鍵，是基于架構(gòu)（或體系）的集成，而不是基于部件（或組件）的集成。

TOGAF 之后，又先后誕生了 FEA（聯(lián)邦企業(yè)架構(gòu)）和 DODAF（美國國防部體系架構(gòu)框架）。前者的體系由五個(gè)參考模型組成：績效參考模型（PRM）、業(yè)務(wù)參考模型（BRM）、服務(wù)構(gòu)件參考模型（FRM）、數(shù)據(jù)參考模型（DRM）、技術(shù)參考模型（TRM），該方法應(yīng)用于美國電子政務(wù)領(lǐng)域，著眼于跨部門、跨機(jī)構(gòu)提升業(yè)務(wù)效率，解決重復(fù)建設(shè)、信息孤島等問題，很具有“企業(yè)級”理念，雖然沒有明確的業(yè)務(wù)架構(gòu)定義，但是很好地應(yīng)用了業(yè)務(wù)架構(gòu)的思維。后者體系挺復(fù)雜的，8 個(gè)視點(diǎn) 52 個(gè)模型，但是實(shí)用性不錯(cuò)，美國國防部和一些企業(yè)在用。

業(yè)務(wù)架構(gòu)這個(gè)詞也有 20 多年的歷史了，但是在開發(fā)人員中，業(yè)務(wù)架構(gòu)顯然沒有需求分析的概念明確，業(yè)務(wù)架構(gòu)師也遠(yuǎn)不如產(chǎn)品經(jīng)理常見。與APP開發(fā)人員討論，他們也常覺得業(yè)務(wù)架構(gòu)有點(diǎn)兒“虛”。細(xì)究其原因，可能有如下幾點(diǎn)：
用得少。原有的單體式或者豎井式開發(fā)依然是大家更經(jīng)常采用的項(xiàng)目構(gòu)建方法，而這種開發(fā)基本上沒有橫向視角，所以無需強(qiáng)調(diào)業(yè)務(wù)架構(gòu)，通常的產(chǎn)品分析或者需求分析足以滿足開發(fā)需要；
難設(shè)計(jì)。業(yè)務(wù)架構(gòu)，特別是大型企業(yè)這種錯(cuò)綜復(fù)雜的業(yè)務(wù)架構(gòu)，說起來容易做起來難，業(yè)務(wù)架構(gòu)對戰(zhàn)略的分解、業(yè)務(wù)架構(gòu)自身的整合與標(biāo)準(zhǔn)化、到 IT 設(shè)計(jì)的過渡都有不少坑，業(yè)務(wù)越復(fù)雜越寬泛就越難駕馭，因此，即便做過業(yè)務(wù)架構(gòu)設(shè)計(jì)的企業(yè)，也有不少將業(yè)務(wù)架構(gòu)設(shè)計(jì)保持在高階狀態(tài)，有點(diǎn)兒“虛”；
易跑偏。施工期間由于客觀因素可能導(dǎo)致實(shí)施對業(yè)務(wù)架構(gòu)的偏離，這種偏離如果沒有及時(shí)糾正或者調(diào)整架構(gòu)，累積久了會(huì)造成業(yè)務(wù)架構(gòu)的失真，會(huì)變“虛”；
難維護(hù)。少數(shù)扛過了業(yè)務(wù)架構(gòu)落地困難期的企業(yè)，也會(huì)由于感受到維護(hù)架構(gòu)的難度而心生放棄，從而降低了對業(yè)務(wù)架構(gòu)的評價(jià)。

其實(shí)，業(yè)務(wù)架構(gòu)從誕生之初就很清楚地定義了自己的使命：面向復(fù)雜系統(tǒng)構(gòu)建。也就是說，業(yè)務(wù)架構(gòu)同其他架構(gòu)一樣，目的也是要降低復(fù)雜度，更好地規(guī)劃系統(tǒng)，因此 TOGAF 是將業(yè)務(wù)架構(gòu)歸屬于 IT 戰(zhàn)略部分。應(yīng)當(dāng)將業(yè)務(wù)架構(gòu)從 IT 戰(zhàn)略中獨(dú)立出來，更多面向業(yè)務(wù)人員，以充當(dāng)業(yè)務(wù)與技術(shù)之間的橋梁。當(dāng)然，業(yè)務(wù)架構(gòu)真正要承擔(dān)起這一職責(zé)，還需要改進(jìn)、簡化業(yè)務(wù)架構(gòu)設(shè)計(jì)方法，對業(yè)務(wù)人員更友好，并且堅(jiān)持使用業(yè)務(wù)架構(gòu)方法做企業(yè)級需求管控。

未來，業(yè)務(wù)不再僅僅是業(yè)務(wù)，技術(shù)也不再僅僅是技術(shù)，誰先實(shí)現(xiàn)思維方式的改進(jìn)，誰就能贏得轉(zhuǎn)型的先手，而業(yè)務(wù)架構(gòu)能力可以在這方面發(fā)揮關(guān)鍵作用。