某银行IT应用体系架构.docx

1 介绍 10
1.1 文档目的 10
1.2 目标 10
1.3 范围 10
1.4 目标读者 10
1.5 假设 10
2 应用体系架构的整体说明 11
2.1 应用体系架构的定义 11
2.2 对某银行IT战略的建议 13
2.2.1 应用服务战略 13
2.2.2 数据管理战略 13
2.2.3 基础设施战略 14
2.2.4 体系架构战略 14
2.3 应用体系架构设计中的关键点 14
2.3.1 银行的核心业务系统 14
2.3.2 客户信息的管理 16
2.3.3 企业应用系统集成（EAI） 17
2.3.4 管理信息系统 19
2.3.5 合理的应用系统功能 20
2.3.6 数据分布模式 21
2.3.7 应用分布模式 21
2.3.8 应引起关注的技术问题和技术管理问题 23
2.3.9 IT规划的管理机制问题 24
3 应用体系架构的整体设计 25
3.1 应用体系架构的整体设计图 25
3.1.1 应用体系架构中的系统功能和全行的应用需求的对应关系 26
3.1.2 对核心业务体系系统的说明 28
3.1.3 总行层面的系统总览 31
3.1.4 一级分行层面的系统总览 32
4 建议的转型计划大纲（待项目计划出） 34
4.1 某银行现有的应用系统和目标模式的差异分析 34
5 核心业务系统的目标功能模式 36
5.1 核心业务系统核心层的目标功能 36
5.1.1 系统的总体功能和特性 36
5.1.2 客户信息管理功能 36
5.1.3 帐户管理功能 37
5.1.4 产品管理 功能 40
5.1.5 帐户交易管理功能 41
5.1.6 报表管理功能 42
5.1.7 出纳/分行交易管理功能 43
5.1.8 管理和监控功能 44
5.1.9 现金管理功能 44
5.1.10 总帐功能 45
5.1.11 应用安全管理功能 46
5.2 核心业务系统的业务层的目标功能 47
5.2.1 核算管理及账务体系 47
5.2.2 内部资金管理 49
5.2.3 结算管理 49
5.2.4 银行卡业务的管理 50
5.2.5 现金管理 50
5.2.6 凭证管理 50
5.2.7 国际结算 51
5.2.8 对各级机构作业的支持 51
5.2.9 营运风险控制体系 52
5.3 金融产品提供 55
5.3.1 公司业务（仅包含帐户处理） 55
5.3.2 个人业务 55
5.3.3 银行卡业务 55
5.3.4 现金业务 56
5.3.5 资金调度业务 56
5.3.6 票据清算 56
5.3.7 外汇买卖业务 56
5.3.8 中间业务 56
6 大前置的目标功能模式 58
6.1 大前置系统的建设目标 58
6.2 大前置架构说明 60
6.3 大前置系统功能说明 61
6.4 前端设备 63
6.5 技术考虑事项 63
7 某银行信息总线目标功能模式 64
7.1 信息总线的整合层 65
7.1.1 概述 65
7.1.2 系统接入子层 66
7.1.3 输出整合 69
7.1.4 BPM 70
7.2 门户技术 80
7.2.1 门户要求 80
7.2.2 两级门户个性化实现方案 81
7.2.3 多种前端接入实现方案 83
7.3 统一的安全认证机制 84
7.3.1 建立客户信息管理系统 84
7.3.2 建立认证LDAP服务器 85
7.3.3 实现单点登录 85
8 MIS系统目标功能模式 89
8.1 数据仓库架构 89
8.1.1 图 1 数据仓库一般架构源系统 89
8.1.2 ETL 90
8.1.3 操作数据存储（ODS） 91
8.1.4 多维数据存储（数据集市） 91
8.1.5 OLAP 92
8.1.6 数据挖掘 93
8.1.7 表现层 95
8.2 管理信息系统体系结构 96
8.2.1 管理信息系统数据仓库体系架构 96
8.2.2 管理信息系统演进策略 101
8.3 分析型客户关系管理应用架构 103
8.3.1 分行层面的客户区分 105
8.3.2 分行层面的多维利润分析 106
8.3.3 分行层面的客户需求分析 106
8.3.4 分行层面的客户行为分析 107
8.3.5 分行层面的交叉销售分析 108
8.3.6 分行层面的客户满意度分析 108
8.3.7 总行层面的客户区分 109
8.3.8 总行层面的客户需求分析 109
8.3.9 总行层面的多维利润分析 110
8.3.10 总行层面的市场趋势分析 111
8.3.11 总行层面的重大事件分析 111
8.3.12 总行层面的客户行为分析 112
8.4 管理会计系统应用架构 113
8.4.1 全面预算 114
8.4.2 多维的成本盈利管理 115
8.4.3 帐户的利润贡献度计算 115
8.4.4 产品/客户的利润贡献度计算 119
8.4.5 渠道的利润贡献度计算 119
8.4.6 机构的利润贡献度计算 119
8.4.7 业绩考核指标 119
8.5 资产负债管理信息系统应用架构 122
8.5.1 市场风险分析和预测 123
8.5.2 利润分析 127
8.5.3 内部资金转移定价（FTP） 129
8.5.4 资本管理 131
8.6 信贷风险管理信息系统应用架构 132
8.6.1 信贷风险管理信息系统数据仓库 133
8.6.2 信贷风险模型 134
8.6.3 信贷风险管理决策支持 141
8.6.4 信贷风险管理监控及报表生成 142
9 信贷业务和风险管理系统目标功能模式 146
9.1 信贷业务管理系统 146
9.1.1 目标模式信贷业务管理系统特性 146
9.1.2 信贷业务管理系统所支持的信贷关键业务流程的具体说明 147
9.1.3 信贷业务管理系统的数据结构 159
9.1.4 信贷业务管理系统的数据流图 163
9.1.5 信贷业务管理系统的系统技术体系结构 164
9.2 信贷风险管理系统 167
9.2.1 信贷风险管理系统的功能模块和整体逻辑视图 167
9.2.2 信贷数据集市及数据管理系统 170
9.2.3 联机数据分析及报表处理系统 175
9.2.4 信贷业务管理系统和信贷风险管理系统的接口 178
10 操作型客户信息管理 179
10.1 操作型客户信息管理平台的总体目标规划 179
10.2 CIF的设计方法 179
10.3 操作型客户信息结构模型分析 180
10.4 本规划操作型客户信息设计 183
10.5 操作型客户信息存放方式 184
10.6 操作型客户信息的建立和维护 186
11 资金管理系统的目标模式 187
11.1 资金管理系统目标模式介绍 187
11.2 资金管理系统对资金流程的全线支持 187
11.3 资金管理系统功能介绍 188
11.4 资金管理系统的数据结构介绍 189
11.5 资金管理系统技术体系结构介绍 190
12 个人理财系统 192
12.1 目标模式的个人理财系统支持的业务： 192
12.2 个人理财系统整体应用流程 193
12.3 个人理财系统功能模块 194
13 ERP系统 198
13.1 总帐管理 199
13.2 人力资源/薪资管理 200
13.2.1 目标模式的人力资源管理系统功能 200
13.3 固定资产管理 203
13.4 采购管理 204
13.5 库存管理 206
13.6 合同管理 208
13.7 ERP系统与其它系统的接口 208
13.7.1 ERP系统与OA（办公自动化）系统的关系 208
13.7.2 ERP系统与其它MIS的关系 208
13.7.3 ERP系统与业务支持系统的关系 209
14 办公自动化系统的目标应用体系结构 210
企业办公自动化的主要功能模块 210
某银行的办公自动化系统的主要基础功能模块 210
某银行的办公自动化系统的主要应用功能模块 213
对某银行办公自动化系统功能模块的建议 214
与其它系统之间的信息交换结构图 215
某银行的办公自动化系统的基础平台的选择 215
15 档案管理的应用体系结构 218
档案管理在某银行IT应用体系中的作用与地位 218
某银行档案管理系统应具备的特点 218
档案管理与其它系统的关系 219
档案管理与办公自动化系统的关系 219
档案管理与银行业务系统的关系 219
档案管理与企业信息站的关系 219
档案管理系统的主要功能模块 219
数据录入、压缩、转换与存储 220
档案检索 221
档案信息发布和使用 222
档案修改与销毁管理 223
系统管理 223
档案管理系统的系统流程 223
某银行档案管理系统的数据中心建设 225
16 投资管理、证券、保险和基金业务系统 227
投资管理 227
投资管理的应用范围 227
投资管理的系统架构 227
投资管理系统的功能需求 228
投资管理系统的主要接口 228
证券与基金管理系统 229
证券与基金管理系统的业务特征 229
1 介绍
1.1 文档目的

