[!TIP]
记录的企业应用架构设计的学习
包括五大内容：

• 什么是应用企业架构
• 企业架构的演变
• 通用型企业应用架构
• 现有案例分析
• 企业应用架构的原则

转载请注明来源：https://janrs.com/q3e1

企业应用架构

本文摘自：https://www.woshipm.com/pd/586436.html

1.什么是企业应用架构

1.1 什么是企业应用架构？我们为啥需要？

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

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

• 完整的企业架构分析构建了，包括业务架构、应用架构、技术架构、数据架构。我们要先从应用架构入手，解决软件系统与公司经营管理的关系。了解了应用架构的建设思路，也就会理解了公司的业务运转，以及各个系统存在的目的与各个负责人在团队中的定位和价值

2.企业应用架构的演变

我们选一个常见的，跟我们相关的行业。分析它的业务发展过程以及信息化技术是如何跟线下业务相辅相成的

[!NOTE]
结合一个小卖部到连锁集团的业务发展过程，来了解企业应用架构的演变

2.1 企业应用架构出现之前

在企业还没达到一定规模之前，是如何管理经营的

2.1.1 小门店的Excel管理

有一个个体经营者，在自家小区开了一个小门店，专门卖一些生活用品，门店不大，只有几十平米，平时都是老板自己一个负责经营管理。包括采购，摆货，销售。
这个老板为了更加准确的科学的打理生意，他自己设计了Excel表格来管理店里的商品与销售数据
利用这些Excel表格，他可以准确的管理库存，计算利润，掌握畅销品和滞销品。并且给自己统计销售日报和月报。

[!NOTE]
管理软件的雏形
所有的软件系统无非就是对数据的增删查改操作

2.1.2 小门店到小型超市的轻量级ERP

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

因为经营的货品更加丰富，日交易量成倍增长，并且有好几名员工需要做数据录入分析工作，这时Excel已经难以满足经营管理的需要。因此他决定给自己定制一套ERP软件来管理超市。

因为目前还处于创业期，资金有限，通过仔细挑选，他只实现了一些必需的功能。

2.2 小型超市引入了客户营销模块

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

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

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

CRM主要聚焦客户资料的管理和营销服务，主要用户为店长和运营人员。
ERP主要聚焦于超市的进销存以及财务业务，主要用户为营业员、出纳、采购、库管和会计。
在这张图中我们使用了分层描述，靠近C端用户的微信公众号在最上层，支持业务运转的ERP放在中间层，偏底层的客户信息集成CRM放在最下层，这样可以清晰地看出几个系统的层次关系，同时也在一定程度反映了系统和业务之间的逻辑对应关系。

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

2.3 小型超市向中型连锁店的发展

2.3.1 中型连锁超市的组织架构

业务进展很顺利，这家超市已经开了五家中型连锁超市了，员工数量达到了几百人。公司走上了正轨，标准化的管理分工已经成型，不同职能单元各司其职。为了有效管理团队，并且让内部流程更加顺畅，老板重新梳理了公司的业务目标、组织架构、运营流程，通过引入OA(
Office Automation办公自动化系统)系统、HRM(Human Resource Management人力资源管理系统)系统以及重构ERP(Enterprise Resource Planning企业资源计划)
等手段，对不合理的制度，低效的流程进行了改造。公司成立了信息技术部，对系统改造或实施新系统，运维部负责保证服务器、网络的稳定。

中型连锁超市的组织架构

2.3.2 中型连锁超市的企业应用架构

此时，老板已经意识到了数据对公司发展的重要性，所有的管理决策都应该基于数据的分析和判断，因此他强化了公司的数据分析能力，于是他实施了数据仓库DW(
Data Warehouse)以及数据可视化BI(Business Intelligence)。
数据仓库可以帮助企业更快速高效准确的理解、捕获和使用数据，做好基础建设工作。尤其是培养员工的数据分析意识和方法，通过数据来进行决策。
随着业务的拓展，数据仓库的价值将未来越凸显。

中型连锁超市的企业应用架构

2.3.3 此阶段的架构前后对比

2.4 企业应用架构的价值

2.4.1 实施数据仓库DM（Data Warehouse）和BI（Business Intelligence）项目的价值

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

2.4.2 构建数据集市的价值

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

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

2.5 企业应用架构跟随业务改变

由于经营良好，能从供应商拿到很好的价格，公司决定开展2B业务，成立了大客户销售部
这对企业系统又提出了新的需求。

2.5.1 开展2B业务下公司的组织架构

因为开展了B端的业务，公司在新手事业部新成立了大客户销售部
信息技术部为了配合业务的开展，也成立了对应的研发部以及需求管理部。

新业务下公司的组织架构图

2.5.2 开展2B业务下的企业应用架构

