APP開發如何設計好業務架構

在APP開發中，業務架構這(zhè)個(gè)詞大(dà)家時(shí)常提到，但是能解釋得(de)清楚的(de)卻不多(duō)，也(yě)常有人(rén)問起業務架構師和(hé)産品經理(lǐ)什(shén)麽區(qū)别？業務架構分(fēn)析和(hé)需求分(fēn)析什(shén)麽區(qū)别？在APP開發中如何做(zuò)好業務架構。

其實，業務架構這(zhè)個(gè)詞并不新，它隐藏在企業架構（EA）中。企業架構是上世紀 80 年代的(de)産物(wù)，其标志就是 1987 年 Zachman 提出的(de)企業架構模型，該模型按照(zhào)“5W1H”，即 what（數據）、how（功能）、where（網絡）、who（角色）、when（時(shí)間）、why（動機）六個(gè)維度，結合目标範圍、業務模型、信息系統模型、技術模型、詳細展現、功能系統六個(gè)層次，将企業架構分(fēn)成 36 個(gè)組成部分(fēn)，描述了(le)一個(gè)完整的(de)企業架構要考慮的(de)内容。

Zachman 模型雖然沒有明(míng)确提出業務架構這(zhè)個(gè)概念，但是已經包含了(le)業務架構關注的(de)一些主要内容：如流程模型、數據、角色組織等，既然沒有提出業務架構概念，自然也(yě)就沒有包含構建方法，所以，Zachman 模型應該算(suàn)是業務架構的(de)啓蒙，同時(shí)，它也(yě)表明(míng)了(le)這(zhè)一工具或者技術的(de)最佳使用(yòng)場(chǎng)景——面向複雜(zá)系統構建企業架構。

TOGAF架構模型明(míng)确提出了(le)業務架構的(de)概念，TOGAF 将企業定義爲有著(zhe)共同目标集合的(de)組織的(de)聚集。例如，企業可(kě)能是政府部門、一個(gè)完整的(de)公司、公司部門、單個(gè)處 / 科室，或通(tōng)過共同擁有權連接在一起的(de)地理(lǐ)上疏遠(yuǎn)的(de)組織鏈。TOGAF 進一步認爲企業架構分(fēn)爲兩大(dà)部分(fēn)：業務架構和(hé) IT 架構，大(dà)部分(fēn)企業架構方法都是從 IT 架構發展而來(lái)的(de)。業務架構是把企業的(de)業務戰略轉化(huà)爲日常運作的(de)渠道，業務戰略決定業務架構，它包括業務的(de)運營模式、流程體系、組織結構、地域分(fēn)布等内容。TOGAF 強調基于業務導向和(hé)驅動的(de)架構來(lái)理(lǐ)解、分(fēn)析、設計、構建、集成、擴展、運行和(hé)管理(lǐ)信息系統，複雜(zá)系統集成的(de)關鍵，是基于架構（或體系）的(de)集成，而不是基于部件（或組件）的(de)集成。

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

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

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

未來(lái)，業務不再僅僅是業務，技術也(yě)不再僅僅是技術，誰先實現思維方式的(de)改進，誰就能赢得(de)轉型的(de)先手，而業務架構能力可(kě)以在這(zhè)方面發揮關鍵作用(yòng)。