1.2 目标

1.3 范围

1.4 目标读者
本文档的目标读者为对于某银行当前IT系统有一定了解的IT管理人员及系统管理人员。
1.5 假设
在本文档的制作过程中采用了一些前提和假设，这些假设将作为文中分析与结论的重要依据。所做假设如下：
所提供的关于IT系统及其相互间关系的信息是准确的；
关于每个系统的目的及功能的描述是准确的；
调查及访谈结果符实。
2 应用体系架构的整体说明
2.1 应用体系架构的定义

本文所指的应用体系架构是支持某银行业务体系架构的相关应用系统的体系架构。
在《某银行业务体系架构最佳实践》一文中指出，银行的业务活动，可以分为：战略规划、资产负债管理和市场风险管理、信贷风险管理、财务管理、客户关系管理、渠道管理、产品管理、营运管理、人力资源管理共九个方面。银行的各类应用系统，在功能上应该直接针对以上九个方面的业务活动的需求或者为这些业务活动提供相关信息。在应用体系结构上，应该和业务体系结构的要求相适应。

银行的大部分应用系统，是为银行的营运服务的。一般零售和批发的银行的营运包括本外币条件下的以下操作，这些操作形成了某银行的应用系统在银行营运方面的基本需求：
1) 面向客户，提供各种金融产品和服务，包括零售银行业务、对公银行业务和卡业务等
2) 操作型的客户信息管理
3) 银行提供金融产品和服务的分销渠道的运作
4) 核算和帐务体系
5) 营运风险控制体系，包括柜员管理、额度管理、业务处理流程的规范、内部审计等
6) 结算处理
7) 清算处理
8) 现金管理
9) 票据管理
10) 贷款的审批和管理
11) 资金运作
12) 柜台业务处理流程
13) 对外接口的处理

