银行科技架构（全）

他，40余载银行IT路，风雨兼程，踏歌而行；

他，是中国银行业IT发展史的亲历者和见证人；

他，是“宇宙行”开发体系的设计师和建设者；

他，友朋遍四方，桃李满天下；

他，就是中国工商银行开发中心前总经理，梁礼方。

蒙梁老准允，优智汇独家开辟《金语梁言》专栏，我们将以各种形式发表梁老对中国金融IT业的思考与见解，并接受广大“梁（凉）粉”的提问，梁老将抽取其中具有代表性的问题，在专栏中答疑解惑。我们期待，《金语梁言》对于转型中的中国金融IT业具有启示和借鉴作用。

上期回顾

上期文章首先探讨了什么是核心竞争力，核心竞争力为什么重要，然后再进一步探讨了银行的核心竞争力是什么，银行科技的核心竞争力又是什么，最后对如何建立和提升科技的核心竞争力给出了建议。

点击阅读《银行科技的核心竞争力》

  目 录  

一、战略架构

（一）科技战略目标

（二）科技定位

（三）科技资源配备

（四）科技资源配置

（五）科技管理

二、业务架构

（一）客户与产品

（二）信息系统的运维模式

（三）信息系统研发模式

（四）测试模式

三、组织架构

（一）顶层架构

（二）科技本体架构

（三）科技部门与业务部门的关系

四、信息系统架构与基础设施架构

五、科技架构存在的

  正 文  

一个理想的银行科技架构是银行科技核心竞争力的首要条件，也是一个最重要的组成部分。

银行的科技架构是银行企业级架构的一部分，是银行企业级架构的一个维度视图。一般认为，银行的科技架构可以分为五个层次：

图1 科技架构

这五层科技架构又可以分为两部分。上三层是顶层架构，关系到银行本身的战略、业务、组织等，构建决策主要来自银行领导层而非科技本身；下两层与科技的信息系统和基础设施相关，在这一部分，科技可以发挥更多的主导作用。在五层架构里，上层架构的具体构建对下层架构的构建通常有决定性的作用。

前面说到，科技架构是科技核心竞争力的一个重要组成部分。那么，科技架构与科技核心竞争力的直接关系又是怎么体现的呢？

图 2 科技架构与科技核心竞争力

如上图所示，科技的核心竞争力包括科技架构、科技团队、信息系统、基础设施、企业文化五个要素（科技架构为架构全部，不单独对应某一层）。这五个要素是否有一个好的架构，直接决定这几方面是否能形成核心竞争力。

下面，我们对这五层架构进行更深一步的探讨。

一、战略架构

银行科技的战略架构是银行战略架构的一部分，科技战略为银行战略服务。科技战略不仅体现了银行科技的战略目标、定位、和实现目标的路线图，还包括为实现科技战略的资源：如资金资源、人力资源的配备与配置，及科技管理体系等。银行科技战略架构的制定，为银行科技所有的下层架构规范了方向。

（一） 科技战略目标

科技的战略目标是银行战略目标的一部分，是围绕银行战略目标、为银行战略目标的实现提供支持的科技愿景。许多银行会因此提出“科技兴行”、“科技是第一生产力”、“科技引领”等战略口号，来表达自己对科技的重视。

要实现科技的愿景，除了有明确的战略目标外，更重要的是体现战略目标的措施，包括：科技定位、科技资源配备、科技资源配置和科技管理。

（二） 科技定位

科技定位指的是，在银行诸多业务与机构中，科技的战略位置，包括：科技机构的数量，级别与等级，科技人员的级别、等级、职称、薪酬、福利与各种待遇，职业生涯发展空间，自我实现的工作环境等。

