企业应用集成阶段建设体系

徐开放

（中国信托登记有限责任公司 上海市 200219）

1 引言

伴随着信息技术发展的日新月异，企业架构逐渐成为企业战略规划的核心组成部分。针对不同的发展阶段，如何有效“编织”企业的业务能力，调和现有技术资源组合，寻找“最优解”，已成为企业架构研究中独立的一门科学。早在上世纪70年代，著名的企业信息系统进化阶段模型--诺兰模型描述了的六个企业发展阶段：初始阶段、传播阶段、控制阶段、集成阶段、数据管理阶段和成熟阶段。在企业的初始阶段、传播阶段及控制阶段中，一般会采用业务主导的战略发展模式。在信息技术实施方面，多数会选择项目制方式，划定指定业务需求为项目实施范围，安排专业信息技术员工担任项目经理，并约定项目周期及预算。为保证业务快速落地，决策上会倾向采用成熟的外包供应商解决方案，配合定制化高速落地。管理层面多采用设置“项目管理办法”及“外包管理办法”，以流程及资源为导向约束项目实施。

此类“作坊式”的建设方式，缺少架构体系的管控，将随着企业的持续发展逐步暴露各类问题。作为企业发展的必经环节，集成阶段往往是架构介入的重要节点。该阶段定义为：在盲目购机、盲目定制开发软件之后，企业管理者意识到计算机的使用超出控制，信息科技投资增长快，但效益不理想，于是开始从整体上控制计算机信息系统的发展，在客观上要求组织协调，解决应用数据共享和交互问题。对应用集成阶段的预期管理及设计，是提升公司实力的关键。

本文讨论了企业信息系统架构在应用集成阶段的体系设计，分别从管理、框架及标准三方面构建完整的应用架构体系。

2 集成阶段的项目管理体系调整

项目制的信息系统建设中，以项目生命周期为核心，通过项目经理贯穿整个项目环节，并设计切片的横向管理团队支撑项目实施，如项目管理办公室（Projеct Managеmеnt Officе,简称PMO）、质量管理、配置管理、运维管理等。

集成阶段管理体系的核心调整是需要进一步细分并剥离出专门负责架构方面的团队，负责主导集成阶段工作，范围包括：

（1）牵头信息技术架构规划和管控；

（2）负责组织对技术标准、规范、方案等评审；

（3）监督信息技术架构规划并监督落地执行情况；

（4）组织架构资产的宣讲培训、修订维护等工作。

架构团队需确保与企业信息技术负责人的有效沟通与及时汇报。在管理体系方面，集成阶段因未对企业的信息技术建设有完整的把控能力。为避免“一刀切”的实施方式调整，建议维持项目制的整体信息技术建设体系。在该体系不破坏的前提下，架构团队应确保与项目管理生命周期的有效契合。此阶段的重点工作应在建立企业级信息技术规范与标准，并通过设置项目过程中必要的检查点，确保项目从设计到落地的完整阶段遵循企业级规范标准，并统筹开发、测试、配置、运维等团队，确保技术规范与标准有效落地和实施。在此基础上，可根据项目实施的反馈情况，螺旋式地优化相关标准，逐步掌握并把控信息技术建设能力。

集成阶段的特点是要解决信息共享和交互问题，需要通过统筹多项目组间的协作管理。在这方面架构团队需要与PMO 团队做好沟通，充分识别涉及多项目组合作的工作项，并进行统筹的开发、测试、配置、投产等排期。排期方面原则上应坚持同进同退原则，并尽可能在各项目组间保持进度同步。

集成阶段的另一大难题是跨部门的协调。原来的项目制竖井式开发模式面对的是单一的业务部门。集成阶段涉及到大量的跨部门协调工作。一方面，需求收集与提出需要实现业务归口，即各系统需明确属主的业务部门，统筹负责需求的收集；另一方面，架构团队应积极与业务宣贯并通过架构规则引导，确保业务充分识别到涉及跨系统的交互场景，并与关联业务方之间的有序合作，避免业务部门间各自圈地为战。最后，需要保留一定的问题上升通道和决策支持体系，确保出线不可调和场景时，相关管理层可及时介入并有效决策。

