業務架構定義
（1）業務架構是 TOGAF 最早定義的，指的是企業的戰略、組織結構、關鍵流程等內容。
TOGAF 9
企業架構思想誕生於 1987 年，這時候，工程化已經搞了快 20 年了，但大家還是沒有搞清楚，在 B 端怎麼設計軟體合適。IBM 的僱員 Zachman 在 IBM 的內部刊物上發表了一篇文章《資訊系統架構框架》，談到了“架構”這個詞在軟體行業應用上的混亂，並提出了自己的架構設計思想，這篇文章後來被奉為企業架構的開山之作。Zachman 的思想最重要的一點就是，架構是多視角的集合，是“一套架構（a set of architecture）”，而非“一個單一的架構（a single of architecture）”。架構是從多個視角觀察企業得到的結果的總和，這實際上也是上一講中提到的架構思維的全面性。換句話說，我們不應該總抱著自己認定的視角去跟別人爭，而是要努力去看看，到底需要多少種視角，才能理清企業的全貌，這樣才能讓我們設計的系統與企業的實際環境匹配上。Zachman 的思想後來在 Open Group（開放組）的努力下發揚光大了。Open Group 在 1995 年提出了一個體繫結構非常完整的方法論 The Open Group Architecture Framework（開放組架構框架，簡稱 TOGAF）。TOGAF 首次正式定義了什麼是企業架構，他們提出，企業架構就是“具有共同目標的組織集合體的基本組成部分及其內外部關係與治理原則”。這個很怪異的“組織集合體”指的就是企業，只不過它比你平時理解的企業範圍大些，能被一個目標圈進來的組織，都可以被當成一個企業看，所以，TOGAF 是支援建立跨組織的架構的。TOGAF 認為企業架構包括業務、資料、應用、技術四部分，也稱“4A 架構”，實際上是 4 種架構視角。Zachman 主張的多視角架構，在這裡算是成型了，做企業架構就要完整地做出這 4 種架構。
（2）偏操作性的定義：業務架構是以實現企業戰略為目標，構建企業整體業務能力規劃並將其傳導給技術實現端的結構化企業能力分析方法。
整體：
從整體出發進行合理佈局。
這樣的設計是最經濟的，但是難度相對也是高的，業務分析上，每個領域都不能只看自己家的領域。只要是跟你的領域相關的，都要橫向考慮到。此外，要落地企業戰略，也需要看到企業的全貌，完整知道企業各個部分之間的相互關係，這樣才好分解戰略，不然，就可能出現對戰略分解上的盲區，影響戰略的落地。全面是架構思維的首要特點，業務架構也是如此。
結構化:
結構化是業務架構分析問題的方式。
有了剛剛的對業務橫向拉通的全面認知，還要把你的認知結果表達出來，這樣才能把它們傳導給要去做開發的技術人員。表達可以有很多種方式，而用來跟技術人員銜接的最好方式莫過於結構化地表達，透過模型之類的手段，把業務架構設計成果表達成技術人員比較好理解的形式。在做模型的時候，如果有設計系統的支援就更好了。如果總是把方案搞成一大堆 Word 文件和 PPT，誰也不好查詢。現在也有一些可用的建模工具和架構管理工具（比如可以用來與 TOGAF 過程配合使用的 ArchiMate 建模工具，有一套標準的、可相互整合的軟體工具集支援的 ARIS 模型框架，等等），有些是架構管理的，有些是流程管理的。不過，相對來說，工具還是比較缺乏的，這主要是因為架構方法論的實踐不夠充分，再加上架構管理工具與軟體開發全生命週期管理的銜接本身也不容易，所以這方面還需要逐步完善。
傳導:
把自己對業務的認知準確地傳導給技術，也是業務架構的任務。
實現好的傳導需要兩個條件：優質的內容；相應的機制。
要注意的是，這兩個不是並列的條件，而是相輔相成的。在內容方面，業務架構要先幫助業務理清自己的環境、搞清業務痛點、設計出解決方案，這樣才能向技術傳導準確的東西，不然，大家都是一頭霧水，就沒辦法進行下一步了。如果不能幫助業務一側找到合理的解決方案，就不會有什麼好的技術方案誕生。但這一點，也正是機制上的一大缺陷。業務架構的工作方式沒有走出技術圈子，沒有走到業務人員中間去。實際上，應該讓業務架構思維在業務一側被廣泛接受、使用，這樣才能保證持續產生好的業務架構解決方案，促進業技融合，這並不是有了業務架構師就萬事大吉了。目前能做這種架構思維推廣的人還很少，而人少的原因其實就是企業本身沒有采用這種工作機制，自然也就培養不出這樣的人。現在，有了業務架構，戰略、業務、技術這三個在企業管理中很容易出現銜接問題的東西，就被一根繩子串起來了，自然也就可以幫助業務人員找到可落地的業務解決方案，幫技術人員理解戰略和業務到底要怎麼實現，從而找到更好的技術解決方案。這就是業務架構的價值所在。你想想，這不就是數字化轉型的要求嗎？大家要透過數字化創造新模式、新業態，要加強技術對業務的支援作用，要實現業務和技術的深度融合，說到底不也是這些東西嗎？當然了，業務架構不是“銀彈”，更不是“無懈可擊”，無論是企業還是個人，如果想有持續的進步，一定要有能力去發展和改進自己的工作方法。想把它用好，也要清楚如何去完善它的不足，這樣才能進一步提升你的數字化能力。那怎麼改進呢？
如何進一步改善業務架構的設計思路？很多技術人員覺得它很“虛”，也就是跟軟體詳細設計的關係不緊密。技術人員好像可以透過這個更好地瞭解企業，但是又認為梳理出來的東西往往是偏宏觀、偏業務的。可以當個背景資料參考，但是如果用它繼續去做詳細設計，總覺得差點兒意思。
這個問題的根源是，當前的業務架構設計實踐沒能把資料和流程很好地結合起來。現在，大家都知道資料很重要，是新的生產要素，甚至還有“一切業務資料化，一切資料業務化”的口號。
但是，具體怎麼做呢？
當然得用笨法子一點一點做，騏驥一躍，也不能十步啊，咱們只能一個流程一個流程地去分析，把流程中要用到的、會建立的資料找出來才行。雖然傳統的需求分析也會這麼做，但是做出的成果是分開的，流程的歸流程，資料的歸資料，該一起做的事情，卻分成了兩塊。不僅分析過程可能浪費了時間，也達不到理想的效果。要是資料分析直接跳過與業務過程的銜接，跑到資料庫表的設計層面，那就更糟糕了。
其實，軟體設計的核心就是分析行為和資料，也就是軟體的功能以及這些功能要涉及到什麼資料。把資料和流程一起說明白，是技術人員最願意看到的業務分析結果。
所以，業務架構的改進方向之一，就是將原有的業務架構和資料架構融合起來，形成新的業務架構。可以考慮把 TOGAF 中原來的業務、應用、資訊（資料）、技術四個架構視角，去掉一個，讓資料架構融入其他架構視角中。
當然，這不是說資料模型沒了，而是業務模型和資料模型應該一起建，兩者結合在一起考慮流程怎麼切分、資料實體怎麼切分，切分後的流程和資料實體到底是什麼關係，這樣才能更有利於對技術的銜接，同時又不至於失去業務友好性，讓業務人員不好理解。
如何改進工作機制？如果只改進設計思路，還不足讓業務架構得到廣泛使用，業務架構總在技術圈子裡的打轉兒是沒前途的，得走出來，才能真正發揮出作用。
業務架構以往的工作方式，尤其是在 TOGAF 體系中，經常被認為是為了構建企業級系統而延伸出來的一個分析業務的環節。這就導致，在很多時候，業務架構會被當作企業級工程的一部分，採用的是類似於需求分析工作的管理模式，按流程坐等需求上門，忽略了獨立應用業務架構方法，去解決業務人員落地企業戰略、搞業務創新的可能性。
實際上，業務架構的核心價值，包括推動企業戰略落地、透過架構設計提升業務協同性、促進業務與技術融合，這些都不是待在技術圈子裡可以解決的問題，也不是待在技術圈子裡就能培養出來的能力，必須得走到業務中間去。
那咋做呢？很關鍵的一點就是把業務架構師派到業務部門去工作，讓業務架構師第一時間接觸到業務人員的各類創新想法，並用企業的業務架構合理引導業務創新落地，幫助業務人員更好地理解技術可以帶來的想象力。
當然，這也面臨一個問題：現在大家都覺得好的業務架構師很少，無人可用，這個問題怨不得別人，只能怨我們自己，不培養，怎麼會有呢？挖牆腳都沒地方挖去。不能等有合適的人了再去做，而是要透過做起來去培養人。
而且，對於個人來說，這麼好的時代機會擺在面前，在業務架構師如此稀缺的情況下，你具備了這樣的能力，自然也就能走在別人的前面，關鍵是要有前瞻性。所以，你要經常訓練自己的結構化思維和溝通能力，看到啥都想著用結構化的思路拆解下，經常模型化地思考問題，好好把自己的思路傳達給別人。
透過設計思路和工作機制的改善，業務架構的橋樑作用還可以發揮得更好，而這座橋正是業務人員面向數字化轉型最需要的。接下來，我再來說說業務架構對數字化轉型最獨特的一個價值。
業務架構對數字化轉型最獨特的價值在數字化轉型過程中，最艱難、最痛苦的很可能是現在的業務人員。現在技術變化太快，技術對原有業務形態的衝擊很大。
比如，移動網際網路興起大約也就十年的時間，移動端的開發技術、安全技術變化都非常快，在業務側，網約車、社群團購、駭客增長、私域流量等玩法紛紛湧起。技術的變化速度讓搞技術的專業人員都應接不暇，感嘆自己職業壽命太短，學不過來，那業務人員情何以堪啊？哪些技術哪天會替代一箇舊工種搞出一個新工種，誰也說不清。
現在人們常說，“最可能擊敗你的不是對手，是新手”。一些跨界而來的人，帶著新思維、新手段，還沒有舊包袱，佔盡天時地利人和，傳說中的“降維打擊”也都是這個道理。無論是企業還是個人，都會面臨這樣的衝擊。
那數字化轉型是要業務人員現在轉行去學技術嗎？當然不是，提升對業技融合的支援能力才是出路。就像我一開始提到的，想要實現業技融合，形成合力，就需要相近的思維模式和共同語言，這就是業務架構能做的事情，不然就會像修“通天塔”的故事那樣，各說各話，最後導致修塔失敗。
提升業務與技術之間的溝通效率，是未來企業競爭的焦點。你想想，如果經過數字化轉型，大家都成為具有一定科技實力的數字化企業了，那最終我們要比拼什麼？是不是又回到了誰家的業務人員能幫技術人員更快了解市場這個點上？而這個拼的就是溝通效率。
只要業務人員能夠適當結構化自己的思維，好好利用、打磨業務架構方法，在不轉行學技術的前提下，也能更好地跟技術人員溝通。
總結業務架構最早是 TOGAF 定義的，關注的是企業的戰略、組織結構、關鍵流程等內容。
操作性的定義：“業務架構是以實現企業戰略為目標，構建企業整體業務能力規劃並將其傳導給技術實現端的結構化企業能力分析方法。”
現在，業務架構的作用被忽視了，需要改進。
方向有 2 個：
一個是要把業務架構與技術設計銜接得再緊密些，把資料架構吸收進來；
另一個是改進工作機制，走到業務人員中間去，把業務架構思維推向業務人員，幫助業務人員進行數字化轉型。
這種兩邊“討好”的方式，正是業務架構的價值所在，當然，它對業務架構師們也提出了不小的挑戰，你要培養好自己思維的邏輯性，還要把自己打造成業務和技術兩邊都具備適當深度的複合型人才。
業務和技術融合