例如，一些银行实行了全行统一的机构等级与行员等级的人力资源制度，对于各级机构，都按照其重要性、贡献度等来为他们定义一个等级。不同等级对应不同的分配。那么，某个银行的某个科技机构定位为1等和3等，银行认同其重要性与贡献度肯定会不一样。另外，机构数量和内部各种编制数，如科技辖下的部门数、各级职数，不同数量有着不同的意义。例如，某银行总行的科技部门有一部三中心：一个科技部、两个数据中心、一个开发中心，四个机构均为总行的一级部，并定位为总行一线部门，等级为一级。而另外一家银行的总行只有一个科技部，在科技部内部再分运营和开发两个子部门，分别负责运营和开发；且该科技部门被定位为保障部门。相比而言可以看出，两个银行对科技的重视程度是不一样的。

而在已经实行行员制的银行，从最基层的行员到最高层的行领导，不同职务、不同岗位都会对应某个明确的行员等级。在同一等级内，还可能会根据岗位资历和历年考核，分为不同的级别。例如，职务可以分为行员、经理、高级经理、总经理等；岗位可以分为管理岗、专业岗、销售岗、运营岗等。其中，专业岗可以细分为：财会、人力资源、信贷、风险、科技等。对应科技岗位，还可以再细分为管理、研发、测试、运维等岗位。相同的职务、业务部门和科技部门对应的等级和级别是一样高、或业务稍高、或科技稍高，体现出银行认同的社会价值与重视程度的不同。

（三） 科技资源配备

科技资源的配备主要包括物质资源与人力资源。

物质资源关键是资金资源。有了充分的科技资金投入，就可以解决科技的场地、硬软件及服务的采购、科技运转费用、科技人力费用等。

另一项关键资源是科技人员的配备，包括人员的数量与质量。高素质科技人员越多，越能发挥科技对银行业务发展的保障与促进作用。

科技资源配备越高的银行，用在科技上的资金越多，科技人员的数量占比越大，说明该行对科技越重视，当然，对科技的期望会越高。反之，如果一个银行在科技资源配备上低于行业平均水平，无论如何也难以体现该银行对科技的重视。

1、科技资金

根据银监会相关数据，2016年底，中国银行业总资产约为232.3万亿，税后利润约为2.1万亿。在科技方面，银行业协会秘书长在公开讲话中提到，2016年我国主要银行业金融机构年度科技投入达到1135亿元。

平均而言，中国银行业的科技投入占其税后利润的5.4%。应说明的是，科技的资金投入除了用于科技采购外，还有大量的科技运营费用和科技人力资源费用。

上述占比只是一个平均值。实际上，一家银行合理的科技投入占比，与银行的规模有关。由于规模效应，尽管大型银行科技投入的绝对值高，但其投入占比反而会略低；而较小的银行，虽然其科技投入的绝对值低，但其投入占比反而需要略高。如图：

图 3  不同规模的银行IT采购占比

上述数字仅是国内银行业科技投入的相关数字，而与海外银行相比，中国银行业在银行科技设备、研发上的投入，其实是有较大差距的，从银行的成本收入比可见一斑：

图 4  主要国家银行业成本收入占比（%）

据相关资料统计，在2004年，中国银行业的成本收入比为63.9%，到2013年，这一数字降到了36.6%。而同期发达国家银行业的成本收入比均呈波动上升趋势，2013年都在60%以上。并且近几年，中国银行业的成本收入比还在下降。据银监会统计，2016年商业银行成本收入比约为28％；一些大型商业银行的成本收入比更是下降到25%左右，对比2004年，降幅超过50%。也就是说，国外银行每收入100块钱，成本在60块钱以上；而中国的商业银行每收入100块钱，只需要花30块钱。

当然，企业的盈利靠的是开源节流、增收节支，既要通过创新、增加营业收入也要节约减少开支。但节支要有一个合适的度，过低的成本收入比，往往表明为了赚钱，把该投入的都省下来，没有随着业务的发展而加大投入。这种方式的“节支”会造成企业发展后劲不足，“可持续发展”就变为一句空话。

2、   科技人力资源

中国银行业监督管理委员会在“中国银行业信息科技‘十三五’发展规划监管指导意见”中提到“要加大信息科技人力资源投入”——大中型银行信息科技人员占比应不低于4%，城市商业银行、具有独立系统的农村商业银行信息科技人员占比应不低于3.5%，省级农村信用联社信息科技人员占服务机构总人数比例不低于3%。

