银行信息系统架构设计框架，助您顺利实现IT技术架构

典型的IT技术架构设计框架如图5-3所示。在架构设计时，有两类输入：第一类输入是系统需求；第二类输入是系统约束。

图5-3 典型IT技术架构设计框架

系统需求包括以下内容：

1）系统需要做什么？也就是系统要实现的功能，例如，客户通过ATM取款或者通过网银转账等。一般通过用例（Use Case）模型来表达。

2）与其他系统的关系？也就是定义系统的边界，包括与其他系统交换的信息及接口方式。一般通过系统关联图（System Context Diagram）来描述。

3）质量要求如何？也就是系统的非功能性需求（例如，性能、可用性、安全性及可管理性等），一般通过系统的非功能性需求说明书来定义。

系统约束包括以下内容：

1）当前的IT环境，包括系统的软硬件平台、开发人员和工具等，以便架构能够比较容易落地。(www.xing528.com)

2）其他约束，例如企业的标准，包括开发及运行环境基础软件（数据库、中间件等）的标准、系统的分类标准等。

3）是否有最佳实践？也就是否有参考架构可以借鉴。例如，IBM的eBRA（e-Bus-iness Referance Architecture）就是一个非常好的面向互联网系统的参考架构。一般说来，首先会寻找类似的参考架构，并且在其基础上根据银行的具体业务和应用需求进行相应的裁剪。

以两类输入为基础，架构设计分为两个主要方向：

（1）组件模型（Component Modeling） 组件模型是描述系统功能性需求的主要文档。包括系统的高阶架构，组件的责任、边界、相互关系以及组件之间的交互等。组件模型是应用架构及数据架构设计的主要内容，在此不再赘述。

（2）操作模型（Operational Modeling） 操作模型是技术架构设计的主要内容，它定义所需的软硬件平台（服务器、存储、网络及基础软件）以承载应用架构设计所包含的组件，确保系统满足服务水平的要求（性能、可用性、安全性等），并为技术架构的详细设计提供蓝图。

操作模型的初级阶段是以整体技术架构如何合理工作为目标，到达详细设计时，将会以如何配置、如何运营管理为目标。因此，一个详细的技术架构设计完成后，以服务器、存储、网络和基础软件为基础，应该包括监控、系统管理、服务水平级别、容量规划、软件和数据的分布、可用性和性能分析、资源采购、产品选型以及相应的组织机构及职责分工配合。一系列结果的输出才是一个完整的操作模型的阶段的成果。

成功的技术架构设计，必须理解和平衡系统需求和系统约束两者之间的关系。需求和约束是管理系统范围、质量以及客户期望的基础，它们也是验证测试活动的基线。需求和约束直接影响了架构设计，如组件的结构和布置决策、解决方案的容量估计和成本，以及产品的选择、部署和配置框架。

该方法早期主要面向某一个大型项目或者项目群来使用，其应用架构与技术架构存在一定的紧耦合关系。按照云数据中心的思想，技术架构与应用架构应该实现松耦合，但是该方法对技术架构的设计仍然适用，只不过需要从整个银行的视角来进行分析和架构设计。我国银行业是一个受到监管的行业，不同的银行其产品服务与监管要求是类似的，导致银行的应用架构存在一定的相似性；但每个银行的IT环境与企业标准可能不尽相同，难以统一规范。从架构设计的角度来看，尽管具体指标有所差别，但银行的非功能性需求具有一定的通用性。非功能性需求是技术架构设计的基础及考虑的重点。