创新的含义是以无先例、更新、更好的技术组合，针对客户的特定需求设计和实现的方案，从而达到一定的技术高度和效果，带给客户技术和业务上的优势。技术创新的同时，我们通过严谨的技术考证，周密的生产模拟测验，严格控制技术创新附带的风险。在客户鼓励技术创新的氛围中，我们不断接受客户的委托，帮助客户设计、规划和实现前人从未尝试过的构想和方案。
以下是我们为客户提供的部分技术创新方案实施案例：

远距离主机开放一体化同城双活灾备体系建设

多年来，银行数据中心一直把建立同城远距离灾备中心作为保障业务高可用性的业界标准。通常，除了用于开发和测试以外，备份中心的大部分设备处理能力都处于闲置状态。早在2008年，我们的客户就对备份中心的资源提出了以下目标：

• 充分利用与生产中心相距70公里（光纤距离）的灾备中心的闲置MIPS
• 保证在发生灾难事件时可在10分钟内恢复业务运行
• 灾难接管和回切过程中保证零数据丢失
• 交易响应时间在可接受的范围

由于客户的银行业务系统既有主机应用又有开放应用，因此我们的设计方案必须覆盖主机和开放系统的所有关键应用。当灾难发生以后，所有关键应用系统必须能够在10分钟之内恢复运行，同时保证无任何数据丢失。
根据我们的双活灾备方案，生产和备份中心以双活模式运行。业务交易可以根据客户预先设定的规则路由到任一中心运行，从而将生产和备份中心变成生产主中心和副中心。我们的解决方案有效地解决了由于两个中心之间的物理通讯距离延迟，而导致交易响应时间增长的问题。鉴于该项目实施的范围广、业务风险高，因此这一一体化同城双活灾备架构分成了几个阶段来实现：
2009年实现了远距离主机系统双中心运行。生产主中心和副中心的主机构成一个跨站点的SYSPLEX，数据采用DB2 Data Sharing进行共享。两个中心均为活动中心，可同时接收处理业务交易。在双活模式下，副中心的闲置主机MIPS得到了有效利用。这一真正意义上的主机双活架构的实施，为我们的客户节省了投资，使客户可灵活利用现有的资源应对突发的交易量高峰。
2011年初，我们协助客户模拟了主中心发生灾难事件，验证了同城双活灾备架构可按照预期目标实现分钟级接管。通过对客户应用和应用环境的深入研究，我们整理出了所有可能的单点故障（SPOF）。通过设计和模拟各种组件故障、应用故障、子系统故障和系统故障，我们确保了同城双活灾备架构以及故障接管/回切流程均可按照设计正常工作。在确保零风险的基础上，我们协助客户在生产环境进行了一次双活灾备演练，包括计划内和计划外灾难接管和回切。计划内灾难接管中，业务处理无任何中断。计划外灾难接管中，主中心的处理可在7分钟内被副中心接管并继续进行正常业务处理。回切到主中心的过程可自动化完成，并且对业务运行完全透明。
借鉴主机同城双活灾备的概念和设计原则，我们进一步提出了开放系统关键业务应用的同城双活灾备解决方案。2012年，客户成功投产了第一套开放应用系统的同城双活灾备架构，并于2013年成功推广了多套关键开放应用系统。2014年初，经过全面的测试和技术验证，客户在生产系统进行了一次开放系统双活灾备切换演练。计划内和计划外灾难切换和回切均顺利完成，实现了所有RTO和RPO目标要求。
以上主机开放一体化的同城双活灾备解决方案的成功实现，为我们的客户的双活灾备实施奠定了良好的基础。从2009年以来，客户有效地利用了同城备份中心的闲置MIPS资源，大大降低了总体MIPS需求，推迟了CPU容量升级。这一双活灾备架构为客户带来了一定的经济效益。同时，面对自然和人为灾难事件，客户的业务得到了更好的保护。即使主中心完全瘫痪的情况下，关键业务系统也可以在10分钟之内恢复运行处理。

基于SOA的主机核心业务系统

为应对快速发展、充满活力、竞争激烈的金融市场的挑战，客户需要更加快速灵活地推出银行产品和功能，以满足业务发展的需要。为此，客户向我们寻求对其主机核心业务系统架构改造的咨询建议。新一代的核心业务系统需要具备以下特点：

• 具有高度灵活性，以满足活跃的金融市场的需要
• 能够根据业务需求迅速提供各项新功能
• 能够适应未来的架构改造需求，包括可简单方便地迁移到开放系统

