应用架构:分层逻辑与模块化实现（应用架构:分层逻辑与模块化实现的区别）

企业数字化建设的日常性、主要性工作是应用系统的开发、实施和运营，因为应用系统实际承载了企业的业务需求，承载了将业务需求转化为数据的采集、运算、分发、共享、统计、分析等信息需求。为了确保业务需求与信息需求能够得到完全而没有冗余地满足，企业必须做好应用架构的规划设计。

应用架构描述了各种用于支持业务架构，并对数据架构所定义的各种数据进行处理的应用功能，包括各个应用系统的功能和技术实现，是应用系统建设和演化的工作指南，可以指导企业的数字化团队有序地建设和优化各类应用系统。

在工作内容和步骤上，应用架构的规划设计，始于业务架构和业务流程中应用功能的识别，进而基于应用功能及更细化的IT功能需求来设计应用功能架构，最终分解为应用功能清单并考虑如何用IT系统的功能模块来承载，以实现业务落地。应用架构规划设计的工作内容和逻辑可参见下图1：

一、架构的原则

应用架构规划设计的基本原则可概括为：分层解耦、体验驱动和服务化设计。

1. 分层解耦

应用架构规划设计时，应该围绕应用能力的轻量级和分层解耦，将应用系统分为前台、中台和后台，这三者之间通过服务进行交互。分层解耦的应用架构规划设计，具体要求包括：

1）面向用户构建前台。面向应用系统的用户构建前台接入，前台仅消费服务而不产生服务。

2）面向服务构建中台。根据业务对象的耦合程度进行应用系统的划分，应用系统之间接口低耦合，应用系统内部功能高内聚，应用服务支撑业务能力的实现。

3）面向信息资产构建后台，确保数据同源和一致。

4）前台、中台、后台等之间充分解耦，通过服务进行交互。

2. 体验驱动

从“功能优先”到“体验优先”。围绕用户体验，构建一站式联接平台，提供用户的沟通、协作效率，具体要求包括：

1）针对外部用户，通过统一的客户界面、统一的用户管理和身份识别、统一的架构规划，构建统一的“数字化全连接”前台，提升用户体验。

2）针对内部用户，建设基于角色的一站式工作平台，连接人、工作、业务和知识，每一角色只有一个角色频道入口。

3）建立用户体验设计标准，落实用户体验驱动的应用开发，保证用户体验的一致性。

4）提供多渠道的接入，优先考虑应用的移动化。

3. 服务化设计

以服务为中心，通过服务化实现应用架构的分层解耦，实现小应用、快速开发、快速扩展、高度复用、高频部署、按需提供的应用服务，快速响应业务变化，具体要求包括：

1）应用系统通过API将服务与功能开放出来,软件包需通过API开发其数据和功能逻辑。

2）所有应用模块间的信息通过服务接口和消息进行调用，服务逻辑与服务通讯协议（REST/SOAP/RFC等）解耦。

3）统一构建公共应用服务，所有服务需在统一的管控平台进行管理。

4）面向服务消费方，服务提供方必须提供明确的SLA承诺。

二、工作的步骤、内容、输入与输出

应用架构规划设计工作的步骤、内容、输入与输出，具体可参见下表1：

表1：应用架构规划工作的步骤、内容、输入与输出

如表1所示，业务架构是应用架构规划设计的关键输入，应用架构需要根据业务架构的要求，设计出合适的应用系统、应用模块、功能项和应用服务，以支持业务流程的线上化、集成化、精简化、实时化、自动化、自助化和智能化。在实践中，业务架构和应用架构需要协同设计和演进，以确保业务和IT的战略一致性和持续创新。

业务架构通过对业务的分析和抽象，定义了一系列业务能力、业务组件、业务流程、流程活动/步骤及其关系。应用架构规划设计时，需要将业务架构的设计内容进行转换，转换并设计出与之相对应的一系列应用模块、功能项或应用服务，每个应用模块、功能项或应用服务承担了特定的业务功能，通过组合和编排来实现完整的业务流程。

