9年互联网研发、产品设计经验。从Excel管理谈到ERP、CRM应用，从应用架构设计谈到互联网化管理。全文1.1W字，小编只能大写的“服”。

作者：杨堃，9年互联网研发、产品设计经验，曾就职于传统外资保险公司，百度，现就职于美菜网。

企业应用架构是指一整套软件系统的构建，通过合理的划分和设计组合在一起，支持企业方方面面的经营运作。

不论是传统企业，还是互联网公司，发展到一定阶段，都需要一整套体系化的应用架构来支撑其运转。良好的、合理的应用架构可以支持企业高效开展业务，控制经营风险，而混乱的、不合理的应用架构则会限制企业的快速发展，成为企业增长与变革的瓶颈。

企业信息化建设已经发展了几十年，传统企业和成熟互联网企业的应用架构并没有本质的区别。本文将通过一个线下小型门店成长为多元化集团的发展历程，逐步向读者展示企业应用架构的演变和设计的理念。

完整的企业架构（EA，Enterprise Architecture）分析构建，包括业务架构、应用架构、技术架构、数据架构，本文聚焦应用架构，更加关注软件系统设计与公司经营管理的关系。

不论是 C 端产品经理或者 B 端产品经理，理解应用架构的建设思路，能够帮助你更轻松的理解公司的业务运转，以及各个系统存在的目的与你所负责工作在整体团队中的定位和价值。

传统企业的应用架构演变

小门店的 Excel 管理之路

我们将从一个简单的案例入手，来展开故事。

假设你是一名个体经营者，在小区中开了一家小门店，售卖居民常用的生活用品。门店不大，只有十几平米，平常由你一个人负责经营管理，包括采购、摆货、销售。

为了更准确、科学的打理你的生意，你设计了一个 Excel 文件来管理你的商品与销售数据。

实际上你只需要做三张表格：

• 张表格存储了你的货品信息
• 第二张表格存储了你的采购记录
• 第三张表格存储了你的销售记录

这三张表格的结构和关系如下图所示：

上图采用了 ER 模型来描述三张表的逻辑结构，* 和 1 的含义是表和表之间的关联关系，例如采购记录和商品信息是多对一关系，即采购记录表中的每条数据只能对应商品信息表中的一条数据，商品信息表中的一条数据可以对应采购记录表中的多条数据。

因为你采用了科学的数据表格管理，记录了门店的所有采购入库和销售数据，这让你的经营变得井井有条；通过这些原始数据，你可以准确的管理库存、计算利润、掌握畅销品和滞销品，还能通过数据透视表制作销售日报和月报。

实际上你通过以上三张表格管理自己的生意，已经是一个管理软件的雏形了。所有的软件系统无非都是对数据的增删改查操作；可以说，如果使用得当，Excel 也可以做出一套小型的软件系统。

小超市的轻量级ERP之路

因为你善于使用信息技术来协助你做生意，你的买卖发展迅速；很快，你将小门店升级成为一家小型超市，并且雇佣了几个店员来帮你。作为店长，你兴奋的绘制出自己的张组织架构图，梦想着事业会继续壮大。

因为经营的货品更加丰富，日交易量成倍增长，并且有好几名员工需要做数据录入分析工作，这时 Excel 已经难以满足经营管理的需要。因此明智的你在开店之前，就决定采购一套 ERP 软件来协助你管理超市。

因为你还处于创业期，资金有限，通过仔细挑选，你选择了一套轻量级的 ERP，并且只购买了其中的几个核心模块，这样既可以控制成本，又可以让你经营的软件设备升级。

现在，我们可以绘制公司的张应用架构图，公司拥有一套系统，包含三个模块。

通过CRM拉近与客户的距离

为了更加准确的理解、认识你的客户，同时也为了能够拉近你和客户的距离，你打算通过 CRM 软件进行更加科学的客户管理。

你设计了一套会员积分制度，所有的客户都能免费办理会员，这样你就可以记录下关键的客户信息，而且你的小伙伴建议你开通一个微信公众号，让客户能够通过微信来查询自己的积分。

这个主意太棒了！你追加购买了几个 ERP 的模块，虽然 ERP 中也包含了 CRM 模块，但是研究后你认为内置的CRM模块功能有限，不支持对接微信，营销功能也不够强大，因此你新购买了一套 CRM 软件，和 ERP 进行了一定程度的对接，同时申请了微信公众号，找外包公司做了一些定制化开发。这样上述想法就都实现了！

我们绘制出公司的第二张应用架构图。

可以看到，核心的客户信息资产模块都在 CRM 中实现，其中内置了营销模块、消息推送服务 Msg 模块，包括 SMS 、EDM（Email Direct Marketing）和微信消息推送。

