金保工程社会保险管理信息系统核心平台三版Word文件下载.docx
《金保工程社会保险管理信息系统核心平台三版Word文件下载.docx》由会员分享，可在线阅读，更多相关《金保工程社会保险管理信息系统核心平台三版Word文件下载.docx（21页珍藏版）》请在冰豆网上搜索。
图2企业架构图
社保核心平台三版主要关注EA的架构部分（见图2圆圈中的内容），具体包括业务架构与IT架构。
EA的战略与治理部分由开发商和地方用户在社保核心平台三版的本地化实施过程中根据当地情况制定。
（一）业务架构
业务架构主要关注两个方面：
组织与能力、流程与信息。
组织与能力是业务的静态视图，主要研究组织的结构与组织应具备的业务能力。
流程与信息是业务的动态视图，主要研究业务在不同岗位间的经办内容、顺序及互相传递的信息。
社保核心平台三版项目组使用CBM（ComponentBusinessModel，组件化业务模型）方法研究组织的能力；
使用BPD（BusinessProcessDesign，业务流程设计）方法研究业务的流程与信息。
社保核心平台三版在业务架构上的主要成果表现在：
《业务流程规范建议》、《社会保险管理信息系统指标体系－业务部分建议稿》、《社保核心平台三版软件需求说明书》等。
1．BPD业务流程设计
BPD方法通过业务流程的逐层分解来深入剖析业务需求，并通过重组流程的方式来优化业务。
社保核心平台三版的业务流程分解成5个层次，即业务域流程、业务组流程、业务单元流程、业务活动流程、业务步骤流程。
图3BPD分层结构
2．CBM组件化业务模型
图4CBM图
BPD以流程的视角分析业务，CBM以组件化的视角分析业务。
通过将BPD设计中的“业务活动流程”层的业务步骤重新按照CBM图的要求分组，形成业务组件，进而形成CBM图。
CBM关注业务组件本身对外提供的服务、业务组件之间的流程性关联及由此体现的服务性关联。
3．BPD与CBM对业务的优化
BPD与CBM都可以对现有的业务进行不同视角的建模，并且都可以依据业务战略目标对现有业务情况进行优化，以达到未来的业务要求。
业务优化是一个将业务战略落实到业务经办与管理的过程。
这个过程需要对业务的目标进行充分的分析，对现有业务状况和存在的问题有充分的了解，然后才能本着实现业务目标、解决现有问题的思想，设计未来的业务。
首先根据BPD方法识别出现有的业务流程，通过对BPD中相同业务能力的提取，形成当前CBM图，体现当前的业务能力。
根据业务战略目标分析得出哪些业务组件的能力需要提高，制定出要提高的业务组件准备达到的能力要求。
根据制定的能力要求对相关业务组件参与的业务流程进行关于成本、效率、服务质量、用户感受等方面的改进。
通过评估得出哪些业务流程的优化已经符合要求，哪些业务流程还需要继续改进，进而进入下一轮业务优化。
业务优化的整个过程是一个不断完善、不断迭代的过程。
图5BPD与CBM对业务的优化过程
（二）IT架构
社保核心平台三版是基于J2EE技术的C/S/S&
B/S/S双兼容的三层结构业务应用平台。
社保核心平台三版的IT架构分为：
应用架构、数据架构、技术架构三个部分。
应用架构主要解决业务系统的功能结构问题。
数据架构主要解决统一、可扩展的行业数据模型问题。
技术架构主要解决在技术上如何对业务进行支撑的问题，技术架构包含技术总体结构设计、技术框架设计、网络拓扑设计、部署结构设计等问题。
图6IT架构概念总图
1．应用架构
社保核心平台三版在功能结构方面分为五大部分，各个部分之间互相联系，互相支撑。
（1）核心业务系统
社保核心平台三版的核心业务系统主要包含公共业务子系统、养老待遇子系统、医疗待遇子系统、工伤待遇子系统、失业待遇子系统、生育待遇子系统、基金财务子系统及相关查询、报表、社保卡等功能。
核心业务系统主要体现了五险统一征缴、待遇分别发放的思想、基本信息与参保信息分离管理的思想、业务财务紧密衔接的思想。
（2）业务管控系统
社保核心平台三版的业务管控系统是对核心业务系统在管理方面的延伸，主要包含绩效管理子系统、稽核管理子系统、内控管理子系统。
由于各个地方的业务管控模式各不相同，具体的业务管控方式方法还要在本地化过程中依据各地的特点实施。
（3）技术支撑系统
技术支撑系统是为实现安全系统、核心业务系统、业务管控系统、接口系统功能的相关技术支撑，包括系统管理子系统、打印组件、UI组件等。
（4）安全系统
社保核心平台三版的安全系统主要实现了登录安全控制、操作权限管理、数据权限管理、用户操作审计等功能。
（5）接口系统
社保核心平台三版的接口系统主要有两大方面，一是社保核心平台三版与金保工程财务软件、跨地区业务管理信息系统、联网数据管理信息系统等的接口，二是社保核心平台三版在本地化时与银行、税务、邮政等系统的接口。
社保核心平台三版的接口部分主要以方案形式提供，接口的具体实现需在本地化过程中完成。
图7应用架构概念总图
2．数据架构
（1）数据架构概述
数据架构主要包括三部分内容，数据定义、数据分布与数据管理。
图8数据架构概念总图
数据定义包含数据模型与数据标准两个部分。
数据模型是数据架构规划中最重要内容，包括数据概念模型、数据逻辑模型、数据物理模型。
定义良好的数据模型可以反映业务模式的本质，确保数据架构为业务需求提供全面、一致、完整的高质量数据，且为划分应用系统边界、明确数据引用关系、定义应用系统间的集成接口提供分析依据。
数据标准指行业中需要遵守的关于数据及数据之间关系的标准及规范。
数据分布，包括数据业务分布与数据系统分布。
一方面是分析数据在各业务环节的创建、引用、修改或删除关系；
另一方面是分析数据在单一应用系统中的数据结构与应用系统各功能模块的引用关系，分析数据在多个系统间的引用关系。
数据业务分布是数据系统分布的基础。
数据存放模式也是数据分布中一项重要内容。
数据管理，一方面要制定贯穿业务数据生命周期的各项管理制度，包括：
数据标准管理、数据分布管理、数据质量管理、数据安全管理等制度；
另一方面要落实数据管理的具体岗位和职责。
（2）社保核心平台三版数据模型概述
为了提高平台的适应能力，满足社保行业的各项业务需求，核心平台三版对原有的数据模型进行了必要调整，提出了如图所示的数据模型。
图9社保核心平台三版的数据模型
社保行业数据参考模型。
主要用于抽象社保行业的核心业务数据。
这些数据是应用系统实施与运行时的重点关注内容，是对日常业务信息进行持久化记录的载体，需在整个信息化层面保持一致性、完整性与准确性。
社保行业数据参考模型包括七个主题，具体是三个基础主题：
当事人（参与者）、资产、产品，四个关联主题：
协议、基金、资产流动账、账户。
通过这七个主题，能够有效地对社保行业的业务数据进行概括和描述。
业务规则参数。
主要用于抽象和定义社保政策及日常业务中的规则，具体包括参保规则、缴费规则、待遇享受规则等。
通过对这些规则的配置，可以适应地方在政策细节和业务细节的差异，较好地满足本地化实施的需要。
在这些规则的基础上，社保核心平台三版还提供了很多配套的算法或引擎，用于支持规则的充分应用。
图10社保核心平台三版的社保行业数据参考模型
业务事件体系。
事件体系用于详细记录业务的处理过程，以便对业务过程的管理和控制。
从图11可以看出整个事件体系由业务处理层、事件索引层和事件处理层组成。
业务处理层包括业务类型、经办人、经办时间、复核人和复核时间等信息，是业务过程的开始。
通过业务处理层与具体业务事件的关联形成事件索引层。
事件处理层由事件头信息、事件波及范围、事件对波及对象的处理结果层三部分组成，是业务过程的详细记录。
事件头信息主要记录事件发起的原因、事件发起人、事件发起时间、事件状态；
事件波及范围层用于记录本次事件影响到的具体单位、人员、险种；
事件对波及对象的处理结果层主要记录本地事件中涉及到的具体单位/人员/险种的具体变更信息。
图11社保核心平台三版的事件体系
3．技术架构
技术架构分为：
技术总体结构设计、技术框架设计、网络拓扑设计、部署结构设计等一系列设计过程。
社保核心平台三版的技术总体结构分为四层：
LEAF（LBSEnterpriseApplicationFramework）平台、J2EE平台、操作系统、基础设施四部分。
以下重点描述LEAF平台的架构分层模型及基础设施的拓扑结构。
LEAF平台架构总体分成五层结构：
①视图层
视图层实现系统与用户的交互，位于客户端。
主要处理用户对系统的操作及将用户的操作结果反馈给用户。
社保核心平台三版支持浏览器的客户端与任何win32程序写成的客户端对系统的请求。
社保核心平台三版提供了X-ART视图组件来丰富基于浏览器的客户端的交互与展现能力。
②控制层
控制层主要由LEAF框架实现，LEAF框架是社保核心平台二版SIEAF框架的升级版本，它分为控制逻辑层及服务层。
控制逻辑层主要对客户端的请求进行协议识别、编码处理、任务分发等处理；
服务层为总体应用提供日志、异常、安全、通用业务回退、数据权限、缓存等服务。
③业务层
业务层分为请求处理层、视图服务层、业务组件层。
请求处理层是联系框架与业务层的纽带，主要处理页面跳转、数据转换、日志处理、异常处理等工作。
它是视图服务层（POJO或EJB）的Client端；
是视图服务层的代理。
视图服务层分为接口层与实现层。
接口层为客户端的一次请求提供纯业务接口，这一层不依赖于任何组件技术（如EJB、POJO等）；
实现层是接口层的组件相关技术的实现，这一层实现了具体的组件技术（如EJB、POJO等），通过组装业务组件的服务完成视图层的要求。
业务组件层为视图服务层提供了可复用的业务服务。
业务组件层包括以下几部分：
业务组件接口层（facade）、业务处理层（PO）、数据访问层（DAO），持久化接口层（OP）。
所有业务逻辑，运算和类之间的调用，由PO层完成。
所有业务实体（或者能够抽象成业务实体），抽象成Entity对象。
为了尽量减少网络传输，数据传输尽量采用数据传输对象（DTO），DTO只保存必须的属性。
④持久化层
O/RMapping层，将面向对象的设计结构与数据库中面向关系的数据结构进行映射，负责应用程序与数据库之间的数据存取工
升级会员 