应用架构规划设计时，还需借鉴业务实践，并考虑现有应用系统的功能及划分。举例来说，制造型企业常见应用域包括研发、生产、营销、供应链、质量、人力、财务、内控、IT等领域，也就是所谓的企业通用应用架构，它们可以作为应用架构规划设计的参考。另外，企业还需做好现有应用系统的投资保护，需要做到遗留或现有系统的迁移和演进，因此，现有应用系统的功能及其划分，也是应用架构规划设计时的考虑因素。

应用架构规划设计工作的成果输出，主要包括：应用架构全景图/分层图（AD/AG/APP/ABB/功能项/功能子项）、应用架构集成图、功能项分布清单、应用集成清单、业务/应用矩阵、角色/功能矩阵、应用服务目录，等等。应用架构全景图/分层图、应用架构集成图、功能项目分布清单等展示了所有应用的全景、应用之间的集成关系、功能项清单类别，其样式与流程架构全景图、流程架构集成图、流程清单等基本相同。业务/应用矩阵以表格的形式描述了L4级业务流程与应用之间的对应关系，角色/功能矩阵以表格的形式描绘了流程角色与应用功能项之间的对应关系。

应用服务化是应用架构规划设计的重要原则，其核心要求是将供业务场景调用的功能项进行服务化，并形成应用服务目录。

三、应用架构的分层逻辑

与业务架构、数据架构类似，应用架构也是以分层的形式来进行规划和呈现。分层式应用架构设计，具体包括应用域（Application Domain，简称AD）、应用组（Application Group，简称AG）、应用系统（Application，简称APP）、应用系统模块（Application Building Blocks，简称ABB）、功能项/功能子项等5个层级（如果把功能子项作为一个单独的层级，那就是6级应用架构），其中，AD属于最上层，功能子项属于最上层。实践中，为了便于理解和操作，应用架构的分层可与业务架构的分层进行对应，具体可参加下图2：

如图2所示，从业务能力的角度看，业务架构分为业务域、业务分类、业务能力、L4操作级业务流程、业务活动/等层级，与之相对于，应用架构分为应用域、应用组、应用系统、应用系统模块、功能项/功能子项等层级。其中，应用域与业务域相对应，应用组与业务分类相对应，应用系统与业务能力相对应、应用系统模块与L4级操作流程相对应，功能项/功能子项与业务活动/活动步骤相对应。

四、何时做与怎么做

理论上，应该是先做应用架构的规划设计，再做具体应用系统的开发和实施。实际上，很多企业还没有包括应用架构在内的企业架构实践，或者是先根据业务的需求把应用系统开发出来以后再考虑从架构层面来做好顶层设计和架构优化。另外，企业在创立之初，或者是对于广大中小企业，业务模式相对简单，用到的应用系统也比较少，可能没必要做企业架构或太细的企业架构；与之相反，随着企业的快速发展，或者是对于那些特大型企业，业务模式比较复杂，用到的应用系统可能有几百乃至上千个，做好应用架构的规划设计就相当有必要。因此，对于何时做应用架构的规划设计，有先规划后建设，先建设后规划，边规划边建设等三种模式。

至于应用架构规划设计的方法，则需要综合应用“自上而下”和“自下而上”等2种方法。所谓“自上而下”，就是根据应用架构的层级，先做应用域的分类，再做应用组的分类，再识别应用系统、应用系统模块，然后再识别功能项及功能子项。所谓“自下而上”，则是以功能项和功能子项的识别为切入口，以业务流程+逻辑数据实体的维度识别出相应的应用功能，再将类似的业务操作进行组合，提炼为同一个功能子项，再在功能项/功能子项的基础上自下而上进行聚合，依次得到应用系统模块、应用系统、应用组和应用域。

五、目的与用途

应用架构规划设计完成后，需要对应用全景图中每一个应用做成熟度评估，评估结果大体可分为以下几种：1）应用新增，2）应用合并，3）保持不变，4）应用优化，5）应用重构。对于需要新增、合并、优化或重构的应用，都需要拟定相对应的工作举措或项目，根据项目的优先级推进项目的实施工作。

从生命周期的角度看，任何一个应用都新增、运行、优化、淘汰的生命周期，而应用架构的规划设计，就是从顶层设计的角度，推动每个一个应用的升级换代，进而确保整个应用架构的生生不息，注重目的是做好业务架构和数据架构的落地，实现业务的实时在线和高效协同，帮助企业提升业务效率，最终实现业务增长的目标。