本文來自一位九年產品老司機的投稿。作者從一個故事說起，將企業應用架構的演變史娓娓道來，全文1.1萬字，小編看完只有一個大寫的“服”，強烈安利各位涉及相關產品的童鞋收藏，不時拜讀。

企業應用架構是指一整套軟件系統的構建，通過合理的劃分和設計組合在一起，支持企業方方面面的經營運作。不論是傳統企業，還是互聯網公司，發展到一定階段，都需要一整套體系化的應用架構來支撐其運轉。良好的、合理的應用架構可以支持企業高效開展業務，控制經營風險，而混亂的、不合理的應用架構則會限制企業的快速發展，成為企業增長與變革的瓶頸。

企業信息化建設已經發展了幾十年，傳統企業和成熟互聯網企業的應用架構并沒有本質的區別。本文將通過一個線下小型門店成長為多元化集團的發展歷程，逐步向讀者展示企業應用架構的演變和設計的理念。

完整的企業架構（EA，Enterprise Architecture）分析構建，包括業務架構、應用架構、技術架構、數據架構，本文聚焦應用架構，更加關注軟件系統設計與公司經營管理的關系。不論是C端產品經理或者B端產品經理，理解應用架構的建設思路，能夠幫助你更輕松的理解公司的業務運轉，以及各個系統存在的目的與你所負責工作在整體團隊中的定位和價值。

一、傳統企業的應用架構演變

1、小門店的Excel管理之路

我們將從一個最簡單的案例入手，來展開故事。

假設你是一名個體經營者，在小區中開了一家小門店，售賣居民常用的生活用品。門店不大，只有十幾平米，平常由你一個人負責經營管理，包括采購、擺貨、銷售。為了更準確、科學的打理你的生意，你設計了一個Excel文件來管理你的商品與銷售數據。實際上你只需要做三張表格，第一張表格存儲了你的貨品信息，第二張表格存儲了你的采購記錄，第三張表格存儲了你的銷售記錄，這三張標的結構和關系如下圖所示。

上圖采用了ER模型來描述三張表的邏輯結構，*和1的含義是表和表之間的關聯關系，例如采購記錄和商品信息是多對一關系，即采購記錄表中的每條數據只能對應商品信息表中的一條數據，商品信息表中的一條數據可以對應采購記錄表中的多條數據。

因為你采用了科學的數據表格管理，記錄了門店的所有采購入庫和銷售數據，這讓你的經營變得井井有條；通過這些原始數據，你可以準確的管理庫存、計算利潤、掌握暢銷品和滯銷品，還能通過數據透視表制作銷售日報和月報。

實際上你通過以上三張表格管理自己的生意，已經是一個管理軟件的雛形了。所有的軟件系統無非都是對數據的增刪改查操作；可以說，如果使用得當，Excel也可以做出一套小型的軟件系統。

2、小超市的輕量級ERP之路

因為你善于使用信息技術來協助你做生意，你的買賣發展迅速；很快，你將小門店升級成為一家小型超市，并且雇傭了幾個店員來幫你。作為店長，你興奮的繪制出自己的第一張組織架構圖，夢想著事業會繼續壯大。

因為經營的貨品更加豐富，日交易量成倍增長，并且有好幾名員工需要做數據錄入分析工作，這時Excel已經難以滿足經營管理的需要。因此明智的你在開店之前，就決定采購一套ERP軟件來協助你管理超市。因為你還處于創業期，資金有限，通過仔細挑選，你選擇了一套輕量級的ERP，并且只購買了其中的幾個核心模塊，這樣既可以控制成本，又可以讓你經營的軟件設備升級。

現在，我們可以繪制公司的第一張應用架構圖，公司擁有一套系統，包含三個模塊。

3、通過CRM拉近與客戶的距離

為了更加準確的理解、認識你的客戶，同時也為了能夠拉近你和客戶的距離，你打算通過CRM軟件進行更加科學的客戶管理。

你設計了一套會員積分制度，所有的客戶都能免費辦理會員，這樣你就可以記錄下關鍵的客戶信息，而且你的小伙伴建議你開通一個微信公眾號，讓客戶能夠通過微信來查詢自己的積分。