• CRM 主要聚焦客户资料的管理和营销服务，主要用户为店长和运营人员；
• ERP 主要聚焦于超市的进销存以及财务业务，主要用户为营业员、出纳、采购、库管和会计。

请注意：这里已经产生了应用架构设计的概念。

公共号、ERP 和 CRM 每个系统都为了解决某一大类的业务问题而存在，有各自清晰地定位、分工和目标用户，每个系统相对独立又互有关联，内置若干模块，每个模块都是为了解决某一大类业务问题下的某一小类问题而设计。

在这张图中我们使用了分层描述，靠近 C 端用户的微信公众号在上层，支持业务运转的 ERP 放在中间层，偏底层的客户信息集成 CRM 放在下层，这样可以清晰地看出几个系统的层次关系，同时也在一定程度反映了系统和业务之间的逻辑对应关系。

中型连锁超市的架构之路

业务进展很顺利，你已经开了五家中型连锁超市了，员工数量达到了几百人。公司走上了正轨，标准化的管理分工已经成型，不同职能单元各司其职。

为了有效管理团队，并且让内部流程更加顺畅，你邀请专业的 IT 咨询公司帮你重新梳理了公司的业务目标、组织架构、运营流程，通过引入 OA、HRM 以及重构 ERP 等手段，对不合理的制度，低效的流程进行了改造。

公司成立了信息技术部，其中项目部配合咨询公司以及软件外包公司进行系统改造或实施新系统，运维部负责保证服务器、网络的稳定。

你理解数据对公司发展的重要性，所有的管理决策都应该基于对数据的分析和判断，因此你邀请咨询公司帮你强化公司的数据分析能力。

咨询顾问建议你实施数据仓库（Data Warehouse）和 BI（Business Intelligence）项目，原因有几点：

• ERP 系统和 CRM 系统都有报表模块，但两个系统的数据相互孤立，不利于整合分析。
• 业务系统的底层数据结构并不适合做复杂的数据分析，常见的多维分析更需要一套数据仓库常用的星形数据结构和雪花型数据结构。
• 成熟的 BI 软件套件可以让你的报表分析与多维数据探查更轻松，其中的仪表盘更能够让你轻松掌控公司全局的核心指标变化。
• 企业经营中很常见的一个问题，就是经营分析指标统计口径太多，造成管理混乱和沟通障碍，除了在管理上规范公司级指标的定义，也需要一套底层数据架构，消除上游各个异构系统的孤岛和屏障，统一管理汇总数据和指标计算。

咨询顾问建议，虽然目前公司的业务系统还没有到非常复杂的阶段，但数据仓库可以帮助企业更快速高效准确的理解、捕获、使用数据，做好基础建设工作，培养员工的数据分析意识和方法，通过数据来进行决策。随着业务的拓展和系统复杂性的提升，数据仓库的存在价值将越来越明显。

在数据仓库项目中，同时构建了数据集市（Data Mart）。数据集市介于 BI 展现层和 DW 数据底层之间，是数据仓库的数据子集。数据仓库的服务对象通常为全公司或全集团，但是不同部门可能有自己的数据分析诉求与指标管理诉求，这时候通过统一的数据底层，封装出针对某个部门使用的小型数据集市，可以保证数据流的合理性、可追溯性，同时研发部门可以完全复用 DW 和 BI 的技术能力，轻松地设计实施 DM 。

如果希望数据仓库在企业中真正发挥作用，不仅仅是软件系统实施问题，更重要的是公司层面的经营分析思路体系化，指标管理规范化，以及数据部门组织架构、与业务部门合作流程设计问题，同时还需要提升全员数据化管理运营的概念和意识。软件本身并不能解决企业的问题，只有配套的架构、流程、制度与意识，才能发挥软件的功效。

应用架构跟随业务而变

由于公司经营良好，很多商品可以从供应商处拿到很好的价格，经过供应商授权，公司决定开展 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 是一套应用体系，而不仅仅是某个单一的独立应用系统。

至此，我们已经绘制出一套一般企业的简化版应用架构图，以及一张常见的组织架构图。可以看到，应用系统的建设，是根据业务的发展变化逐步完成的，每个系统都有独立存在的意义和价值。

多元化业务带来的应用架构演变

在线商城业务带来了互联网化管理

公司的零售业务发展进入了瓶颈期，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 中查到公司级别的完整客户信息。

信息孤岛与主数据管理

电商系统如期上线，业务发展迅速，电商团队的运营和产品人员年轻，聪明，充满活力，思维活跃，玩法众多，电商技术团队响应迅速，产品经理和技术团队的无缝配合，让技术力量真正推动了业务的增长。