某银行作为一家企业，自然需要有：
14) 企业基本资源的管理，包括机构、人力资源、采购、营业性费用等方面的管理
15) 办公的自动化
16) 档案的电子化管理

银行的管理，自有它的专业特色，正如在《某银行业务体系架构最佳实践》一文中指出的：
17) 资产负债管理和市场风险管理
18) 财务管理中的银行管理会计
19) 银行客户关系管理
20) 信贷风险管理
需要专门的银行管理信息系统的支持。

鉴于某银行有决心发展混营业务，逐步建设成为金融集团，就还应该考虑：
21) 投资活动的营运和管理
22) 个人理财金融产品的管理营运和管理
23) 证券业务金融产品的营运和管理
24) 保险业务金融产品营运和管理

所以，在应用体系架构的规划中，要考虑上述的业务操作和业务管理职能在IT的环境中，如何实现及如何互相交互方面，为这些需求的实现和今后系统功能的扩充建立基本的框架。
在解释毕博对某银行近三年的应用体系架构的规划之前，先要阐述毕博对某银行IT战略的建议。

2.2 对某银行IT战略的建议

某银行需要开发稳定的IT战略。在这个过程中，需要将业务战略所需的IT环境与现有的IT环境进行比较，从而识别目前的IT环境多大程度上适应业务战略，然后识别差距、开发能弥补缺陷的IT战略、确定IT的工作方向，以启动IT战略的实施。

毕博的方法论认为，完整的IT战略包括以下五个方面：
1) 应用服务战略
2) 数据管理战略
3) 基础设施战略
4) 体系架构战略
5) IT组织和IT管制方式的战略
其中“IT组织和IT管制方式的战略”不在本项目的范围内。

在本项目的进行过程中，随着对某银行业务战略和愿景认识的深入、对某银行IT现状的深入，毕博建议以下的IT战略作为全行的IT战略
2.2.1 应用服务战略
1) 充分利用现有系统的功能和潜力
2) 最大程度地使用自动的工作流管理
3) 优化应用系统的客户服务能力和效率
4) 在全行逐步实施业务规则管理
5) 创造一个稳定、可扩展的开发环境
2.2.2 数据管理战略
1) 实施管理信息/决策支持
2) 提供操作型和分析型的所有客户信息

3) 逐步形成全行的一致的数据储存技术和数据储存方式

2.2.3 基础设施战略
1) 将全行IT规划、开发和管理的过程规范化
2) 需要开发完整的营运维护方案

2.2.4 体系架构战略
1) 规划和实施银行应用体系架构

2) 规划和实施银行数据体系架构

3) 规划和实施银行安全体系架构

4) 规划和实施银行技术体系架构

2.3 应用体系架构设计中的关键点

