数据架构调研与评估报告分析.docx
《数据架构调研与评估报告分析.docx》由会员分享，可在线阅读，更多相关《数据架构调研与评估报告分析.docx（16页珍藏版）》请在冰豆网上搜索。
数据架构调研与评估报告分析
1.
数据架构调研与评估
1.1.总体数据架构现状
上图摘自《中国人寿应用系统介绍及计划》，它描述了整个中国人寿主要的应用系统间的关联和数据交换，从总体上看来，中国人寿：
∙基本实现了业务信息的电子化，绝大多数业务处理都有应用系统支持；
∙主要的业务功能区域（如寿险实务、财务管理等）的信息处理都有较为成熟的应用架构和数据架构；
∙各个应用系统之间可以利用数据文件进行数据交换，实现了信息的传递和共享；
∙银保通系统能够实现和银行间的实时数据交换；
∙基于数据库技术的信息处理体系基本成熟；
∙初步建立了以中间库为基础的数据交换平台，并基于它实现了企业数据综合查询统计功能；
∙初步建立了以统计报表工具为手段的数据统计和报表系统；
∙财务系统利用了数据仓库技术和SAS工具进行数据分析，除此之外，诸如上海还建立了自己的数据仓库系统；
∙基于NOTES的消息系统支持了公司的日常信息沟通工作；
∙基于影像技术的非结构化数据正在一些分公司使用，并逐步推广。
1.1.1.数据模型和应用的相关性
∙以应用为划分的“烟囱”结构，数据基于应用，并被锁定在应用系统中
-数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分，由于应用系统的供应商不同，并且其设计工作也缺乏相互之间的协调，因此，数据模型基本按照各个应用系统的功能需求进行设计和实现；
-由于缺乏有效的数据共享，一个应用所需的数据无法从相关的其他应用系统中获得（如AMIS需要从CBPS获取客户数据），而只好重复录入；
-另一方面，由于同一个数据可能存在多个数据源（从多个应用系统中被重复录入），由此导致了信息的不一致。
∙结构化数据基本上都利用数据库技术实现，非结构化数据只有少数地方使用影像技术实施了电子化，从应用程度上两者之间的集成度不高，影像工作流技术和其他应用系统之间没有能够做到无缝联接。
∙缺乏自动化和实时的数据交换
-以数据文件交换为主要手段
▪现有的数据交换方式通常是从一个应用中将数据导出到平台文件中，再传递到目标平台并并导入到目标应用系统中；
▪由于大批量的数据抽取工作会影响到正常的业务处理效率，因此通常的数据抽取都被设定在在晚间进行，所以数据的时效性较差（通常都在一天左右）。
-数据交换过程缺乏严格的数据校验、过程控制等
▪接口数据的错误经常是在导入目标系统时才发现，而不是作为系统数据质量控制的一部分，预先在源系统中进行合法性校验；
▪数据交换的过程缺乏技术性控制：
诸如大批量数据分割、数据传输的校验、重复操作的处理、操作回滚等。
∙对不同版本或开发商的同一应用，缺乏统一规定的应用系统数据外模式
-例如业务处理系统，总颁系统CBPS和深圳、江苏、上海的系统对外的数据模式和接口都不相同，和其他应用系统（如CLAF）的接口需要各自编写相应的接口软件来实现。
1.1.2.数据物理层次和数据提升（staging）
∙事务（transaction）处理层数据
-应用系统中存储了完整的、原始的事务处理数据；
-应用系统中的主要事务处理数据都具备时间戳等增量识别标志；
-没有后备系统存储离线历史数据；
-数据分布在各个省公司或地市公司的应用系统中，多数省份实施的是服务器的物理集中；
∙数据集成平台
-缺少完整统一的集成平台来集成各应用中的数据，建立企业级信息视图
∙轻度统计汇总数据
-利用应用系统自身的报表功能和统计功能实现；
-地市级的IT人员完成了一定的查询和报表开发工作，以满足业务部门的小规模要求；
-对于应用系统中没有的报表，利用手工（UTAB或EXCEL）实现；
-总公司层面缺乏对轻度汇总数据的全面集成；
∙高度汇总数据
-应用系统中具备部分高度汇总统计功能；
-对于应用系统中没有的报表，利用手工（UTAB或EXCEL）实现；
-由于手工工作太多，人为因素影响了数据的完整性和准确性，使得数据准确性和可信度不够高；
∙决策支持模型
-缺乏灵活的系统统计分析功能；
-缺乏企业级统一的数据平台，从而也就无法建立企业级的决策支持分析模型；
-目前的SAS系统主要基于财务数据的分析。
1.1.3.用户期望
∙未来信息系统必须有长远规划，可支持多种管理模式；
∙加强信息系统的整合，建立对内对外信息披露的统一的、高效的平台，满足业务管理、销售支持、决策分析等各方面需要；
∙系统建设要面向客户和市场，支持业务流程和管理优化，支持应用系统在不同用户界面或渠道的拓展，如Internet、电话、多媒体终端等；
∙充分利用录入的原始数据，提供丰富的、方便的统计查询及分析功能；指导我们的管理工作；业务处理和行政管理规范化、自动化、流程化、无纸化；另外，通过信息系统建立预警机制，加强业务监控；
∙信息系统由封闭走向开放，将员工、客户、业务员、代理机构、合作伙伴有机结合起来。
∙用户认为目前信息系统距离业务需求的差距（优先级）
从上图中可以看出，目前的应用系统信息处理效率不高是用户反映最多的问题，其次是信息量不丰富和准确性不够。
因此，上述各项中，建立高效的数据处理应用系统和统一集成的数据整合平台是用户的重点期望。
1.1.4.初步的差距分析
编号
ID
观察
Observation
根本原因
RootCause
影响范围
Impact
紧急程度
Urgency
改进建议
Action
04.1
整个信息系统缺乏总体性，数据接口设计、开发、维护、升级等工作复杂
没有总体的业务信息流的定义，从而无法进行总体的数据流设计
所有应用
紧急
定义业务处理的信息流，在此基础上定义信息系统的数据流，统一应用间数据交换定义
O4.2
企业级总体监控信息难以获取，时效性差
没有总体数据架构规划
没有建立数据提升系统
业务监控、管理和决策
紧急
分阶段建立企业级统一的数据平台（One-View），包括：
基础数据平台、各汇总层次数据、决策支持模型
04.3
信息系统的组织和设计是面向业务流程处理的，而不是以客户为中心的
旧的业务管理模式是面向处理流程的
所有业务管理和客户服务
紧急
建立以客户为中心的业务管理和客户服务模式，在此基础上按照CRM的理念改造现有信息系统
1.2.数据标准化管理
1.2.1.中国人寿数据标准化现状
∙基本上所有的业务和IT人员都充分认识到数据标准化对业务的重要性，但往往数据标准化被认为是IT部门的工作，而忽视了建立数据标准化的基础：
业务信息定义的标准化；
∙但实际上，除了部分代码标准是总公司下发的以外，业务部门并没有统一制定业务信息的标准定义，因此，IT部门也就缺乏必要的、统一的依据来制定数据标准；
∙从组织保证上，并没有一个指定的团队来负责业务信息乃至数据定义的标准化工作；
∙各应用系统的开发商不同，而中国人寿对各供应商在数据标准化上也无法进行有效的控制，导致所遵循的数据标准不统一；
∙由于总颁应用系统普及面较广，对某一个具体的业务应用来讲，使用该应用系统的数据标准基本是统一的。
1.2.2.现有数据标准制定和管理制度
∙数据标准的制定由应用系统开发商负责，而不是由一个独立的数据规划部门负责；
∙开发商遵循自己的数据标准制定流程进行管理，基本属于开发管理的范畴，而不是IT管理和规划的范畴；
∙现行的数据管理是面向最终数据结果（如统计报表、精算数据准备等）的，而忽视了数据定义和处理的标准化，各地对同一个名词的理解和定义可能都不相同。
1.2.3.用户期望
∙对业务的重要性：
在对现状调研的过程中，无论是业务人员还是IT人员，所有的受访者都一致认为信息标准化程度对业务是非常重要的。
∙业务信息标准化的优先级：
上图是业务人员对信息标准化优先级的反馈统计，而从IT人员的反馈来看，唯一的区别是他们认为最优先的应当是业务操作过程信息：
综合业务和IT人员的看法，我们可以认为，保单信息、客户信息和业务操作过程信息是当前最迫切的标准化需求，也是进行数据整合是实施数据清理的重点工作。
∙信息标准无法贯彻的原因：
由上图可以看出，几乎所有的受访者都不认为标准化不适应业务需要或会导致工作量增大，而认为标准无法贯彻的原因是没有管理制度；因此，我们初步认为，中国人寿有着很好的标准化实施基础，而制定和贯彻标准化管理制定是这项工作的重点突破口。
1.2.4.初步的差距分析
编号
ID
观察
Observation
根本原因
RootCause
影响范围
Impact
紧急程度
Urgency
改进建议
Action
04.1
应用间甚至业务功能和部门间信息沟通复杂
没有统一数据标准
所有
紧急
建立统一的业务信息标准，并在此基础上建立统一的数据标准
O4.2
数据标准的贯彻能力弱
缺乏授权的流程的制度保证标准的贯彻
所有
紧急
建立数据标准的制定、发布、维护流程，并建立定期审计制度；
严格控制应用开发的数据标准，将其作为开发项目验收条款的一部分
1.3.数据质量管理
1.3.1.现有主要业务支撑系统
见应用系统评估部分
1.3.2.数据质量控制
1.3.2.1.现有数据质量问题
现有的数据质量问题主要表现在：
∙相对于新的业务应用系统来说，老业务数据不完整，导致系统升级和移植后，数据质量不能达到新应用系统的要求；
∙系统校验控制不严谨或BUG导致的数据错。
∙管理员为保证业务的运行，在取得授权的情况下，直接修改数据库后台数据，由于对应用系统的熟悉程度的差异，导致出现数据不一致；
∙升级和移植过程中数据转换或迁移操作错误，导致的数据错；
1.3.2.2.数据质量管理现状
∙现行的数据质量标准
-中国人寿没有全公司范围的数据质量考核体系，现行的数据质量评价主要通过以下几方面进行：
▪业务考核或报告中，数据统计的准确度和完整性；
▪应用系统运行时所执行的业务逻辑校验；
▪数据交换时的合法性检查；
∙现有的数据质量控制方法
-应用系统所实现的校验逻辑和业务规则；
-数据交换时的合法性检查；
-应用系统间的数据对照；
∙现行的数据质量管理制度
-缺乏完善的对数据录入人员的数据质量考核体系；
-缺乏对开发过程的数据标准化控制；
-缺乏系统上线流程中的数据迁移管理；
-缺乏对应用系统运行过程中的数据质量审计和考核体系。
∙现行的数据质量管理工具
-现行的数据质量管理工具主要是为数据接口所开发的校验程序，用于发现交换数据的错误；
-由于没有企业级统一的数据平台，因此，也就没有全司范围的数据质量监控和数据自动修正工具。
1.3.3.初步的差距分析
编号
ID
观察
Observation
根本原因
RootCause
影响范围
Impact
紧急程度
Urgency
改进建议
Action
04.1
现有历史数据质量无法满足以客户为中心的要求
由于业务需求和应用逻辑定义不完善，导致历史数据不完整
缺乏完善的数据质量考核体系
所有
紧急
在建立以客户为中心的业务模型的基础上，尽量补齐或修正所需的客户信息和相关交易信息；
对无法补齐或修正的数据，发布数据质量报告，明确告知最终用户；
对于现在后今后产生的数据，建立严格的数据质量考核体系，加强应用操作，尤其是数据录入的监督
O4.2
系统升级越频繁，数据质量越差
系统开发缺乏严格的测试，导致BUG引发的数据错误
系统升级时没有系统地考虑数据地迁移和转换过程
系统升级和维护
紧急
建立需求部门负责把关的严格的测试体系，对应用系统
引入解决方案部署过程（SolutionArchitectureandInfrastructureDesign），保证系统升级过程更加系统和完善;
将系统的部署或升级方案作为应用开发验收的一部分
04.3
管理员人为修改导致数据质量下降
业务需求定义不完善
应用系统不灵活
管理员对应用系统处理过程及表之间的参照关系不熟悉
系统维护
一般
建立统一的数据直接修改流程，严格控制直接后台修改的授权、修改方法和测试过程
1.4.应用系统数据管理
1.4.1.应用系统数据维护
1.4.1.1.CBPS应用系统数据维护描述：
∙业务逻辑控制（数据校验）
-不允许为空数据的强制录入控制
-业务规则校验
-变化幅度异常的数据
目前的应用系统中上述方面做的比较好，但在以往的应用系统由于需求定义不完善的原因，存在由于上述控制不完善导致的非正常数据。
∙数据扫描和一致性校验
-应用系统没有的错误数据清理工具；
-没有实施例行检查操作,把正常情况下要到今后某一时刻才反映出问题的数据（如接口异常），再提前找出来处理掉；
∙错误数据清理
-目前没有应用系统自动的错误数据报警和清理功能；
-错误数据清理仍是相当艰巨的工作；
-部分分公司做了错误数据清理工作；
∙历史数据卸载
-系统设计时没有考虑历史数据卸载计划、卸载机制；
-缺乏历史数据卸载这方面的知识和经验；
∙直接后台修改
-系统中存在错误数据，导致前台无法正常操作，需要后台修改。
这部分比重相对较大；
-由于某些功能程序不支持，需要后台修改.；
-后台修改一般采用会办单的形式流转；
-复杂问题的诊断，较为慎重的做法是在测试库上模拟验证；
∙系统升级和迁移
-系统升级和迁移频繁；
-升级和迁移时缺乏良好的测试，导致出现操作不正常，以及数据错误。
1.4.1.2.上海应用系统数据维护描述：
∙业务逻辑控制（数据校验）
-不允许为空数据的强制录入控制
现有系统对数据录入的控制较严格，目前存在的某些数据字段为空的原因是由于历史数据缺失，或者过去业务需求定义时没有要求强制录入。
-业务规则校验
目前存在的业务规则校验问题主要是：
I.历史数据没有满足业务规则，所以移入时就不正确；
II.应用程序中存在的BUG，导致业务规则校验没有被100％地实现；
-变化幅度异常的数据
目前系统中存在某些数据满足规则但不合理的现象，如投保年龄超过条款规定的原因，可能是依据业务特批进行的操作。
∙数据扫描和一致性校验
应用系统后台后台配备有审计程序，定时运行，根据规则搜索异常数据，查找原因并处理。
∙错误数据清理
目前对错误数据的清理基本是管理员手工执行：
如果是生产系统数据有错，尽量修改；如果缺失没法补，则放弃对该错误的修改（备案否？
）。
∙历史数据卸载
最初的系统设计未考虑这个问题。
目前准备将一些表按规则拆分，但需要应用系统中的一些功能（比如查询作修改？
），必须统一考虑。
∙直接后台修改
目前应用系统中的直接后台修改集中在团险领域，由于团险协商情况较多，系统不能接收。
处理方法是：
由业务做批示，开发人员写脚本，提交运行人员执行，将数据导入；
∙系统升级和迁移
一般不删除旧表或旧字段。
升级时写好脚本，并测试。
1.4.2.现有数据库平台
基本上，目前所有的主要应用系统全部使用Informix作为数据库平台；少量的支持性应用（如网站等）使用MSSQLServer，上海采用DB2作为数据仓库平台。
用户对数据库平台的评价如下图所示：
从上图看到，用户对Informix数据库管理系统的综合评价基本处于可接受的状态，因此可以认为，目前Informix在中国人寿的运行状况较为平稳。
从目前的使用情况来看，Informix存在如下问题：
∙产品供应商支持能力弱；
∙从发展的角度看，由于系统不再更新，技术水平和性能都将逐渐落后；
综合上述现状和问题，我们初步认为，将系统迁移到其他数据库平台是必然的趋势，由于目前Informix的运作正常，整个移植计划周期可以根据IBM对Informix的周期来确定，而不必急于立刻实施应用系统的迁移改造。
1.4.3.现有数据访问权限控制
1.4.3.1.权限管理状况综述
从上述两个统计图可以看出，目前数据库和应用系统的数据访问控制已经可以满足用户的需求，总体的评价较好。
并且具备了一些审计功能。
而另一方面，从应用数据的角度，中国人寿缺少一套完整的数据访问审计机制，由于审计和系统效率以及管理工作量之间存在的矛盾平衡关系，因此需要对审计功能进行总体的评估，即从业务风险控制和系统管理的角度，划分需要审计的操作环节，并将其作为应用开发和系统管理的重要组成部分。
1.4.3.2.CBPS数据访问权限控制描述：
∙基于应用系统的访问权限
-应用系统有独立的权限管理功能
-权限的划分一般基于功能进行划分
-涉及到客户的一些重要信息控制不是很严，比如帐户信息等。
业务上也没有这方面的要求和规定
∙管理员权限管理
-权限管理职责所属部门无统一规定
-注重权限的增加，往往忽视操作员岗位变动或离司后权限的更新
∙审计
-无进入，退出系统的日志记录和监控机制
-数据访问、修改的轨迹较难追踪
-部分数据的产生无时间戳
1.4.3.3.上海系统数据访问权限控制现状描述：
∙基于应用系统的访问权限
-操作员通过操作系统用户登录，往往使用同一个用户
-数据库中设置不同操作系统用户对数据的访问权限，一般所有都放开
-操作员登录后直接进入应用系统画面，中断后也直接logout
-应用系统中，对各类操作员、各项功能分别设置使用权限
∙管理员权限管理
-应用系统权限设置功能委派专人负责，可能是IT人员，也可能是业务人员
-人力资源部负责统一清理岗位权限：
整理公司现有员工序号，设置岗位，整理各岗位可以使用的业务系统清单和系统中的功能清单，然后统一设置
∙审计
-某个功能进入和出去的时间和操作员信息有日志记录，对数据实施了哪些操作则无
-操作员的增加、销户、对某个功能使用权的增减，这类操作管理部门往往控制不严
1.4.4.初步的差距分析
编号
ID
观察
Observation
根本原因
RootCause
影响范围
Impact
紧急程度
Urgency
改进建议
Action
04.1
应用系统的非功能性要求较弱
应用系统的技术设计不足
所有应用系统
紧急
将技术设计作为应用开发的重要部分，并在验收时进行严格测试
04.2
数据库平台难以支撑未来应用
Informix属于将被逐步淘汰的平台
所有基于Informix的应用
紧急
像其他数据库平台迁移
04.3
信息的权限控制不严谨
注重功能操作权限控制，忽视了数据访问权限的控制
所有应用系统
紧急
将信息安全控制和数据保护作为应用系统开发中数据模型设计的一部分工作，信息安全的设计应当以数据访问控制为单位，而不是仅以应用系统功能执行权限为单位；
升级会员 