零程式碼平臺賦能了業務開發者，讓他們可以不寫程式碼就能完成應用實現。但是企業應用設計和開發畢竟是一個複雜過程，對於大多數使用者來說，即興創作是很難的。對於比較複雜的應用搭建需求，它依然需要一個完善的分析和計劃的過程。
在企業資訊系統建設過程中，開發和實施前都離不開架構設計工作，對於複雜的系統，資訊架構所花的工作時間比例更高。而且，資訊架構是一個長期過程，它不僅服務於具體業務系統開發和實施的需求，還包括中長期規劃和服務於應用的迭代與遷移需求。
本章重點介紹企業資訊架構（Enterprise Architect）的一般方法，以及如何簡化它們來服務零程式碼應用搭建的過程。
企業資訊架構的一般方法
從上世紀七八十年代開始，企業資訊架構就開始成為一個專業領域，形成了一整套方法論。這些方法論圍繞複雜組織的資訊系統建設提供了抽象的思維框架和計劃工具，它們雖然大多來自軍工、航天和政府需求，但經過整合以後，同樣適用於企業領域。
在這些方法中，來自IBM的Zachman框架和源自美國國防部的TOGAF框架是比較典型的資訊架構方法論。我們對這兩個方法論做一個簡單介紹。
1.1 Zachman框架
Zachman框架起源於John Zachman先生在1987年完成的資訊系統架構論文“A framework for information systems architecture”，他把資訊系統架構設計相關的各種元素歸納到如下表格之中：
從這個複雜的表格可以看出，資訊架構是一個多層次和多要素的複雜工作。他服務於組織的不同層面需求，也需要多角色一起參與建設。這是一個在宏微觀層面都非常完整的框架。依照這個框架來完成分析和計劃工作必然是相當完善的。但因為它的完善，也給企業界的使用帶來繁冗的工作。五種參與角色和六大考量要素綜合起來就是三十個格子，如果都按照這個標準來做架構設計，企業資訊系統的規劃成本就太高了。所以，我們往往把Zachman框架當作一個分工和思考的檢查清單來使用，至少可以幫助我們避免重要的遺漏。
1.2 TOGAF模型
TOGAF模型全稱The Open Group Architect Framework，目前由The Open Group負責維護，已經發展到9。x版本。
TOGAF框架定義了企業架構內容和實施步驟及交付物，將企業架構劃分為業務架構、應用架構、資料架構和技術架構，形成了涵蓋企業各方面的架構體系，是一個面向各種不同組織、具有很強通用性的企業架構。對於實際的架構工作，其指導意義高於實踐操作的意義。其中，業務架構：定義企業戰略、企業治理、組織結構以及關鍵的業務流程。資料架構：描述組織的邏輯與物理資料資產的結構和組織的資料管理資源。應用架構：提供描述應用系統的部署、互動以及系統與組織核心業務流程之間關係的藍圖。技術架構：描述用於支援業務、資料、應用服務的軟體、硬體的能力。這些軟、硬體以及邏輯技術部件包括 IT 基礎設施、中介軟體、網路、通訊、處理機制、標準等。
附圖：TOGAF架構開發方法
TOGAF的一大特色在於其獨特的架構開發方法AMD （Architecture Development Method），它是一個以需求為中心的迴圈過程。在總體框架和規劃原則的前提下，ADM方法從架構願景出發，經過業務架構規劃，確定資訊系統架構和技術架構，然後結合現有的資訊化基礎，給出企業資訊化建設，適應性改造的解決方案。遷移計劃針對實施方案中不同專案的優先權，評估各個專案的依賴程度、遷移費用、收益等，並形成具體的實施規劃；實施治理制定了各個實施專案的建議，建立架構規約來管理所有實施和部署的過程，以確保實施專案架構與相關專案架構的一致性。架構變更管理關注業務目標、環境和技術等方面的演變和發展，為是否啟動和規劃新的架構進化週期提供。
TOGAF目前是企業架構專業領域最知名的框架，它也有完善的培訓、認證體系。但它和Zachman框架一樣，都過於龐雜，缺乏實際專案落地的可用性，更多地演化成為一個職業，而難以被一般企業實踐直接所用。
接下來的小節會專門介紹一個簡化的資訊架構方法。它保留了經典企業資訊架構的戰略視角，但更多著眼於IT專案的落地需求，簡化了參與角色和架構實現中的環節，讓非專業人員也能夠從事資訊架構的實質性工作。
一個簡化的資訊架構方法（RPIC）
方法論的介紹很容易陷入晦澀的程式說明，它最好能夠結合例項來表達。為此我們專門準備了一個大多數企業使用者能夠有代入感的案例。但在解析案例之前，還是有必要先簡單概述一下這個方法論的核心思想。
RPIC是Role，Process，Information和Content的縮寫，意思是角色、流程、資訊和內容。它是一個循序漸進的分析計劃過程，從企業管理和運營角色的分解出發，為每個涉及到的角色（可能包括外部角色）分析他們
在業務活動中需要完成的流程和接觸的資訊（資料）
，當枚舉出所有的流程和資訊後，就能夠取得它們的不重複並集；透過這個並集內容分項規劃資料架構、角色許可權、統計報表和工作流程四項核心架構內容。
這四種架構內容是非常具體的IT專案落地藍圖，無論是外購系統配置，還是自行開發，包括使用零程式碼應用平臺搭建，都能夠透過這個方法獲得完善的計劃引導，建立有秩序的執行步調和達到預期的結果。
整個過程簡潔明快，著眼於具體規劃產出。稍有IT經驗的職場人員經過簡單訓練就能夠掌握。尤其是結合零程式碼平臺，規劃人員甚至可以直接上手完成具體的應用搭建。當然，使用者要了解這是一個簡化的框架。它不可避免地會忽略一些內容，比如企業戰略視角、複雜企業組織的干係人網路、規劃的長期視角、應用的迭代和遷移計劃。這些被裁剪的內容並非不重要，只是它們不一定出現在每個應用的需求時刻。而且我們也會有其他辦法來針對性補充。
接下來的案例，我們會按照這個方法論，一步一步引導大家理解和掌握企業資訊架構技巧。
結合案例的方法論解析
3。1 案例背景
案例中的企業叫“普渡餐飲”，是一家成長中的企業餐飲服務企業。它為周邊企業提供員工送餐和宴會送餐服務，面對的客戶物件是企業。因為普渡餐飲重視菜品質量和口味，它的服務獲得了一些高福利企業的歡迎。一般企業會為員工常年訂購早餐和午餐，遇到有會議用餐需求的時候，也非常樂意繼續使用普渡餐飲的服務，因此普渡餐飲的這兩種業務有明顯的客戶交叉現象。
普渡餐飲的產品目錄是有獨立菜品和套餐組成的綜合選單。員工早午餐可以從數十種套餐中進行選擇，宴會則可以選擇套餐或者自選的菜品組合。大多數客戶會傾向於選擇訂購套餐。
因為在發展的早期階段，普渡餐飲目前只有一個生產加工中心。出於成本控制的目的，普渡餐飲除了包裝材料以外，幾乎不保留任何生鮮原料庫存，採購完全根據前一天的訂單，在當晚完成採購，次日根據訂單加工和派送。菜品加工完全在自營的生產加工中心完成。因為營業規模有限，普渡同一時期只在數家固定的生鮮配送商那裡採購，每月結算費用。
普渡餐飲的物流服務是外包的，透過固定合作的物流公司將製作好的菜品和包裝快遞給本地客戶。物流公司每月根據實際的物流費用與普渡餐飲結算。
3。2 案例目標
結合以上的案例背景，
我們的目標是為普渡餐飲設計核心業務系統的資訊架構，並透過零程式碼平臺來實現整套應用
。為了控制篇幅，我們把核心業務系統定義為從普渡餐飲接單開始到餐品交付，並完成收款的全部過程，捨去行政、人事、營銷等環節。
我們要獲得的產出物具體包括：
資訊架構中的資料結構定義
工作流程定義
可用的應用系統
配套的使用文件
3。3 架構設計過程
（1）價值創造過程總覽
為了梳理清楚一家企業的資訊架構需求，我們一般可以先繪製一張流程圖。這張流程圖可以從宏觀的層面將這家企業的價值創造過程表達出來。在流程圖中，節點表達的是參與主體，既可能是內部部門，也可能是外部角色。價值創造按照從左往右的方向進行，這樣既容易繪製（減少交叉），又能夠有條理地遍歷所有的參與角色。而角色是RPIC方法中的出發點，我們不能遺漏任何參與業務流程的重要角色。
在本例中，客戶向普渡餐飲的銷售部下訂單，銷售部據此向內部的加工中心下加工單，加工中心再據加工單向生鮮配送商下采購單。以上是整個業務活動的資訊流部分。然後生鮮配送商向加工中心配送食材原料，再被加工成最終產品，並透過物流服務商配送給客戶。在這個流程圖中，資訊流用虛線表達，實物流用實線表達。在後面的資訊架構工作中，我們重點要關注的是資訊流，以及和資訊流相關的角色主體。
透過以上的流程圖，我們獲得了以下參與角色：
銷售部
加工生產中心
客戶（外部）
生鮮配送商（外部）
物流服務商（外部）
在角色定義中，內部使用者一般要精確到特定的職能，而外部角色一般不需要細化，因為上下游協作主體一般都有固定的角色來和本企業進行互動。比如在本例中，無論是物流服務商，還是生鮮配送商，都是由客戶服務部門來對接的。
所以接下來，我們按照這個分析結果逐項釐清所有的流程參與角色
（2）參與角色盤點
從總覽流程圖，我們挖掘出了和業務活動有關的角色。
在列舉具體角色的時候可以分別從管理角色和運營角色這兩種型別出發
。因為必然存在的科層分工，每個企業組織中都會有不同的崗位層級，他們在業務活動中需要接觸不同的資料物件和完成不同的工作內容，因此，分開列舉運營使用者和管理使用者能夠幫我們把資訊架構設計得更完善。
下表是我們根據主體物件繼續開發出來的角色清單。為簡化案例，我們只細分了和案例目標有關的兩個職能部門和總經理角色。這樣我們就有了RPIC方法的出發點——角色（Role），後續的架構設計工作將圍繞這些角色的工作視角進行。如果你需要透過使用者訪談來幫助架構設計，也可以明確地將這些角色使用者當作訪問物件，觀察他們的業務活動，蒐集來自他們的工作材料。
（3）梳理不同角色的資訊和流程觸點
我們以其中三個角色為例，來說明如何梳理不同角色的資訊和流程觸點。這三個角色是銷售專員，廚師長助理和總經理。
銷售專員和廚師長助理都是運營使用者角色，他們的資料和流程觸點往往比較具體，涉及到
原始行
資料的蒐集和錄入，也包括髮起具體的業務活動。透過分析，我們可以總結銷售專員的最重要業務活動就是
接受客戶的訂單和向加工中心發出加工單
；進一步分析，如果要處理客戶訂單，就不可避免地要
建立和維護客戶檔案，以及產品價目表
這兩個關聯資料物件，否則這個訂單是無法有效建立的。（不可能在一個客戶的多訂單中重複錄入客戶資訊，也不應該在訂單中不斷重複產品具體資訊）。這個進一步分析表達在下圖的擴充套件箭頭上。這種擴充套件分析是我們透過角色業務活動整理資料架構的基本方法。在這個分析圖中，加粗和紅色的字體表達的就是整理出來的業務資料物件，也就是RPIC方法中的I（Information）。
透過如上分析，我們枚舉出以下業務資料物件：
訂單
客戶
產品價目表
加工單
供應商
物料
採購訂單
運單
除了這兩個運營使用者角色，我們再分析一個管理角色——總經理。
管理角色對於企業資訊和流程的運用一般都會基於運營使用者已經處理的資料內容，所以如下圖所示，總經理希望分析訂單和客戶變化趨勢，分析利潤情況，這兩者的基礎資料支援都已經在以上運營使用者管理的資料基礎之上，我們已經無需再擴充套件更多的資料物件。
但是，管理視角可能會提示我們既有資料架構的不足。比如，如果總經理希望考察加工中心的人效資料，則最好能夠增加加工中心的出勤資訊資料。
額外說明一下，在本例中，之所以訂單的成本核算可以根據採購單直接獲取，是因為這家餐飲企業在財務會計上使用批次成本法，也就是銷貨成本可以直接對應到某些批次的進貨成本。
這樣，透過每個角色的業務活動分析，我們整理出他們各自所需要接觸的資料和流程，分析結果如下圖所示：
至此，我們已經完成了架構設計的基礎工作。接下來，我們需要進一步細化RPIC方法中的Process和Information
（4）用ER圖細化資料模型
第3步已經列出資訊系統所需要的資料物件。在此基礎上，我們繼續細化資料的屬性，也就是描述每個資料物件的欄位。
描述資料的屬性可以基於現有工作流程中的材料，比如現有的IT系統介面，Excel檔案，紙質表單等。如果設計者本人不直接從事相關業務活動，還可以訪談相關的職能使用者。
下面給出本案例需求所涉及到的資料物件列表和他們的屬性。在架構設計上，我們一般用實體關係圖（ER圖）來表達。ER圖的繪製雖然有一些專業約定，但是它並不難理解，所以建議零程式碼應用深度使用者學習掌握。概括來說，ER圖繪製的規則包括：
（1）用表格框來表達一個獨立的業務物件，對應著關係資料庫中的資料表。同一性質的主體必須放到同一個資料表中。比如我們不能有客戶表和大客戶表，也不能有年度客戶表這樣的概念，客戶就是客戶，所有屬性的客戶都應該在一個獨立的客戶表中。
（2）在表格框的主體部分羅列描述主體的屬性，對應著關係資料庫中資料表的欄位。在正式的應用開發設計中，還需要定義欄位型別、主鍵和外來鍵，對於應用平臺搭建使用者來說，這些技術化的環節全部可以省略。
（3）用連線線建立不同資料表之間的關聯。關聯主要包括一對一、一對多和多對多的型別。比如本例中，客戶和訂單就是一對多的關係，用
表示。而訂單明細和產品價目表就是一對一的關係，用
表示。有關關聯資料庫的基礎知識可以參考第3章中關於工作表關聯的型別。
（4）整個ER圖的佈局要注意位置關係，讓具有關聯關係的物件排列在附近位置，讓關聯關係更容易被理解。
在上圖中，除了之前分析步驟列出的8個數據物件外，還增加了5個數據物件。分別是產品分類，訂單明細，產品價目明細，採購明細和加工明細。這些明細表擴充套件是業務資料結構中常見的手段，它能夠提高業務系統的靈活性。比如如果一個訂單表沒有訂單明細，那麼一個訂單就只能記錄一種產品的購買，如果一次訂購多個產品，就不得不分開多個訂單。這顯然是不合理的。訂單產品明細中的記錄再和產品價目表專案關聯，就建立了一個更加合理的資料結構。
產品分類表的建立則是為了讓顧客訂購產品的時候能夠方便地按照類別進行查詢，比如冷菜、熱菜、早餐和套餐等。
設計資料結構也並非一定要使用ER圖。對於簡單的資料關聯關係，用一般表格加標註來做計劃也是可以的。無論用何種方法做計劃，分析出來的資料物件列表就會完整對應零程式碼應用搭建時的工作表物件。
企業軟體行業發展數十年，在常規的企業運營活動中已經積累和完善了成熟的資料模型。比如管理銷售漏斗的CRM資料架構，管理貿易活動的ERP資料架構，管理專案績效的PSA資料架構。這些資料架構都反映在成熟的軟體產品中。所以，企業自建數字化系統既不能閉門造車，也無需自己重新發明輪子。有時候直接參考成熟軟體的資料架構是一個明智的做法。明道雲零程式碼平臺在提供銷售管理應用模版時，就直接復刻了Salesforce和微軟Dynamics CRM的資料結構。
（5）用流程圖繪製業務流程
第3步列出各個角色的流程和資料觸點，接下來我們詳解每一個流程，為具體的應用設計作準備。我們以列出的5個流程中的“按加工單採購流程“為例進行具體拆解。
按加工單採購是廚師長助理的業務活動。他接受來自銷售部門的加工單，根據加工單內容向生鮮配送商下采購訂單。以下是透過標準流程圖對這項業務活動的流程解析。廚師長助理根據生產工單內容生成了原料採購單，並根據當前輔料庫存的情況決定是否增補輔料。每一項採購流程均已供應商確認而結束。
在流程圖的右側，我們可以在對應的位置上起草一些具體的架構內容。比如，根據
多工
單生成採購單的節點就對應了加工單的自定義動作（工作流的一類）的建立，它的實質是要根據加工單明細來獲取物料明細，並將物料明細組合成計劃狀態下的採購單。而同樣，建立輔料採購單則比較簡單，它應該直接依附在物料表記錄上，針對特定輔料來建立採購單。
3。4 架構產出物與藍圖完善
透過以上步驟，我們從角色出發，遍歷每個角色的流程和資訊觸點，完成了多項架構內容的產出。這些產出可以直接服務於零程式碼應用搭建。我們可以小結如下：
（1）資料結構作為
工作表
（2）根據單據狀態，可以建立工作表下的多個
檢視
，例如“草案訂單”、“待執行訂單”等。
（3）系統所涉及到的所有內外部角色清單，作為應用中的自定義
角色
依次建立和賦權。
（4）運營角色和管理角色所需要的報表內容，作為
自定義頁面
及其
統計元件
搭建的藍圖。
（5）每個角色的業務活動及其分析出來的流程作為
工作流
配置的藍圖。其中有一部分工作流將透過使用者的手工觸發（自定義動作）執行。
以上這五個部分就是應用平臺搭建所需要的基本架構內容。我們從需求命題的參與角色出發，一步一步梳理，得到具體的工作清單。這個過程所需要花的時間取決於專案的規模。一般而言，單個職能部門的小型應用並不需要這麼完善的分析過程，但像這家餐飲公司的核心業務系統還是有必要進行這樣的架構分析工作的。雖然零程式碼應用平臺的使用不像程式碼開發工作那麼技術化，但我們依然鼓勵使用者加強文件工作，提高應用系統的質量，至少可以提高一次做對系統的機率。
4、應用實現
4。1 工作表和檢視
應用搭建的基本技能我們已經在本書的其他章節詳細介紹，本案例章節呈現一個根據藍圖而搭建的應用實現面貌。
在這個明道雲實施專家搭建的應用中，將不同業務環節分組（頂部選單），在每個業務分組下建立對應的工作表。比如，如圖產品管理分組下就建立了系列（分類），產品，產品明細和產品配方這四個物件。
生產工單是之前資料架構過程中涉及的資料物件，在實現的應用中，生產工單包含了生產明細的子表。下圖是一張生產工單的樣例。
4。2 使用者角色
架構分析的第一步就是角色列表，可以將這些角色透過應用平臺配置為自定義角色，並根據資料接觸需要分別給他們賦權。
4。3 工作流
在明道雲應用平臺中，工作流是由觸發器和一系列動作節點構成的。只要觸發器滿足條件，就會自動執行所有的動作節點。在本案例中，有諸多環節均需要由特定角色觸發工作流程，例如生成加工單。這個工作流可以透過一個按鈕觸發，然後透過資料操作相關的節點，將訂單中的資料轉移到加工單上。下圖是整個系統所配置的工作流。
4。4 自定義頁面和統計
圍繞管理角色所需要的統計資料，應用平臺可以透過自定義頁面上插入統計元件，再將頁面分發給不同的角色。例如本例中就建立多個“駕駛艙頁面”，不同職能角色看到的頁面組合可以是不一樣的。
5、從架構藍圖探索更多的數字化機會
命題作業已經基本完成，我們可以藉助架構工作的價值，進一步探索數字化運營的機會。反過來來說，如果我們拋去架構設計過程，直接根據需求搭建應用，就失去了看清全域性的機會。創新不是空中樓閣，只有看到，才有更大的機會想到。架構藍圖的價值就是提供給企業主一個發想和驗證的工具。
5。1 延伸到更完整的業務環節
案例只覆蓋了普渡餐飲的接單、採購、生產加工和配送環節。對於完整的企業運營來說，還有很多其他環節具備數字化升級價值，比如此例中，普渡餐飲可以把營銷拓客，銷售轉化，客服，人事考核等都加入進來。利用零程式碼應用平臺的一大好處就是各個業務系統實際上是緊密相連的，減少了採用不同技術解決方案帶來的資料孤島問題。比如延伸客服應用時，顯然可以直接共享既有的客戶和訂單資料。明道雲的工作表關聯可以跨應用實現，所以無論怎樣規劃應用組合，都是可以實現企業內的資料統一治理。這對企業數字化建設是一個重要價值。
在延伸業務環節的時候，一般可以從核心業務流程，或者說是企業的關鍵價值創造過程開始。比如本例中，普渡餐飲的價值創造就是為客戶加工餐飲訂單並配送的過程。在核心業務流程完善後，再向支援性職能擴充套件。這是我們在企業數字化建設里程碑設計中的常規考量。
在這兩種性質的業務環節中，一般只有核心價值創造流程才值得建立差異化競爭優勢。比如普渡餐飲有機會利用數字化能力建立零庫存且全自動的原材料採購和配送體系，從而建立在企業餐飲服務市場的成本優勢。而在支援性業務環節，只需要對標一般競爭者即可。數字化建設的主要精力始終應該聚焦在核心業務流上。
5。2 以顧客為中心的服務延伸
案例中還沒有涉及到客戶體驗相關的環節設計。這個環節對於任何企業來說都應該是有發揮和創造的空間。譬如普渡餐飲可以建立線上選單，允許顧客直接自助下單，可以為客戶建立選單收藏，提高客戶下單體驗。客戶下單以後，還可以實時跟蹤訂單處理狀態，甚至可以直接跟蹤到加工單。需要的時候給廚師長帶個話都可以。
數字化建設在顧客體驗方面的創新空間是無窮盡的。設計什麼樣的資訊系統，提供什麼功能，一切都可以以是否能夠給客戶帶來價值和高體驗為標準。相反，我們也可以根據客戶現實的痛點逆向思維，想一想我們如何透過數字化能力來解決客戶的這些問題。比如客戶在宴會用餐的時候，不想花時間來盯著物流，那麼我們就可以在進入加工步驟和交付給物流公司的時候主動推送簡訊通知客戶。這些就是我們常說的有溫度的IT。
5。3 自動化
所謂自動化，就是將過去需要人員處理的工作交給程式處理，理論上，只要有可線上的業務資料，透過原生開發，總能夠實現想要的自動化場景。只是這個過程比較昂貴。它涉及到業務需求部門和軟體研發團隊的高密度溝通，需要做很多的除錯和驗證工作。
零程式碼應用平臺給了業務使用者一個機會自助完成這些複雜的自動化特性開發工作。準確得說，這個過程是透過視覺化配置完成的，並不需要寫程式碼。在本例中，普渡餐飲透過客戶的訂單內容，查詢訂單產品明細所對應的原料數量，即可自動計算出每天所需要進行的原料採購單。透過實驗和調優，可以將原料預定數量控制得非常精確，而且不需要花費人工計算。而過去，批次餐飲生產企業都必須依賴主廚的個人經驗判斷來做決策，既不準確，也不易於內控。這個自動化設計可以成為普渡餐飲運營過程中的亮點，不僅運營效率高，而且節省了很多不必要的人力投入。
像這樣自動化的機會還很多。它們一般貫穿在各項業務活動之間，傳統上靠人員協作來解決。再比如，生產加工中心給物流公司下配送單也可以是全自動的，它可以根據加工單的狀態變化來自動觸發，也可以每天定時按照加工單內容批次生成配送單。
5。4 洞察
當業務運營起來以後，我們就會不斷積累出商業資料。這些資料會給企業更多的洞察機會。比如普渡餐飲可以透過客戶訂單結構分析來優選菜品組合，透過價格敏感度測試最佳化定價，透過訂單配送時間需求來最佳化運營班次，幾乎任何商業資料的集合都會帶來更好的決策。
只要資料在一起，進行報表分析就不復雜，你甚至不用再投資昂貴的BI軟體，零程式碼平臺本身就能夠製作各種基於資料表的統計元件，這個過程如同製作Excel圖表一樣簡單。
5。5 業務擴充套件
企業投資數字化建設，有一個很重要的動因就是滿足未來的規模化成長。當業務規模不大的時候，用簡單的工具也許還能對付，例如銷售部如果只有幾名員工，那麼靠Excel記錄和日常溝通就能夠解決銷售管理問題。但是當人員擴充到數十後，很難逃避真正意義上的數字化建設。
人員擴充只是業務擴充套件的一種形式。更復雜的擴充套件包括引入多個運營實體。例如普渡餐飲很可能需要在一個城市建立多個生產加工中心，以降低配送成本和加快配送速度；它也有可能未來走出一個城市，建立全國性運作。這時候，集中服務的數字化系統就發揮出了更大的效力，單位成本也會得到攤薄。建立多運營實體在IT上並不一定很昂貴。基於上文我們分析的普渡餐飲業務資料架構，我們只要增加運營城市、加工中心物件，就能夠將現有的應用快速擴充套件為一個多站點使用的系統。這一切都離不開科學和有前瞻性的架構工作，它就是本章主要介紹的內容。
