深度丨从一个故事讲述企业应用架构的演变史（下）

接上篇： 深度丨从一个故事讲述企业应用架构的演变史（中）

三、企业通用应用架构设计

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、系统之间数据要实现单向流转

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

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

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

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

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

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

注：本文为投稿文章，原作者杨堃。

相关阅读：

深度丨从一个故事讲述企业应用架构的演变史（上）

深度丨从一个故事讲述企业应用架构的演变史（中）

本文系投稿稿件，作者：人人都是产品经理；转载请注明作者姓名和“来源：亿欧”；文章内容系作者个人观点，不代表亿欧对观点赞同或支持。