按照银行业协会秘书长在公开讲话中的信息， 2016年中国主要银行业金融机构信息科技人员约7.8万，科技人员占比2.28%，仍远低于银监会的要求。

上述数字只是一个平均数，一个银行科技人员的占比，与科技采购的投入占比一样，和银行规模有关。由于规模效应，大银行的IT人员绝对数高，但占比反而会略低；而较小的银行，尽管其IT人员绝对数低，但其人员占比反而应该略高。如图：

图 5  不同规模的银行IT人员占比

（四） 科技资源配置

除了科技资源的充分配备外，还要考虑资源如何配置。科技资源的配置有几个维度：一是总行、分行、支行与网点的区域分布维度；二是科技管理、科技研发、测试、系统运维等科技职能维度；还有硬件、软件、服务的投入方向维度等。

现实情况是，不管哪个银行配备了多少的科技研发人员，对该银行各个业务部门来说，总觉得科技研发仍然赶不上业务发展的需要，每个部门都希望能够抢到更多的研发资源为其服务。但据了解，没有哪一个银行配备了一个仲裁机构，去解决关于研发资源如何用在不同的业务条线上的配置问题。

通常的解决办法是，要么是爱哭的孩子多吃奶；要么是哪个部门取得某个领导的发话，说某个项目很重要，从而抢到研发资源。而理论上，既然大部分银行均认同科技资源属于战略资源，那么一个企业的战略资源的配备与配置应该由该企业的最高决策机构——董事会来决定。

总之，科技资源是一种有限的战略资源，只有根据各银行的战略目标，结合实际情况，通盘考虑、合理分配，才能达到资源效益的最大化。

（五） 科技管理

科技管理指的是银行对科技的管理体系。

银行科技部门的行级主管领导，一些银行是由副行长主管，一些银行是由CIO主管。还有部分银行由CIO与副行长双重领导。除此之外，银行还会通过一些行级的跨部门委员会，如科技治理委员会、科技管理委员会、新产品创新委员会等对科技进行宏观管理。

同时，银行对科技的管理还涉及银行相关职能部门，如人力资源部、财务部、内审、风险、采购、法律等管理部门。

二、业务架构

科技架构的第二层，是科技的业务架构。

通常，一个企业的业务架构，主要包括产品划分和定位、客户细分与定位、市场与销售策略，及业务流程、内控风险管理等。银行也大体如此，其业务架构是为了完成银行战略目标而制定的。

科技的业务架构与银行业务架构相关，又有其特点，其中最主要的内容是定位科技的客户、科技产品、产品研发方式、测试方式，信息系统运维模式等。

（一） 客户与产品

科技的客户和产品与银行的客户、产品有密切的关系，但概念不一样。

科技的服务对象除了银行客户外，还为一些与银行业务有关的第三方机构、监管机构服务；也为银行的内部管理、银行内部的各机构、员工提供相关科技信息服务；还为科技本身、如信息系统的开发和运维人员提供服务。简言之，科技的客户有三类：银行客户与相关机构、银行内部机构与员工、科技本身。

因此，对应不同用户的科技的产品也可以大致分为三类：银行客户产品、内部管理与办公产品、科技运营支撑产品。

（二） 信息系统的运维模式

在中国银行电子化的进程中，银行信息系统的发展经历了从分散到集中的过程，系统运维模式自然也从分散逐步变为集中。随着银行形态的多样化和信息技术的发展，银行目前的运维模式会面临新的选择。

规模比较小的银行需要考虑，是否还需要建自己独立的系统和独立的数据中心；中等规模的银行也许会建自己独立的系统和独立的数据中心，但在考虑灾备方案时，他们也要斟酌是否需要建立自己独立的灾备中心。

另外，银行也可以考虑把某些产品上云或被托管。当前一些公有云、公有平台，可以为银行提供一些金融业务托管，或金融产品货架。

（三） 信息系统研发模式