這個主意太棒了！你追加購買了幾個ERP的模塊，雖然ERP中也包含了CRM模塊，但是研究后你認為內置的CRM模塊功能有限，不支持對接微信，營銷功能也不夠強大，因此你新購買了一套CRM軟件，和ERP進行了一定程度的對接，同時申請了微信公眾號，找外包公司做了一些定制化開發。這樣上述想法就都實現了！

我們繪制出公司的第二張應用架構圖。

可以看到，核心的客戶信息資產模塊都在CRM中實現，其中內置了營銷模塊、消息推送服務Msg模塊，包括SMS、EDM（Email Direct Marketing）和微信消息推送。

• CRM主要聚焦客戶資料的管理和營銷服務，主要用戶為店長和運營人員；
• ERP主要聚焦于超市的進銷存以及財務業務，主要用戶為營業員、出納、采購、庫管和會計。

請注意：這里已經產生了應用架構設計的概念。公共號、ERP和CRM每個系統都為了解決某一大類的業務問題而存在，有各自清晰地定位、分工和目標用戶，每個系統相對獨立又互有關聯，內置若干模塊，每個模塊都是為了解決某一大類業務問題下的某一小類問題而設計。

在這張圖中我們使用了分層描述，靠近C端用戶的微信公眾號在最上層，支持業務運轉的ERP放在中間層，偏底層的客戶信息集成CRM放在最下層，這樣可以清晰地看出幾個系統的層次關系，同時也在一定程度反映了系統和業務之間的邏輯對應關系。

4、中型連鎖超市的架構之路

業務進展很順利，你已經開了五家中型連鎖超市了，員工數量達到了幾百人。公司走上了正軌，標準化的管理分工已經成型，不同職能單元各司其職。為了有效管理團隊，并且讓內部流程更加順暢，你邀請專業的IT咨詢公司幫你重新梳理了公司的業務目標、組織架構、運營流程，通過引入OA、HRM以及重構ERP等手段，對不合理的制度，低效的流程進行了改造。公司成立了信息技術部，其中項目部配合咨詢公司以及軟件外包公司進行系統改造或實施新系統，運維部負責保證服務器、網絡的穩定。

你理解數據對公司發展的重要性，所有的管理決策都應該基于對數據的分析和判斷，因此你邀請咨詢公司幫你強化公司的數據分析能力。

咨詢顧問建議你實施數據倉庫（Data Warehouse）和BI（Business Intelligence）項目，原因有幾點：

1. ERP系統和CRM系統都有報表模塊，但兩個系統的數據相互孤立，不利于整合分析。
2. 業務系統的底層數據結構并不適合做復雜的數據分析，常見的多維分析更需要一套數據倉庫常用的星形數據結構和雪花型數據結構。
3. 成熟的BI軟件套件可以讓你的報表分析與多維數據探查更輕松，其中的儀表盤更能夠讓你輕松掌控公司全局的核心指標變化。
4. 企業經營中很常見的一個問題，就是經營分析指標統計口徑太多，造成管理混亂和溝通障礙，除了在管理上規范公司級指標的定義，也需要一套底層數據架構，消除上游各個異構系統的孤島和屏障，統一管理匯總數據和指標計算。

咨詢顧問建議，雖然目前公司的業務系統還沒有到非常復雜的階段，但數據倉庫可以幫助企業更快速高效準確的理解、捕獲、使用數據，做好基礎建設工作，培養員工的數據分析意識和方法，通過數據來進行決策。隨著業務的拓展和系統復雜性的提升，數據倉庫的存在價值將越來越明顯。

在數據倉庫項目中，同時構建了數據集市（Data Mart）。數據集市介于BI展現層和DW數據底層之間，是數據倉庫的數據子集。數據倉庫的服務對象通常為全公司或全集團，但是不同部門可能有自己的數據分析訴求與指標管理訴求，這時候通過統一的數據底層，封裝出針對某個部門使用的小型數據集市，可以保證數據流的合理性、可追溯性，同時研發部門可以完全復用DW和BI的技術能力，輕松地設計實施DM。