本节所述的关键点，既是某银行IT规划中所应处理的重点业务或技术问题，也是毕博对整个规划的设计的基本起点。在介绍整体的应用体系结构规划前，读者很有必要了解这些关键点。
2.3.1 银行的核心业务系统
按国际通行惯例，一般银行核心业务系统的分类较专——针对零售银行、批发银行、信用卡（国际贷记卡）、投资银行等提供专用系统，很少有大一统的系统包罗所有的业务。这不仅体现在国际上主要银行的系统部署的实践中，也体现在国际上产品化的核心业务系统的分类上。道理很简单，因为业务的性质不同，所需的系统功能和技术架构会有不同的侧重点。
举例说，零售银行一般面向的客户是个人和规模较小的商业客户，因此业务重点是临柜、ATM、电话银行、小额支付等。由于此类业务的特点是客户和帐户量大、交易量大、金额小、需要通存通兑和7X24小时服务等，所以在考虑系统效率、数据储存、系统与渠道接合这些方面会是设计的重点。
对批发银行而言，客户和帐户量与零售银行比较小，但交易金额是比较大的，所以系统的设计的重点在于交易的安全、交易流程的控管、资金结算的快速、资金管理服务的多元化、信贷风险管理的严谨等方面。从应用来说，范围包括对公存款、贷款、贸易融资、外汇、资金市场等。由于面对对公的客户为主，所以批发银行系统对于“7X24”的需求会稍低一点。
至于信用卡系统，一般是独立于核心应用业务系统的。因为信用卡的发行机构不一定是银行，而且以这产品的特点来说，信用卡户的额度完全基于个人的信贷能力，也不一定需要在银行有帐户。一般来说，信用卡系统分为发卡和代理经营两大类，所需的系统是业务代理系统和业务处理系统两大类。
某银行的DCC项目规划，将核心业务系统CCBS规划为对私业务、对公业务、卡业务、代理业务、理财业务、证券和保险业务的大一成的系统，这既反映了某银行对建设与数据中心的宗旨相一致的核心业务系统的决心，也反映了某银行对企业应用集成技术（EAI）（EAI技术，请参见本节第三段的论述、本文的正文论述和附件的介绍）的使用尚不熟练。
基于此，毕博对某银行的核心业务系统的规划的基本点是：CCBS将本外币的对私和对公金融产品的帐务处理、操作型客户关系的处理、对私金融的业务流程、核算和帐务体系集成为一体是可行的也是合理的。其它类型业务的核心系统，考虑另建或另购系统实现，并通过信息总线连接起来，成为逻辑意义上的大核心业务系统。
核心业务系统除了所提供的金融产品外，该系统的核心机制也是很重要的，毕博专门对该机制的国际最佳实践作了介绍，希望对某银行的CCBS系统的开发有所帮助。

2.3.2 客户信息的管理 
不论是什么类型的系统，银行现在都会相当讲究如何配合客户关系管理的观念、怎样推进“面向客户、面向管理”，以协助银行去管理和挖掘客户和产生新的高盈利的业务。
现在国外银行的应用系统都强调支持中央客户信息，每个客户在银行系统内都是一个唯一的个体，而所有客户的信息都是与所有的业务应用子系统共享，确保银行的每一个用户都可以基于自身的权限看到客户的所有资料，从而提供更集中的控管和优质服务。所以一个设计优秀的客户信息系统是现代化的银行系统的一个非常重要的基础。 
国外银行的客户信息比较注重怎样支持业务营销、客户关系管理、风险管理等各方面的需求和应用，因此客户信息的定义会根据数据分析（MIS、DSS、CRM等系统）的需要而增加了许多数据项，并让用户在有需要的时候新增自定义字段。这个对于未来的管理信息、决策支持、商业智能等系统来说是一个非常重要的铺垫，没有充足、一致的数据来源，再好的数据挖掘和分析工具都是派不上用场的。而且基于以客户为中心的结构，系统更容易提供综合理财类的新兴业务和综合对帐单等。
本规划是完全基于以客户为中心的设计思想，因此必须有CIF系统的支持。从目前银行业的发展趋势来说CIF系统应该是一个独立的统一心系统，其它系统应该只是通过标准接口使用该系统。但某银行的CIF系统的建立已由总行统一规划和实施的DCC项目所包括，是CCBS核心业务系统的一部分，毕博尊重这样的决定。无论CIF系统以何种方式存在，全行其它系统只是通过与CIF系统的接口去访问CIF，而不需要建立自己的CIF系统。以下是我们某银行CIF系统建立的一些建议。
考虑到某银行客户规模这么大，客户种类繁多的银行的中央客户信息，如何在总分行的结构下存储和使用，以怎样的步骤进行实施，和其它系统及信息总线的关系是什么，也是本次应用体系结构规划的总要内容。规划的详细内容见第章操作型客户关系管理。