上述管理体系工作可通过修订相关规范，如项目管理规范、外包管理规范等，确保制度上的解释权。然而在执行层面上，额外的步骤和工序需通过较高的学习和宣贯成本，以及额外的人力成本贯彻，很容易面临“有法难依，执法不严”的情况。此时需通过引入良好的集成框架，提升管理颗粒度及效率，并有效统筹管理效率。

3 集成体系框架选型

集成体系框架选型需基于现有企业的发展状态量身定做，并重点关注信息功能集成、信息资源集成及信息处理集成，实现方式包括硬件集成、软件集成和应用集成3 部分。其中软件集成是核心，硬件集成是通过软件集成实现的，应用集成是软件集成的延伸。进入21 世纪后，随着互联网技术的发展，软件与应用的边界亦越发模糊，尤其在企业中，软件或者应用原型往往需要大量的二次开发改造，形成满足业务需求的最终应用。应用的数量以及复杂度都大幅增加，由此引发的集成要求也不断提高。传统基于I/O 设备的集成体系，如共享数据库、文件系统、内存等，以及企业应用集成（Enterprise Application Integration，简称EAI），一般被用于集成企业相对传统固化业务，虽然存在时代发展特性与合理性，但一般不作为新兴企业的主推方向。该类集成体系依赖外部供应商解决方案，并没有打破技术实现的“黑盒”，对企业的长久发展形成一定阻碍。

图1：服务定义维度

基于服务的架构（Service Oriented Architecture，简称SOA）开始成为业界趋势。该架构最早由世界著名信息研究和顾问公司高德纳（Gartner）咨询公司于1996 提出。SOA 的目标在于让IT 变得更有弹性，以更快地响应业务单位的需求，完成实时企业（Real-Time Enterprise）的愿景。该架构模式受到主流信息技术公司的大力支持，IBM、Oracle、BEA 等大型机构纷纷推进相关建设，从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户化和人员技能的投入等方面取得了不错的成绩。

面对互联网时代愈发快速变化的业务环境，部分企业根据自身发展需要，及对信息技术的进一步掌握，满足了微服务架构模式的必要性和可行性。微服务架构基于SOA 体系，要求应用进一步的原子化颗粒化，以便可更敏捷地实现信息互访，并可灵活组合后提供弹性的应用服务。由此引发出的中台概念，进一步强化形成应用中台的企业服务资产，并融合数据中台等主题中台概念，使前台业务可依托场景快速有效实现。

除部分机构因成本或其他历史原因外，一体化系统模式及企业应用集成模式已基本结束运营周期。SOA 架构体系已有成功的商业解决方案，从管理、系统、架构方面的转型成本更为可控，作为企业整体应用集成框架的落地风险程度较低。同时，微服务架构框架有丰富的开源社区支持，使企业有更好的技术控制能力，已在互联网为首的行业大规模推进。各企业可根据自身需要对上述框架进行整合或裁减，找到合适自身的集成体系框架，并通过设计标准确保框架定性定量的有效落地。

4 集成标准体系设计

集成标准体系设计的核心理念是服务。业界对服务的普遍认知为：服务是一种可重复的业务活动的逻辑上的描述，是一种自包含的、可组合的“黑盒子”。如何更好地定义服务、识别服务、设计服务是架构设计的关键。相关要求包括：

（1）企业应从服务的角度来设计应用；

（2）SOA 要求企业超越单独应用来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用；

（3）企业应推广内部通用的技术标准，提倡优先调整原有服务模式而非进行大规模新的应用代码开发，确保面对变化的企业外部环境做出快速响应；

（4）服务应依托在一套管理体系上，包括规章制度、实施团队、管理系统等，可以基于该体系方便地管理企业全局服务，而不是拘泥于传统的单一系统管理，实现业务与技术的双重管理；

（5）通过分析服务之间的相互调用，SOA 使得企业管理人员方便地获取服务执行的数据信息（如时间、来源等），这样就帮助业务人员或应用架构师迭代地优化业务流程和应用系统。