如果希望數據倉庫在企業中真正發揮作用，不僅僅是軟件系統實施問題，更重要的是公司層面的經營分析思路體系化，指標管理規范化，以及數據部門組織架構、與業務部門合作流程設計問題，同時還需要提升全員數據化管理運營的概念和意識。軟件本身并不能解決企業的問題，只有配套的架構、流程、制度與意識，才能發揮軟件的功效。

5、應用架構跟隨業務而變

由于公司經營良好，很多商品可以從供應商處拿到很好的價格，經過供應商授權，公司決定開展2B業務，成立了大客戶銷售部，公司將作為供應商的B端渠道，挖掘企業客戶。為了讓銷售工作高效展開，對銷售人員進行嚴格的過程管理，同時也為了保留客戶資料，避免銷售獨占客戶資源，根據CTO建議，公司決定實施操作型OCRM（Operating CRM）項目。同時由于各部門經常出現個性化的軟件開發訴求，軟件外包維護的成本高，效率低，公司決定招聘研發團隊，用自己的隊伍進行軟件的二次開發。

在設計OCRM系統時。CTO面臨兩個選擇：

方案一：新做一套獨立于現有CRM的OCRM

• 優點：OCRM系統已有成熟的軟件可以選擇，無需從頭開發；兩個系統邊界清晰，分工明確，便于未來各自的發展與演變。
• 缺點：應用架構會略有復雜，需要將原有的CRM和OCRM做數據打通，對原有的客戶模型做升級。

方案二：在原有的CRM基礎上開發新模塊

• 優點：新開發的模塊完全基于公司業務流程和模式設計，適配程度高。
• 缺點：新開發模塊成本高速度慢，系統邊界模糊，導致以后維護升級時模塊管理的混亂。

綜合評估兩套方案實現的成本和速度，考慮到對未來業務變化的靈活支持，同時為了避免影響核心CRM業務的穩定性，CTO決定采用方案一，讓兩個系統各自聚焦，互相獨立，邊界清晰，雖然無形中增加了公司應用架構的復雜性，但可以快速實施支持當前的緊迫業務，并靈活應對未來公司的銷售業務變化。

一般來講：B端客戶的數據模型和C端客戶差異非常大，B端客戶模型關注組織架構和人員角色的描述，C端客戶模型關注客戶本身個人信息的描述，即便應用系統中將客戶模型和操作型系統分開建設，客戶模型一定會做成兩套以支持不同的上下游業務系統。

上圖為了簡化表述，只繪制了一個模塊“客戶信息”，但讀者應該認識到：該模塊應該包含B端、C端兩套客戶模型。實際上有的公司會明確將兩套客戶模型在應用架構中分開設計并且分別建設，以便更加準確的體現應用架構中的業務概念。

廣義上來講，CRM代表一種企業對待核心客戶資源的管理理念和運營方法，CRM是一種概念而非某一個獨立的應用系統。

大型的企業涉及多條業務線，不同的業務線有不同的客戶群。企業需要有統一的客戶視圖和管理理念，以及強大的IT系統支持，來實現準確的客戶接觸點管理，充分挖掘客戶群體實現精準銷售，積極有效的維護企業和客戶的關系。

CRM體系化的系統建設中包含了客戶建模、會員積分管理、營銷中心、銷售線索和過程管理、小型數據倉庫或數據集市、統一客戶視圖、客戶畫像和數據挖掘、電話銷售中心等等。不同的企業對系統的劃分和團隊的管理各不相同，但所有CTO都應該明白CRM是一套應用體系，而不僅僅是某個單一的獨立應用系統。

至此，我們已經繪制出一套一般企業的簡化版應用架構圖，以及一張常見的組織架構圖?？梢钥吹?，應用系統的建設，是根據業務的發展變化逐步完成的，每個系統都有獨立存在的意義和價值。

二、多元化業務帶來的應用架構演變

1、在線商城業務帶來了互聯網化管理

公司的零售業務發展進入了瓶頸期，CEO需要尋找新的增長點。

