银行信息系统架构:战略解读与差距分析

在应用架构规划的战略解读与差距分析阶段，业务战略和业务架构、IT战略、领先的架构实践与新技术以及现状系统的问题和差距是架构规划的重点分析内容。

1.业务战略解读和业务架构分析

（1）业务战略 本书2.3节总体规划方法已对业务战略进行了描述。业务战略是应用架构最为重要的方向性输入。应用架构的终极目标是要支撑业务战略的实现。在规划的过程中，需要对业务战略进行解读，分析业务战略对信息化的需求，转化为架构设计的要求，这些要求要在架构设计过程中体现。这个过程需要借助一些工具对战略进行结构化描述和分析。业务战略通常需要有业务方向、战略能力等方面的内容。业务方向至少包括企业的使命、愿景、战略目标是什么，这些是企业要往哪里去的问题。战略能力需要包括企业如何才到达业务方向定的方向的核心能力。

基于企业能力的分析是在IT规划中常用战略分析手段，可以采用组件化业务模型（CBM：Component Business Model）、战略能力网络（SCN：Strategic Capabilities Net-work）等。组件化业务模型CBM是一个常用的面向战略和运营层面的规划与分析方法，它从能力角度对支撑业务战略的业务能力进行识别、分析和差异化描述，从中识别信息化的需求。组件化业务模型CBM既可以是业务战略的一部分，也可以是业务架构的一部分，它的应用场景横跨了从业务战略到业务架构，将在下文业务架构对组件化业务模型进行描述。

（2）业务架构 业务架构（BA：Business Architecture）从架构角度来看，是整个企业架构的重要组成部分，它对上支撑了业务战略的实现，对下为应用架构和数据架构提供输入，指导应用和数据架构的实现，是应用架构规划过程中最为重要的业务上的输入。

从业务角度来说，业务架构描述的是一个企业的运营模式，是企业战略转化为日常运营的机制。业务架构定义了企业如何创造价值以及企业内外部的协作关系，描述了企业如何满足客户的需求，进行市场竞争，与合作伙伴合作，建立运营体系，考核绩效等。

业务架构是基于战略决定企业各组成部分如何运转的工具，建立了企业战略与日常运营之间的关联关系。宏观层面的企业战略需要通过业务架构来进行分解，从战略范畴落实到战术范畴。日常运作的组织、流程、IT系统都应该是在业务架构指导下运转的。如果没有业务架构而直接组织和建立企业的日常运营，就会出现运营与战略的脱节，各个业务环节缺乏统一协调等问题。

事实上，企业都存在着业务架构，好的业务架构会显著提高企业的效率和竞争能力，使企业避免产生很多管理方面的问题。

关于业务架构的内涵与外延，业界目前没有统一的定义，如业务架构常见的组件图（见图3-7）是对业务架构包含的组件的描述，代表了一种对业务架构的观点。下文将围绕其中的业务组件和业务流程两个方面进行描述，他们都是从不同的视角对业务的描述。根据前文的规划方法，业务组件的分析或者业务流程的分析和重组，是应用架构规划的重要输入，能够有效地指导应用架构的规划。如图3-7所示。

（3）业务组件与业务能力 业务组件就是企业的业务模块和业务能力。在企业架构中，通过业务组件化把企业的产品、销售、采购、生产、财务等业务功能转变为业务模块，具体的方法被称为“组件化业务模型”，简称为CBM（Component Business Model），CBM通过企业功能组件化的方式对企业进行重新定义和组合的过程，在一张图上就可以直观地显示出企业的业务蓝图；CBM不仅仅是对企业高层次的描述，而是一个内容丰富的业务模型设计工具，它采用了一种全新的视角—组件化的方式对企业进行分析和设计。

图3-7 业务架构常见的组件

每个业务组件，即每个业务能力包含五个维度，如图3-8所示。

1）组件业务用途是它在组织内部存在的目的，表现为该组件向其他组件提供的价值。