2.3.3 企业应用系统集成（EAI）
银行的应用系统，无论先期规划得多么有远见、项目执行得多么有出色，终究会出现IT应用及基础设施不能满足日趋迅猛的市场变化的需求的现象。遇到这种情况，国际上最佳实践的银行往往首先奉行整合的技术路线。他们将使用系统整合技术，挖掘现有应用系统的潜力作为第一选择，这就需要使用EAI技术。毕博建议某银行全面、系统地使用EAI技术，来联系横贯整个企业的异构系统、应用、数据源等。
EAI是将进程、软件、标准和硬件联合起来，在一个企业内或更多的企业系统之间实现无缝集成，使它们就像一个整体一样。EAI通常表现为对一个商业实体的信息系统进行业务应用集成，或者是为不同公司实体之间的企业系统集成。由于EAI是建立一个灵活的、标准化的企业应用底层架构，可以允许新的基于IT的应用和商业处理能够更容易和更有效的被部署。

EAI涉及到结构、硬件、软件以及流程等企业系统的各个层面：
业务过程集成
应用集成
数据集成
集成的标准：要实现完全的数据集成，必须首先选择数据的标准格式。集成的标准化促成了信息和业务数据的共享和分布，构成了企业应用集成的核心。
平台集成：要实现系统的集成，底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全的通信。

在EAI技术的支撑下，现有的应用系统在全行的范围内成为了特定的功能模块。例如：对于金融市场上利率和汇率的信息，银行的资金系统、信贷系统、管理信息系统中的ALM管理、财务会计管理等都需要这类信息。银行一旦建立了市场数据汇入接口，就不必为所有需要此信息的系统都安装接口，而可以通过将数据接口视为全行的标准功能模块，将其挂接在今后的信息总线上，供各个系统共用。
通过进行EAI，银行可以建立系统整合的基础，从而在业务上获得下列好处：
1) 业务流程标准化、自动化、流程化
利用EAI产品的自动化能力，确保业务流程管理（BPM）得到清晰的划分，局部的变化不再对企业整体运作造成影响。随着某银行各项业务变革的深入，参照国际先进模式，为提高业务操作的效率和效果，或进行前瞻性业务流程改造，对现行业务流程的变动将越来越频繁。如果对支持这些业务流程的系统直接进行更改，系统开发的周期、成本和风险都是相当可观的，并且会拖延业务变革的步伐。通过EAI的 BPM，将原有系统所支持的基本业务操作单元视为全行的通用标准模块（如支付、账单处理等），在标准模块的基础上配置新的业务流程，全行系统的灵活性、有效性将得到极大的改善。
2) 集成的，基于WEB的基础设施和通用用户体验
银行可以对后台系统的数据传输进行控制，并在基于WEB的企业门户中显示这些信息。
3) 降低系统实施和运作的成本
EAI架构能够更加灵活地根据战略市场转移添加或者改变业务能力，同时在现有系统中对数据集成进行有效的管理。
4) 降低对于多个系统的依赖
银行可以对那些功能和数据重复的系统进行有选择的淘汰和整合，从而降低旧有系统的人力操作成本。