公司赚钱了，老板很开心。但很多问题也同时暴露了出来。我们先来看看之前的应用架构。

之前为了快速上线，有一些应用架构遗留问题没有解决。现在公司有三套客户资料库，线下客户通过微信公共号访问 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 并列画在底层。

抽离共性模块全面服务化建设

公司业务发展稳定，各个系统底层做过几次技术重构，性能更强健。为了让各个应用系统更加聚焦，提升稳定性，节约开发成本，避免重复劳动，CTO 和产品技术总监讨论后决定对一些公有服务从各自应用系统中剥离，统一进行服务化改造升级，为以后公司新业务的开展打好基础。

例如，将 CRM 和商城后台的消息模块功能合并，将商城支付模块单独剥离，设计实施了集成化的权限管理系统 Auth，给全公司多个应用提供统一的权限管理服务，控制公司运营风险。

CTO 和产品技术总监合作加强了数据团队建设，设立了数据挖掘团队，丰富了客户画像，加强了经营分析能力，产生了更多的策略输出。数据策略输出不仅给在线商城提供了更强劲的推荐策略，也为 CRM，运营人员提供了更丰富的策略运营、精准定向活动推送支持。

强健的底层架构快速支持新业务开展

公司在寻找新的增长点，计划开展个人理财业务。公司的组织架构有了新的调整，管理模式也有了新的提升，形成了集团化治理模式，成立了财务共享中心，人力资源共享中心。

新设立的理财事业部，和零售事业部、电商事业部一起，调整为独立核算事业部编制，事业部聚焦经营和销售，集团层面给事业部提供基础运作支持。信息技术部也与时俱进，将之前的需求管理部调整为产品部，信息技术部主要负责 CRM、CallCenter、ERP、OA、HRM、DW、BI 等应用系统，保证集团职能部门运作，为事业部的应用系统提供基础架构和底层服务支持。

因为集团IT应用架构已经非常强健，理财业务的系统构建可以迅速展开，CTO 和理财事业部的产品总监沟通后绘制了集团应用架构图，理财业务只需要建设一套 C 端 APP 和一套基本的管理后台，而类似于客户数据、支付、Push 服务、DW 和 BI 都直接使用集团现有系统，无需重新开发。

CTO 和产品总监讨论后，认为上述架构图还存在一点问题，账号管理不应该单独创建，集团已经有着很成熟的统一客户管理理念，多套账号管理模块会再次造成信息孤岛问题。因此决定将现有的账号管理模块也进行平台化、服务化升级，给理财业务提供支持。集团层面的 Passport 系统诞生了。

更新后的架构图如下：

这里顺便解释一下：为什么本文对所有软件系统都称为系统，而互联网公司则习惯称其为产品。

互联网的发展催生了产品经理的岗位。产品经理常分为 C 端产品经理，B 端产品经理（包括商家端和运营管理中后台）等。

B 端产品线中，有 CRM 产品经理、供应链产品经理等。在互联网公司似乎不太在意区分产品和系统的叫法，到底两者有何区别？

实际上，所谓产品是指企业提供的商品或服务，给企业带来利润。早期的互联网公司多为虚拟经济形态，面向用户的软件系统就是公司给消费者提供的商品或服务，因此聚焦软件功能设计的人员被称为产品经理。

而互联网公司是一类高度依赖信息技术能力驱动业务的公司，对各类软件系统都倾向于自主建设，因此不论是面向客户的系统，或面向企业内部的系统，软件设计人员都统一叫做产品经理，其职责定位就是负责软件的设计和实现，软件系统习惯被称为产品；而在传统企业，负责软件设计的人员一般都叫做需求分析师或系统分析员，软件系统习惯被称为系统。

其实怎么称呼都无所谓，本文统一叫做系统。

企业通用应用架构设计

通用企业应用架构图

对上文的应用架构图做一些简化和调整，以便更加准确的体现应用架构的共性以及与业务的对应关系，得到一张更加清晰简洁的企业级应用架构图。

层是对外系统。所有给企业外部客户使用的系统都在这一层，包括官网，普通用户或客户使用的 C 端。如果是类似于美团，天猫这种平台性质的业务，还会包括给商家使用的商家端。这类系统站在与客户接触的前线，是公司实现商业模式的桥头堡。

第二层是对应 C 端系统的管理后台。常见的管理后台都会包含订单、CMS 、商品等模块。每个 C 端业务形态都会对应一个管理后台，有些管理后台的模块可能会被抽离出来集中维护，例如风控，消息服务，客户主数据。

第三层是业务单元支持系统。绝大多数企业业务的开展，必然不能单纯靠线上的运作来实现经营，而可能包含电话销售，客服，地推，仓配等一系列业务单元共同运作。业务单元的运作需要强大的系统支撑。