信息系统的研发模式关系到银行科技产品的生产方式。银行科技的核心竞争力，最重要的一个体现是银行的信息系统。选择合适的研发方式，关系到是否能以最理想的方式来建立银行的核心竞争力。

通常，不同规模的银行，信息系统的建设有以下几种模式：

• 完全自主规划与研发。

• 自主规划、关键组件自主研发、其他组件主导研发。

• 部分自主规划、部分主导研发。

• 基本外包。

自主研发与研发外包的含义是比较清晰的，主导研发的含义是：

• 自主定义应用系统的数据标准、接口标准、数据交换规范。

• 自主定义应用系统的架构。

• 对完全按需求定制的研发外包，要主导整个研发过程。包括系统设计、数据库设计、流程设计等。要担当项目经理，日后基本能主导所有系统维护工作。

• 对所有需要客户化的外购产品，参与整个客户化的过程。要掌握所有的参数设定技能，要掌握日后非底层功能的维护、修改技能。

• 在外包采购时，从原来的项目外包改为人力资源外包（俗称买人头）。由银行承担项目的成败责任，外包公司只负责外包人员的资质与人事管理。

不同的银行，由于规模不一样，可用于信息系统建设的资金与人力投入不一样，研发团队的能力不一样，选择信息系统的建设模式就会不一样。一般来说，大型商业银行，它们的资产在十万亿以上、利润在千亿以上，应该采用完全自主规划与研发的方式；大型的股份制银行，它们的资产在万亿以上、利润在百亿以上，应该采用自主规划、自主研发与主导研发相结合的方式；其他资产在数千亿、利润数十亿的中等规模银行，可以采取部分自主规划、部分主导研发为主的研发方式。关于信息系统研发模式的详细论述，可以见第二季文章《信息系统的建设模式》。

（四） 测试模式

作为一个完整的产品研发项目，宏观上有三大阶段：一是项目定义与概要设计，二是详细设计与编码，三是各阶段的测试。但在当前，许多中小银行，项目的集成测试、系统测试、用户验收测试都由业务部门或第三方测试公司去实施。

项目测试的重要性不言而喻。没有高质量的测试，就不可能有高质量的产品，从而不可能有安全可靠的运行。但是，由于业务部门没有专业与固定的测试人员，由业务部门牵头、组织并实施测试，会存在如下问题：

• 测试人员的质量不能保证。

• 测试人员数量不能保证。

• 测试知识、经验、案例的积累不能保证。

• 测试的综合管理与协调困难。

其结果，往往是测试的效果不能保证，从而项目的质量不能保证。所以，项目测试往往是中小银行在研发过程的一个痛点、软肋，如何选择合适的测试方式，涉及整个信息系统的质量与运行质量。

三、组织架构

银行的组织架构是为了满足业务架构的要求而制定的组织保障架构，组织架构最好能与业务架构、业务流程相适应。银行组织架构包括业务部门的组织架构和科技部门的组织架构。

科技的组织架构，一是指科技顶层架构；二是指各科技本体架构，包括各科技部门的设立、职能、与它们之间的关系架构；三是指各科技部门与业务部门的关系。

（一） 顶层架构

一个完善的科技顶层组织架构应该包含的主要内容，请参考前文《银行IT治理》，这里再略为重复论述一下：

1、CIO

根据银监会的精神，有条件的银行，应该设立CIO。关于CIO，前文已有论述，不再展开。

2、科技管理委员会

职能与前文所说的科技治理委员会有重叠，通常也可以合并为一个委员会。如果两个委员会同时存在，通常治理委员会对董事会负责，管理委员会对管理层负责。而治理与管理的区别在于制定规则与执行规则。

3、产品创新委员会

与上述两个委员会的职能也会有重叠，可以合并为一个或两个委员会。

产品创新委员会比较聚焦在产品创新方面的规划与决策，特别要协调解决业务部门的需求与相对稀缺的科技研发资源之间的矛盾关系。产品创新委员会在重大研发投入上，要评价业务需求的效益与可行性，从而评定项目研发的优先级。

