银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持,需具体

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持,需具体相关的知识,希望对你有一定的参考价值。

参考技术A 在整合过程中,建设核心业务系统成为一个新热点。此时,国内银行建设核心业务系统面临两种选择:一是自主开发,二是整体引进。承载着打造“后发优势”及快速与国际接轨的梦想与希望,国内一些银行纷纷走上整体引进之路。 然而,在具体实施过程中,“引进一套国外系统,复制一家一流银行”似乎只是一种理想化的设想。实施国外核心业务系统项目后,国内银行往往投入大量资源,花费大量时间,项目实施计划一改再改,上线时间一推再推,系统却还是不能投入生产。有些银行经过一到两年的探索和尝试,最终还是放弃了国外产品,掉过头来转向国内IT厂商提供的软件。 将国外系统移植到我国银行现有的生产关系环境中,“空气、阳光、土壤、水份”等都大为不同,如果系统的灵活性和适应性不强,结出的果子自然亦非当初所设想的样子。是南橘北枳,中国的银行完全不适于采用国外的系统?或仅仅是水土不服,只要经过本地化、客户化的改造后,国外系统还是能发挥其应有的效应?业内外人士都在密切关注———国外银行核心业务系统在中国实施本地化和客户化的难点究竟在哪里? 引进国外银行核心业务系统产品,购买只是简单的第一步,如果不经过大量的本地化和客户化工作,系统根本无法发挥其功效。不同类型的国外软件在本地化和客户化过程中会遇到不同的问题。纯技术类软件主要面临技术问题,管理类软件除了技术问题外,更大的困难是文化、体制的差异。整体引进国外银行核心业务系统,虽然遇到很多技术问题,但根本原因还是在于国内外监管环境和体制流程方面的巨大差异。 国外核心业务系统本地化和客户化是一项复杂的系统工程 很多人存在这样一个认识误区,认为软件本地化就是软件翻译,软件客户化就是按照客户需求加以修改。实际上,软件本地化是将一个软件产品按特定国家、地区或语言市场的需要进行加工,使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动;软件客户化是指在分析用户需求与产品差异的基础上,在满足客户需求和保证系统结构稳定的前提下,对软件进行的一系列开发、测试活动。因此,国外软件本地化是一项复杂的系统工程,不是一个简单的从外语到中文的翻译过程;客户化也不单单是按照客户需求去修改系统,否则就失去了购买成型产品的意义。 国外银行核心业务系统在中国的本地化,主要包括本地化界面、国内环境接口、本地化报表、本地化文档及培训等方面。界面本地化包括:语言的汉化,将系统界面中的画面、菜单、操作符、提示信息等要素用中文进行表示;界面的易使用性,针对国外产品操作界面与国内风格的不同,通过适当修改、简化或进一步细化成一个容易使用的操作界面;用户操作习惯的满足,根据用户在旧系统上形成的较好的操作习惯,实现系统对应内容的差异最小化。 与国内外环境的接口:包括人民银行现化支付系统、中央国债登记结算公司接口、上海证券登记结算公司接口、外管局国际收支申报系统、人民币大额和可疑支付交易监测系统、人民币交易系统、结售汇系统、进口品报关单检查和进口单位名录系统、各种本地数据交换信息接口等。 本地化报表:国外核心业务系统报表功能高度参数化,因此报表本地化与报表的具体形式关联性并不十分紧密,工作量主要集中在内部数据的采集。 本地化文档及培训:本地化文档包括用户手册,操作手册、技术手册等;本地化培训,包括详细客户培训、详细设计培训、技术标准培训等。 国外银行核心业务系统在中国的客户化,主要包括需求差异分析、与内部系统的对接、第三方提供功能的集成等三个方面。需求差异分析是以国内银行现有业务或预期目标为基础,对照国外金融IT产品进行功能性分析,找出差异以及应对策略的过程;与银行内部系统对接要分析清楚现有系统与即将开发的新系统之间的详细关联关系,保证新旧系统平稳衔接;第三方提供功能的集成,是指在保证第三方提供的系统运行正常的基础之上,考虑与核心系统进行集成。这一般是由国外厂商在当地IT公司中选中的一家总集成商来完成。 国内外银行监管环境的巨大差异增加本地化难度 国外银行核心业务系统模块多、规模大,业务范围涵盖银行业务的方方面面,其本地化和客户化过程对任何国家的任何银行而言,都不亚于一场革命。把它放到我国银行的背景环境之中,矛盾就会更加突出。我国金融市场化程度不高,监管框架、相关法规制度与国际标准还存在较大差异,银行治理结构的缺损、内部经营管理体制的僵化,操作方式落后,这些都加大了核心业务系统本地化和客户化的工作量。 监管环境和相关法规是硬约束,为适应国内的财会准则以及人民银行、银监会等监管机构的监管要求,国外的核心业务系统必须做出适当修改。此类差异主要体现在以下几方面: 国内外利率管制程度不同,系统在国内本地化和客户化时,某种程度上要牺牲系统的先进性。在国外核心业务系统中,利率就象一个魔方,其多维、立体的参数设置和组合,在打通银行及相关混业领域、联贯各产品方面发挥着灵活的作用。 在国外发达的金融市场环境中,利率作为最核心、最重要的交易要素主要体现在价格功能。国内现阶段金融市场尚未完全放开,利率很大程度上是金融监管当局的管理工具。按照人民银行的利率管理办法,对于各种类型的存款或贷款,利率要求都不尽一致,特别是针对部分种类的存款和贷款更有特殊的规定。国内监管部门利率规定繁多,利息计算方法复杂,因此产生很多差异。这些差异应该按监管规定进行修改,但考虑到修改量太大会影响其稳定性,需要采取折衷作法。 国内外对外汇管制程度的不同,造成核心业务系统本地化和客户化时,系统修改的难度和工作量加大。在外汇管制的背景下,结售汇是我国监管框架下的特殊业务。根据外汇局外汇管理的有关规定,每笔结售汇业务都涉及到:对客户是否在其“名录”中进行真实性的审核;需要对其贸易必备条件进行逐笔、逐级进行审批;还要进行询价、头寸申报、买卖外汇、结算、售汇报表等。国外由于外汇自由兑换,没有哪个模块有类似功能。如果走定制开发模式,可以考虑单独设置结售汇模块。但对国外核心业务系统而言,修改需求介于操作与报表之间,开发起来有一定难度。另外,根据外汇局要求,结售汇报表、大额可疑报表、经常账户报表要直接从业务系统中生成并报送,类似需求对国外系统的改动也很大。 国外系统要与国内支付系统直联,需要对整个模块做彻底的修改。为实现资金清算的STP(直通式处理),核心业务系统应与现代化支付系统相连接。由于国外系统没有通过国内大额支付系统汇划处理业务的界面,需要按照人行的《中国现代化支付系统与商业银行行内系统接口方案》中规定的报文格式要求,包括支付报文、非支付报文、对账报文等,对系统做大量的改动和测试工作。从稳妥角度考虑,国内银行在建设核心业务系统过程中,一期可以先实现交易驱动账务核算,待系统稳定后再推进清算的直联工作。 国内外会计管理理念和制度的差异,需要重新构架会计体制,实现会计管理的全面转型。国外核心业务系统的会计核算功能,靠交易驱动来实现系统自动化处理。这既是国外系统直通式处理和参数化灵活配置的优势体现,也是实施过程的难点所在。会计核算不仅要跨越管理理念的差距,而且要把大量的制度创新和方案设计的工作想在前头和做在前头。具体来说,就是对所有业务模块驱动会计核算的核算结果通过制度规范想在前面,对上万个会计参数通过严格的确认和配置做在前面,否则会直接影响系统自动化输出的会计核算的结果。这既要求业务归口部门及早改变传统的会计管理模式,又要组织起银行内部技术资源,扎扎实实地做好系统上线前后的各项准备工作。如果会计核算结果的准确性、效率性及安全性缺乏保障或受到置疑,就会动摇整个核心业务系统的根基。 考虑到国内金融改革与银行开放的速度和进程,对上述重大差异要有前瞻性的态度和解决方案。对于接近国际标准、具备中国特色、预计不会成为改革对象、当前必须遵守的法律、法规,要认真对待,研究解决方案。对于事过境迁、含义模糊、明显属于过渡安排、不涉及法律诉讼的制度和规定,可以不予考虑或暂时放一放。另外,在解决方案的方式方法上,要优先考虑适当变通,尽可能地少改产品。按照这样的大原则,才能把修改系统的工作量降到最低。 国内外银行管理体制流程的巨大差异增加客户化复杂度 此外,国内银行经过多年改革与发展也形成了自己独特的管理体制和操作流程。这些管理体制和操作习惯中,大部分来自于经验积累和成绩总结,也有一部分属于不规范的范畴,与国外同业相比存在着一定的差异。有些差异我们已经司空见惯,甚至变成了日常管理操作的一部分。引进国外核心业务系统,要从多个角度思考对这些差异的系统处理方案。 内部核算、清算体制的差异。与国内银行实行的总分行多级核算体制不同,国外银行一般实行一级核算体系,对总分行清算资金往来系统只设一个过渡账户--总分行往来,总分行共用该账户,相互占用资金不计息。因此,国外核心业务系统中没有系统内资金清算功能,总分行不能对开清算资金往来账户。按国内银行的资金管理体制,分行作为一级经营单位,与总行资金往来需要相互计算利息。因而需要开立清算资金账户,用于系统内资金往来。 虽然目前以“集中”和“集权”为主要特征的改革已经成为国内银行的趋势,但这种权利上收和层次减少还限于支行层权力及核算单位的取消,效果尚不十分明显。由于账务层次过多,一些分行内部账交易的数量甚至超过了往来账户,潜在风险加大。不仅占用大量计算机资源,造成系统处理速度慢,批量处理时间长,月终、年终处理压力大,而且也增加了国外核心业务系统本地化和客户化的工作量。 资金管理体制的差异。国外银行由于实行总行一级核算,分行被看作总行的营销前台,客户是银行共同的资源,因此,贷款发放可以简化为银行与客户之间的借贷关系。银行向客户发放贷款属于财务会计核算范畴,由核心业务系统处理;总分行之间的资金占用和利益分配,属于银行内部利益再分配范畴,可以通过外挂的管理会计模块进行核算。而国内银行核算层次多,系统内各层次之间资金关系复杂。有些银行为了加强系统内资金管理,实行了系统内借款的作法。具体执行中要求贷款的发放、回收、计息等均与总、分行间的系统内借款处理绑定关联。此类需求若要在核心业务系统中实现,需要系统做出重大改动。 后督的作法问题。为加强事后监督,国内有些银行实行了后督制度。在手工方式下,后督一般于业务发生次日对原始凭证、会计凭证、审批单和交易流水进行逐笔检查,以此达到对本、外币结算清算和会计核算业务进行逐笔事后监督的目的。国外系统中没有类似我们理解所说的后督功能,如果要实现国内银行现行后督的作法和要求,系统修改的工作量非常大。 “双敲复核”问题。根据会计制度有关规定和风险控制要求,存款、支付、清算所有模块均需增加录入复核功能。即录入员输入交易要素后,由另外的复核员重新录入关键的交易要素,两次录入相符才提交该笔交易。出于降低风险的考虑,国内银行希望能够实现这一功能。但对于国外系统而言,增加双敲复核的功能需要对系统做较大改动,增加处理界面近一倍。国外产品供应商建议采取主管授权和降低录入人员操作权限的方法的方式替代复核功能。由于该项变通处理涉及面广,影响深远,需要分时、分步才能解决。 “倒起息”需求问题。倒起息有时被称作“利率晚到”,指由于某种原因,利率的实际生效日需要提前到系统当前日期之前。国外也有倒起息操作,只不过频率没有我们这么高。目前国外核心业务系统还不能处理好这个问题,完全按照国内银行的自动处理要求对系统进行改造也有一定难度。最后往往选择的是折中的方式:即倒起息在同一结息期内的情况下,系统可以自动计算利差并进行计息;倒起息跨一个结息期时,系统只能提供利息调整数的计算功能,但要手工调整;跨多个结息期时,系统完全要手工操作。还有一种方案建议将利差的计算放在系统之外,通过两个系统自动衔接,实现利息调整批量完成。 重要空白凭证管理问题。国外核心业务系统有支票、汇票、本票的管理功能,但管理层次少,管理内容简单。国内银行要求对银行汇票、银行承兑汇票、银行本票(定额、不定额)、定期存单、来账报单实行总分行多级集中管理,可随时增添票据种类,保留系统对客户的管理,同时需要记表外账(单式记账)。这是国外核心业务系统需要向国内靠拢的地方。 跨分行访问控制问题。国外银行机构设置扁平化,分行只是按业务纵向销售总行产品的前端,因此国外系统一般没有跨分行访问控制的概念,各分支机构间可以随意访问,很多模块无需对跨分行权限进行限制,一家分行可以改动另外一家分行的业务。由于国内银行管理模式与国外不同,因此很容易发生分行错记总行账的问题。即使产品供应商不愿意修改,从风险控制的角度看,类似差异需要按照国内银行现有模式进行修改。 综上所述,由于国内外市场发育程度不同,银行的外部监管环境和法规制度相差较大,银行内部的管理体制、业务流程和操作习惯也有很大的区别。差异是客观存在的,但却是可以靠银行、国外核心系统提供商及国内总集成商共同努力,找到一个彼此接受、合理可行的解决方案。由于差异的解决程度,直接影响到项目的成功与否和风险大小,因此需要各参与方正视差异,共同面对和分担项目风险。这些差异解决好了,就能够实现国外技术与中国实践的良好“嫁接”;解决不好,就会成为“夹生饭”,煮不熟也吃不下。(此文为作者博士论文节选

银行业数据中心分布式架构转型思考

作为中央银行的信息处理、业务系统运行和网络安全保障中枢,金融信息中心紧密围绕人民银行信息化工作的决策部署,在夯实基础性工作的同时,积极探索分布式架构下的运维工作,以适应新形势要求。


近年来,随着我国社会经济的快速发展,金融业务不断创新,金融业信息技术发展迅猛。金融宏观调控和监管不断加强、业务需求不断变化对银行信息技术(IT)部门的服务管理水平提出了更高要求。银行业务系统所普遍采用的集中式架构在新形势下局限性日益凸显,IT部门亟需转变理念,推动系统架构的优化调整,向分布式转型。作为中央银行的信息处理、业务系统运行和网络安全保障中枢,金融信息中心紧密围绕人民银行信息化工作的决策部署,在夯实基础性工作的同时,积极探索分布式架构下的运维工作,以适应新形势要求。
  
  一、银行业IT架构发展及现状
  
  纵观我国银行业信息化发展历程,银行IT架构的演进过程与信息技术发展水平、社会经济环境、监管政策等息息相关。当前,银行IT架构发展已到了从集中式架构向分布式架构转型变革的关键节点。
  
  1.集中式架构面临迫切的转型需求。20世纪70年代,我国银行业开始运用计算机代替手工进行业务处理,90年代中后期,实现全国范围的银行计算机处理联网。2000年以来,银行业普遍开始投入建设全国集中的核心业务系统,这种集中式系统架构以其成熟稳定、可靠性强的优势,支撑银行业务及信息化建设取得了长足的发展和进步。随着国家安全可控战略的实施,移动互联网金融的兴起,普惠金融业务量的迅速提升,银行业面临着利率市场化和金融脱媒所带来的转型压力,集中式架构逐渐呈现出故障容错能力及弹性扩展能力不足、对基础软硬件产品依赖度高、核心技术受制于人等局限性,亟需转型升级。
  
  2.分布式架构探索实践取得成效。我国对分布式架构的实践探索始于BAT等大型互联网公司。为了应对互联网金融业务的快速创新和业务规模的爆发式增长,这些公司在对相关应用场景分析的基础上,通过对业务进行合理的拆分构建了以数据分布存储、多节点并行处理为主要特点的分布式架构系统,有效支撑了网络促销、红包等消费模式和金融产品。分布式架构以水平扩展为主,通过横向扩充节点,一个节点扩充到多个节点,每个节点运行独立,节点之间通过网络互连。随着节点扩充,系统处理能力能够随之提升,单节点失效时,整个集群仍可以对外提供服务。相对集中式架构,分布式架构的优势在于采用更加开放的架构,各节点松耦合,降低了单个节点对基础软硬件的可靠性、可用性依赖,可用性高、可扩展性好、成本较低、受制于单一厂商的制约较少以及对国外技术产品依赖性较小等。
  
  在“互联网+”蓬勃发展以及国家大力推进金融领域安全可控的大背景下,以工商银行、建设银行为代表的国有银行也在加快推动IT架构转型,采取与外部合作模式,或自行研发方式,在网上银行、数据分析等领域逐步探索采用分布式架构,为分布式架构规模化应用积累了丰富的实践经验。
  
  二、银行IT部门如何开展IT架构转型工作
  
  面对系统架构转型的压力,银行IT部门首先要转变服务理念,变被动为主动。在实施层面,要统筹规划,健全工作机制,加强沟通协作,保障IT架构转型工程的稳步实施。
  
  1.转变服务理念,从“支撑业务”到“引领业务”。架构转型既是技术层面的革新,同时也对银行IT部门提出了新的要求。在相当长的一段时间内,银行IT部门秉承“支撑业务”的服务理念和系统建设模式,积累了大量集中式架构系统的建设和运维经验。但随着互联网金融业务不断创新发展,集中式架构从系统处理能力到应用响应速度等方面已不能完全满足业务发展的需要。分布式架构的提出,弥补了集中式架构在上述方面的局限性,使IT部门更加主动地参与到全行互联网金融创新、大数据等战略实施中,利用新技术来创新业务模式、重塑业务流程,从业务的支撑者向引领者转变。
  
  2.做好顶层设计,从“各负其责”到“统一协作”。分布式架构的实施是一个系统性工程,IT部门应从战略和战术层面积极应对。
  
  首先,要做好顶层设计,统筹考虑IT战略、规划、架构、开发、运维等各个环节,在继承已有系统建设成果的基础上,根据自身实际制订分布式架构转型实施方案。
  
  其次,加强开发部门和运维部门的沟通协作,促进应用架构与基础架构的融合。开发部门要合理设计应用架构,从应用特点出发,对业务种类、业务流程进行拆分,处理好“分布”和“集中”的关系,关键要保障数据一致性和业务连续性;运维部门要创新IT资源的供给方式和服务模式,探索建立资源弹性供给、灵活调度的云平台,实现对应用架构的有效支撑。整体上要加大研发投入,考虑采用引入产品、自行研发、合作研发等模式,加强与互联网公司的技术和经验交流,做好技术人才培养和储备。
  
  三、金融信息中心关于IT架构转型的工作思考及探索实践
  
  为应对分布式架构的转型,银行业数据中心应提前规划和布局,做好保障和支撑。金融信息中心按照人民银行信息化工作要求,直面IT架构转型大势,稳步推进各项工作,实现运维能力的持续提升。
  
  1.夯实工作基础,为IT架构转型作好准备。分布式架构下,基础设施规模和复杂度都将大大增加,运维管理工作难度加大。金融信息中心将立足当下,把握关键,完善工作机制,创新工作方法,迎接架构转型的挑战。
  
  将风险防控作为常态化工作。无论在何种体系架构下,风险防控永远是运维工作的第一要务。金融信息中心高度重视风险防控,完成了运行风险防控课题研究,促进各部门自觉主动地梳理运行风险,制订风险处置清单和计划,做到对风险及其处置进展心中有数、心中有底。分布式架构对运维人员的全局意识和专业能力提出了更高的要求。下一步,我们将以分布式研究成果带动风险排查工作深入开展,促进运维人员持续提升IT架构转型形势下的主动防范风险意识。
  
  引入和升级工具提高自动化运维水平。IT架构转型将带来设备规模的成倍增加,系统涉及的节点众多,系统间的互操作更频繁、依赖关系更复杂,对运维工作的标准化和自动化要求更高。金融信息中心要将标准化、专业化、流程化的理念融入运维管理工作,建立自动化运维平台,逐步完善日常监控、故障处置、配置管理、周期巡检、安全管理等功能,以适应当前和未来开放式云平台的运维管理需求。首先,通过运维操作脚本化提高操作的可靠性,降低由人为误操作、缺少配置基线所引发的风险。其次,在现有监控工具的基础上,结合分布式架构特征梳理和完善监控指标集,收集各类设备运行信息开展系统可用性、容量等方面的关联分析,确保故障发生时及时响应。再次,建立故障的自动隔离和处置机制,确保系统中单个节点故障不会影响到其他节点,且随着业务量和性能的变化实现弹性扩容。
  
  2.完善管理体系,提升数据中心“软实力”。分布式架构的应用引发IT资源供给方式的变化,进而推动运维组织模式作出相应调整。金融信息中心借鉴行业先进经验,持续完善管理体系建设。
  
  建立一体化的运维管理模式。分布式架构下,网络、计算、存储等IT资源需要统一管理、集中监控和按需分配。金融信息中心在组织架构上,强化横向部门“一体化大运行”的管理职能,注重对运维人员专业能力和综合素质的培养;立项开展了“IT一体化监控平台”项目,以期实现对各类IT资源的集中监控,该项目已完成一期建设。未来,我们会将监控平台与流程管理平台对接,为其提供监控数据和配置数据,实现从故障发现到处置的闭环管理,确保整个运维体系的完备性。
  
  梳理和优化各类流程和制度。金融信息中心借鉴ISO20000、ISO27001,以及数据中心服务能力成熟度模型等国内国际标准,查找自身在流程和制度建设方面的不足,完善管理制度体系和评估体系。通过开展此项工作,从金融信息中心全局出发梳理和优化变更管理、事件管理、应急管理、资产管理等关键流程,加强部门之间的横向协作,提高了运维管理效率。我们将结合分布式架构对于运维操作的制度、规范、规程、细则要求,进一步建立健全有关制度体系,优化运维流程,提升金融信息中心运维服务和安全管控水平;同时,深化与标准研究机构、认证机构和商业银行的沟通交流,促使运维人员有机会学习同行经验和更新分布式架构下的技术知识结构。
  
  3.加快技术研究与实施,打造数据中心“硬实力”。为了更好地满足分布式架构下的IT资源供给需求,金融信息中心在云平台、分布式双活数据中心等方面开展研究与实践。
  
  研究探索数据中心云化之路。针对分布式架构的IT资源供给需求,搭建弹性敏捷部署、资源池化灵活调度云平台将是数据中心未来发展的趋势。金融信息中心系统梳理了云计算相关方针政策、法律法规、标准规范、产业发展现状、行业监管要求,初步拟定了高效、可扩展的云平台的实施方案。根据国家安全可控战略以及金融行业信息安全要求,在部署方式上将以私有云为主,实现对数据、安全性和服务质量的有效控制;在云服务商选择上,将综合考虑国产化、产品成熟度、服务能力、实施成功案例等各方面因素。另外,由于基础设施云(IaaS)业界已经有较为成熟的经验和稳定的产品,在技术路线上,以IaaS作为切入点,先期实现各类IT资源的虚拟化部署、集中管理和统一调度;再逐步探索平台云(PaaS)实施方案,为人民银行业务系统提供统一的软件开发、测试和发布环境。
  
  开展分布式双活数据中心规划布局。为更好地满足业务连续性要求,借鉴行业经验,金融信息中心着力推动“分布式双活数据中心”规划,以适应IT架构转型和业务发展的要求。所谓“双活”,即运用分布式技术,将业务拆分到两个不同地域、不同规模的数据中心的IT资源上,各中心之间同时并行对外提供服务。分布式双活数据中心模式无论在服务能力方面还是资源利用效率方面,都要优于目前广泛应用的“主备数据中心”模式。金融信息中心将按照人民银行信息化建设规划,在现有生产中心A机房基础上,加快完善同城生产中心B机房的功能布局,探索搭建针对重要分布式系统的“双活”环境,以及针对重要非分布式系统的同城灾备环境,更好地适应人民银行未来业务发展要求。
  
  综上所述,后续,金融信息中心将按照人民银行信息化工作的统一部署,结合中央银行数据中心实际情况,既要看到IT架构转型的必要性和优势,亦要清醒认识人民银行信息化特点及整体规划要求,把控数据中心运维全局,以确保安全生产为前提,科学规划、严格论证、分步实施、稳妥推进,持续关注以下几个问题。
  
  一是把握IT架构转型的关键节点和实施策略,不断深化对以分布式处理、统一管理、弹性扩展、快速联网接入等为核心特点的分布式技术架构的认识,加强人员技术储备。
  
  二是以新系统上线、分布式“双活”数据中心建设、云平台建设等为契机,深入开展虚拟化技术、分布式技术以及与分布式环境相契合的底层监控等运维技术的研究应用。研究制订合理的架构、系统、业务迁移策略及相关软硬件产品选型测试标准,确保IT架构转型过程的平滑过渡。
  
  三是加强运维与设计开发的衔接和融合,综合运用多种方式,促使运维人员掌握系统架构及业务应用逻辑,为后续运维工作打好基础。
  
  四是完善银行业数据中心联席会议机制,充分发挥银行业数据中心运维标准等工作组的作用,与业界同行和产业各方沟通交流,共同研究和应对运维管理工作中的新问题,分享先进理念和实践经验,形成共赢的良好局面。


以上是关于银行的业务系统如何适应市场需求的变化以及需要哪些IT系统的支持,需具体的主要内容,如果未能解决你的问题,请参考以下文章

范围管理

为啥企业需要数据仓库

银行业数据中心分布式架构转型思考

VaR值计算性能千倍提升——某头部外资银行实例分享

金融零售业务大数据分析解决方案

企业网络介绍