ESB+MDM+DAP+Portal项目思考
Posted 数通畅联
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ESB+MDM+DAP+Portal项目思考相关的知识,希望对你有一定的参考价值。
ESB企业服务总线平台、MDM主数据管理平台、DAP数据分析平台都是公司的核心产品。MDM实现对企业基础数据的治理,实现基础数据的统一;DAP实现企业数仓的建设,实现基于业务数据的分析展现;而ESB作为MDM、DAP和业务系统的集成工具,完成基础数据、业务数据的同步、分发、汇聚与整合,实现数据价值的最大化;Portal一般作为企业门户用于搭建企业应用中心和统一入口,将各个业务的入口进行统一,同时待办、新闻以及关注度较高的业务指标进行集成展现。
近期参与一次ESB交付项目,虽然只负责ESB产品交付,但整个项目是典型的ESB+MDM+DAP+Portal项目,所以对项目的实施交付过程进行了梳理,对项目中涉及的内容、相关问题和解决方案进行推演,总结项目经验为后续实施同类项目提供借鉴。由于本次项目中台数仓和统一门户不涉及ESB,所以对于DAP和门户在最后做总结说明。
1总体说明
本次客户方的需求是建设数据中台,是典型的综合应用集成(ESB+MDM+DAP+Portal)的项目。整体项目是通过多个系统厂商合作进行的,我们主要是提供ESB产品,支持主数据和业务系统的集成,包括主数据同步、分发、业务系统间的单据集成等。
1.1项目背景
客户方有十几个部分使用的系统,还需要维护几十个业务系统,系统业务割裂、信息孤岛、基层填报压力大等问题日趋突出,信息化现状已经不能满足企业发展的需要。为此客户方相关部门及人员进行了长期反复调研论证,经研究通过,制定了全局信息系统整合实施方案。通过主数据建设实现信息化系统的有效整合、数据地融合共享,建设数据中台有效推动信息化的集成整合。
1.2整体架构
如图所示为本次综合应用集成(ESB+MDM+DAP+Portal)项目的整体架构图,底层依赖于服务器支撑,各业务系统部署在对应的服务器中,并面向企业业务产生业务数据,数据传输主要是通过ESB和ETL工具实现,其中ESB主要满足业务系统间主数据和业务数据的传输,实现主数据治理和业务单据集成;ETL工具实现从个系统抽取数据,构建数据仓库以及数据分析展现,而综合门户作为统一入口,集成各业务系统以及统一认证,从而实现信息化系统的整合与统一。
1.3建设内容
本次项目以数据中台建设为核心,实现各系统间的数据贯穿,主要包含以下内容:
1.搭建主数据平台,实现组织、人员、客户、供应商、物资等基础数据的治理与统一;
2.搭建ESB企业服务总线平台实现服务治理,各业务系统将服务、接口注册到ESB平台,从而完成基于总线模式的数据与业务集成;
3.建设中台数仓和分析平台,通过ETL实现业务数据的定时抽取,从而实现数仓汇聚以及BI数据分析;
4.建设统一门户平台,搭建各系统的统一入口,实现集团与上级多级账号的统一,基于门户完成统一认证和单点登录。
2项目总结
通过参与本次项目的交付,对于项目的实施过程进行了梳理,对于主数据、数据分析的实施模式,整个项目所实现的价值和产生的问题进行了总结,也为后续同类项目的实施提供借鉴。
2.1集成模式
本次项目的集成模式主要从三个方面进行考虑。一是主数据集成;二是业务单据集成;三是数仓集成。
2.1.1主数据集成
主数据集成实现了全服务化的集成,主数据同步、分发都是采用ESB进行服务接口封装,基于实际业务系统和数据情况,制定统一的数据集成标准,包括接口命名、入参格式、出参格式等。同步时主数据将自身的数据接收接口通过ESB进行封装、发布成Web Service或Http流程,源头系统通过调用ESB接口将数据推送到ESB服务,再写入到主数据平台;分发时接收系统将接收接口通过ESB封装、发布成Web Service,然后将封装后的服务注册在主数据平台,主数据平台通过自身的分发功能调用Web Service实现数据分发。
2.1.2业务集成
业务集成主要是业务系统单据的集成,包括成本、进度、物资、财务等系统的数据传输,集成模式也是采用接口对接的方式,数据接收系统将数据接收接口通过ESB封装、发布成Http流程,源系统通过调用Http流程实现数据推送,从而实现跨系统的单据集成。
2.1.3数仓集成
数仓的建设采用定时数据抽取的方式,利用ETL工具定时从业务系统、主数据平台抽取业务数据,并在数仓中进行数据汇总,再基于数仓数据进行BI分析,配置业务大屏的展现效果。
2.2项目价值
通过主数据和ESB建立了主数据治理体系,完成了各业务系统服务接口的集中管理,形成了标准的服务、接口规范,保证了服务协议、出参、入参规范统一,便于管理维护,后续业务集成以及业务扩展时可以实现服务、接口复用,提高集成和开发效率,提高信息化价值。
同时在本次项目中形成了以ESB为基础的业务系统集成模式,源系统提供数据并调用ESB服务、接口,目标系统直接对接ESB,将内部服务、接口通过ESB进行封装、发布,降低了系统集成的难度,实现了服务的解耦,同时也固化了后续业务集成的模式。
2.3问题分析
1.在利用ESB进行服务封装的过程中,少部分使用了Web Service,大部分使用了Http流程,但是并没有使用Rest Service。Http相对独立,但是管理起来比较分散、相对零散,而Rest Service基于服务的方式,可以向相同或类似的业务封装在同一个服务中,管理比较方便,并且Rest Service的调用方式和Http基本相同;
2.没有使用到ESB的服务注册和应用集成功能,所有的服务接口都是通过在ESB设计器通过Http调用组件进行封装处理的。
3标准规范
本次项目做得比较好的一点就是在项目成立之初建立了比较全面的标准规范,这也是本次项目能够快速上线的原因之一。特别是主数据集成的相关标准,是值得后续项目加以借鉴的。
3.1主数据维护
主数据的维护有两种方式,一是以主数据为源头,二是以业务系统为源头。主数据为源头的数据直接在主数据平台进行录入,再分发下游业务系统;业务系统为源头的数据通过业务系统维护后,通过同步服务同步至主数据,再由主数据分发至下游其他业务系统。
主数据的同步与分发是以主数据编码为识别标识,通过编码进行数据对比,实现数据新增和更新操作。而在系统上线之前,则是通过线下Excel清洗的方式实现数据初始化,将原基础导出成Excel进行手动对比清洗,之后导入到主数据平台,再开启数据同步、分发,实现主数据集成。
在进行主数据分发的过程中,参考数据作为一大类数据也实现了同步和分发,从而保证各系统之间参考数据的一致性。
3.2主数据集成
基于不同类别的主数据同步和分发的业务系统不同,分别建立标准规范,定义数据接收、发送的接口标准,包括接口名称、服务地址、入参格式、出参格式、字段说明等。
如下图所示为业务系统接收人员数据的接口说明:
下图为入参说明:
3.3业务集成
为了便于在ESB中进行服务的开发与转换,同时也便于业务系统进行系统接口开发,业务系统间单据集成的接口标准和主数据集成的标准接口基本相同,只是在入参信息中字段编码、名称和含义有所区别,对此不再进行过多说明。
3.4文档标准
为了便于项目交付与验收,在进行项目实施过程中,需要对项目实施过程中的文档进行统一整理与交付,包括实施过程中的调研、需求、开发、标准、培训、部署等文档进行分类整理,交付最终客户,保证甲方客户可以接手后续的运维与开发工作,如下为ESB交付的相关资料文档:
4项目推演
基于本次项目的实施情况,以及在项目进行过程中的参与情况,对项目的相关内容进行推演,梳理综合应用集成项目(ESB+MDM+DAP+Portal)的具体实现模式以及相关的落地策略。
4.1实施模式
对于综合应用集成项目(ESB+MDM+DAP+Portal),由于涉及主数据治理与数据分析两大块内容,所以在实施模式上充分考虑不同的业务场景需要。
4.1.1主数据集成
主数据集成主要考虑主数据的同步、分发,一般有推、拉、推拉结合的方式,其中推的实时性较高,但是需要源头系统扩展开发数据推送处理,并且需要考虑一旦推送了错误数据的补偿机制;拉由ESB发起,存在一定延时,但业务系统工作量小,只需要有提供数据的接口即可(或者通过ESB读库扩展服务);推拉结合业务系统推送标识至ESB,也是实时数据推送,需要业务扩展,但是业务系统只需要推送标识即可。
4.1.2业务集成
相对于主数据,一般业务集成的实时性要求更高,业务单据往往要求能及时进行传输,所以尽量采用推或推拉的方式进行业务单据集成,由源头系统进行改造,扩展单据的数据推送功能,再由ESB进行下发操作,将业务单据分发至下游业务系统。
4.1.3数仓建设
数据仓库的建设由于要实现各业务系统大批量的基础数据和业务数据汇总,所以建议数仓数据才用定时同步,并且是在夜间等数据量小的情况下进行数据汇聚。由于数仓需要支持数据分析与决策,所以数仓的建设必须合理,需要充分考虑大批量数据读写的性能、数据库的优化、历史数据的留存、数据仓库模型、数据版本、多维度的数据汇总等。数仓只有满足高性能、高效率、稳定性与精确性才能满足数据分析与决策的需要。
4.2准备工作
1.提前了解项目的总体需求、建设内容,需要使用的产品和部署方案等;
2.了解项目的总体时间安排,根据以往同类项目经验,初步进行工作进度评估和时间节点确定,分解工作并制定初步工作计划;
3.在进场前准备相关资料文档,包括调研清单、蓝图模板、标准规范模板、相关标准产品以及产品的使用手册、部署手册等资料。
4.3标准建立
建立全面的标准规范,包括主数据同步/分发、业务集成、数仓模型、分析主题、分析指标等,并且在实施工作开始之前相关标准进行确认,获得相关各方的认可,并且保证在实施过程中能够严格按照标准进行执行,特别是数据集成的过程中切忌避免标准,如果确实标准不能满足需要,可以对标准进行变更并及时同步给相关实施团队和人员。
4.4实施过程
实施过程中需要重点把控项目的进度、风险和需求。进度方面主要是严格按照制定的实施计划进行推进,如果出现项目拖期的情况,要及时分析原因赶上进度,如果确实因为某些原因无法维持原有进度,一定要及时调整计划并通知各项目相关人员。项目风险主要是考虑项目实施过程中可能出现的业务变更等,一旦出现很大程度可能影响项目进度,所以要及时规避并准备好风险预案。需求变更是在实际项目中最频繁出现的问题,而且在实际项目中是一定会出现的,对于需求变更要严格控制,如果出现较大程度的需要变更一定要签变更申请,并更新进度计划。
5分析总结
综合应用集成项目(ESB+MDM+DAP+Portal)是公司解决方案中涉及产品比较多的项目,而且是偏重于业务和数据类的项目,所以在实施过程中是比较困难的,也是容易出现问题的项目。特别是主数据治理和数据分析部分,数据的准确性和全面性是衡量数据成功与否的重要依据。
5.1问题分析
通过参与本次项目以及在以往项目中的经验,ESB+MDM+DAP+Portal的项目出现问题最多的就是主数据治理和数据分析。MDM负责主数据治理,源头数据的清洗会成为项目的难点,各业务系统都有基础数据,并且数据量比较大,如何进行数据清洗,怎样才能保证洗后数据的唯一性、准确性,这些问题都会严重影响主数据治理成果。
DAP负责数仓建设与数据分析,其中数仓建设又是一个难点,因为数仓汇总要汇总系统中大量的业务数据,并且需要留存历史数据,所以数据的存储、版本至关重要,所以数仓如何建设、如何存储、如何实现数据同步至数仓,都会直接影响到数据分析结果。
5.2项目总结
在综合应用集成(ESB+MDM+DAP+Portal)的项目中,主数据的治理成果比较容易体现,数据同步、分发后很容易发现问题数据,所以对于主数据治理做好前期的数据清洗,制定标准的数据同步和分发接口、流程,是能有效保证主数据治理成果的。但是对于数据分析而言,由于涉及大量业务指标,必须保证指标的准确性,甚至要求分毫不差,而且经过汇总之后,个别指标出现问题又很难识别和检查,所以数据分析往往需要大量的工作去对比、判断数据的准确性,这是不可避免的,所以对于数据分析一定要协调客户方参与,进行数据分校核对与确认。
5.3个人总结
在本次项目中虽然只是参与了ESB交付的工作,但由于ESB需要支持主数据同步、分发以及业务单据的对接,所以在这个过程中对于主数据治理项目如何实施、如何推进有了更深的了解,对于后续主数据治理项目的实施落地也有了更清晰的思路,无论是数据清洗还是数据集成,标准和方案的制定都非常重要。只有建立好标准,并且严格按照标准执行,才能保证项目的有效落地与推进,不然很容易出现反复变更、进度拖期的问题。
对于数据分析来说,数仓的建设将是至关重要的,数仓数据的准确性、全面性、存储的合理性,都会影响最终的分析结果,并且为了保证数据的准确性,也需要大量的人工进行数据的检查与核对,这将是整个项目中最耗时、最费力的工作,但也是不可避免的。
本次项目虽然没有全面参与项目具体实施,对于数据分析、门户建设等相关内容了解的也不是很全面,但是通过这个项目过程,对于项目实施的一些标准、规范、安排等有了更多了解,无论是对个人成长还是后续同类产品的实施与交付都起到积极作用。
以上是关于ESB+MDM+DAP+Portal项目思考的主要内容,如果未能解决你的问题,请参考以下文章