通过进行EAI，某银行可以在技术上获得下列好处：
EAI解决方案带来的技术好处主要是建立在这样的一个事实之上：该架构是可以重复使用的，具有很高的升级性和可配置性。它结合了以下的能力：
1) 方便地集成新的组件和系统；
高度集成的工作流引擎，可以实时地对面向客户的业务流程中的任何事务进行有效的管理和监控；
通用消息总线，在应用系统之间传递消息；
通过连接器将分散的应用系统整合为一个单一、有效的事件驱动系统。
在数据大集中和大前置建立后，根据所选用的形式不同，这时应该规定哪些数据保存在中心数据库中，并制定相应的交换格式和交换方法。由于这些与所选择的方式以及以后的某银行信息总线有很大的关联性，甚至有可能与未来的某银行信息总线融为一体，所以这里不详细展开讨论，而在下面的信息交换平台中提及其可能用到的技术。
在中心数据仓库逐步建立后，我们应该建立与之相配套的各种系统，例如客户信息系统，对中心数据库进行挖掘分析的系统、信贷系统、风险预警、国际结算等等，这些系统的建立与后面的某银行信息总线所采用的技术有很大的相关性，总而言之，必须能够与某银行信息总线很好地互连。
2.3.4 管理信息系统
某银行使用管理信息系统（MIS）一词，主要指的基于数据仓库技术，面向不同的银行管理主题的，对集中的业务数据和其他银行内/外数据的综合分析、处理和应用的系统。在本规划中， 管理信息系统被划分为分析型客户关系管理系统、管理会计系统、信贷风险管理系统、资产负债管理信息等系统。（其中信贷风险管理系统和信贷业务系统的关系紧密，一同在第章中论述）
我们对管理信息的这种划分，直接和《某银行业务体系架构最佳实践》相对应。
由于总、分行之间的管理职能有所不同，总分行管理信息系统对数据的要求也随着不同的管理需求有所不同。此外，由于越来越多管理决策需要详尽的、多维的支持信息；同时也要求管理信息系统能具备一定的分析预测和知识发现能力。
2.3.5 合理的应用系统功能
国内银行应用系统的开发经常发生的问题是：或者因为应用系统的需求来自于某个业务部门的业务操作和管理的需要而没有全行视野；或者需求没有前瞻性；或者作为需求的提出者的业务部门和作为需求实现者的技术部门的沟通问题；或者对国际同行同类系统的信息或参考不够，导致应用系统功能不足。对某银行而言，这种案例很多，例如：养老统筹系统、计算机设备管理系统、离休干部信息管理系统、机构信息系统等一批小型的企业资源管理系统，在功能上都属于ERP系统的范畴，不应独立开发、互不关联；信贷审批系统、信贷管理信息系统（CMIS），股票质押信息系统、坏帐核销系统、信贷清分系统、抵债资产系统等，在功能上都归属于全面的信贷业务管理和风险管理系统的范畴（参见）。
本次某银行IT规划的重点，在应用功能的规划上。虽然对银行信息总线的规划，是解决某银行系统功能割裂的问题的一个方案。但如何使某银行的各个应用系统的功能逐步具备完备性、前瞻性依然是主体问题。为此，在讨论某银行IT规划主体方案（第三章）的基础上，本规划，从第五章起，详细介绍了国际先进银行的各个应用系统的具体功能要求，供某银行参考。

2.3.6 数据分布模式
银行保存大量的数据包括业务数据以至统计分析性的数据，也运行很多不同的系统（如业务处理系统、ATM、POS、客户服务中心、各种基于数据仓库技术的MIS系统等）。在毕博建议的IT规划中，不是所有的数据都存放在总行或区域数据中心。某些数据（包括业务数据和统计性数据）可能需要存放在分行以至网点的服务器中。数据存放在分行或网点可能是因为这些数据纯粹是本地的数据而没有存放在总中心或区域数据中心的价值；也可能是为了提高交易处理效率；也可以是为了在系统离线时（与总中心或区域数据中心通讯断掉）进行必须的业务处理。
银行的数据从种类可以分为系统数据、业务数据和管理数据；从地域方面可以分为全行数据与本地数据（分行、网点）。
在本次规划中，总数据中心或区域数据中心与灾难备份中心保存几乎所有的系统数据、业务数据，也包含总行层面的数据仓库与其他后续系统的数据。在分行层面主要保存系统数据和本地业务数据，部分的本地业务数据也会存放在总数据中心或区域数据中心。在分行层面还保存了部分存放在总数据中心或区域数据中心的业务数据，主要的原因是在于提高交易的预处理能力，减小传送主机的交易量及通讯量。如柜员在柜面终端键入了客户号或帐号时需要马上显示客户或帐户姓名，以方便柜员核对的话，该等数据存放在分行是可以更快的把资料送到柜员终端，也不需要到主机提取。原则上，这些数据是不应该经常改动的。但当这些数据被改动时，分行保存的相关数据也应该同时被改动以保持数据的一致性。但帐户余额等敏感就不应该存放在分行里面，以减低银行所面对财务风险。
由于部分系统的静态数据是同时存放在数据中心和各个分行的，所以需要制定一套数据同步的过程，建议是在每天的日终处理后联机交易开始前进行静态数据的同步。这个时间点也是分发新的程序到每个分行的最佳时机。保证数据同步的另一套机制是依靠某银行的信息总线，详细情况可以参看本规划的第章。
2.3.7 应用分布模式
某银行是通过不同的系统来完成所需的操作（包括业务处理和后续的其他处理）。银行在实施集中以后，不同的应用将会分别运行在总中心，区域数据中心，分行以至网点。决定各个应用运行的地点取决于几个条件：应用的性质（本地应用或全行应用）、使用数据性质、接口系统要求等等。
某银行的应用应该是按该应用的特性分布在不同的中心、地方。例如：总数据中心或区域数据中心是运行核心业务系统的环境，也是总行MIS（即数据仓库、决策支持系统和商业智能系统）运行的理想环境，因为这些系统都需要全行的数据。网上银行的用户可以通过互联网来进行操作，也适宜在总数据中心运行。由于手机用户的流动性，手机银行系统也应该在总数据中心运行。因为客户关系管理(Customer Relation Management, CRM)系统需要管理分布在不同分行的集团客户，也建议在总数据中心运行。
由于一级分行是连接总数据中心的枢纽，其地位非常重要。在大集中模式下分行的角色在起了很大的变化，所以分行需要考虑一个很完善的“大前置”系统来负起与总数据中心、本地系统、支行/网点与本地其他金融机构的通讯连接。在后面会讨论到“大前置”系统的基本功能要求。ATM/POS是比较适合在分行里面运作，主要的原因是这些系统都需要跟本地其他金融机构(如金卡)的系统联系。银证转帐系统也需要跟券商进行通讯而比较适合在分行运作。中间业务平台也是需要很多的本地通讯功能，在分行运作是比较理想的。电话银行和Call Centre系统就比较适合在分行运作，主要的原因是在于中国地方比较大，所使用的方言也比较多，很多时候拨近来的客户不一定很懂普通话，在分行运作对总体操作有好处。操作员也能够更亲切的提供优质的服务。但有些银行倾向把电话银行和Call Centre系统在总数据中心里面运行，这也是可以的，但需要解决了语言方面的问题，譬如电话银行除了提供普通话的服务外，也可能需要提供其他多种常用语言(如广东话、上海话、四川话、潮州话等等)的服务。Call Centre由于是客户与操作员的直接对话，懂得当地的语言与俚语是比较理想的。
分行里面的报表生成系统是指在实施了集中处理后在总数据中心或区域数据中心可能会把很多的业务数据下发到各个分行，以便生成所需的运作报表。总数据中心只传送原始数据会减轻网络的传送量，也让分行更有弹性来生成本地报表。如果银行的策略是在总数据中心生成所有报表后发送到分行打印的话，则分行的报表系统只需要具备接收、打印和重打功能。
支行、网点当然只需要运行柜面系统，也可能需要接收从分行送过来的报表进行打印。