信息部新开发了一套独立于CRM的OCRM(Operational CRM操作型客户关系管理系统)。两个系统边界清晰，分工明确。
B端客户的数据模型和C端客户差异非常大，B端客户模型关注组织架构和人员角色的描述，C端客户模型关注客户本身个人信息的描述，即便应用系统中将客户模型和操作型系统分开建设，客户模型一定会做成两套以支持不同的上下游业务系统。

新业务下公司的企业应用架构图

2.5.3 此阶段的架构前后对比

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

公司的零售业务发展进入了瓶颈期，需要寻找新的增长点。决定开展电商业务

2.6.1 开展电商业务下的公司组织架构

公司因为零售业务进入了瓶颈期，经过评估，决定开展电商业务，新成立了电商部，新聘了部门负责人，直接给CEO汇报。为了学习互联网公司，以技术力量推动业务创新，电商部组织结构参考了一般互联网公司组织结构，有自己独立的研发团队，设置了产品岗位，产品技术总监给电商部负责人汇报。电商部受到CEO极度重视，给与极高自治权和最高资源支持，同时CEO还将之前线下的客服团队升级为公司一级部门，直接给CEO汇报，统一处理线上线下的客服与售后业务。

开展电子商务后的组织架构图

2.6.2 开展电商业务下的企业应用架构

此时，产品技术总监设计的应用架构体系，包括PC和移动版的前端应用，以及完整的后端系统，包括订单、售后、客户信息、会员、营销、账号、CMS。此外，仓储、财务系统会接入现有ERP的服务，配送模块直接与第三方配送服务商系统对接。
基于此应用架构，公司的电商业务很快也很好的发展起来了

开展电子商务后的企业应用架构图

2.6.3 此阶段的架构前后对比

2.7 看似完美的架构

这个看似完美的架构，其实有很大的问题？

[!NOTE]
搞明白其中的原因，也就更深入的体会什么是企业应用架构，企业应用架构到底在架构什么。

2.7.1 信息孤岛与主数据管理

之前为了快速上线，有一些应用架构遗留问题没有解决

• 线上客户关注公共号后，查不到自己的资料，这让客户感觉很诡异。
• 线下客户想在线上商城下单，发现之前登记的账号不能使用，需要重新注册完善资料，客户很烦躁。
• 数据同步30分钟一次，有时候客户刚修改完资料再致电400，客服查到的客户信息不是最新的，让客户很生气，客服很苦恼。

2.7.2 解决方案很简单

解决方案很简单，那就是只保留一份客户信息库，这份客户信息库保存最核心的，与业务单元无关的客户属性和资料。至于积分、会员等扩展属性依然由各个应用系统维护管理。将客户信息库独立，商城、CallCenter、CRM和微信公共号通过统一接口调用Customer Profile存储的核心客户档案，不论客户或业务员从哪个端口查看或修改信息，变化对其他端口都是透明、实时的。实际上这就是客户主数据管理MDM（Master Data Management）的设计理念

[!NOTE]
难的是有前瞻性的架构，所以学习很重要

2.7.3 重新认识数据

越重要越底层

主数据经常作为底层数据应用来管理，因此在架构图中我们将它和DW并列画在最底层
将电子商务部的、公众号推广的、以及电销中心的客户数据全部归结到底层的主数据库MDM（Master Data Management）

2.7.4 此阶段的架构前后对比

[!NOTE]
数据很重要

• 由于在数据仓库中冗余出了两个客户对象，不论是线上团队还是线下团队，都无法做更准确的客户画像和跨渠道消费行为分析。

• 在企业应用系统建设中，不可避免的会遇到信息孤岛问题，信息孤岛是指因为各种原因，每个应用系统独立建设时，没有和外界系统做良好的打通，导致应用系统之间存在流程或数据的孤立性，最终给业务带来严重影响。解决数据信息孤岛的经典方法就是主数据管理（MDM）的思想，主数据管理通过应用架构的拓扑设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。常见的主数据有客户主数据，商品主数据等。

• 主数据管理的设计理念应该自始至终贯穿企业应用架构的设计过程，因为在企业的发展过程中，各个阶层的领导需要实时的查看数据报表并做出经营战略决策。如果设计不合理，导致中途重构，公司有可能错过发展的良机；如果数据没法归结和打通，公司也无法准确的制定符合市场的经营策略。总之，数据对于公司来说，是资产的体现。

2.8 进一步优化架构

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

2.8.1 架构也可以模块化

公司业务发展稳定，各个系统底层做过几次技术重构，性能更强健。为了让各个应用系统更加聚焦，提升稳定性，节约开发成本，避免重复劳动，CTO和产品技术总监讨论后决定对一些公有服务从各自应用系统中剥离，统一进行服务化改造升级，为以后公司新业务的开展打好基础。例如，将CRM和商城后台的消息模块功能合并，将商城支付模块单独剥离，设计实施了集成化的权限管理系统Auth，给全公司多个应用提供统一的权限管理服务，控制公司运营风险。
CTO和产品技术总监合作加强了数据团队建设，设立了数据挖掘团队，丰富了客户画像，加强了经营分析能力，产生了更多的策略输出。数据策略输出不仅给在线商城提供了更强劲的推荐策略，也为CRM，运营人员提供了更丰富的策略运营、精准定向活动推送支持。

