IT数据架构调研与评估报告

《IT数据架构调研与评估报告》由会员分享，可在线阅读，更多相关《IT数据架构调研与评估报告（23页珍藏版）》请在金锄头文库上搜索。

1、IT数据架构调研与评估报告1?数据架构调研与评估1.1.总体数据架构现状上图摘自中国人寿应用系统介绍及打算, 它描述了整个中国人寿要紧的应用系统间的关联和数据交换，从总体上看来，中国人寿：?差不多实现了业务信息的电子化，绝大多数业务处理都有应用系统支持；?要紧的业务功能区域（如寿险实务、财务治理等的信息处理都有较为成熟的应用架构和数据架构；?各个应用系统之间能够利用数据文件进行数据交换，实现了信息的传递和共享；?银保通系统能够实现和银行间的实时数据交换；?基于数据库技术的信息处理体系差不多成熟；?初步建立了以中间库为基础的数据交换平台，并基于它实现了企业数据综合查询统计功能；?初步建立了以统计

2、报表工具为手段的数据统计和报表系统；?财务系统利用了数据仓库技术和SAS工具进行数据分析，除此之外，诸如上海还建立了自己的数据仓库系统；?基于NOTES的消息系统支持了公司的日常信息沟通工作；?基于影像技术的非结构化数据正在一些分公司使用，并逐步推广。数据模型和应用的相关性?以应用为划分的 烟囱结构，数据基于应用，并被锁定在应用系统中-数据并没有被作为一个单独的IT组成部分被规划和设计，而是作为应用系统的一部分， 由于应用系统的供应商不同，同时其设计工作也缺乏相互之间的和谐，因此，数据模型差不多按照各个应用系统的功能需求进行设计和实现；-由于缺乏有效的数据共享，一个应用所需的数据无法从相关的其

3、他应用系统中获得（如AMIS需要从CBPS 猎取客户数据），而只好重复录入；-另一方面， 由于同一个数据可能存在多个数据源（从 多个应用系统中被重复录入），由此导致了信息的不一致。?结构化数据差不多上都利用数据库技术实现，非结构化数据只有少数地点使用影像技术实施了电子化， 从应用程度上两者之间的集成度不高， 影像工作流技术和其他应用系统之间没有能够做到无缝联接。?缺乏自动化和实时的数据交换-以数据文件交换为要紧手段现有的数据交换方式通常是从一个应用中将数据导出到平台文件中，再传递到目标平台并并导入到目标应用系统中；由于大批量的数据抽取工作会阻碍到正常的业务处理效率，因此通常的数据抽取都被设定在

