對于企業級業務機構設計而言，一定是從企業管理、戰略、組織結構上來入手，這樣才能更好的驅動企業數字化轉型和資訊化建設。
以前，我們的科技都來自于業務，有了實際的需求，迫使科技的進步。業務提需求，技術管實作，業務發展催生技術發展。但現在，科技的進步速度遠遠超出了我們的業務發展速度，我們的業務在技術的引領下，發展得更多種多樣，商業模式也受到影響，技術與業務已經到了深度融合得時代。
科技的快速發展驅動着每一個行業，每一次科技的革命都會誕生一批偉大的企業。但傳統的企業在科技的浪潮中如何能保持競争優勢，相信每個企業主都知道調整戰略方向，順勢而為。
那麼這個“勢”到底是什麼呢？
我們從工業革命開始，社會飛速發展，從設施化時代進入自動化時代，現在已經處于資訊時代，往數字時代，智能化過渡，企業的資訊化轉型顯得至關重要。那在資訊化建設中，應該怎樣搭建業務架構，與技術架構又有怎麼樣的關系？
一、什麼是業務架構
業務架構是以企業戰略為基石，結合業務流程，組織架構的一種表達方式。是技術架構的驅動力，企業通過建構業務架構，來緩解企業壓力，與轉型的不适。
作為企業業務與技術的的橋梁，實作資訊化的深度融合。不同于業務流程和業務需求的分析，業務架構更強調整體性，結構性。技術永遠都是為業務服務的，所有的架構師都是為了解決某種業務而誕生的。能解決實際的問題，才是技術的價值。
二、業務架構與技術架構的關系
1）業務架構的作用
多數的架構師和業務，和企業發展戰略上是脫節的。他們專注于技術的實作，而忽略使用這項技術的業務目的，與企業的聯系。業務架構的作用就是在這之間建立橋梁，用于實作業務需求到IT的順利傳導，将戰略映射到技術上來提現。
在通向“數字化”時代的程序中，業務架構的獨特性在于幫助企業完成了深刻的“數字化”轉型，使企業通過資訊技術将内部、業務與IT深刻地連接配接起來，成為高效的“數字化”企業。
2）業務架構帶動深度融合
如果業務本身不結構化，直接用技術架構一位的去迎合，去套。那麼技術人員也很難做出一個具有良好架構的系統，業務架構就像一個容器，而業務架構就是裡面的内容。
三、業務架構設計
業務架構搭建，要從頂層結構即企業戰略開始，通過梳理企業目标，發掘企業能力需求（既可能是企業自身業務與技術水準發展産生的轉型需求，也可能是科技導緻的行業生态變化、來自競争對手的被動需求）。再通過價值鍊分析方式，建構企業整體能力布局（即業務架構），并在分析過程中，将能力需求放入能力布局中，并以此在業務層面落地戰略、檢驗戰略的可行性，甚至調整戰略。
1）價值鍊分析
價值鍊分析模型就是企業競争力分析，這個方法從企業管理的角度來說，是久經考驗的方法，特别适合用來做企業級橫向的競争力分析。價值鍊主要包括基本活動和支援性活動，基本活動是指主要生産過程，支援企業上下遊的核心流程，支援性活動則是指對基本活動起輔助作用及維持企業基本運轉的各類活動。
這裡我用一個生産制造業的價值鍊舉個例子，對于不同的企業，性質不同，則價值鍊不同。價值鍊如何設計完全可以是個性化的，隻要确認能夠符合企業的特點，覆寫其價值創造過程即可。
抽象出價值鍊模型
2）流程模型分析
劃分工作流：搭建好價值鍊這一“橫軸”之後，就可以基于價值鍊的各個環節分析多個“豎軸”了。數軸就是價值鍊上業務領域的劃分取決于企業的戰略和價值定位，從客戶和産品出發，業務領域實際上就是由一組業務活動構成的，業務活動中的角色和任務，展現了所有參與到價值創造過程中的組織單元的分工協作關系。分析工作流：工作流程的分析實際上是将一個業務領域中的所有業務處理過程按照價值鍊約定的範圍進行分解，形成每一個價值鍊環節中的一個或者多個工作流，通過UML等工具進行企業業務流梳理。3）企業資料流分析
說到資料模型，我們肯定第一反應是想到資料庫設計中的ER圖，但是ER圖（實體關系）通常是面向單個系統進行建構的，用來描述實體,屬性,任務之間的關系。
在建構企業級資料模型時，就需要橫向分析所有業務領域的ER圖，通過建立分析架構，根據實體、資料屬性進行歸類，形成統一的企業級邏輯模型，保證資料的唯一性。
對于不同行業，由于業務的特殊性，如：自動化包裝業務、資訊采集業務。需要不同領域的專業資訊系統來完成，企業級的業務資料通常會随業務在各個業務領域流動，這就要考慮将每個業務領域的ER模型結合一起設計，涉及到系統內建。
4）元件分析：流程與資料的結合的産物
流程模型與資料模型是描述業務的一對“難兄難弟”，流程模型表達的是“處理”，資料模型表達的是“輸入”和“輸出”，合起來就是計算機的基本工作流，這在大部分軟體設計方法論中都是共識。
資料模型和流程模型的組合，可以清楚地描述出，什麼樣的事件或條件可以觸發一組業務活動，業務活動需要的輸入有哪些，業務流程的處理規則是什麼，經過業務流程的處理，輸出又有哪些如果将該業務系統化，就會變成如下的問題：
實作業務活動的計算機程式是在什麼樣的場景（事件）下開始執行的？程式需要讀取哪些資料（實體）？依據什麼樣的順序（活動）？規則（任務）由誰（組織、角色）執行？執行之後将會産生哪些資料（實體）？任務會直接處理資料，而這種處理通常可分為增加、修改、删除、查詢四類操作。在軟體設計上，通常會考慮将關系較近的資料實體聚合在一起，按照行為接近資料的原則，再将相應的功能聚合成一個元件。從業務模型的角度來看，就是按照主題域劃分邊界，将與主題域内實體相關的任務聚在一起構成業務元件任務與實體的關聯主要是基于對實體的增、删、改操作。
資料模型包含主題域這個層級，即将關系較近的資料實體聚合成一個分類，對于這種關系我們可以給出一個主題名稱。在軟體設計上，通常會考慮将關系較近的資料實體聚合在一起，按照行為接近資料的原則，再将相應的功能聚合成一個元件。從業務模型的角度來看，就是按照主題域劃分邊界，将與主題域内實體相關的任務聚在一起構成業務元件。
下面是筆者在設計某資訊系統時，結合資料模型以及主題域劃分邊界，建構的元件化設計思路。
5）梳理整體結構
關鍵元素：價值鍊、業務領域、業務流程、業務資料和業務元件5個關鍵元素。
通過對以上幾個因素的分析梳理出業務架構：
結語
以上就是筆者在對企業級架構設計的的實戰中的一些複盤與總結，對于企業級業務機構設計而言，一定是從企業管理、戰略、組織結構上來入手，這樣才能更好的驅動企業數字化轉型和資訊化建設。