2）为了实现业务用途，每个组件要执行一系列相互独立的活动。

3）组件需要各种资源，如人员、知识和资产等来支持这些活动。

4）每个组件都根据自己的管控模式，以相对独立的实体方式进行管理。

5）像单独一个企业一样，每个业务组件都可以提供和接受业务服务。

图3-8 业务组件包含的内容

业务组件具有如下的特点：

1）业务组件是独立的业务模块，在企业系统中承担特定的职责。组件可以由企业自己完成，或者由合作伙伴完成，企业组件化的过程也是内部和外部专业化的过程，企业可以通过组件化建立价值网络，重复利用外部资源来提升自己的竞争力。

2）组件内部各个活动之间是紧密关联的，而与外部其他组件的关联程度较低，所以组件是可以独立运作的，这使专业化分工和外包成为可能。

3）每个业务组件的输入和输出都高度标准化。组件不能够直接使用其他组件内部的活动或者资源，只能根据组件之间的标准接口提出服务请求，从而获得所需的服务。

4）组件一般都拥有自己的资源，它们在完成特定的有价值的活动中会消耗这些资源，也存在没有资源的组件，它们只能通过调用其他组件资源的方式来实现自己的功能。

举例来说，银行可将自己的信用决策活动集中起来，形成一个独立组件。为获得规模效益，可以将过去分散在各个业务单元的相关员工、流程和资产集中在一起，还可以整合银行的财务数据库，以提高决策活动所需信息的质量。集中保存信息帮助信用评估人员在评估各个账户之间的各种信息后，做出更好的选择（比如在客户申请信用卡时）。基于对客户的信用风险情况的更清楚的了解，银行可以更有效地实现金融产品的交叉销售。(www.xing528.com)

要最大程度发挥组件的优点，银行需要汇总企业内部具有高度凝聚力的活动，也就是具有需要类似员工、流程和技术活动。比如以前银行有五个不同的小组来处理信用评分，而简化后的新的信用管理组件则可以管理所有潜在的顾客信贷活动，如管理申请流程、配置信贷资源以及信贷政策合规性管理等。信用管理组件具备自身的管理结构和管控模式，从而具有高度的自主性。原则上，它能作为单独的业务向本公司提供服务，必要时它还能为其他公司提供服务。在运行过程，新组件具有高度的协作性。它与公司内外部的其他组件协调工作。协作过程是通过组件间的输入、输出服务进行的。在需要输入服务已完成特定活动时，信用管理组件会从其他组件获得该服务输入（如客户信息和账户恢复等）。反过来，在信用评估、信用报告等其他业务组件需要时，信用管理组件就会向其他业务组件提供服务输出。预先定义的服务水平协议会规范所有这些交易的标准（如输入与输出格式、时间、数量、质量、支付和备份等）。通过这种服务导向的方式，信用管理组件既可以明确自身的业务边界，同时又可以通过松散耦合方式与其他业务组件进行协作。在业务环境发生变化时，每个组件能够轻松断开旧的链接，形成新的链接。

从企业层面来看，公司内部存在多个业务组件。组件化业务模型CBM可按照业务能力和责任级别两个基本维度对组件进行组织，如图3-9所示。

图3-9 组件化业务模型图

纵向维度按照业务能力划分各种活动形成组件。横向维度为每个活动指定一个责任级别，即引导、控制和执行。引导级别的组件应该为其他组件提供战略方向和公司策略，此外，他们还应该促进组件间的配合。控制级的中层组件在引导级别和执行级别的组件发挥相互制衡的作用。他们监控业绩、管理例外情况并发挥看管资产和信息的作用。执行层的组件所提供的业务行动可促进企业的价值实现。他们处理各种资产和信息，供其他组件或者最终客户使用。

在银行应用架构规划过程中，借助CBM的方法，银行可以先进行业务组件框架的规划，在这基础上细化成为银行自身的业务能力框架。同时针对每大类业务能力分析和识别对信息化的具体要求，这些要求可以直接转换成应用架构的设计约束和要求，如图3-10所示。

