应用架构设计

建设一个系统或者平台，并不是从无到有做一个独立系统那么简单，而是需要考虑如何和企业内部的其他系统融合，如何搭建系统之间的结构。

企业级应用架构是指企业的各个软件系统有机集成在一起的方式。在实际工作中，产品经理通过研究企业的业务组织划分方式及运营运作特点，来设计软件系统划分和搭建的方式，同时利用软件模块可抽象、可复用的特点，得到一套适用于企业经营管理发展的软件产品体系结构。

对于任何一家公司，只要打算使用软件系统，就要在一开始考虑清楚，应该如何设计企业级应用架构。

实际上，所有软件系统从本质上讲，都是对数据进行增删改查操作的集合。

当企业规模达到一定复杂度之后，必须有一套软件系统来支撑其运营和经营运转，否则管理会失控、混乱。中型企业的软件系统，在功能上要有力支持当前的业务开展和管理；在体系架构上，也应该为未来的架构拓展和系统拓展打好根基。

软件本身并不能解决企业的问题，还需要配备对应的架构、流程、制度，以及人员认识上的提升，才能发挥软件的功效。

现在越来越多的企业架构开始引入数据仓库和大数据。但是数据仓库和大数据是两个完全不同的概念，二者在理念、技术方案应用领域都完全不同。

首先在理念层面，数据仓库源于交易数据，对数据准确性要求比较高，适合做离线分析；大数据源于日志的行为数据，对数据准确性要求不高，适合做自动化策略。

技术方案层面，数据仓库采用传统的经典数据分析思路，也就是抽样、分析、预测；大数据基于海量数据和运算能力，不做抽样，而做全量研究，不做分析，去做模型应用。

在应用领域层面，数据仓库主要用来做企业经营分析，大数据主要用来做各种业务自动化应用。

业务的多元化也会带来应用架构的演变。集团企业依托稳定的主营业务做支撑，探索并发展多元化的业务形态。集团企业可能有全资子公司、控股子公司、分公司等多种公司类型，经营多个品牌，有多条业务线、多个业务团队，企业管理制度复杂，这些都给应用架构的建设提出了更高要求。

在演变过程中，可能会出现信息孤岛的情况。在企业 IT 系统建设里，组织架构汇报关系的安排会影响系统架构设计，这是非常常见的现象。知名的康威定律描述的正是这个现象，即系统架构是设计者组织架构的镜像。换句话说，组织架构会在很大程度上影响系统架构设计。

在企业应用系统建设中，非常容易出现信息孤岛问题。所谓信息孤岛，就是因为各种原因，在建设单个应用系统时没有和外界系统进行良好打通，导致某些流程或数据对外界系统来说是孤立的，最终给业务带来严重影响。

当然，这个问题也有解决方案。最经典的方法是主数据管理，即 MDM。主数据管理通过应用架构的拓扑结构设计，配合相应的管理手段，帮助企业存储、识别唯一的关键数据，避免企业内部关键数据的冗余和不一致问题。

但是，引入主数据管理会让应用架构变得更复杂，在实施初期需要投入比较多的时间和资源。而在企业发展的某些阶段，快速迭代上线意味着对商机的捕捉，以及对市场变化的迅速跟进。所以，什么时候引入主数据管理，是需要综合全面权衡的事情。

在企业的应用架构体系发展到一定程度之后，各个系统都要用到的模块通常会被抽象出来，改造为公用的基础模块。需要开展新业务或者研发新系统时，不需要从零开始搭建，可以大量复用已有模块，研发效率会越来越高。

所以，架构设计既要支持业务在短期内快速发展，又要保证架构主体正确，能够适应未来变化和拓展的需要。这就引出了另一个常见概念：中台。

中台是一种企业级的软件抽象、下沉、复用理念，既可以解决 IT 系统研发重复造轮子的问题，也可以提高企业的集中化管理。中台可以大致分为几类：

组织中台

组织中台研究的是企业内部的组织结构设计，如何通过合理的权责划分以及管理架构搭建，提高业务部门的经营能力，迅速响应市场变化，并且让企业提升整体跨部门、跨业务线的协作效率，降低运营成本，实现标准化管理。

组织中台的设计思路实际上已经存在很多年。在集团企业里，往往采用事业部制的组织形态，再配合各种共享服务中心的建设，实现前后端业务分离：前端业务保持灵活性，后端业务提供支持。

业务中台

业务中台研究的是企业内部的软件系统如何进行抽象和设计，从而让企业的软件系统像搭建积木一样灵活，可以重复、高效利用现成的软件组件，快速组装开发出新的软件系统，从而节约软件开发成本，并支持新业务开展。

业务中台还有另外一层含义，也就是能够给全企业提供一致服务的管理与软件产品，也可以纳入业务中台的范畴，比如呼叫中心或者项目管理软件。总之，业务中台是一个非常宽泛的概念，每个公司的定义都不太一样。

数据中台

数据中台研究的是企业内部的数据管理和治理问题，以及数据产品体系和数据底层结构的搭建问题。数据中台研究的范畴包括企业统一的数据安全、数据规范、元数据管理、数据编码管理，以及数据仓库、数据集市的拓扑架构，也包括大数据底层和运算能力建设以及复用。