經過評估，決定開展電商業務，新成立了電商部，從市場上聘來了某電商平臺VP作為部門負責人，直接給CEO匯報。為了學習互聯網公司，以技術力量推動業務創新，電商部組織結構參考了一般互聯網公司組織結構，有自己獨立的研發團隊，設置了產品崗位，產品技術總監給電商部負責人匯報。電商部受到CEO極度重視，給與極高自治權和最高資源支持，同時CEO還將之前線下的客服團隊升級為公司一級部門，直接給CEO匯報，統一處理線上線下的客服與售后業務。

新業務開展，大家干勁十足，因為電商部產品技術總監和公司CTO之間不存在匯報關系，產品技術總監為了快速推進項目，所有決策基本只是告知CTO。產品技術總監作為純互聯網背景專家，認為購買現成軟件套件不利于系統的二次開發和自主維護，長遠來看會限制公司業務發展，希望整套系統實現自主研發。雖然CTO極力反對，但經過電商部負責人和產品技術總監的游說，CEO聽取了總監的建議，并且總監承諾自己的研發團隊效率極高，一定會在承諾之日交付系統。

產品技術總監設計的應用架構體系，包括PC和移動版的前端應用，以及完整的后端系統，包括訂單、售后、客戶信息、會員、營銷、賬號、CMS。此外，倉儲、財務系統會接入現有ERP的服務，配送模塊直接與第三方配送服務商系統對接。對于這個架構設計，CTO比較不滿，認為客戶信息和賬號管理不應該重復建設，而應該統一規劃管理，但產品技術總監一心快速推進實施，對于信息技術部開發效率低的情況他早有耳聞，他可不希望被一些不可控力影響導致自己的項目延期，因此CTO的抗議他不予理會。

升級后的客服部門，新建了20人坐席的電銷中心，以支持主要來自于線上的電話客服訴求。新成立的客服團隊需要CallCenter系統開展業務，雖然CallCenter的主要服務群體是線上業務的客服話務員，但CEO為了在一定程度上安撫CTO的不滿情緒，將CallCenter項目安排給CTO負責。CTO采購了一套成熟CallCenter來支持400熱線業務，對此安排電商部的產品技術總監沒有什么異議，但在CallCenter的實施中卻出現了問題。因為CallCenter系統只負責電話作業，其中的客戶資料一般由上游系統提供。但是公司現有兩套客戶資料，一套是保存在CRM的線下業務客戶資料庫，一套是在線商城的客戶資料庫。為此只能在CallCenter中新增一套客戶庫，將另外兩套客戶庫數據同步過來，這樣客服人員才能在CallCenter中查到公司級別的完整客戶信息。

2、信息孤島與主數據管理

電商系統如期上線，業務發展迅速，電商團隊的運營和產品人員年輕，聰明，充滿活力，思維活躍，玩法眾多，電商技術團隊響應迅速，產品經理和技術團隊的無縫配合，讓技術力量真正推動了業務的增長。公司賺錢了，老板很開心。但很多問題也同時暴露了出來。我們先來看看之前的應用架構。

之前為了快速上線，有一些應用架構遺留問題沒有解決?，F在公司有三套客戶資料庫，線下客戶通過微信公共號訪問CRM系統中的客戶信息，在線商城的客戶通過線上商城訪問e-Store系統的客戶信息。當客戶致電400時，電銷業務員（TSR）訪問的是從e-Store和CRM同步過來的客戶信息。

線上客戶關注公共號后，查不到自己的資料，這讓客戶感覺很詭異。

線下客戶想在線上商城下單，發現之前登記的賬號不能使用，需要重新注冊完善資料，客戶很煩躁。

數據同步30分鐘一次，有時候客戶剛修改完資料再致電400，客服查到的客戶信息不是最新的，讓客戶很生氣，客服很苦惱。

有的客戶喜歡打電話讓客服改資料，因為客戶資料是單向同步，客服無法協助客戶修改資料，客戶很氣憤，為什么你們連這點服務都做不好！

很多客戶在線上線下都消費，但由于在數據倉庫中冗余出了兩個客戶對象，不論是線上團隊還是線下團隊，都無法做更準確的客戶畫像和跨渠道消費行為分析。