举例来说，在银行业务能力框架中有客户与营销管理能力组，如果要提升客户管理的相关能力，对信息化的总体要求可以分解到表3-1所示的具体内容，这些是战略和业务架构对应用架构的具体要求。

图3-10 银行业务能力框架（示例）

表3-1 银行业务能力信息化需求分析（示例）

同时借助CBM的方法，可以分析银行的现状系统对每个业务组件的支撑程度如何，可以作为现状系统问题和差距分析的一种有效手段。

（4）业务流程 业务流程与业务活动是看待业务的第二个重要视角，也是业务架构常见的组件之一。与业务组件和业务能力方法不同，对业务流程的建模、分析和重组是另外一种截然不同的描述业务的方法。这种方法的使用往往需要业务上先进行相关的优化，优化后的结果作为输入，提供给应用架构进行规划。

业务流程建模与分析主要在业务运作层面，也可以在战略层面发挥价值。通常业务流程建模的主要目的是要尽可能准确地识别企业运营所需要的所有业务活动，并明确它们之间的关联关系，进而形成业务流程模型，支持跨部门与部门内的业务改进。业务活动是业务流程的重要组成部分，也是业务流程建模的主要成果。业务活动客观存在于业务环节中，必须有一个明确的业务目标和产出物，并需要创造价值。

流程模型是基于价值链、以标准化语言对业务流程的一种结构化、规范化的描述，它包括流程结构、流程信息和流程视图三个部分。流程结构从流程节点和流程与流程关系两个维度描述了从价值链到操作步骤的层次结构。流程信息定义了如何对一个流程进行完整的定义，包括流程定义、流程描述、输入/输出信息归属部门、流程与流程关系等内容。流程视图主要定义了用户视图（业务视图）、企业级视图（技术视图）。

有了流程模型，可以实现从企业级视角对用户流程进行跨部门整合，从而在全行范围内可以共享领先实践的流程；同时基于建模的流程设计应用蓝图，有利于识别组件化共享服务，指导系统建设；通过挂接业务需求和数据需求，发现需新增的业务活动，完善目标业务架构，明确转型举措。

2.IT战略解读与分析

根据银行应用架构规划的实践，并不是所有的银行都有清晰定义的IT战略，明确IT在银行中的定位、与业务之间的关系以及明确的战略目标等。应用架构的规划目标是要支持信息技术战略的实现，并且要符合信息化的原则，架构规划是从业务、数据、应用、技术等几个方面进行描述未来该如何做才能实现信息技术战略。

3.现状系统问题和差距分析

现状系统的问题和差距是应用架构设计的另外一个重要输入，也是现状分析阶段的重要输出。

在现状分析阶段，应用架构设计人员会通过文件、资料阅读，各主要业务部门以及科技部门访谈的形式获得对现状系统问题和差距的全面了解，并进行分析。这个过程中，应用架构设计人员至少需要获得如下的信息和材料：

（1）银行系统清单 系统清单应该能够回答银行现状有多少系统？这些系统的功能与定位如何？主要用户和使用状况如何？管理了哪些数据？系统之间的集成关系如何？系统的实现技术、方式等相关细节信息。

（2）系统对业务支撑情况 系统当前对所在业务领域支撑的情况如何？功能覆盖如何？是否存在多个系统功能重叠的情况或者功能缺失的情况？业务部门对系统支撑情况的反馈意见如何？科技部门对系统支撑情况的意见如何？

（3）系统存在的问题 业务部门对系统支撑有什么意见？有什么问题？系统当前存在的技术方面的问题是什么？科技部门对系统存在问题的意见和建议是什么？

（4）系统现状与业务期望的差距 业务部门对系统进一步的期望是什么？差距在哪里？通过CBM或者流程模型等方法进行系统业务支撑分析来看，当前的差距在哪里？与领先的架构实践比较，系统支撑的差距在哪里？对IT战略支撑的差距在哪里？