4、在晚间进行，因此数据的时效性较差（通常都在一天左右）。-数据交换过程缺乏严格的数据校验、过程操纵等接口数据的错误经常是在导入目标系统时才发觉，而不是作为系统数据质量操纵的一部分，预先在源系统中进行合法性校验；数据交换的过程缺乏技术性操纵：诸如大批量数据分割、数据传输的校验、重复操作的处理、操作回滚等。?对不同版本或开发商的同一应用，缺乏统一规定的应用系统数据外模式-例如业务处理系统，总颁系统CBPS和深圳、江苏、上海的系统对外的数据模式和接口都不相同，和其他应用系统 (如CLAF的接口需要各自编写相应的接口软件来实现。1.1.2. 数据物理层次和数据提升(staging) ?事务(transa

5、ction)处理层数据-应用系统中储备了完整的、原始的事务处理数据；-应用系统中的要紧事务处理数据都具备时刻戳等增量识别标志；-没有后备系统储备离线历史数据；-数据分布在各个省公司或地市公司的应用系统中，多数省份实施的是服务器的物理集中；?数据集成平台-缺少完整统一的集成平台来集成各应用中的数据，建立企业级信息视图?轻度统计汇总数据-利用应用系统自身的报表功能和统计功能实现；-地市级的IT人员完成了一定的查询和报表开发工作，以满足业务部门的小规模要求；-关于应用系统中没有的报表，利用手工(UTAB或EXCEL ）实现;- 总公司层而缺乏对轻度汇总数据的全而集成；?高度汇总数据-应用系统中具备部

6、分高度汇总统计功能；-关于应用系统中没有的报表，利用手工（UTAB或EXCEL ）实现；-由于手工工作太多，人为因素阻碍了数据的完整性和准确性，使得数据准确性和可信度不够高；?决策支持模型-缺乏灵活的系统统计分析功能；-缺乏企业级统一的数据平台，从而也就无法建立企业级的决策支持分析模型；-目前的SAS系统要紧基于财务数据的分析。1.1.3. 用户期望?以后信息系统必须有长远规划，可支持多种治理模式；?加强信息系统的整合，建立对内对外信息披露的统一的、高效的平台，满足业务治理、销售支持、决策分析等各方面需要; ?系统建设要面向客户和市场，支持业务流程和治理优化，支持应用系统在不同用户界面或渠道的

7、拓展，如Internet、多媒体终端等；?充分利用录入的原始数据，提供丰富的、方便的统计查询及分析功能；指导我们的治理工作；业务处理和行政治理规范化、自动化、流程化、无纸化；另外，通过信息系统建立预警机制，加强业务监控；?信息系统由封闭走向开放，将职员、客户、业务员、代理机构、合作伙伴有机结合起来。?用户认为目前信息系统距离业务需求的差距优先级）从上图中能够看出，目前的应用系统信息处理效率不高是用户反映最多的问题，其次是信息量不丰富和准确性不够。因此，上述各项中，建立高效的数据处理应用系统和统一集成的数据整合平台是用户的重点期望。1.1.4. 初步的差距分析编号ID 观看Observation

8、 全然缘故Root Cause 阻碍范畴Impact 紧急程度Urgency 改进建议Action 04. 1 整个信息系统缺乏总体性， 数拯接口 设计、开发. 爱 护. 升级等工作复 杂没有总体的业务信息流的定义，从而无法进行总体的数据流设计所有应用紧急立义业务处理的信息流，在此基础上定义信息系统的数据流，统一应用间数据交换左义04.2 企业级总体监控信息难以猎取，时效性差没有总体数据架构规划没有建立数据提升系统业务监控. 治理 和决策紧急分 时 期 建 立 企 业 级 统 一的数据平台 (One- View) ,包括：基础数据平台、各汇总层次数据. 决策支持模型04.3 信息系统的组织和设

9、计是面向业务流程处理的，而不是以客户为中心的旧的业务治理模式是而向处理流程的所有业务治理和客户服务紧急建 立 以 客 戸 为 中 心 的 业务治理和客户服务模式，在此基础上按照CRM的理念改造现有信息系统2?数据标准化治理1.2.1. 中国人寿数据标准化现状?差不多上所有的业务和IT人员都充分认识到数据标准化对业务的重要性，但往往数据标准化被认为是IT部门的工作，而忽视了建立数据标准化的基础：业务信息定义的标准化;?但实际上，除了部分代码标准是总公司下发的以外，业务部门并没有统一制定业务信息的标准定义，因此，IT部门 也就缺乏必要的、统一的依据来制定数据标准；?从组织保证上，并没有一个指定的团

10、队来负责业务信息乃至数据定义的标准化工作；?各应用系统的开发商不同，而中国人寿对各供应商在数据标准化上也无法进行有效的操纵，导致所遵循的数据标准不统一；?由于总颁应用系统普及面较广，对某一个具体的业务应用来讲，使用该应用系统的数据标准差不多是统一的。1.2.2. 现有数据标准制定和治理制度?数据标准的制定由应用系统开发商负责，而不是由一个独立的数据规划部门负责；?开发商遵循自己的数据标准制定流程进行治理，差不多属于开发治理的范畴，而不是IT治理和规划的范畴；?现行的数据治理是面向最终数据结果（如统计报表、精算数据预备等）的，而忽视了数据定义和处理的标准化，各地对同一个名词的明白得和定义可能都不

11、相同。1.2.3. 用户期望?对业务的重要性：在对现状调研的过程中，不管是业务人员依旧IT人员，所有的受访者都一致认为信息标准化程度对业务是专门重要的。?业务信息标准化的优先级: 上图是业务人员对信息标准化优先级的反馈统计，而从IT人员的反馈来看，唯独的区别是他们认为最优先的应当是业务操作过程信息: 综合业务和IT人员的看法，我们能够认为，保单信息. 客户信息和业务操作过程信息是当前最迫切的标准化需求, 也是进行数据整合是实施数据清理的重点工作。?信息标准无法贯彻的缘故: 由上图能够看岀，几乎所有的受访者都不认为标准化不适应业务需要或会导致工作量增大，而认为标准无法贯彻的缘故是没有治理制度；因

12、此，我们初步认为，中国人寿有着专门好的标准化实施基础，而制定和贯彻标准化治理制定是这项工作的重点突破口。1.2.4. 初步的差距分析编号ID观看Observation全然缘故Root Cause阻碍范畴Impact紧急程度Urgency改进建议Action04. 1 应用间甚至业务功能和部门间信息沟通复杂没有统一数据标准所有紧急建立统一的业务信息标准，并在此基础上建立统一的数据标准04.2 数据标准的贯彻能力弱缺乏授权的流程的制度保证标准的贯彻所有紧急建立数据标准的制左、公布、爱护流程，并建立定期审计制度；严格操纵应用开发的数据标准，将其作为开发项目验收条款的一部分1.3 ?数据质量治理1.3

13、.1. 现有要紧业务支撑系统见应用系统评估部分1.3.2. 数据质量操纵现有的数据质量问题要紧表现在：?相关于新的业务应用系统来说，老业务数据不完整，导致系统升级和移植后，数据质量不能达到新应用系统的要求；?系统校验操纵不严谨或BUG导致的数据错。1.3.2.1. 现有数据质量问?治理员为保证业务的运行，在取得授权的情形下，直截了当修改数据库后台数据，由于对应用系统的熟悉程度的差异，导致显现数据不一致；?升级和移植过程中数据转换或迁移操作错误，导致的数据错；?现行的数据质量标准- 中国人寿没有全公司范畴的数据质量考核体系，现行的数据质量评判要紧通过以下几方而进行：业务考核或报告中，数据统计的准

14、确度和完整性；应用系统运行时所执行的业务逻辑校验；数据交换时的合法性检查；?现有的数据质量操纵方法- 应用系统所实现的校验逻辑和业务规那么；- 数据交换时的合法性检查；- 应用系统间的数据对比；?现行的数据质量治理制度缺乏完善的对数据录入人员的数据质量考核体系; - 缺乏对开发过程的数据标准化操纵；- 缺乏系统上线流程中的数据迁移治理；- 缺乏对应用系统运行过程中的数据质量审计和考核体系。1.3.2.2. 数据质量治理现状?现行的数据质量治理工具- 现行的数据质量治理工具要紧是为数据接口所开发的校验程序，用于发觉交换数据的错误；- 由于没有企业级统一的数据平台，因此，也就没有全司范畴的数据质量

15、监控和数据自动修正工具。1.3.3. 初步的差距分析编号ID 观看Observation 全然缘故Root Cause 阻碍范畴Impact 紧急程度Urgency 改进建议Action 04. 1 现有历史数拯质量无法满足以客户为中心的要求由于业务需求和应用逻辑定义不完善，导致历史数据不完整缺乏完善的数据质量考核体所有紧急在建立以客戸为中心的业务模型的基础上，尽量补齐或修正所需的客户信息和相关交易信息：对无法补齐或修正的数据，公布数据质量报告，明确告知最终用户：关于现在后今后产生的数据，建立严格的数据质量考核体系，加强应用操作，专门是数据录入的监督04.2 系统升级越频繁，数据质量越差系统开

16、发缺乏严格的测试，导致BUG 引发 的数据错误系统升级时没有系统地考虑数据地迁移和转换过程系统升级和爱护紧急建立需求部门负责把关的严格的测试体系，对应用系统引入解决方案部署过程Solution Architecture and Infrastructure Design ),保 证系统升级过程更加系统和完善；弱索统的部署或升级方案作为应用开发验收的一部分04.3 治理员人为修业务需求泄义系统爱护一样建立统一的数据直截了当修改流编号ID 观看Observation 全然缘故Root Cause 阻碍范畴Impact 紧急程度Urgency 改进建议Action 改导致数据质量下降不完善应用系统不灵活治理员对应用系统处理过程及表之间的参照关系不熟悉程，严格操纵直截了当后台修改的授权、修改方法和测试过程1? 4?应用系统数据治理1.4.1. 应用系统数据爱护1.4.1.1. CBPS应用系统数据爱护描述：?业务逻辑操纵（数据校验）-不承诺为空数据的强制录入操纵-业务规那么校验-变化幅度专门的数据目前的应用系统中上述方而做的比较好，但在以往的应用系统由于需求定义不完善的缘故，存在由于上述操纵不