3.4.2.2
数据模型化、标准化原则
共享数据的逻辑结构应独立于各应用系统，并遵循全行统一的数据模型以及通用数据格式和标准，用以最高效地开发跨业务条线的通用解决方案和应用，增加跨应用系统数据的一致性并提高数据质量，减少数据转换和数据复制的成本。 3.4.2.3
数据的集中化原则
在数据架构设计上保持逻辑集中，但在物理上也支持灵活分布。总体来说，跨业务条线、跨部门、跨区域、跨应用的全行共享数据应在总行集中并统一管理。
数据架构设计逻辑集中，表现在数据模型、数据库定义上完全一致，且数据库中存放的数据项均是唯一标识的。 3.4.2.4
避免数据冗余和复制原则
同一数据的获取应限制在某一应用系统中，并尽量在同一系统中维护。数据复制只有在满足性能和可获取性需求时才予以考虑。 3.4.2.5
数据的可用性原则
? 全行共享数据应支持相应业务需求，具备持续、可用性能力。
3.4.2.6 数据访问的性能原则
对全行共享数据的使用应在性能上能满足对业务服务的要求。 3.4.2.7
数据的分布和存储原则
? 交易型数据的分布 ? 操作型数据存储分布 ? 管理分析型数据存储分布
3.4.3 3.4.3.1
xx银行的数据架构设计 xx银行的全行概念数据模型
全行级的数据架构设计的内容是基于银行概念数据模型的，有必要先介绍其设计原则、应具备的特点、主要内容、作用和意义。
第 26页 /共 38页
? 银行全行级概念数据模型的设计原则
? 正确的业务概念及完整性原则 ? 连续性原则 ? 灵活性原则 ? 前瞻性原则 ? 可操作性原则
? 银行业概念数据模型须具备的特点
? 根据事物的内在特征，业务概念内外部应统一建模，提高模型的通用性和灵
活性
? 介质和产品/金融协议应分离 ? 金融协议和核算应剥离
条件建模抽象了产品间的相似性，而令产品的差异性分属有产品模型的各个分支条件上。概念数据模型符合条件建模的理念，助于规则引擎的介入，实现产品开发的可配置化，能够更快速的响应市场需求。
3.4.3.2
xx银行主数据源的分布规划
全行级的数据架构设计的是围绕应用架构的。在xx银行目标应用架构的框架下，xx银行主数据源的分布规划
以下介绍该规划的原则、规划内容
? 规划原则
? 单一数据视图原则 ? 接近主数据源应用原则
? 实体间关系的主数据分布确定原则
4 IT基础设施架构设计 4.1
IT基础设施架构总体设计
4.1.1 IT基础设施架构建设模式
面对基础设施面临的挑战，xx银行首先要改变的是基础设施的建设模式。
第 27页 /共 38页
在传统的建设模式中，是先考虑业务，再到应用和数据，最后是IT基础设施的传统串行模式，采用这种模式带来问题是基础设施对未来的变化不能快速做出响应，每上一个新系统，都要考虑基础设施上需要建设的内容，这种建设模式无法在激烈的竞争条件下生存发展。
建议xx银行应过渡到业务、应用和数据、IT基础设施同时考虑的并行模式。
图 4-1 建设模式
在这种模式下，基础设施的建设在业务目标确定的情况下同步开展，其思路是在应用架构进行变化的同时，开始基础设施架构搭建，这个架构具备支撑未来应用架构需求的能力，是一个随需应变的运行环境。 4.1.2 目标IT基础设施架构 4.1.2.1
设计思路 对于基础设施并行建设模式来说，选择何种基础设施架构是非常重要的，只有按照一个具备良好灵活性、扩展性、可用性的目标架构进行建设才可能保障将来对业务的快速响应，提供高质量的服务。对于xx银行来说，本次规划很重要的一点是要“具有前瞻性”，因此，规划的目标是按照一个随需应变的运行环境进行规划设计，其目的是为了更好的适应业务的需求与变化。
要建立运行环境随需应变，基础设施必须与应用松耦合，通过基础设施架构的简化来达到目的。基础设施架构的简化是从使用者的视角来看，从IT建设的角度来看，其实质是建立基础设施资源池，提供各种标准化的服务，这些服务组合起来可以支持全行的各种应用。这种简化架构可以将以前一套应用建一套系统的竖井式建设方式转变为根据应用的需求分配资源的方式。
可以用四个标准角度的目标来衡量这种简化的基础设施架构。如果能够实现这些目标，则可以建立一套“随需应变”的技术架构：
? 运行可靠化 ? 资源虚拟化 ? 通用服务标准化 ? 管理流程化
除了从这四个方面考虑，同时还要结合监管要求，确保未来的基础设施架构是符合金融监管部门的要求。
第 28页 /共 38页
4.1.2.2
目标架构对应用的支持
基础设施架构为应用提供运行环境，因此，对应用支持的程度很大程度上决定了应用的运行水平。基础设施架构对应用的支持体现在如下几方面：
? 高可用：在网络、服务器等各个层面保证系统的连续运行; ? 安全：保证系统的安全运行、保证系统和数据的使用安全；
? 基础服务通用：将各应用需要使用的服务通用化，形成通用IT服务，这些服务为应
用提供标准接口，从而使应用只关注业务逻辑；
? IT资源易于使用：将网络、服务器、存储等基础资源进行整合、虚拟化，这些资源
对于应用来说是透明的，应用不需要关心是如何部署，只需要提出对资源使用的需求，基础设施架构通过资源池分配相应的资源来满足应用的需求，从而实现对应用的快速部署、快速上线、快速运行的支持，对于未来多边的市场，是十分重要的一点。
? IT资源可管理性：对IT资源进行良好的管理是基础设施架构能够良好运行的必要条
件，从一个侧面也保障了应用的良好运行。
综上，结合xx银行的目标架构的设计思路，未来的基础设施架构是能够对应用起到良好的支持作用。下表是目标架构对xx银行应用架构的支持总结，具体的基础设施架构服务组件将在后续章节描述。
4.1.3 生产和灾备中心建设的策略
xx银行做为一家全国性的银行。IT已经在走“大集中”的路线，正在逐步上收分行的应用至总行的数据中心。目前xx银行具有一个生产数据中心，异地灾备服务中心。
根据《商业银行操作风险管理指引》第十九条提出“商业银行应当制定与其业务规模和复杂性相适应的应急和业务连续方案，建立恢复服务和保证业务连续运行的备用机制，并应当定期检查、测试其灾难恢复和业务连续机制，确保在出现灾难和业务严重中断时这些方案和机制的正常执行”。同时根据《中国人民银行关于进一步加强银行业金融机构信息安全保障工作的指导意见银发[2006]123号》第八条“加强灾难恢复系统建设，提高业务持续运营能力”明确提出了指导意见“全国性大型银行，原则上应同时采用同城和异地灾难备份和恢复策略，区域性银行可采用同城或异地灾难备份和恢复策略。对于核心的系统，应实施应用
第 29页 /共 38页
级备份，以保证灾难发生时，能尽快恢复业务运营，对于其他应用系统，可实施系统级或数据级备份”。
参考上述国家制定的指引，对于XX这样一个银行，目前具备的相当的灾难恢复能力，形成了两地三中心的灾备架构
同城灾备中心主要为了预防非区域性灾难，异地灾备中心主要为了预防区域性灾难。通过这个两个中心的建设，可以提供较高的恢复能力满足国家监管及xx银行自身发展要求。
对于这种两地三中心的架构，生产中心是全行核心的数据中心。灾备中心的定位可以有不同的考虑。
一般来说对于灾备中心的定位有如下考虑基准点：
? 满足监管要求； ? 考虑投入的间接收益
? 利用备份系统的设备和场地进行系统开发和系统测试、人员培训等，对于保持灾备
中心人员的技能和团队的稳定也有良好的意义；
? 保持灾备中心人员的技能和团队的稳定对于灾难切换的成功有重要意义。
如下是一个可能采取的方式的比较：
? 单一灾难恢复中心 ? 第2 生产中心
? 优点：充分利用备份系统在非灾难情况下的闲置处理能力，节省在生产中心
有关数据分析、数据挖掘、辅助决策的投资。
? 缺点：需要在第二生产中心配备系统管理、应用管理团队，人员需要做大的
调整。如果采用应用系统同时提供服务（双提交），对于应用系统来说技术实现难度大。相对节省的投资，ROI（投入回报率）不高，人员难以管理。
综合以上的分析，建议xx银行灾备中心（同城、异地）的定位如下（在不影响灾备功能的前提条件下）：
模式1：建设复合功能的灾备中心（技术实施难度低，灾备中心资源利用率提高） 模式2：单一灾备中心?-已实现（功能定位明确，实施难度最低，人员和资源的利用率不如模式1，同时人员的技能保障能力不如模式1）；
第 30页 /共 38页