4、   相关科技风险管控与审计部门

（略）。

科技的顶层组织架构如何设置，体现了银行顶层希望如何掌控银行科技的战略方向，协调科技与业务的关系，让科技在既定的投入下能为银行发挥最大的效益。

（二） 科技本体架构

科技本体架构指的是科技部门本身的组织架构，具体形式与科技业务架构有关。

银行科技部门的组织架构，垂直来看，主要有总行级的科技部门与分支行级的科技部门；从职能划分来看，有科技规划、科技管理、应用系统研发、测试、系统运行等。在分行，科技部门主要承担的是分行级的系统运维及一些局部的应用研发。

在总行，不同的银行，上述科技职能会归属到一个或几个部门内。部门间有的是平级关系，有的虽然是平级部门，但接受科技管理部门的业务管理。尽管总行科技组织架构不尽相同，但基本可分为两大类，在这里姑且将其定义为一体化架构与非一体化架构：

1、   一体化架构

一体化架构的科技体系表现为，由一个牵头的科技部门在业务上管理与协调整个银行的科技体系。在这种体系下，科技部门基本作为一个整体面向业务部门，做到统一规划、统一研发、统一运行管理。

2、   非一体化架构

这类科技体系表现为，各种科技职能归属在两个或以上的科技部门中。这些科技部门基本是同级平行运作的部门，彼此之间的关系由科技部门主管行长或CIO协调。

银行科技架构举例：

图 6  银行科技架构举例

不同的银行，应该根据自身条件采取合适的组织架构。规模较大的银行，分工可以细一点，机构可以多一点；规模不大的银行，组织架构可以精简一点。但无论如何，一体化的科技架构比非一体化的架构更利于科技管理。

（三） 科技部门与业务部门的关系

科技部门与业务部门的关系，主要体现在银行产品研发的组织架构上。

正如银行产品与科技产品的概念不同，银行产品研发与科技研发也是两个不同的概念。科技研发是产品研发的一个环节。银行相关产品管理部门把产品设计出来后，通过科技研发，产品得以通过计算机系统进行管理、销售，使客户能够通过计算机系统享受产品所提供的更安全和快捷的服务。所以，科技研发体系也是整个产品研发体系的一部分。

1、   国内银行传统研发架构

在国内，产品的创新和研发模式，一般都是由业务部门提出业务需求，科技部门按需求进行科技开发，然后投产、推广。产品研发架构和流程举例如下：

图 7   通常的产品研发架构与流程

①分行业务部门向总行业务主管部门提交需求申请；

②经研究与完善，总行业务主管部门向总行产品研发管理部门提需求申请；

③经审查整理，总行产品研发管理部门向总行科技项目主管部门提需求立项；

④经沟通评审，总行科技项目主管部门根据项目情况，向研发部门内的相关开发部门下任务书。

这种模式，在国内银行此前的电子化进程里为大多数银行采用，发挥着很大的作用。但是随着金融市场的快速发展和变化，金融产品创新速度不断加快，银行科技研发团队日益发展，计算机应用系统逐渐庞大，科技人员的分工越来越细，这种瀑布式的研发模式对当前的需求越来越不适应。

从以上流程可见，这样的架构和流程存在以下问题：

• 整个研发链条比较长，环节多。真正的需求部门是分行的产品部门，而他们离开发部门太远。

• 一般来说，编写需求的人员大多是业务骨干而不是专业的产品研发人员，他们资质一般，并不能满足编写高质量需求的要求；而反过来说，科技研发人员缺乏熟悉的业务知识，只能通过需求书来了解业务做法，一般较少从面向计算机应用上提出优化的业务实现建议，一些具体细致的处理方法往往用想当然的办法去实现，但这未必是业务真正需要的方法。

• 当前许多新的金融产品本身是金融创新，业务本身没形成一个定型且成熟的做法和流程，即使编写出一个需求，也不是一个稳定的、长远不变的需求。