CEO很生氣，找到CTO和電商產品技術總監，質問怎么回事。CTO回答，我們遇到了嚴重的信息孤島問題！由于CRM和商城后臺數據互相孤立，導致核心客戶資源不同步，不統一，讓公司無法得到一個完整準確的客戶視圖。如果要解決這個問題，必須對應用架構進行改造，并且改造比較耗時。CEO很郁悶，沒想到應用架構不合理會影響到業務發展，也沒有想到組織架構的設計會導致應用架構出問題。為此，CEO做了一些調整，產品技術總監實線向電商部經理匯報，虛線向CTO匯報；總體來講產品技術總監對電商業務銷售端負責，CTO對全公司IT架構管理和其他所有系統負責。經過善意的溝通，CTO和產品技術總監的矛盾消除了，大家決定合力解決問題。

解決數據信息孤島的方法很簡單，那就是只保留一份客戶信息庫，這份客戶信息庫保存最核心的，與業務單元無關的客戶屬性和資料。至于積分、會員等擴展屬性依然由各個應用系統維護管理。調整后的應用架構圖如下：

將客戶信息庫獨立，商城、CallCenter、CRM和微信公共號通過統一接口調用Customer Profile存儲的核心客戶檔案，不論客戶或業務員從哪個端口查看或修改信息，變化對其他端口都是透明、實時的。實際上這就是客戶主數據管理MDM（Master Data Management）的設計理念。

在企業應用系統建設中，不可避免的會遇到信息孤島問題，信息孤島是指因為各種原因，每個應用系統獨立建設時，沒有和外界系統做良好的打通，導致應用系統之間存在流程或數據的孤立性，最終給業務帶來嚴重影響。解決數據信息孤島的經典方法就是主數據管理（MDM）的思想，主數據管理通過應用架構的拓撲設計，配合相應的管理手段，幫助企業存儲、識別唯一的關鍵數據，避免企業內部關鍵數據的冗余和不一致問題。常見的主數據有客戶主數據，商品主數據等。

主數據管理的設計理念應該自始至終貫穿企業應用架構的設計過程，需要注意的是，企業應該在合適的階段實施主數據管理和治理。主數據將應用架構變得更復雜，在初期階段實施時需要投入更多時間和資源，而在企業發展的某些階段，快速迭代上線意味著對商機的捕獲和市場變化的迅速跟進，一個合格的架構師應該在應用架構設計和公司業務發展之間做出合理權衡，要根據現實的情況和資源，敢于在應用架構的和理性上做出妥協和讓步。

主數據經常作為底層數據應用來管理，因此在架構圖中我們將它和DW并列畫在最底層。

3、抽離共性模塊全面服務化建設

公司業務發展穩定，各個系統底層做過幾次技術重構，性能更強健。為了讓各個應用系統更加聚焦，提升穩定性，節約開發成本，避免重復勞動，CTO和產品技術總監討論后決定對一些公有服務從各自應用系統中剝離，統一進行服務化改造升級，為以后公司新業務的開展打好基礎。例如，將CRM和商城后臺的消息模塊功能合并，將商城支付模塊單獨剝離，設計實施了集成化的權限管理系統Auth，給全公司多個應用提供統一的權限管理服務，控制公司運營風險。

CTO和產品技術總監合作加強了數據團隊建設，設立了數據挖掘團隊，豐富了客戶畫像，加強了經營分析能力，產生了更多的策略輸出。數據策略輸出不僅給在線商城提供了更強勁的推薦策略，也為CRM，運營人員提供了更豐富的策略運營、精準定向活動推送支持。

4、強健的底層架構快速支持新業務開展

公司在尋找新的增長點，計劃開展個人理財業務。公司的組織架構有了新的調整，管理模式也有了新的提升，形成了集團化治理模式，成立了財務共享中心，人力資源共享中心。新設立的理財事業部，和零售事業部、電商事業部一起，調整為獨立核算事業部編制，事業部聚焦經營和銷售，集團層面給事業部提供基礎運作支持。信息技術部也與時俱進，將之前的需求管理部調整為產品部，信息技術部主要負責CRM、CallCenter、ERP、OA、HRM、DW、BI等應用系統，保證集團職能部門運作，為事業部的應用系統提供基礎架構和底層服務支持。

