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

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

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

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、信息孤岛与主数据管理

电商系统如期上线，业务发展迅速，电商团队的运营和产品人员年轻，聪明，充满活力，思维活跃，玩法众多，电商技术团队响应迅速，产品经理和技术团队的无缝配合，让技术力量真正推动了业务的增长。公司赚钱了，老板很开心。但很多问题也同时暴露了出来。我们先来看看之前的应用架构。

之前为了快速上线，有一些应用架构遗留问题没有解决。现在公司有三套客户资料库，线下客户通过微信公共号访问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产品经理、供应链产品经理等。在互联网公司似乎不太在意区分产品和系统的叫法，到底两者有何区别？

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

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

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

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

相关阅读：

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

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

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