2.3.8 应引起关注的技术问题和技术管理问题
本次IT规划的主体是系统的应用体系结构和应用功能规划，不着重于系统的各项技术问题。这里我们简要的强调一下应用体系结构下，个个应用系统在开发和实施过程中应注意的技术问题和技术管理问题。
某银行应该努力使得各个应用系统在以下的技术特性上，达到最佳的综合分值：
1) 系统的安全性
2) 系统的适应性——适用于多种软硬件平台
3) 系统的扩展性——模块化和参数化
4) 系统的稳定性、可靠性、可用性
5) 系统的开放性——相对稳定的核心与不断丰富的外围功能的统一
6) 系统的配置灵活性
7) 系统吞吐量
8) 系统效率
9) 系统的可维护性

某银行应该努力使得自己在各个应用系统的开发过程中，逐步做到：
1) 一致的开发平台和开发工具
2) 一致、成熟的软件工程方法
3) 一致、成熟的软件过程方法

2.3.9 IT规划的管理机制问题
要使IT规划能长期的起到反映业务的驱动力、指导IT开发和建设工作的作用， IT规划本身需要得到长期的维护，以反映最新的业务环境的变化、某银行业务操作能力的变化、某银行IT系统的发展所带来的变化等，对全行的应用系统所带来的不同需求。
这需要某银行有一套成熟的IT规划的管理机制，这套机制的几个要点是：
1) 在IT规划部门和各个业务和技术部门充分沟通的基础上，确保被普遍认同的IT规划，能对全行的IT工作起指导作用
2) 跟踪和记录外部业务环境的变化、全行业务战略的变化、全行业务能力的变化和全行的应用系统的变化，及时评估这些变化的影响，特别是对应用系统需求的影响
3) 除了定期（建议以一年为单位）审视、修订和完善本行的IT规划外，但发生重大的内外部环境、战略或能力的变化时，适时修订IT规划
4) 需要行级领导和IT主管领导的大力支持、适度介入，并给于方向性的指导和合理的资源配置的保证
5) 成熟的IT规划方法论
6) 合格的IT规划人员和IT规划团队，对团队成员要仔细甄选
3 应用体系架构的整体设计
3.1 应用体系架构的整体设计图