因為集團IT應用架構已經非常強健，理財業務的系統構建可以迅速展開，CTO和理財事業部的產品總監溝通后繪制了集團應用架構圖，理財業務只需要建設一套C端APP和一套基本的管理后臺，而類似于客戶數據、支付、Push服務、DW和BI都直接使用集團現有系統，無需重新開發。

CTO和產品總監討論后，認為上述架構圖還存在一點問題，賬號管理不應該單獨創建，集團已經有著很成熟的統一客戶管理理念，多套賬號管理模塊會再次造成信息孤島問題。因此決定將現有的賬號管理模塊也進行平臺化、服務化升級，給理財業務提供支持。集團層面的Passport系統誕生了。更新后的架構圖如下。

這里順便解釋一下：為什么本文對所有軟件系統都稱為系統，而互聯網公司則習慣稱其為產品。

互聯網的發展催生了產品經理的崗位。產品經理常分為C端產品經理，B端產品經理（包括商家端和運營管理中后臺）等。

B端產品線中，有CRM產品經理、供應鏈產品經理等。在互聯網公司似乎不太在意區分產品和系統的叫法，到底兩者有何區別？

實際上，所謂產品是指企業提供的商品或服務，給企業帶來利潤。早期的互聯網公司多為虛擬經濟形態，面向用戶的軟件系統就是公司給消費者提供的商品或服務，因此聚焦軟件功能設計的人員被稱為產品經理。而互聯網公司是一類高度依賴信息技術能力驅動業務的公司，對各類軟件系統都傾向于自主建設，因此不論是面向客戶的系統，或面向企業內部的系統，軟件設計人員都統一叫做產品經理，其職責定位就是負責軟件的設計和實現，軟件系統習慣被稱為產品；而在傳統企業，負責軟件設計的人員一般都叫做需求分析師或系統分析員，軟件系統習慣被稱為系統。

其實怎么稱呼都無所謂，本文統一叫做系統。

三、企業通用應用架構設計

1、通用企業應用架構圖

對上文的應用架構圖做一些簡化和調整，以便更加準確的體現應用架構的共性以及與業務的對應關系，得到一張更加清晰簡潔的企業級應用架構圖。

第一層是對外系統。所有給企業外部客戶使用的系統都在這一層，包括官網，普通用戶或客戶使用的C端。如果是類似于美團，天貓這種平臺性質的業務，還會包括給商家使用的商家端。這類系統站在與客戶接觸的最前線，是公司實現商業模式的橋頭堡。

第二層是對應C端系統的管理后臺。常見的管理后臺都會包含訂單、CMS、商品等模塊。每個C端業務形態都會對應一個管理后臺，有些管理后臺的模塊可能會被抽離出來集中維護，例如風控，消息服務，客戶主數據。

第三層是業務單元支持系統。絕大多數企業業務的開展，必然不能單純靠線上的運作來實現經營，而可能包含電話銷售，客服，地推，倉配等一系列業務單元共同運作。業務單元的運作需要強大的系統支撐。

第四層是職能單元支持系統。企業發展到一定規模后，必然會有完善的職能單元作為后勤部門支持業務單元的運轉和企業的正常運作，例如法務、財務、人力、客服，每個部門的正常運轉都需要相應系統的支持。

第五層是基礎架構支持系統。信息化建設到達一定程度后，企業有必要將通用功能服務化，平臺化，以保證應用架構的合理性，提升服務效率。這類系統主要給其他應用系統提供基礎服務能力支持。

第六層是數據底層，和第五層類似，這一層主要集中在數據層面的統一和封裝，對各個下游系統提供數據服務。