• 由于上述原因，在项目的开发过程中，随着产品雏形的不断展现，业务人员会不断提出完善的需求变更。在项目越接近完成的时候，业务人员才越清楚他们真正需求的东西，并越清楚看出他们所期望的东西与研发现实的差距。这种情况，使得越接近研发后期，需求变更越多，甚至会出现颠覆性的变更要求，加深业务和科技的矛盾。

• 按需求研发产品的做法，本身要求有高质量的、稳定的需求。当需求不完善、理解不透彻、后期变更频繁时，研发的质量和效率就大打折扣。

• 需求部门与研发部门没有直接责任关系，研发过程沟通不畅，且需求部门对研发资源与研发成本不负责任。研发的结果，无论是研发工期、研发投入、研发质量、产品功能，往往都不容易达到需求部门的理想要求。

由于研发资源一般都达不到业务部门的理想需要，业务部门往往抱怨科技部门对该项目重视不足、投入不够。这个问题不仅出现在银行界、也不仅在国内，随着计算机应用向广度和深度发展，各行业均出现了此问题，所以才有业界对原来的开发模式（瀑布法）提出质疑，进而提出所谓的“原型法”和“敏捷法”。

关于什么是“原型法”和“敏捷法”，不是这里要陈述的，读者可以参考有关方面的资料。这里着重想说的是，对于银行而言，这两种新方法与传统方法的主要不同之处，体现在业务团队与科技团队的关系上。

• 新方法强调业务人员与科技人员在整个研发过程中的紧密结合，面对面沟通，共同完成整个研发阶段的各项工作，共同对研发成果负责。

  而传统方法由业务人员编制需求、完成验收，由科技人员完成研发，相互之间基本通过文档沟通。科技部门只对经确认的需求书负责，不对研发产品的实际使用效果负责。

• 新方法尽量把用户的需求分解成基本功能和增值功能，尽快先做出一个能运行的拥有基本功能的原型产品反馈用户，让用户能感知真实产品的内外特性，以便能更好地提出下一步完善与发展的设想，不断迭代推进新版本。

  而传统方法希望，已经确认的需求和方案是一个完善的、静态的方案，相当于需求方与研发方的一个合约。不希望在研发过程中、特别是后期出现变更。实在需要的变更最好能在另外一个需求里提出，通过另外的项目实现。

• 新方法的需求以基于场景的方法展现，把需求内容分解为一个个用户场景，具体展现每一个用户场景的I-P-O，即：输入（界面和内容）、处理（流程和内容）、输出（界面和内容），及描述每个场景的前提和限制。

  而传统方法的需求一般通过文字描述，往往不够规范、具体、详细。

传统研发流程举例如下：

图 8  传统产品研发模式

新的研发流程举例如下：

 图 9  新的产品研发模式

在上述三点里，其中第一点说的就是强调业务人员与科技人员的紧密结合。

2、   理想的产品研发架构

参照国外银行的案例，在研发架构上，多数采用业务研发人员与科技研发人员紧耦合的方式，这种方式也与现代的敏捷开发方式相适应。理想的研发架构举例如下：

图 10  理想的研发架构举例

这种架构的特点是：

• 对科技研发部门的研发架构和业务部门的产品研发架构作了相应整合，其他部门架构基本不变。这样可以尽量减小对现有体制的冲击。

• 科技的产品研发部门交与业务的产品管理部门，与原来业务产品研发人员整合在一起，业务产品研发与科技研发从原来的甲、乙方关系变为一家人。科技产品研发在技术上对科技部门负责，在业务上对产品管理部门负责。

• 科技研发部门内原来的职能部门（架构设计、项目管理、推广支持等）与基础架构开发部门（渠道及整合、服务交付与流程控制、业务支撑、技术支撑）仍然由科技研发部门统一管理。

这种架构的优点是：

• 业务产品研发与科技产品研发完全整合，处在研发链条的前端，能对一线的需求作出快速响应。面对面的沟通代替了文档的交接，业务与科技共同承担产品开发的责任及其成败。

