因为工作原因，我与银行的信息科技部门打交道比较多。在和这些“甲方”客户聊天的时候，我常问他们一个问题：你们到底是干IT的还是干金融的？
很多人都觉得自己是干IT的。
但事实上，IT是金融的“果”，金融是IT的“因”。
IT只是银行业为客户（对公/对私）提供安全、稳定、可靠、便捷、全方位的高质量金融与增值服务而带来的“果”，而这个“因”，实际上还是银行业在风险完全可控的前提下，围绕所有与金融直接或间接相关的活动场景（比如存款、投资、融资、支付、核算…），为客户提供相应的产品和服务。
随着信息化建设的推进及互联网企业的颠覆式创新，这些金融活动场景，正在加速从线下渠道走到线上渠道，银行只有通过不断提供更加友好、创新产品体验（比如易用可视化的交互、技术含量较高的生物识别），才能在同业竞争中获取更好的口碑及更多客户。
互联网企业利用后发优势，不断通过将大数据、云计算等新兴技术与传统金融相融合，为大众提供更加安全高效便捷的金融服务，这对传统银行业的优势领域形成一定挑战和压力，但同时也为银行业改革发展转型带来了新的指导和动力。在这样的大背景下，“信息科技”就成为银行业抵御风险和增强竞争力的关键。
因此，近年来很多银行都提出“科技兴行” 、“科技是银行的第一生产力” 、“科技引领”等战略口号。为了化解压力和挑战，银行业务部门需要深化客户需求，不断优化、新增更具创新的产品和服务。
对于银行信息科技部门来说，一方面要不断响应业务部门需求，开发出更多的软件产品与之对应，另一方面还要保障过去已上线业务的稳定可靠运行。因此，相当一部分业务的压力被转移到信息科技部门，这也触发了信息科技在软硬件产品和运营管理方面的创新和变革。
在这个变革的过程中，信息科技部门不得不面对各种业务架构的坑——
❶ 竖井中看不见的手
应用系统由于部署模式的原因，导致硬件资源上存在竖井现象。这种情况，绝大部分可以伴随着IT基础设施层面的技术发展，利用虚拟化和云计算进行弥补和改善。
但是应用系统所承载和对应的业务产品服务，却如同一只看不见的手，悄无声息的搭建出了很多形式各异的服务竖井。
这种竖井出现的原因其实很简单：随着业务规模和服务范围不断扩张，应用系统在投产运行3-5年后，原来设计的软件架构不一定能很好的满足业务的发展，同时，由于研发部门对需求的理解偏差、及及每次需求临时变更，都会导致服务竖井的出现。
我过去一半的职业生涯，都是软件攻城狮，对此深有体会。比如，当收到一个新的服务需求变更时，由于之前服务设计的通用性和业务前瞻性不足（大神级除外，而且银行外包服务商考虑人员成本问题，通常人员能力参差不齐），要满足新的业务需求，就要在原有的数据模型和业务逻辑上做出较大的改动，这是很多软件工程师最不想做的，而且时间紧任务重，因此更多的人会选择放弃对新业务需求的支持，保持现有服务稳定，重新开发一套跟这个服务差不多的功能模块。
长此以往，就会有大量的功能和业务在多个系统中同时存在，逐步累积隐患。
❷ 业务需求和系统响应能力分化
伴随业务部门的需求增长越来越迅猛，银行信息科技部门在对原有系统的改造升级就变得越来越吃力，而且随着时间的推移、人员的流动，到最后某个关键应用系统可能已经复杂到谁也讲不清楚，原来对外提供的业务服务到底分散在哪些产品模块中，又会被哪些系统使用。
一旦发生故障，大家都如坐针毡，对业务响应的能力也就显得愈发紧张，直到有一天信息科技部门再无法再满足业务部门新的需求。
业务系统的潜藏竖井越来越多，运维管理的成本和复杂度也逐年攀升。
最终，一套系统在生产环境的交易链路，可能复杂到无法直视的地步，让信息科技的管理者感觉整个应用系统和业务服务都处在失控的状态。
❸ 面向服务的SOA架构
为了化解这种困境，业界早在十几年前就提出了面向服务的架构（SOA，Service-Oriented Architecture）理念，它将应用程序的不同功能模块（称为服务）进行拆分，并通过这些服务之间定义良好的接口和规范联系起来。
SOA的出现，给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻松的互相关联组合共享信息。
按理说只要充分了解业务逻辑，利用SOA这种松散耦合理念，就可以不用编写太多代码，通过业务流程图就可以快速搭建一套新的应用系统。
然而不幸的是，在过去10年中，银行绝大多数客户只是利用SOA的理念简单，从技术视角做了个企业服务总线，将原本错综复杂的服务做个整理，实现了业务架构上的系统互联互通，并未真正实现一个企业内部的服务路由枢纽和渠道，也就没有真正发挥出SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
回头再看SOA项目建设过程，我们不难发现，在业务架构转型的过程中，只有持续运营、完善和改进这些服务模块，让其变得更加稳定和灵活，才能逐步成为企业在某领域最为专业的服务能力。
衡量这些服务能力好坏的标准，目前业内还没有一个定论。但是我觉得应该包括一些服务成功率、请求频率、请求响应时间等关键指标。
只有这样，我们才能分析缺陷问题，确认改进方案，持续优化改进服务接口能力，才能真正达到SOA中所描述的业务的快速响应，更好地支持业务创新，然而走到这一步却异常的艰难。
❹ SOA架构转型升级之路
在过去很多年中，我们在银行里会经常看到这样一幕：一个系统上线运行5-8年后，信息科技部门会不断提出“现有系统不管是技术架构还是业务架构，都不能满足未来业务长久发展的需求，需要整体升级”，而这样的升级往往意味着推倒式重建。
拿J行来说，从2010年底开始规划重构包括银行与非银行业务，这是一次涵盖基础设施、业务、技术、实施在内的系统性升级工程。
该行首先把业务解构成可以被业务或产品重用的组件和构件，参照SOA理念将业务划分为自治而相互依存的部件，不但可以被独立优化提高业务运营模式的灵活性，而且可以依据离散且可重用的服务进行业务建模，将所提供的服务发布在网络上， 与其他应用进行集成存储业务服务，这也最终为该行后来发布的公有云打下坚实的基础。
该行的整个转型升级过程，三期分步实施，持续6年之久，于2017年6月主体功能全部投产，实现由原本面向单一项目管控，向 “一套业务模型、一套IT架构、一套实施工艺、一套管理流程”模式转型。
虽然该行这样推倒式重建，对现有业务带来了不小冲击，有不少基础功能的重复建设和资源投入，但是这次升级改造实现了其IT系统建设模式从“部门级”到“企业级”的根本转变。
而且由于从顶层设计出发，构建一个更健全、更规范、更灵活、更稳定开放的“集中式+分布式”融合架构，使它既适用于瀑布式大规模开发，指导大型商业银行战略转型项目的顺利实施，也适用于迭代式的敏捷开发，推动诸如该行龙支付等创新产品的迅速投产。
最近该行房屋租赁业务更是搞的风生水起，由此一跃成为银行业争相学习模仿的榜样。
该行于2018年4月份成立金融科技公司，尝试为同业、企业和战略伙伴提供领先的金融级IT服务，引领行业能力输出，并于2018年11月份获得银行科技发展特等奖的殊荣。
我也有幸参与了这次转型升级的起始和收尾工作，在此非常感谢那些曾经跟我一起奋战在第一线的小伙伴们，我们一起见证了该行的转型历程。
❺ 转型阵痛与运维管理挑战
中国银行业信息科技“十三五”发展规划监管指导意见提出，“各家银行持续提升信息科技服务能力，构建绿色数据中心，推进运维自动化和智能化，提升数据中心运营管理能力成熟度，实现基础架构转型升级，提升信息技术架构管控能力….”
虽然政策压力不小，但每家银行业务规模、战略规划、历史包袱、人员能力都不尽相同，如果选择像J行这样大破大立推翻重做一站式解决方案，不但要付出非常大的努力，还需要去承担比较多的资本风险、人员风险、时间风险等。
因此大多银行采用比较稳健的架构转型方式，分阶段分步骤，逐步将非交易类、核心账务类竖井式业务系统，从传统平台逐步迁移到开放平台，采用微服务架构的方式针对逐个系统进行升级改造，这样不仅可以保障整个IT架构能够平稳过度，也能灵活适配瞬息万变的互联网业务需求。
凡事有利就有弊，无论各家银行采用哪种转型升级模式，都能在一定程度上缓解信息科技部门对业务部门的响应压力，但是为了稳妥起见，大多银行实际上还是维持新老架构同时运行，而这样的双态数据中心，不但增加了整个数据中心的IT架构复杂度，而且增加了系统运维的压力。
为了保证这些业务系统“稳定、可靠、安全”运行，提升运维管理的效率，信息科技部门采购了大量的运维管理工具。
拿Z行来说，他们在18年筹备智能运维平台时，梳理了包括自研和外采行内正在使用的运维系统，居然有77套之多
Z行总共需要运维的业务系统，才不过500多套，为何会出现如此之多的运维管理工具？
这些工具都是怎么产生的？各种类别运维管理工具林立，会不会也有出现业务系统式竖井？
这又是一个很大的话题……