4.1 服务定义

服务定义维度如图1 所示。服务是企业业务能力的资产。服务定义应充分基于公司业务体系，满足拆分组合原则、前后端分离原则、无状态原则。在此基础上，通用服务在技术上可基于以下模型的六个维度定义：

（1）数据维度。服务对企业内通用的业务实体进行标准化，建立起服务间的数据模型。数据维度的统一是实现数据在各应用系统中的流转与转换的前提。该部分定义建议依赖企业级的数据主题。数据主题是全部数据对象的高阶抽象，提供企业级的数据管理框架。企业经营的所有业务数据均能在数据主题进行明确的映射和贯标。提前进行数据主题的梳理，不仅能有效地拉动业务部门参与服务体系制定，更能为业务的持续发展提供指导性意见。依据开放组体系结构框架（TOGAF）建议，数据主题的建立一般不用重复造轮子，可充分借鉴架构资源库，分别参照企业所在的行业通用业务模型、IT 行业发布的通用高层次业务领域模型（如电子商务、供应链管理等）等，基于企业特定业务场景优化调优后生成。

（2）消息维度。该维度定义了服务交互的消息格式载体，是应用系统和业务服务之间交互时输入/输出消息格式进行标准化。标准化的主要通过编号体系实现，包含服务编号体系，实现对服务所在的业务应用域、系统、模块等进行定位并编号；流水编号体系，实现对服务调用运行态上下文跟踪编号；状态编号体系，实现对服务调用结果和状态的编号。

（3）连接维度。该维度定义了服务建立交互连接时的相关标准，包含协议的适配、消息的格式转换和验证、以及安全标准、异常处理机制等。系统通过服务建立连接时，需遵循连接维度的标注，具体包括服务的事务一致性机制、超时机制、幂等机制、重试机制等。

（4）交互维度。该维度定义了服务实际交互时的不同方式方法。通常根据业务场景，可基于交互频率、交互数据量、响应时间等维度形成服务交互矩阵，并可根据业务输入形成标准的交互模式，如同步/异步交互、联机/批量交互、调用/通知交互等。

（5）安全维度。该维度定义了服务的安全性，确保服务在安全策略与企业的业务需求和目标相一致。主要包含身份鉴别策略、访问控股策略、审计策略、完整性策略、保密性策略等。整体的安全维度控制程度，可参照企业的信息安全等级保护级别进行定制化约束。

（6）网络维度。该维度定义了服务的网络交互策略，确保服务在不同网络环境下的设计。该维度首先需充分识别不同网络环境下的网络隔离级别、网络通信协议、负载均衡等设计，确保服务在主要网络场景下的有效访问，如内网不同网络区段间、内网至停火区至外网间等。

4.2 服务资产

通过上述多维度量化定义的服务具备纳入服务资产的前提。服务资产是集成阶段的一个重要的产出，是企业业务能力于信息技术下的综合体现。通过对服务资产的描述，形成服务全景图及服务全量分析报告，方便管理者有效识别公司的业务能力，并可通过模块化的方式组装拼接，在不同业务场景下快速部署并释放业务功能。

服务资产一般可通过建立服务目录方式。完整的服务目录应包含各个服务的定义，并可根据一定维度进行梳理并展现，如业务维度、系统维度等。服务中描述的元数据、数据字典、公共代码及服务级别等信息，需要进行充分的治理，包括但不仅限排错、排重、全局唯一定义、描述标准化等，并做好统筹的版本管理，确保服务目录在时间上及空间上的一致性。

表1：服务生命周期管理

服务资产需要专业团队进行持续管理。需确保该团队的权威性及独立性，并与架构团队做好配合，通过一定的管理机制，如评审会议等，保证服务资产的高度完备性。

4.3 服务生命周期管理

服务生命周期管理是服务基于日常信息技术工作及项目实施环境下的管理体系。首先需要识别该管理体系下的相关参与方。具体包括：