以上六層劃分涵蓋了企業所有的應用系統建設，每一個應用系統的存在都將定位在六層中的某一層。上圖示例的系統涵蓋了絕大多數正常企業經營運轉常見的應用系統，在現實世界中，應用系統數量會遠遠多于上圖所示，例如商業銀行可能會有成百上千個系統存在。但是理解一個常見企業的組織結構，部門定位，以及上述應用架構圖形成的原因，可以讓你更準確快速的理解、掌握、設計任意一個應用系統。

2、不同類型企業的應用架構圖示例

因為一般企業的組織架構設計，職能單元的設計基本沒有太大區別，而以上簡化版的應用架構圖映射了一個標準化企業的各個常規業務單元，且涵蓋了絕大多數企業中標準的應用系統，所以我們可以將不同互聯網企業的應用架構圖映射到上圖中。

下面我們用三個例子，向讀者演示不同業務形態、發展階段的公司，其應用架構的可能形態。作者并未在以下公司任職，或與相關內部人員探討過其公司應用架構，以下示意圖均為作者根據幾個公司的業務特點和發展階段，所做的推測。

首先以美團點評為例。

美團的業務模式主要為供需平臺建設，幫助消費者和服務提供方撮合交易。外部系統包括了C端系統和商家端系統，C端系統為消費者常用APP，商家端系統為商家提供商品管理、交易管理、推廣管理、經營分析等功能。C端或商家端都對應后端管理系統，方便企業內部對整個平臺進行管理、營銷、風控等。

平臺需要發掘更多的商戶資源入駐，因此會有銷售過程管理的OCRM系統；平臺需要對C端客戶提供客服與售后支持服務，相信美團點評的業務量，一套專業的CallCenter系統必不可少；美團提供了自營的配送服務，TMS系統必然成為標配（也有可能是SCM中的模塊）。

由于美團業務不涉及自營的實物貨物買賣服務，沒有倉儲體系，因此推測沒有WMS系統（或者ERP中包含了WMS模塊但是沒有啟用）。O2O業務需要管理大量線下門店，因此GIS（Geography Information System）系統不可或缺，對于實力較強的公司，可能還會開發獨立的POI（Point of Information）管理系統（也有可能是GIS中的模塊）。至于財務、OA、Passport、Auth、BI、DW、MDM等，必然都是公司標配。

接下來再以今日頭條為例。

今日頭條構建了信息流資訊類C端，吸引網民使用，這類產品最常見的盈利方式為廣告變現。在公司經營之初，可能采取了市面上的DSP平臺來完成APP的廣告管理（當然也可能從來沒有采用過），為了更好的設計廣告產品，相信現在一定有自己的廣告投放管理平臺，因此公司會有給廣告主使用的B端廣告投放管理系統。

（當然也有可能還沒有這類平臺，作者在百度工作時很多商業變現產品投放管理都是PM和廣告主線下溝通后通過內部平臺操作的）。

因為業務模式以廣告投放為變現手段，因此后端系統可能沒有交易類后端復雜，但基本的CMS和風控（反垃圾、反作弊、合法合規）必然是有的。公司需要盈利，就需要售賣產品，售賣產品永遠不可能只在線上運作，必然會有BD團隊支持，因此今日頭條也會有CRM系統，管理對象為廣告主而不是網民。

但是WMS、TMS系統這類系統估計就不需要了。至于CallCenter，筆者查詢了官網，沒有找到相關的客服熱線，猜測還沒有建設。

今日頭條的早已度過創業期，標準的管理軟件應該配備齊全，例如OA、HRM；不同的基礎架構支持系統，在當前階段有可能有，也有可能沒有；例如Auth、Pay、MDM等。作為一個純技術公司，BI、DW當然是標配。

最后的例子，我們挑一個相對規模小，產品形態單一的例子，例如墨跡天氣，萬年歷這類工具類應用的公司。

這類公司在創業初期，不考慮變現的情況下，團隊小，產品簡單，應用架構圖也會非常簡單，在產品發布時，只需要實現官網、C端、后臺管理、賬號和會員管理就足夠了。當然隨著公司的發展，常見的變現手段之一就是廣告投放，可能會繼續演變到類似于今日頭條的應用架構。

以上舉了三個例子，讓讀者更好的理解應用架構演變和公司業務模式以及發展階段的關系。在實際工作中，應用架構的建設與面臨的情況會復雜得多，只要理解了以上簡化版的例子，可以更容易理解實際工作中的場景。