2.8.2 此阶段的架构前后对比

2.9 优化后的架构反哺企业新业务开展

2.9.1 反哺新业务开展的组织架构

公司在寻找新的增长点，计划开展个人理财业务。公司的组织架构有了新的调整，管理模式也有了新的提升，形成了集团化治理模式，成立了财务共享中心，人力资源共享中心。新设立的理财事业部，和零售事业部、电商事业部一起，调整为独立核算事业部编制，事业部聚焦经营和销售，集团层面给事业部提供基础运作支持。信息技术部也与时俱进，将之前的需求管理部调整为产品部，信息技术部主要负责CRM、CallCenter、ERP、OA、HRM、DW、BI等应用系统，保证集团职能部门运作，为事业部的应用系统提供基础架构和底层服务支持。

反哺新业务开展的企业组织架构图

2.9.2 反哺新业务开展的企业应用架构

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

反哺新业务开展的企业应用架构图

[!Warning]
信息孤岛的问题再次出现：商城后台的账号管理与理财业务后台的账号管理又出现了重复与隔离！

2.9.3 进一步优化

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

2.9.4 此阶段架构前后对比

3.通用型企业应用架构

提炼出通用型的企业应用架构，方便结合具体业务进行信息化建设

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

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

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

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

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

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

4.现有案例分析

4.1 美团点评企业应用架构

• 美团的业务模式主要为供需平台建设，帮助消费者和服务提供方撮合交易。外部系统包括了C端系统和商家端系统，C端系统为消费者常用APP，商家端系统为商家提供商品管理、交易管理、推广管理、经营分析等功能。C端或商家端都对应后端管理系统，方便企业内部对整个平台进行管理、营销、风控等。

• 平台需要发掘更多的商户资源入驻，因此会有销售过程管理的OCRM系统；平台需要对C端客户提供客服与售后支持服务，相信美团点评的业务量，一套专业的CallCenter系统必不可少；美团提供了自营的配送服务，TMS( Transportation Management System运输管理系统)系统必然成为标配（也有可能是SCM中的模块）。

• 由于美团业务不涉及自营的实物货物买卖服务，没有仓储体系，因此推测没有WMS(Warehouse Management System仓库管理系统) 系统（或者ERP中包含了WMS模块但是没有启用）。O2O业务需要管理大量线下门店，因此GIS（Geography Information System地理信息系统）系统不可或缺，对于实力较强的公司，可能还会开发独立的POI（Point of Information信息点系统）管理系统（也有可能是GIS中的模块）。至于财务、OA、Passport、Auth、BI、DW、MDM等，必然都是公司标配。

4.2 今日头条企业应用架构案例

• 今日头条构建了信息流资讯类C端，吸引网民使用，这类产品最常见的盈利方式为广告变现。在公司经营之初，可能采取了市面上的DSP( Demand-Side Platform需求方平台)平台来完成APP的广告管理（当然也可能从来没有采用过），为了更好的设计广告产品，相信现在一定有自己的广告投放管理平台，因此公司会有给广告主使用的B端广告投放管理系统。

• 因为业务模式以广告投放为变现手段，因此后端系统可能没有交易类后端复杂，但基本的CMS和风控（反垃圾、反作弊、合法合规）必然是有的。公司需要盈利，就需要售卖产品，售卖产品永远不可能只在线上运作，必然会有BD(
  Business Development商务拓展)团队支持，因此今日头条也会有CRM系统，管理对象为广告主而不是网民。

• 但是WMS、TMS系统这类系统估计就不需要了。至于CallCenter，本人查询了官网，没有找到相关的客服热线，猜测还没有建设。

• 今日头条的早已度过创业期，标准的管理软件应该配备齐全，例如OA、HRM；不同的基础架构支持系统，在当前阶段有可能有，也有可能没有；例如Auth、Pay、MDM等。作为一个纯技术公司，BI、DW当然是标配。

4.3 墨迹天气，万年历企业应用架构案例

–

这类公司在创业初期，不考虑变现的情况下，团队小，产品简单，应用架构图也会非常简单，在产品发布时，只需要实现官网、C端、后台管理、账号和会员管理就足够了。当然随着公司的发展，常见的变现手段之一就是广告投放，可能会继续演变到类似于今日头条的应用架构。

5.企业应用架构的原则

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

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

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

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

• 架构设计核心目标是支持业务，有些时候不合理的存在是合理的
  应用架构存在的首要目标是支持业务，很多成长性企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度导致企业错过发展时机。这种情况在互联网型企业更为常见。业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。