当然，要注意的是，数据中台更多关心从业务和产品层面对数据的治理、管理、应用，而不是技术层面的问题。

技术中台

技术中台研究的是软件产品的技术实践过程中，哪些技术的处理能力和架构可以进行抽象复用。技术中台是纯粹从技术实现底层来思考基础服务和基础模块的复用能力。它的设计思路和产品中台一脉相承，都是技术人员需要深度思考的问题。

通用的企业级应用架构设计一般分为五层：

对外系统：所有供企业外部客户使用的系统都在这一层，包括官网、普通用户或客户使用的 C 端系统。
管理后台：与 C 端系统对应的管理后台，每个 C 端业务形态都会对应一个管理后台。有些管理后台的模块可能会被抽象为公共服务，下沉到第五层。
业务单元支持系统：绝大多数业务的开展都不可能只靠线上运作来实现，通常要包含电话销售、客服、地推、仓配等一系列业务单元共同协作。业务单元的运作需要一个强大的系统来支持。
职能单元支持系统：企业发展到一定规模，必然会有完善的职能单元作为后勤部门，支持业务单元的运转和企业的正常运作。
基础服务支持系统：信息化建设达到一定程度后，企业有必要将通用功能服务化、平台化，以提升服务效率，保证应用架构的合理性。这类系统主要给其他应用系统提供基础服务能力支持，这一层主要聚焦于数据层面的统一和封装，对各个下游系统提供数据服务。大数据平台也可以和数据仓库并列，同属于这一层。

在做企业级应用架构时，需要注意以下几点：

一套应用系统是为了解决某一类业务问题而存在的。对应某一个业务模块，如果业务部门本身权责定义混乱，必然会导致对应的业务应用系统定位混乱，进而导致后续维护、升级、管理困难。因此，在设计业务系统之前，业务调研非常重要。如果发现不合理的地方，需要和业务方一起确认、梳理清楚，然后再开始设计。
业务需求是在不断变化的，这就要求应用系统是灵活的、可拓展的。一个拓展性强的应用系统，对外界来说应该是简单的、易理解的，与外部系统的接口应该简明、可拆解；在系统内部，各个模块应该高度聚合，模块之间要实现松耦合。
不要让易变的新业务影响现有业务的稳定性。新业务发生变化的可能性很大，失败的可能性也大。因此，可以考虑新建独立的微小型应用系统来支撑新业务，以避免改造成熟的核心系统，影响其稳定性和健壮性。
系统之间要实现数据的单向流转，确保数据流可回溯，这样才能保证数据的一致性和可追溯性。混乱的数据流转会造成应用架构管理和企业经营管理的灾难。
应用架构设计的首要目标是支持业务发展。在企业创业初期和成长时期，业务还在试错，活下去最关键。系统建设要全力支持业务，而不要过于追求架构的完美。如果一上来就谈整体架构的合理性，很可能花了巨大的成本去实现合理架构后，业务已经取消或者失效。这就要求必须懂得在合理架构设计和灵活多变的业务需求之间做出权衡或者取舍。一方面要保证整体应用的大框架是合理的，因为如果大框架有偏差，修正的代价会是什么？另一方面，在必要的时候，要允许局部偏差的存在。局部偏差的修正成本是比较低的。对于某条产品线的负责人和产品经理来说，也要在架构的合理性和整体的业务需求之间做出选择。
在实际工作中，新旧系统的关系是架构师或产品线负责人需要经常思考的：到底是做一套新系统，还是修改旧系统？新系统该如何定位？旧系统该如何调整定位？数据如何流转？系统之间如何关联？底层数据如何打通？是否要复用其他系统模块？是否要将某些模块抽象化、服务化、平台化？产品经理则要在自己负责板块思考类似的问题，识别潜在的系统架构风险。必要的时候，向上级汇报问题，避免做出错误决策。

应用架构的问题也可以进一步划分为自研软件系统和商业化软件平台两类来分析。

自研软件系统

在设计一套新系统时，必须考虑如何与公司现有的系统架构融合，以及不同系统模块之间如何衔接。这项工作复杂度比较高，不仅需要有丰富的架构经验，还需要深刻理解业务特点和可能的演进方向，同时熟悉公司目前的系统架构，才能快速提炼出相关问题。

这项工作一般由产品负责人、公司架构师，甚至 CTO 共同讨论决定。

商业化软件平台

任何一个商业化软件产品在实施过程中，都要考虑和甲方已有架构的融合。如果产品经理不懂应用架构常识，在软件集成能力设计、模块通信设计上就会出现问题。这些问题不单纯是技术问题，很有可能演进成业务问题，甚至是商业问题。

乙方厂商如果有多产品线协同，同样需要思考应用架构的体系设计问题。一方面，产品矩阵背后要有一体化的架构设计思考；另一方面，为了提升公司研发效率，需要避免重复造轮子。

对于某些工具型 B 端产品设计，不用过多考虑应用架构问题。这类产品场景非常聚焦，也不太涉及和其他系统的协同，最多需要考虑权限、账号系统的集成打通。