（1）服务需求方，主要包括业务部门提供业务和服务需求的需求联系人，是服务场景的提出者。该参与方是服务生命周期启动的关键点，需在各个业务需求场景下，充分识别交互场景和流程、业务参与人、交互数据表单及敏感数据。

（2）服务集成方，主要是应用集成的架构设计、服务管理及服务治理的主体，一般由集成体系框架对应的项目组构成。该参与方负责服务生命周期管理体系的落地实现，并确保集成体系在实施过程中全程遵循企业架构规则要求，同时收集并形成企业级的服务资产。

（3）服务调用方及服务提供方，主要包括调用服务及提供服务的对应系统的项目实施团队。该参与方负责服务的具体设计及实现，并确保服务在各自系统的有效实现，即一方面要满足服务需求方的业务场景，另一方面要符合服务集成方的集成体系要求。

（4）服务运维方，主要是应用系统的生产运维团队，也是服务运维主体。运维方负责服务集成方、调用方及提供方的系统运维，并是集成体系在生产环境的第一接触点。于生产环境产生的反馈信息亦是集成体系调优改善的重要输入。

集成阶段，在仍然采用项目制的信息系统建设模式下，服务的生命周期管理应遵循项目管理模式，并有效嵌入其中，使各团队在实施过程中可逐步适应。以传统瀑布模型为例，服务基于项目生命周期管理可参考如表1 所示矩阵。

服务生命周期管理的主旨是与开发模式的契合，并通过服务定义及服务资产所规定的量化标准，约束确保相关环节的准入准出符合集成体系要求。企业采用敏捷开发等其他模式的，同样可基于现有的生命周期管理模型完成服务体系的落地。

4.4 支撑体系设计

对于因涉及跨多团队合作，需明确确认各参与方达成统一意志的，或存在不一致需要仲裁的，可设立一定的会议节点统筹管理。会议可由架构团队主持，确保公立性，内容主要包括：

（1）收集服务并多方沟通明确确认服务集成方案，并根据服务资产确定受影响项目组和改造范围；

（2）确定受影响参与方的改造情况和可行性；。

（3）初步确定各参与方的排期及计划，并确认对应的上线版本。

同时，可基于DevOps 理念，通过工具落地制度，一方面使协调工作基于流程体系高效有序，另一方面减少管理的人为影响。可通过以下工具的优化设计有效提升服务体系的有效落地。

（1）项目管理工具。基于服务生命周期的设计在相关节点，如需求分析节点，基于服务资产主动触发生成各参与方的工作任务，并在设计、开发、测试等环节关联各个项目组对于同一服务场景的工作项内容，确保一致的排期和高效的协作。

（2）服务管理工具。基于服务设计要求形成线上服务管理工具，提供确保服务资产的高效展现和检索，减少线下文档的管理问题，并设置自动化管理流程，有效支撑服务设计时需要的比对、参照和纠错功能，减少频繁的线下宣贯及沟通成本，并可根据线上设计，直接生成代码部署开发测试环境。服务管理工具也可增加审批流程，提升与项目管理工具的交互功能，实现项目管理流程节点的联动跳转。

（3）配置管理工具。基于项目管理工具的需求关联情况，对于各关联系统于开发态、测试态及交付态的版本进行统筹发布管理，并完善灰度发布、蓝绿发布等功能，确保不同场景下各业务系统间的风险隔离。配置管理工具可以集成自动化测试工具，对集成体系下多系统交互进行标准测试，进一步提升测试效率。

上述工具可充分打通，通过信息共享及自动化管理，以项目管理生命周期为轴，串联集成体系在跨系统环境下的有序协作。

5 总结

企业级应用集成体系的设计，以满足企业战略及业务支撑为核心，结合先进的架构理念，找到最合适企业的体系。该体系的落地并非一蹴而就，需要充分识别各参与方的痛点，并从管理、框架、标准多维度推进。同时整体体系需根据企业发展及自身特殊情况动态调整。集成阶段的有效发展形成的管理经验及架构资产，将为企业进一步提升自主技术能力打下扎实基础，并为企业后续的厚积薄发提供有效支撑。