第四层是职能单元支持系统。企业发展到一定规模后，必然会有完善的职能单元作为后勤部门支持业务单元的运转和企业的正常运作，例如法务、财务、人力、客服，每个部门的正常运转都需要相应系统的支持。

第五层是基础架构支持系统。信息化建设到达一定程度后，企业有必要将通用功能服务化，平台化，以保证应用架构的合理性，提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。

第六层是数据底层。和第五层类似，这一层主要集中在数据层面的统一和封装，对各个下游系统提供数据服务。

以上六层划分涵盖了企业所有的应用系统建设，每一个应用系统的存在都将定位在六层中的某一层。

上图示例的系统涵盖了绝大多数正常企业经营运转常见的应用系统，在现实世界中，应用系统数量会远远多于上图所示，例如商业银行可能会有成百上千个系统存在。但是理解一个常见企业的组织结构，部门定位，以及上述应用架构图形成的原因，可以让你更准确快速的理解、掌握、设计任意一个应用系统。

不同类型企业的应用架构图示例

因为一般企业的组织架构设计，职能单元的设计基本没有太大区别，而以上简化版的应用架构图映射了一个标准化企业的各个常规业务单元，且涵盖了绝大多数企业中标准的应用系统，所以我们可以将不同互联网企业的应用架构图映射到上图中。

下面我们用三个例子，向读者演示不同业务形态、发展阶段的公司，其应用架构的可能形态。作者并未在以下公司任职，或与相关内部人员探讨过其公司应用架构，以下示意图均为作者根据几个公司的业务特点和发展阶段，所做的推测。

首先以美团点评为例。

美团的业务模式主要为供需平台建设，帮助消费者和服务提供方撮合交易。外部系统包括了 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端、后台管理、账号和会员管理就足够了。当然随着公司的发展，常见的变现手段之一就是广告投放，可能会继续演变到类似于今日头条的应用架构。

以上举了三个例子，让读者更好的理解应用架构演变和公司业务模式以及发展阶段的关系。在实际工作中，应用架构的建设与面临的情况会复杂得多，只要理解了以上简化版的例子，可以更容易理解实际工作中的场景。

企业应用架构设计的一些建议

后，我们来谈一谈如何合理的设计企业应用架构。不论是架构师，产品条线负责人，或某个系统的产品负责人，都要有架构设计的理念和知识，尤其是后端产品经理，必须充分理解企业应用架构的基本概念。这里给出一些应用架构设计的建议。

1. 系统定位和边界要清晰，对应的业务定位和边界要清晰

一套应用系统的存在，都是为了解决某一类业务问题，对应某一个业务板块。如果业务板块或业务单元定义模糊，也会导致对应的应用系统定位混乱。

2. 系统要实现松耦合，高内聚

系统要对外界透明，简单，易理解，与外部系统的接口要简明，扼要，灵活。内部模块高度聚合，粒度越细越不可拆解。

3. 易变的，尝试中的新业务要避免影响现有业务的稳定性

对新业务的支持，可以考虑新建独立微小型应用系统，以便避免改造成熟核心系统，影响其稳定性和健壮性。

4. 系统之间数据要实现单向流转

系统之间尽量保证单向数据流转，确保数据流可回溯，数据的一致性和可追溯性。混乱的数据流转管理会造成应用架构管理的灾难。

5. 架构设计核心目标是支持业务，有些时候不合理的存在是合理的

应用架构存在的首要目标是支持业务，很多成长性企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度导致企业错过发展时机。

这种情况在互联网型企业更为常见。业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。

对于 CTO 或公司架构师，要保证整体企业应用架构的合理性，只要大框架合理，局部的偏差可以忽略，修正的成本也比较小，如果大框架有偏差，修正的代价会非常高。对于产品条线负责人，要保证局部框架的合理性，避免出现设计不合理造成的返工和补救工作。

很多时候架构师或条线负责人要做出判断，是做一套新系统，还是修改老系统；新系统如何定位，老系统如何调整定位；数据如何流转，系统之间如何关联，底层数据如何打通；是否要复用其他系统模块，是否要将某些模块抽象化，服务化，平台化。对于产品经理，要在系统级别的粒度做出类似问题的判断，能够识别出可能存在的系统演变风险，及时升级控制不了的问题，避免做出错误决策。

企业架构是一套庞大复杂的体系，本文是对其中应用架构部分，结合作者实际工作经验的浅薄理解，业界有着众多的企业架构建设规范和指引，例如 Zachman、EAP、TOGAF 。这些框架涵盖了信息技术和企业战略结合实施的方方面面，感兴趣的读者可以做更深入的学习。