基于新一代核心业务系统的灵活性以及市场投放速度的要求，我们研究了基于服务的架构（SOA）。核心业务系统与所有主要业务系统（包括主机和开放系统）均有连通和互动，因此新的架构中必须提供标准的接口，报文交换格式，以及服务请求方/提供方规则。我们首先对一些不确定的关键技术进行了概念验证（POC）。之后，我们从原有的核心业务系统中挑选了一些业务功能，并基于SOA设计搭建了一个模型。这些准备工作帮助我们和客户更好地了解了确定、定义和实现服务的关键技术和步骤，服务的流程和构建，以及为更好地实现服务所需的企业级的组件（平台）。经过一系列的功能和性能测试，并对原始设计方案反复修订之后，我们协助客户完成了一套初步的企业级架构设计方案。经过客户管理层的审批，终于启动了这一应用架构改造工程。
为了方便这一新的SOA架构的开发，我们帮助客户研发了一套SOA开发工具，以帮助客户对组件、服务、服务流、数据结构、标准化接口、报文交换格式、数据字典进行开发和治理。此外，我们还参与了企业级公共组件（平台）的开发工作，以加快应用开发并为应用提供支持。为了监控系统中处理的业务交易，我们还设计开发了一套新的应用监控系统，将业务交易和关键性能指标结合起来，以方便应用开发、维护以及问题诊断。
由于该项目涉及的规模和技术难度较大，客户新一代核心应用系统的开发和部署是分阶段实施的。经过两年的开发和验证，客户于2011年至2012年先后成功投产了多家海外分行。在此基础上，客户持续对新一代核心应用系统进行了国内版本的改造和优化，并于2014年下半年成功投产了第一家国内分行。

业务交易监控系统

为了确保关键业务系统的稳定运行，客户需要一个既能跟踪业务交易，又能监控相关性能指标的监控工具。根据客户要求，我们协助设计并开发了一个专门为客户应用系统定制的监控系统。该系统可以提供：

• 对每笔业务交易的实时监控：包括交易在各个系统环节所花的时间，资源消耗情况，以及异常处理情况
• 对交易异常的主动预警：在第一时间检测到并确认处理规律和/或资源消耗发生的异常，并根据预设规则发送报警
• 帮助应用问题诊断的有用信息
• 自动Abend分析和报表功能
• 历史业务交易量和性能数据：可用于进行趋势分析和主动性能优化
• 历史业务交易数据统计：可用于进行业务规律，趋势和客户行为分析

基于我们对客户核心业务系统的深入了解，我们帮助客户设计并部署了这一应用监控系统，有效地将应用和系统组件的监控整合在一起。我们设计的应用架构可分为两层，结合了系统和应用编程技术。数据收集是在交易发生的主机上完成的。而数据处理、分析、存储和展现则是在AIX服务器上实现的，以便更贴近最终用户。这一应用架构确保了尽可能减少主机资源的使用，并为将来的修改提供了更多灵活性。自客户使用了该监控工具以后，可以更加及时地发现、预防并解决问题，避免对业务运行造成大的影响。

应用架构改造

随着客户贷记卡业务的迅速增长，在高峰时段，交易响应时间开始受到影响，生产系统时常发生一些故障。经我们对业务系统的研究，业务量已迫近单个TCB的处理极限。对此的解决方案就是将应用改造为CICSPlex环境下的多CICS架构。由于实施先例的局限性，客户面对着应用分布在多个独立CICS而带来的数据处理难题，或者彻底替换新的贷记卡应用系统的两难局面。
我们的服务团队与客户应用技术人员共同进行了深入的应用分析，重点研究了应用关联性和依赖关系。在此基础上，我们设计了一个将应用迁移到CICSPlex上的应用和系统架构改造方案。通过修改部分应用程序，消除了应用关联性和依赖关系。同时各CICS分区之间的负载均衡问题也得到了有效的解决。通过反复大规模测试和压力测试，我们对这一架构改造方案的数据一致性和性能进行了充分验证。2007年，贷记卡应用CICSPlex架构改造顺利投产。
在新的应用/系统架构下，客户可以根据业务量的需求任意添加AOR，因此消除了阻碍客户业务发展的潜在的限制因素。从2007年到2014年，客户的贷记卡业务量增长了12倍。改造后的贷记卡应用架构为客户的业务发展提供了有效的支持，同时大大提高了系统的可用性，并改善了交易响应时间。

批量自动化改造

客户为了加强对核心业务系统的批量处理的监控、管理和报表功能，需要使用Control-M批量作业调度工具来替换原有的应用批量调度功能。对此，应用厂商提出了一个需要大量修改应用、开发周期冗长的改造方案。由于这一方案的开发成本、周期和对应用改动的复杂程度，该项目很难得到客户管理层的批准立项。为此，客户要求我们重新对上述改造项目进行方案分析，并提出一个更好的解决方案。
通过对客户应用批量处理流程、规则、异常处理、厂商批量调度功能以及Control-M工具调度处理的全面深入的分析，我们最终提出了一个将厂商批量调度功能和Control-M调度处理整合起来的解决方案。根据这一方案，无需对核心业务应用进行任何修改，从而极大地减少了项目实施的风险，并有效缩短了项目周期。通过一些系统和应用编程，我们的解决方案可以实现批量调度的完全自动化处理，并对批量运行完全透明。在客户管理层批准了该项目方案后，我们仅用几个月时间就完成了全部设计、开发、测试工作，并协助客户成功完成了生产部署。