企业应用架构是指一整套软件系统的构建，通过合理的划分和设计组合在一起，支持企业方方面面的经营运作。不论是传统企业，还是互联网公司，发展到一定阶段，都需要一整套体系化的应用架构来支撑其运转。良好的、合理的应用架构可以支持企业高效开展业务，控制经营风险，而混乱的、不合理的应用架构则会限制企业的快速发展，成为企业增长与变革的瓶颈。
企业信息化建设已经发展了几十年，传统企业和成熟互联网企业的应用架构并没有本质的区别。本文将通过一个线下小型门店成长为多元化集团的发展历程，逐步向读者展示企业应用架构的演变和设计的理念。
一、传统企业的应用架构演变
1、小门店的Excel管理之路
我们将从一个最简单的案例入手，来展开故事。
假设你是一名个体经营者，在小区中开了一家小门店，售卖居民常用的生活用品。门店不大，只有十几平米，平常由你一个人负责经营管理，包括采购、摆货、销售。为了更准确、科学的打理你的生意，你设计了一个Excel文件来管理你的商品与销售数据。实际上你只需要做三张表格，第一张表格存储了你的货品信息，第二张表格存储了你的采购记录，第三张表格存储了你的销售记录，这三张标的结构和关系如下图所示。
上图采用了ER模型来描述三张表的逻辑结构，*和1的含义是表和表之间的关联关系，例如采购记录和商品信息是多对一关系，即采购记录表中的每条数据只能对应商品信息表中的一条数据，商品信息表中的一条数据可以对应采购记录表中的多条数据。
因为你采用了科学的数据表格管理，记录了门店的所有采购入库和销售数据，这让你的经营变得井井有条；通过这些原始数据，你可以准确的管理库存、计算利润、掌握畅销品和滞销品，还能通过数据透视表制作销售日报和月报。
实际上你通过以上三张表格管理自己的生意，已经是一个管理软件的雏形了。所有的软件系统无非都是对数据的增删改查操作；可以说，如果使用得当，Excel也可以做出一套小型的软件系统。
2、小超市的轻量级ERP之路
因为你善于使用信息技术来协助你做生意，你的买卖发展迅速；很快，你将小门店升级成为一家小型超市，并且雇佣了几个店员来帮你。作为店长，你兴奋的绘制出自己的第一张组织架构图，梦想着事业会继续壮大。
因为经营的货品更加丰富，日交易量成倍增长，并且有好几名员工需要做数据录入分析工作，这时Excel已经难以满足经营管理的需要。因此明智的你在开店之前，就决定采购一套ERP软件来协助你管理超市。因为你还处于创业期，资金有限，通过仔细挑选，你选择了一套轻量级的ERP，并且只购买了其中的几个核心模块，这样既可以控制成本，又可以让你经营的软件设备升级。
现在，我们可以绘制公司的第一张应用架构图，公司拥有一套系统，包含三个模块。
3、通过CRM拉近与客户的距离
为了更加准确的理解、认识你的客户，同时也为了能够拉近你和客户的距离，你打算通过CRM软件进行更加科学的客户管理。
我们绘制出公司的第二张应用架构图。
CRM主要聚焦客户资料的管理和营销服务，主要用户为店长和运营人员；
ERP主要聚焦于超市的进销存以及财务业务，主要用户为营业员、出纳、采购、库管和会计。
请注意：这里已经产生了应用架构设计的概念。公共号、ERP和CRM每个系统都为了解决某一大类的业务问题而存在，有各自清晰地定位、分工和目标用户，每个系统相对独立又互有关联，内置若干模块，每个模块都是为了解决某一大类业务问题下的某一小类问题而设计。
4、中型连锁超市的架构之路
业务进展很顺利，你已经开了五家中型连锁超市了，员工数量达到了几百人。公司走上了正轨，标准化的管理分工已经成型，不同职能单元各司其职。为了有效管理团队，并且让内部流程更加顺畅，你邀请专业的IT咨询公司帮你重新梳理了公司的业务目标、组织架构、运营流程，通过引入OA、HRM以及重构ERP等手段，对不合理的制度，低效的流程进行了改造。公司成立了信息技术部，其中项目部配合咨询公司以及软件外包公司进行系统改造或实施新系统，运维部负责保证服务器、网络的稳定。
你理解数据对公司发展的重要性，所有的管理决策都应该基于对数据的分析和判断，因此你邀请咨询公司帮你强化公司的数据分析能力。
咨询顾问建议你实施数据仓库（DataWarehouse）和BI（BusinessIntelligence）项目，原因有几点：
ERP系统和CRM系统都有报表模块，但两个系统的数据相互孤立，不利于整合分析。
业务系统的底层数据结构并不适合做复杂的数据分析，常见的多维分析更需要一套数据仓库常用的星形数据结构和雪花型数据结构。
成熟的BI软件套件可以让你的报表分析与多维数据探查更轻松，其中的仪表盘更能够让你轻松掌控公司全局的核心指标变化。
企业经营中很常见的一个问题，就是经营分析指标统计口径太多，造成管理混乱和沟通障碍，除了在管理上规范公司级指标的定义，也需要一套底层数据架构，消除上游各个异构系统的孤岛和屏障，统一管理汇总数据和指标计算。
咨询顾问建议，虽然目前公司的业务系统还没有到非常复杂的阶段，但数据仓库可以帮助企业更快速高效准确的理解、捕获、使用数据，做好基础建设工作，培养员工的数据分析意识和方法，通过数据来进行决策。随着业务的拓展和系统复杂性的提升，数据仓库的存在价值将越来越明显。
在数据仓库项目中，同时构建了数据集市（DataMart）。数据集市介于BI展现层和DW数据底层之间，是数据仓库的数据子集。数据仓库的服务对象通常为全公司或全集团，但是不同部门可能有自己的数据分析诉求与指标管理诉求，这时候通过统一的数据底层，封装出针对某个部门使用的小型数据集市，可以保证数据流的合理性、可追溯性，同时研发部门可以完全复用DW和BI的技术能力，轻松地设计实施DM。
如果希望数据仓库在企业中真正发挥作用，不仅仅是软件系统实施问题，更重要的是公司层面的经营分析思路体系化，指标管理规范化，以及数据部门组织架构、与业务部门合作流程设计问题，同时还需要提升全员数据化管理运营的概念和意识。软件本身并不能解决企业的问题，只有配套的架构、流程、制度与意识，才能发挥软件的功效。
5、应用架构跟随业务而变
在设计OCRM系统时。CTO面临两个选择：
方案一：新做一套独立于现有CRM的OCRM
优点：OCRM系统已有成熟的软件可以选择，无需从头开发；两个系统边界清晰，分工明确，便于未来各自的发展与演变。
缺点：应用架构会略有复杂，需要将原有的CRM和OCRM做数据打通，对原有的客户模型做升级。
方案二：在原有的CRM基础上开发新模块
优点：新开发的模块完全基于公司业务流程和模式设计，适配程度高。
缺点：新开发模块成本高速度慢，系统边界模糊，导致以后维护升级时模块管理的混乱。
综合评估两套方案实现的成本和速度，考虑到对未来业务变化的灵活支持，同时为了避免影响核心CRM业务的稳定性，CTO决定采用方案一，让两个系统各自聚焦，互相独立，边界清晰，虽然无形中增加了公司应用架构的复杂性，但可以快速实施支持当前的紧迫业务，并灵活应对未来公司的销售业务变化。
上图为了简化表述，只绘制了一个模块“客户信息”，但读者应该认识到：该模块应该包含B端、C端两套客户模型。实际上有的公司会明确将两套客户模型在应用架构中分开设计并且分别建设，以便更加准确的体现应用架构中的业务概念。
广义上来讲，CRM代表一种企业对待核心客户资源的管理理念和运营方法，CRM是一种概念而非某一个独立的应用系统。
大型的企业涉及多条业务线，不同的业务线有不同的客户群。企业需要有统一的客户视图和管理理念，以及强大的IT系统支持，来实现准确的客户接触点管理，充分挖掘客户群体实现精准销售，积极有效的维护企业和客户的关系。
至此，我们已经绘制出一套一般企业的简化版应用架构图，以及一张常见的组织架构图。可以看到，应用系统的建设，是根据业务的发展变化逐步完成的，每个系统都有独立存在的意义和价值。
二、多元化业务带来的应用架构演变
1、在线商城业务带来了互联网化管理
公司的零售业务发展进入了瓶颈期，CEO需要寻找新的增长点。
经过评估，决定开展电商业务，新成立了电商部，从市场上聘来了某电商平台VP作为部门负责人，直接给CEO汇报。为了学习互联网公司，以技术力量推动业务创新，电商部组织结构参考了一般互联网公司组织结构，有自己独立的研发团队，设置了产品岗位，产品技术总监给电商部负责人汇报。电商部受到CEO极度重视，给与极高自治权和最高资源支持，同时CEO还将之前线下的客服团队升级为公司一级部门，直接给CEO汇报，统一处理线上线下的客服与售后业务。
新业务开展，大家干劲十足，因为电商部产品技术总监和公司CTO之间不存在汇报关系，产品技术总监为了快速推进项目，所有决策基本只是告知CTO。产品技术总监作为纯互联网背景专家，认为购买现成软件套件不利于系统的二次开发和自主维护，长远来看会限制公司业务发展，希望整套系统实现自主研发。虽然CTO极力反对，但经过电商部负责人和产品技术总监的游说，CEO听取了总监的建议，并且总监承诺自己的研发团队效率极高，一定会在承诺之日交付系统。
产品技术总监设计的应用架构体系，包括PC和移动版的前端应用，以及完整的后端系统，包括订单、售后、客户信息、会员、营销、账号、CMS。此外，仓储、财务系统会接入现有ERP的服务，配送模块直接与第三方配送服务商系统对接。对于这个架构设计，CTO比较不满，认为客户信息和账号管理不应该重复建设，而应该统一规划管理，但产品技术总监一心快速推进实施，对于信息技术部开发效率低的情况他早有耳闻，他可不希望被一些不可控力影响导致自己的项目延期，因此CTO的抗议他不予理会。
2、信息孤岛与主数据管理
电商系统如期上线，业务发展迅速，电商团队的运营和产品人员年轻，聪明，充满活力，思维活跃，玩法众多，电商技术团队响应迅速，产品经理和技术团队的无缝配合，让技术力量真正推动了业务的增长。公司赚钱了，老板很开心。但很多问题也同时暴露了出来。我们先来看看之前的应用架构。
线下客户想在线上商城下单，发现之前登记的账号不能使用，需要重新注册完善资料，客户很烦躁。
数据同步30分钟一次，有时候客户刚修改完资料再致电400，客服查到的客户信息不是最新的，让客户很生气，客服很苦恼。
很多客户在线上线下都消费，但由于在数据仓库中冗余出了两个客户对象，不论是线上团队还是线下团队，都无法做更准确的客户画像和跨渠道消费行为分析。
CEO很生气，找到CTO和电商产品技术总监，质问怎么回事。CTO回答，我们遇到了严重的信息孤岛问题！由于CRM和商城后台数据互相孤立，导致核心客户资源不同步，不统一，让公司无法得到一个完整准确的客户视图。如果要解决这个问题，必须对应用架构进行改造，并且改造比较耗时。CEO很郁闷，没想到应用架构不合理会影响到业务发展，也没有想到组织架构的设计会导致应用架构出问题。为此，CEO做了一些调整，产品技术总监实线向电商部经理汇报，虚线向CTO汇报；总体来讲产品技术总监对电商业务销售端负责，CTO对全公司IT架构管理和其他所有系统负责。经过善意的沟通，CTO和产品技术总监的矛盾消除了，大家决定合力解决问题。
解决数据信息孤岛的方法很简单，那就是只保留一份客户信息库，这份客户信息库保存最核心的，与业务单元无关的客户属性和资料。至于积分、会员等扩展属性依然由各个应用系统维护管理。调整后的应用架构图如下：
在企业应用系统建设中，不可避免的会遇到信息孤岛问题，信息孤岛是指因为各种原因，每个应用系统独立建设时，没有和外界系统做良好的打通，导致应用系统之间存在流程或数据的孤立性，最终给业务带来严重影响。解决数据信息孤岛的经典方法就是主数据管理（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（GeographyInformationSystem）系统不可或缺，对于实力较强的公司，可能还会开发独立的POI（PointofInformation）管理系统（也有可能是GIS中的模块）。至于财务、OA、Passport、Auth、BI、DW、MDM等，必然都是公司标配。
接下来再以今日头条为例。
今日头条的早已度过创业期，标准的管理软件应该配备齐全，例如OA、HRM；不同的基础架构支持系统，在当前阶段有可能有，也有可能没有；例如Auth、Pay、MDM等。作为一个纯技术公司，BI、DW当然是标配。
最后的例子，我们挑一个相对规模小，产品形态单一的例子，例如墨迹天气，万年历这类工具类应用的公司。
以上举了三个例子，让读者更好的理解应用架构演变和公司业务模式以及发展阶段的关系。在实际工作中，应用架构的建设与面临的情况会复杂得多，只要理解了以上简化版的例子，可以更容易理解实际工作中的场景。
3、企业应用架构设计的一些建议
最后，我们来谈一谈如何合理的设计企业应用架构。不论是架构师，产品条线负责人，或某个系统的产品负责人，都要有架构设计的理念和知识，尤其是后端产品经理，必须充分理解企业应用架构的基本概念。这里给出一些应用架构设计的建议。
1.系统定位和边界要清晰，对应的业务定位和边界要清晰
一套应用系统的存在，都是为了解决某一类业务问题，对应某一个业务板块。如果业务板块或业务单元定义模糊，也会导致对应的应用系统定位混乱。
2.系统要实现松耦合，高内聚
系统要对外界透明，简单，易理解，与外部系统的接口要简明，扼要，灵活。内部模块高度聚合，粒度越细越不可拆解。
3.易变的，尝试中的新业务要避免影响现有业务的稳定性
对新业务的支持，可以考虑新建独立微小型应用系统，以便避免改造成熟核心系统，影响其稳定性和健壮性。
4.系统之间数据要实现单向流转
系统之间尽量保证单向数据流转，确保数据流可回溯，数据的一致性和可追溯性。混乱的数据流转管理会造成应用架构管理的灾难。
5.架构设计核心目标是支持业务，有些时候不合理的存在是合理的
应用架构存在的首要目标是支持业务，很多成长性企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度导致企业错过发展时机。这种情况在互联网型企业更为常见。业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。
对于CTO或公司架构师，要保证整体企业应用架构的合理性，只要大框架合理，局部的偏差可以忽略，修正的成本也比较小，如果大框架有偏差，修正的代价会非常高。对于产品条线负责人，要保证局部框架的合理性，避免出现设计不合理造成的返工和补救工作。
很多时候架构师或条线负责人要做出判断，是做一套新系统，还是修改老系统；新系统如何定位，老系统如何调整定位；数据如何流转，系统之间如何关联，底层数据如何打通；是否要复用其他系统模块，是否要将某些模块抽象化，服务化，平台化。对于产品经理，要在系统级别的粒度做出类似问题的判断，能够识别出可能存在的系统演变风险，及时升级控制不了的问题，避免做出错误决策。
企业架构是一套庞大复杂的体系，本文是对其中应用架构部分，结合作者实际工作经验的浅薄理解，业界有着众多的企业架构建设规范和指引，例如Zachman、EAP、TOGAF。这些框架涵盖了信息技术和企业战略结合实施的方方面面，感兴趣的读者可以做更深入的学习。