• 科技研发的投入完全向业务部门透明，业务部门对产品研发的成本与效益负更大的责任，不仅有利于更充分使用相对稀缺的科技研发资源，而且也有利于产品研发团队的成长和发展。

• 科技研发部门内非产品研发部门全留在科技研发部门内，可以保证整个系统应用架构的完整性和各种标准、规范的统一性。

• 银行产品研发的链条比传统的研发架构大幅减少，由原来的4步减少到1步。

• 当某条产品线的科技研发人力资源显得不足时，该产品线的业务部门会主动向行里要资源，减轻科技要求增加资源的压力。

二、信息系统架构与基础设施架构

科技架构的两层底层架构，是信息系统架构与基础设施架构。

信息系统架构通常简称为系统架构，包括应用架构、数据架构、流程架构、技术架构等。系统架构是银行信息系统为了满足银行的经营、管理目标而建立的信息系统体系架构，与科技架构的业务架构、组织架构相关。

基础设施架构指的是：为了信息系统能安全、高效运行所需要的一系列软、硬件设施架构。软件指的是系统软件，如操作系统、数据库、系统平台等；硬件包括各种计算机和网络通信设备等设施。广义的基础设施还包括计算机系统的运行环境，如园区、机房、办公室及配套的“风、火、水、电”等。

信息系统架构与基础设施架构的内容非常之多，专栏已用专门的文章进行单独探讨，见第一季《信息系统架构》、《应用架构》、《程序架构》、《数据架构》、《技术架构》、《流程架构》、《基础设施架构》。

三、科技架构存在的问题

如上所述，理想的架构通常是上层架构决定下层架构、下层架构要满足上层架构的要求，基于上层架构而构建。但在现实中，对于某个银行来说，其科技架构也许并不理想，未能充分发挥科技的作用。其主要原因可以从以下几个方面来思考：

从战略架构层面来看，银行最高层领导是否已形成清晰的科技定位与发展战略，该科技的发展战略是否符合与满足银行战略目标的需要；银行对科技的期望与投入是否匹配；科技资源的配备和配置、资金、人力投入是否充足与恰当。

从业务架构层面，银行的业务架构是否与时俱进、适应形势发展的，是否有利于战略目标的实现和银行信息化的实现；科技的研发模式与运维模式与银行业务的需要是否吻合。

与时俱进的业务架构，如果没有相应的组织架构作为保障，也不容易落实。而组织架构的变动会涉及许多人员的安排，涉及许多权力、利益的再分配——这是一个非常敏感的问题。基于历史的原因和人事关系，银行虽然意识到应该进行相应的组织变更，但还是不容易做到或者不能彻底做到。

科技与业务部门的关系，有一个发展和认识的过程。当前银行业务与科技的组织架构，是否理顺了业务与科技的关系，使业务部门与科技部门能紧密合作，相互促进；是否理顺了科技内部的科技规划、科技管理、系统研发、测试、运行、维护的关系，使各方面各司其职、相互配合，使整个科技整体高效运行。由于科技技术本身发展很快，以前认为不能实现的东西，随着技术的发展成为可能。例如数据中心的大集中，以前是一个高风险的决策，但现在，中国在这方面已经走在世界前面。而运维模式的变化，往往带来管理、研发和运维的集中，带来科技组织架构的变化。

银行的信息系统架构也一直在不断的发展和完善。随着技术的发展，人们对应用架构的看法也在不断变化。理想的应用架构模型一直在变化和完善，是一个终极追求的目标。

基础设施架构一方面随着应用架构的变化而变化、随着技术的发展而发展。但另一方面，基础设施架构还有一个投入与产出的权衡问题，而权衡本身，是一个比较主观的决策。所以理想的基础设施架构也是一个不断变化和完善、终极追求的目标。

总之，在现实上，与科技相关的这五层架构，一般未能完全做到上下匹配、相互适应。最终的结果是，支撑银行对外业务与内部管理的信息系统不能完全弥补科技架构的各种缺陷、对银行经营管理支撑不力，降低了银行相关领导与部门对科技的满意度。

作者：梁礼方，编辑：天羽。