3、企業應用架構設計的一些建議

最后，我們來談一談如何合理的設計企業應用架構。不論是架構師，產品條線負責人，或某個系統的產品負責人，都要有架構設計的理念和知識，尤其是后端產品經理，必須充分理解企業應用架構的基本概念。這里給出一些應用架構設計的建議。

1. 系統定位和邊界要清晰，對應的業務定位和邊界要清晰

一套應用系統的存在，都是為了解決某一類業務問題，對應某一個業務板塊。如果業務板塊或業務單元定義模糊，也會導致對應的應用系統定位混亂。

2. 系統要實現松耦合，高內聚

系統要對外界透明，簡單，易理解，與外部系統的接口要簡明，扼要，靈活。內部模塊高度聚合，粒度越細越不可拆解。

3. 易變的，嘗試中的新業務要避免影響現有業務的穩定性

對新業務的支持，可以考慮新建獨立微小型應用系統，以便避免改造成熟核心系統，影響其穩定性和健壯性。

4. 系統之間數據要實現單向流轉

系統之間盡量保證單向數據流轉，確保數據流可回溯，數據的一致性和可追溯性?；靵y的數據流轉管理會造成應用架構管理的災難。

5. 架構設計核心目標是支持業務，有些時候不合理的存在是合理的

應用架構存在的首要目標是支持業務，很多成長性企業或初創公司面對生存的壓力，不能為了保證架構的合理性而拖延系統實施速度導致企業錯過發展時機。這種情況在互聯網型企業更為常見。業務還在試錯期，系統需要盡快保證支持業務試錯，如果一上來就談論整體架構的合理性，很可能花費巨大成本實現了合理架構后，新業務已經取消或失敗。優秀的架構師和CTO要懂得在合理架構設計和靈活多變的業務發展之間做出智慧的權衡取舍。

對于CTO或公司架構師，要保證整體企業應用架構的合理性，只要大框架合理，局部的偏差可以忽略，修正的成本也比較小，如果大框架有偏差，修正的代價會非常高。對于產品條線負責人，要保證局部框架的合理性，避免出現設計不合理造成的返工和補救工作。

很多時候架構師或條線負責人要做出判斷，是做一套新系統，還是修改老系統；新系統如何定位，老系統如何調整定位；數據如何流轉，系統之間如何關聯，底層數據如何打通；是否要復用其他系統模塊，是否要將某些模塊抽象化，服務化，平臺化。對于產品經理，要在系統級別的粒度做出類似問題的判斷，能夠識別出可能存在的系統演變風險，及時升級控制不了的問題，避免做出錯誤決策。

企業架構是一套龐大復雜的體系，本文是對其中應用架構部分，結合作者實際工作經驗的淺薄理解，業界有著眾多的企業架構建設規范和指引，例如Zachman、EAP、TOGAF。這些框架涵蓋了信息技術和企業戰略結合實施的方方面面，感興趣的讀者可以做更深入的學習。

插播一條廣告

大家好，我是《決勝B端》作者楊堃，曾在VIPKID任產品總監一職。在工作中，遇見有很多優秀的B端產品經理，但缺少體系化、針對B端產品的實操訓練，在成長中走了許多彎路。

我努力將自己多年做B端產品的經驗提煉總結出來，和起點學院聯合打造了一門B端產品體系課——《To B產品實戰訓練營》希望能給需要的同學一些實質性的幫助。

幫助大家構建B端產品知識體系脈絡，掌握B端產品建設，從業務診斷、需求分析，到抽象建模、設計落地的全過程的方法思路，最終直接應用于工作實踐。

掃碼即可報名，還可為大家爭取到的專屬優惠~

立即搶座，報名成功后即可領取詳細課程資料！

作者：楊堃（微信號公眾號：goYangKun），9年互聯網研發、產品設計經驗，曾就職于傳統外資保險公司，百度，現就職于vipkid。

本文由 @楊堃 原創發布于人人都是產品經理。未經許可，禁止轉載