这是毕博对某银行IT应用规划的整体架构。
上图中，蓝色代表核心业务体系中的关键应用系统。核心业务体系的范畴和某银行正在进行的以CCBS为核心业务系统的DCC规划的范畴大体相仿。但在局部上的考虑，二者有所不同。红色代表某银行的总行和一级分行的信息总线。绿色代表除核心业务系统以外的，某银行的其他关键应用。这些应用往往有自身的体系结构，其服务器和客户端分布在总分行。黄色代表某银行的对外接口部分，大体分为五类：外联交换型接口、终端驱动型接口、增值服务型接口、中间/特色业务型接口、全国性业务接口。
总行的核心业务系统以外的其他关键应用，在物理上存在于某个数据中心里，但在逻辑上属于总行层面。总行和数据中心业务职能的不同决定了它们各自所辖系统的功能的不同。
3.1.1 应用体系架构中的系统功能和全行的应用需求的对应关系
应用体系架构中所涉及的系统，其功能应该涵盖第一章中总结的某银行的各类应用需求。本规划中，这个对应关系如下表所示：

系统名称
所实现的业务需求
备注
核心业务系统体系
面向客户提供各种金融产品和服务，包括零售银行业务、对公银行业务和卡业务等
大部分对公业务，在核心业务体系只完成账户处理部分。
银行提供金融产品和服务的分销渠道的运作

核算和帐务体系

营运风险控制体系，包括柜员管理、额度管理、业务处理流程的规范、内部审计等

结算处理

清算处理

现金管理

票据管理

外汇处理

柜台业务处理流程

对外接口的处理

操作型的客户信息管理

信贷业务管理信息系统和信贷风险管理系统
贷款业务操作和信贷风险管理

资金业务系统
资金运作

全行ERP系统
企业基本资源的管理，包括机构、人力资源、采购、营业性费用等方面的管理

全行办公自动化系统
办公的自动化

电子档案管理系统
档案的电子化管理

MIS系统
资产负债管理和市场风险管理

财务管理中的银行管理会计

客户关系管理系统
银行客户关系管理
本规划中，将分析型客户关系管理系统归为MIS系统
投资管理系统
投资活动的营运和管理

全行个人理财系统
个人理财金融产品的管理营运和管理

证券业务系统
证券业务金融产品营运和管理

保险业务系统
保险业务金融产品营运和管理

在本章应用体系架构的整体说明中，只阐述这些某银行今后的关键应用系统在应用体系结构中的地位和相互间的主要关系。这些系统的具体功能，是本次规划的主体内容，也是应用体系架构之所以包含这些应用的原因所在，同时也体现着本规划“借鉴国际先进经验，前瞻性、合理的规划应用系统功能”的原则。各个关键应用系统的具体功能规划，从本文的第五章开始，逐个做详细的介绍，我们称之为各个应用系统的目标功能模式。
3.1.2 对核心业务系统体系的说明

核心业务体系，从逻辑上可以视为一个大的应用系统，并与总行的信息总线相连。核心业务体系中的系统，包括某银行DCC项目规划中所提论述的CCBS、大前置系统、各个前端系统以及设备前置接口。
和DCC项目规划的认识一致，毕博认为：在全国所有38 个省市分行全部集中以后，北京和上海两个数据中心，以及今后可能会规划的更多的数据中心，在逻辑上可看作是一个数据中心。在数据中心的前置系统中，目前的清算和龙网均已消失，重要客户系统可能保留部分管理信息。某银行系统全国范围内实现通存通兑处理，总行的资金部门可实时理解各个分行的资金头寸的使用状况，实现实时的头寸管理和资金调度。省市分行的大前置机所连接的外挂系统有银联接口、电话银行、ATM/POS 等自助设备的前置机。

毕博建议的某银行的核心业务体系的架构，在以下几方面和某银行的DCC规划有所不同：
1）接口的处理方面
引发大量业务交易的接口，即终端驱动型接口、增值服务型接口，因为在目前的情况和实际应用中，由于要保证大前置的效率，所以需要的是快速反应，所以我们应该单独从专有技术例如TP Monitor来实现。其他的接口，即外联交换型接口、中间/特色业务型接口、全国性业务接口，强调的接口的公用性和集成性，应该挂接在总分行的信息总线上。
2）对公业务：
对公业务的操作流程，如信贷的审批、拟定、放款、管理和不良贷款的清收；票据业务的处理流程等，不在核心业务系统体系中实现