 |
|
级别： 初级
Scott Simmons , 执行 IT 架构师, IBM
2008 年 12 月 08 日
目前银行业正在积极进行其核心系统的现代化工作。转换或替代关键银行应用程序的过程带来了相互冲突的共生挑战——就像在马拉松期间进行心脏手术一样的。尽 管维护和管理当前的解决方案并同时进行其替换工作，这似乎都很必要但又无法同时进行，但的确可以同时进行，而且我们可以从前人那里学到一些经验和教训。
来自 IBM WebSphere Developer Technical Journal 。
上 面的标题对于技术专栏而言可能奇怪，但这个类比实际上是某个银行客户在描述自己的系统需求时所说的话。银行核心系统相当于银行的心血管系统，提供能够推动 产生收益的运作（如帐户管理、存款、贷款、信用卡等等）的解决方案。当前的核心系统大部分都是存在已超过 20 年的基于大型机且面向产品的应用程序，缺乏灵活性，而且经常会对 IT 快速高效地响应新业务需求造成影响。
在与全球银行客户的 大量项目合作中，IBM® Banking Center of Excellence (BCOE) 亲历了很多核心系统现代化（转换或替代这些关键应用程序的过程）的合作工作，因此上面的标题代表了在维护和管理当前解决方案的同时进行替换核心系统功能工 作时所存在的共生挑战。
在讨论“心脏手术”之前，我们需要稍微暂停一下，明确说明核心系统现代化不是遗留系统集成，其中包括的工作远远不止这些。
首先，“遗留”这个术语对于银行大型机解决方案而言并不恰当。遗留定义为属于、与之相关或就是之前的或已经过时的计算机系统的状态 。 因此，“遗留”在此上下文中并不是一个有效的术语，因为大型机系统是 IT 方面广为应用的设备，当前约占全球大型机上数据的 80% 或更多。尽管这个估计值因为行业不同会有所变化，但 CICS®、IMS 和批处理环境中的 COBOL 和 PL1 形成了世界核心银行系统的基础。更为重要的是，在可以预见的将来，这个方法将继续担当银行 IT 基础设施的基础角色。尽管在分布式系统上实现的核心银行解决方案的数量有所上升，但大型机固有的可伸缩性、可靠性和安全性作为关键决定因素，决定了全球 Tier 1 和 Tier 2 银行中仍将继续使用大型机。
其次，核心系统现代化不仅仅是一个集成方法。事实上，核心系统中目前出现的很多问题都是由于应用了未对端到端解决方案体系结构予以足够重视的集成解决方案造成的。图 1 中以图形的方式说明了这个问题。
面向产品的核心银行解决方案受到由于不断增加的维护负担而导致的持续应用程序碎片的折磨。2005 年，Tower Group 指出，核心系统在银行的总体 IT 开销方面占了一半的份额，而在 IT 总体维护工作中占到了四分之三的份额。 核 心系统内的不灵活性限制了响应业务需求的能力，而这反过来又导致需要采取修补措施来保持解决方案的相关和可行。我们现在的一个客户曾表示，向其现有的基于 CICS 的核心系统添加一个金融产品需要超过 6 个月时间。此类 IT 负担导致整个局面难以维持。因此，各家银行都在评估核心系统备选方案，以减少成本及（可能更为重要）提供更好的业务和 IT 一致性。
那么，核心系统现代化的答案是什么呢？
当然，在很多情况下建议的方法并不止一个。业务优先级、地理位置方面的考虑、承担的风险以及上市时间需求是推动“手术”决策的部分关键因素。在 Banking Center of Excellence，我们发现核心系统现代化通常归入以下四个主要领域：
- 程序包替换： 选择和实现供应商程序包替换当前核心系统。
- 自定义应用程序开发： 设计、开发和实现自定义解决方案来替换当前核心系统。
- 扩充或扩展当前核心系统功能： 选择并实现一些现成解决方案来扩展或扩充当前核心功能领域，如产品和定价管理、客户主控数据管理、客户关系管理以及其他特定的核心银行领域。
- 渐进现代化方法： 结合使用现成解决方案和自动化开发来逐步革新和扩展（在某些情况下，替换）当前核心系统体系结构中的各个部分。
上 面列出的前三个方法都是有效的选项，但本文的讨论将以第四个方法为重点，采用渐进的方法更新银行核心系统。完整的端到端核心系统替换项目（如果愿意，可以 将其称为“心脏移植”）可能需要四年甚至更长时间才能完成，需要数亿美元的投资，而且还不保证成功。另一方面，通过渐进方法，银行可以通过迭代方法“在马 拉松期间进行心脏手术”，此类方法的目标是当前核心系统中的业务关键型差异，总体体系结构的大部分内容都不会有变化。
 |
|
渐 进式的现代化根据业务需求以增量方式扩展或替换核心系统功能。此方法已经被 IBM 推广了很多年。随着面向服务的设计方法的正式化、银行特定的主控数据管理功能的出现以及行业模型的成熟（如 IBM 的 Information FrameWork），此方法越来越多地被视为战略路线图中的首选方法。
核心系统现代化需要在业务战略和所选方法之间建立联系。 此外，通常还必须获得 CEO、CIO 或董事会积极的项目/计划支持，才能让采用面向业务的方法的核心系统现代化项目在总体上获得更大的成功。我们还发现，在定义了全面的业务体系结构（例如， 业务模型和相关活动或流程、业务角色/用户组以及业务信息模型）的情况下，这些项目能取得更大的成功。业务体系结构经常使用 IBM 的组件业务建模技术等方法建模为业务组件。定义了所有这些业务组件后，就可以通过开发流程模型、用例和关联的关键性能指标（Key Performance Indicator，KPI）设计解决方案。这些模型和 KPI 将成为技术设计的主要输入信息。
通过 这个业务驱动的方法，银行可以根据业务需求对需要现代化的领域进行优先排序。确定优先级之后就可以进行具体领域的分阶段开发或活动了。有些公司采用多个工 作流同时进行的方式，但这个多活动方法通常挑战性较大，尝试并行进行多个项目的银行需要对项目之间的相互依赖关系以及预期结果进行管理。有序的范围管理是 执行现代化路线图的一个关键成功因素。
可以通过采用行业框架和参考模型来加速解决方案定义工作。通过使用模型，银行可以在“手术”过程中进行最佳实践自定义。很多银行都使用 IBM 的 Information FrameWork 来帮助进行流程和数据解决方案的评估、需求定义和组件开发工作。
Information FrameWork 包含多个模型，包括：
- 金融服务数据模型（Financial Services Data Model，FSDM） 提供银行业务的概念和信息领域的分类模型。
- 金融服务功能模型 (Financial Services Function Model) 详细介绍银行必须管理的主要功能。
- 银行数据仓库模型（Banking Data Warehouse Model，BDWM） 满 足数据仓库和业务智能需求的扩展数据模型。相关的组件包括业务解决方案模板 (Business Solution Templates)、应用程序解决方案模板 (Application Solution Templates) 和项目视图 (Project Views)，用于为数据仓库和业务智能项目提供进一步的支持。
- 金融服务工作流模型（Financial Services Workflow Model，FS-WM） 详细说明独立于产品、渠道、组织结构或技术的企业级关键业务词典。
- 业务流程模型 (Business Process Models) 记录了银行和金融服务方面的 400 多个流程，涉及领域包括客户登记、事务处理和支付等。
- 业务对象模型（Business Object Model，FS-BOM） 为所有金融服务概念提供用例定义和集成类模型，以支持需求定义和面向业务的解决方案设计。
- 接口设计模型（Interface Design Model，FS-IDM） 详细说明业务对象模型中标识的组件和接口，用于支持面向服务的组件的实现。
Information FrameWork 中各个组件的详细信息不在我们的讨论范围之内，不过最近一本红皮书（请参见参考资料 ） 非常详细地描述了如何将 Information FrameWork 和 IBM Software Development 平台结合使用，可作为核心系统开发人员的重要参考资料。Information FrameWork 建议采用自顶向下的方法，从而将银行业务体系结构的元素与 IT 体系结构规范进行关联。
Information FrameWork 标识了银行组织关键领域，其中包括（但不限于）核心系统。我们目前的一个银行客户将 Information FrameWork 作为扩展检查清单使用，用于对超过 300 个大型机应用程序中的数据和应用程序资产进行分类。配合自顶向下设计方法（基于 Information FrameWork 的金融服务数据模型和流程模型）的这个应用程序资产分析是该银行核心系统活动的基础。
成功的现代化项目中重复出现的一个主题是为将来的核心体系结构定义通用解决方案技术。核心系统现代化通常需要采用业务或技术级别的一致企业方法——尽管并没有必要在所有解决方案中使用完全相同的体系结构方法。
考虑到定义良好的业务和技术体系结构，我们通常建议采用渐进现代化方法。这个迭代方法包括三个主要领域：
-
应用程序转换 重点关注应用基于模式的方法对当前的基于大型机的核心银行资产进行集成和扩展。我们见到过实现此工作的各种方法（稍后将对此进行进一步的讨论），通常通过自底向上设计和开发进行。此方法还可用于将核心解决方案资产与第三方解决方案集成，以支持各种最佳方法。
-
业务流程管理（Business Process Management，BPM） 是 基于流程的方法，通常以业务流程和用例的自顶向下建模为基础。此方法经常被视为补充和扩展当前核心系统的 SOA 解决方案。流程层和服务中间层对基础核心系统进行了隔离，可以支持跨各种外部用户和通信解决方案（例如，移动、直连、Internet 等）、基于渠道的创新应用程序的开发。
-
客户、帐户和产品数据的主控数据管理 。 面向产品的应用程序竖井 (silo) 组成了大多数核心银行解决方案，带来了核心银行数据领域（如客户和产品数据）的数据冗余。由于银行会面对“多版本事实”，因此这方面的数据增加会导致数据 质量问题。为了处理这种情况，通常会采用关注两个关键数据领域的主控数据管理解决方案：
- 客户和帐户领域： 此解决方法的特点是，将传统客户信息文件（Customer Information File，CIF）解决方案发展为能管理所涉及各方和帐户/安排关系的端到端客户数据体系结构。
- 产品领域： 此功能与“产品工厂”函数相关，重点关注用于支持产品创建和生命周期管理的操作产品目录。
这些方法彼此并不排斥，项目可以在其路线图中使用上述的一个或多个方法。目前，我们看到了很多企业都转向基于业务流程管理和主控数据管理的方法，但是我们会发现，不少的银行仅仅通过应用程序现代化活动来进行核心系统更新。
|
|
应 用程序转换是核心系统现代化最基本的方法。很多银行都通过重构大型机应用程序、为现有应用程序资产启用服务或重新编写当前解决方案的各个部分来实现此方 法。这样做的一个局限在于，此方法经常意味着要采用 IT 驱动的自底向上方法进行核心系统更新。尽管应用程序转换可以帮助您进行发展下一代核心系统的初始步骤，但此方法经常是战术性的响应，仅限于公开一个或多个 关键资产或为其启用服务。通过结合范围更广的战略活动（如业务流程管理或主控数据管理），应用程序转换可在业务驱动的核心系统方法中扮演重要的角色。
Jim Rhyne 撰写的文章 SOA programming model for implementing Web services: SOA and the mainframe software environment 中认为，“扩展大型机”方法通常是总体拥有成本最低的最简单的基于 SOA 的备选方案。之所以基于 SOA 的应用程序转换是更新方法中的一个重要组成部分，这是其中的一个主要原因。从面向服务的角度分析应用程序转换时，一个存在问题的方面就是候选服务的标识以 及后续的服务规范制定和建模。我们敦促客户使用面向服务的建模和体系结构（Service Oriented Modeling and Architecture，SOMA）方法来开发服务模型和总体 SOA 方法。在 SOMA 服务标识阶段，资产发现会使用 IBM Rational® Asset Analyzer 和 CICS Interdependency Analyzer 之类的工具来生成资产元数据。通过分析此元数据，客户能够对潜在资产进行隔离和标识候选服务。
在资产分析阶段，我们建议客户选择 少量的关键领域或应用程序作为重点。一旦资产发现流程标识了潜在的资产，会将此信息与业务需求进行结合，以筛选潜在的候选服务。IT 驱动的应用程序转换项目经常会跳过这个关键的步骤，因而可能会标识出数以百计的细粒度候选服务。这种情况下可能会设计出不面向业务的服务，不能反映所需的 目标核心系统状态，从而极大地限制了 SOA 方法的有效性。
Information FrameWork FS-BOM 和 FS-IDM 模型从业务和技术的角度提供了对组件服务的设计和开发的支持。这些模型支持与 IBM Rational Software Architect 集成来支持设计活动，而且通过提供用于服务定义和实现的模型来支持服务标识和规范制定阶段。我们当前的一个银行客户使用 FS-IDM 模型来指导设计工作，以将目标金融产品管理服务作为与 Banking Center of Excellence 合作项目的一部分进行集成。
在服务标识和规范制定之后，将会开始服务实现活动，执行服务实现任务。应用程序转换的备选方案通常可归入三个主要方面：
-
包装资产： 此 方法包含多项技术。一个颇受欢迎的技术可让客户使用 Host Access Transformation (HATS) 之类的工具重构 3270 个用户界面，以生成基于 Web 的接口和服务。很多客户通过 J2C 适配器开发或使用利用 CICS 和 IMS 提供的 Web 服务框架来采用面向服务的方法。这些基于 SOA 的开发任务通常会使用 IBM Rational Developer for System z™ 之类的工具。经常会使用企业服务总线 (Enterprise Service Bus) 模式对这些外部化的服务或操作进行扩展，以提供中介、转换和路由。
-
重新设计资产结构： 此方法对资产的特定方面进行扩展。通常，我们会看到企业使用此方法来支持数据访问的重新定义（例如，从 IMS-DL/1 过渡到 DB2®）。这也提供了用于通过 IBM WebSphere MQ 或 JMS 之类的解决方案为应用程序启用消息的方法。
-
重新构建资产： 此 方法是最复杂的，且特点是要通过 Java™、COBOL、C 或 IBM Rational Business Developer 重新编写资产。这些重新构建活动通常伴随着将功能重新部署到新解决方案体系结构（如 WebSphere Application Server）的工作，例如，有时候会将资产重新部署到分布式平台。该转换方法的成本开销最大，需要谨慎的评估来确保解决方案与将来需求的一致性。此外， 此设计需要详细规定当前资产的退役过程，而这还需要进行依赖关系分析和规划。
|
|
通 过面向流程的方法进行核心系统的渐进更新是保持业务需求与 IT 一致的关键。使用心脏旁路手术对此进行类比可能比较合适，因为 BPM 方法使用了由流程和服务组成的中间层来扩展核心应用程序。尽管此方法较为复杂，但这是一个得到了广泛应用且经过测试的常见方法。BPM 方法的特点是，要使用基于 SOA 的 BPM 技术（包括 WS-BPEL）将服务聚合为面向业务的高阶服务和功能。
这个面向 流程的方法从作为服务标识的一部分的领域分解技术开始。这组活动将指导业务架构师使用流程建模技术来标识和分解主要业务功能。在客户合作项目中，我们经常 使用 Information FrameWork 业务流程来加速核心系统业务流程的发展；这些模型可以直接与多个工具结合使用，包括 ARIS、IBM WebSphere Business Modeler 和 IBM Rational Software Architect 等。
尽管严格来说，业务流程管理能够作为流程建模和分析工作的一部分进行，但实现可执行业务流程仍然是解决方案方法中一个重要的部分。通过松散耦合的编程模型对服务组件进行编排，可以创建存在于不同应用程序、平台甚至组织中的业务服务。
核 心系统解决方案设计的这个面向流程的方法如图 2 中所示。此关系图描述了作为高级业务服务的小额贷款，此业务服务由多个流程组成，如贷款发起、贷款服务和贷款完成。每个流程调用原子服务和组合服务，如接 受申请、调查信用度等等。而每个服务，反过来提供特定服务组件的接口，这些服务组件可能是适配器操作、消息流或其他封装了操作系统的功能的接口组件。此 外，流程还利用了在关系图右侧的集成、服务质量（Quality of Service，QoS）和数据层中描述的技术服务组件。通过为核心系统集成启用松散耦合方法，业务处理方法提供了可更方便地生成新业务服务的基础。
基 于 BPM 的 SOA 解决方案中间层还提供了支持服务的服务使用者应用程序开发。因此，通过解决方案分层，银行可以为公开的服务开发基于渠道的接口（例如，移动、直连、 Internet），然后根据需要充实或扩展渠道层。例如，此方法支持从业务服务（如贷款发起）生成 Portlet。
|
|
作 为现代化的第三个方面，主控数据管理模式提供了通过更为简单且统一的数据体系结构扩展和增强核心银行应用程序的解决方案。当前核心系统中一个重要的缺陷 是，存在作为关键数据源的应用程序，数据量会大幅度增加。缺乏“事实的唯一版本”会带来维护难题，导致违反法律规定和出现数据不一致。企业主控数据管理 （Master Data Management，MDM）方法能够提供“事实的唯一版本”，从而增强核心系统功能和提供过渡到下一代目标核心系统的方法。
文章 Master Data Management architecture patterns 讨论了 MDM 方法的体系结构方面，并标识了四个关键实现样式：
- 合并： 提供一组有限的主控数据，并支持通过批量导入/导出数据进行同步。
- 注册中心： 为企业应用程序提供对主控数据的只读访问，仅仅在主控数据解决方案中将一个较小的领域信息子集（交叉引用和关键数据）具体化。
- 共存： 在 MDM 系统中将所有主控数据特性具体化，并定期使用分布式创作模式在主控数据解决方案和源/目标应用程序之间进行信息同步。
- 事务： 为所有关键主控数据提供集中创作的操作源（记录系统）——而且主控数据始终保持一致、准确和完整。
我 们发现很多用户都采用共存样式作为过渡方法，以过渡到最终的事务样式。我们当前的一个银行客户使用 Information FrameWork 和 IBM InfoSphere™ Master Data Managerment Server 支持客户主控数据实现和全局产品目录项目。其解决方案最初在 InfoSphere Master Data Managerment Server 及其现有的基于 CICS 的应用程序之间使用基于 SOAP 的服务调用实现了共存模式。作为过渡计划的一部分，我们设计了在接下来 2 到 3 年时间内将解决方案迁移到事务样式的方法。
MDM 解决方案的实现通常通过采用 Information FrameWork FSDM 和 IBM（或其他供应商）的主控数据解决方案进行补充。当前 InfoSphere Master Data Managerment Server 通过使用 Information FrameWork 参考模型提供对客户和产品领域的支持，我们正在对主控数据领域和流程进行增强，以支持更多的银行需求。正如前面讨论的，各个组织使用 FSDM 来指导信息领域的定义工作，使用 FS-IDM 来确定目标服务实现。客户 MDM 解决方案的重点是涉及方领域的概念（例如代理、客户、员工、潜在客户、提供商等）和帐户实体的概念（例如契约、协议、奖励计划、金融帐户等）。举例来说， 某个银行客户当前将 FSDM 与 IBM 的 MDM 解决方案结合使用，以实现全局客户存储库，从而为跨营销关系管理和客户体验改进提供支持。
产 品主控数据管理方法提供了在单个目录或存储库中的全局产品功能的实现，能够为缩短新产品的上市时间和跨多个业务领域和应用程序的产品管理提供支持。产品领 域主要关注产品实体和特定产品的特征（如属性、规则、条款和条件、定价、风险等）。产品领域支持跨帐户和位置领域的支持。
|
|
最 后，对必须作为渐进现代化解决方案的一部分进行设计、开发和管理的非功能体系结构方面进行审查的工作极为重要。毕竟，当病人接受手术时，务必维持其生命特 征。而这要在病人参加马拉松的同时进行就变得富有挑战性了；需要在渐进方法中提供对当前功能的完全访问，并同时对这些功能进行增强。新解决方案的非功能方 面必须与当前环境一致，才能达到应用程序使用者的预期要求。
BCOE 与大量客户一起对其当前环境及其对核心系统更新的准备情况进行了评估。这些评估揭示了其操作环境中的产品流通空白，并对开始核心系统更新方法之前关于纠正基础设施问题的建议所带来的缺陷进行了监控。这里的要点是，您并不希望“对病恹恹的人进行手术”。
必须在对每个服务、流程和数据函数进行建模的过程中确定非功能需求。在评估各个方法时，应该对多个关键非功能领域进行评估，如：
-
性能和可伸缩性： 新 解决方案必须支持相同的工作负载（以及项目规定的工作负载），且响应时间与当前系统相当。此要求可能会强制在设计和实现之间进行折衷，以包括服务建模决 策、服务实现选项、虚拟化技术以及扩展解决方案的引入（例如，IBM WebSphere DataPower® 之类的设备、zIPP 和 zAPP 之类的大型机专用引擎和 IBM WebSphere Extended Deployment）。
-
可用性和可靠性： 与性能和可伸缩性类似，用户希望解决方案具有与当前系统一致的正常运行能力和可靠性。通过添加的额外组件来支持现代化时，设计必须标识硬件和软件冗余、故障转移功能的定义和保证以及关于远程站点恢复的其他注意事项。
-
安全性： 在现在这个充满黑客的时代，安全性的重要性越来越明显。大型机多年来的一个关键特征是在硬件和软件级别具有可靠的安全性。通过引入新的解决方案组件，可能会出现新的安全注意事项，而需要引入联合安全性解决方案或安全组件（如 DataPower 设备）。
-
管理和监视： 通过引入新的解决方案组件，需要对管理和监视需求进行重新评估。因此，用户需要评估用于管理这些解决方案的系统管理资源（工具和人员配备）。可能需要添加其他工具，也可能需要开发其他操作流程和过程来管理这些新解决方案。
由于上面的原因，平台决策（硬件和操作系统）在现代化方法中变得非常关键。考虑到核心系统普遍分布在大型机上这一事实，将新解决方案部署到大型机上的呼声很高。大型机的主要优势包括：
-
流程性能： 大型机是性能和可伸缩性的标准，只有大型分布式系统才能与之媲美（对于特定类型的应用程序，在某些情况下甚至超越了其性能）。
-
管理： 即使在性能与分布式解决方案相当时，大型机的可靠性、持续操作能力、安全性、退款支持和虚拟化均超过了与其相当的分布式平台功能。
-
对 SOA 的支持： CICS 和 IMS 环境中的关键更新支持直接实现 SOA 和新组件方法。这是大型机领域一个关键的发展功能（同时也是核心更新方法的一个重要方面）。
-
绿色活动： 新近对“绿色”计算的关注是大型机方面一个重要的优势。冷却和能源利用方面的进步已经让大型机在处理分布式环境中部署的类似工作负载时具有巨大的优势。
要 说明的是，我并不是不赞成使用分布式系统，关键是要为解决方案找到合适的平台。尽管我们发现目前有将核心银行系统部署到分布式系统的趋势，但大型机（和 System z）在支持混合工作负载方面拥有绝对的优势，而且将继续提供支持核心系统操作所需的可伸缩性、可靠性、安全性和可用性。
除 了确定最优平台方法外，现代化工作的软件解决方案堆栈定义还带来了一系列重要的体系结构决策。正如我们提到的，有三个主要方法，而每个方法都需要引入新的 开发和运行时解决方案。通常，客户已经有了其中的很多解决方案，不过尚未将其应用到核心系统解决方案中。完成我们前面讨论的核心系统更新方法范围内的工作 所需的组件包括：
- 流程服务器解决方案 ，如 IBM WebSphere Process Server：这个组件提供了用于执行基于 WS BPEL 的流程解决方案和支持人工任务管理的框架。
- 服务注册中心/存储库解决方案 ，如 IBM WebSphere Service Registry and Repository：此解决方案组件支持发布、查找、丰富、管理和治理服务与策略的能力。
- 门户服务器解决方案 ，如 IBM WebSphere Portal：此组件为面向用户的基于角色的应用程序和关联的搜索、个性化及安全功能提供运行时环境。
- 规则引擎解决方案 ，如 iLog Jrules：此组件提供业务规则管理系统，用于定义和管理业务规则和策略。
- 企业服务总线解决方案 ，如 IBM WebSphere ESB、WebSphere Message Broker 和 WebSphere DataPower SOA 设备：这些组件将服务中介作为面向服务的体系结构实现的一部分提供。
- 主控数据管理解决方案 ，如 IBM InfoSphere Master Data Management Server：此组件对跨客户、产品、帐户和其他关键主控数据领域的数据进行管理。
图 3 显示了用于支持核心系统现代化的综合软件堆栈。尽管支持更新项目并不需要所有的组件，但此关系图中显示了用于支持应用程序转换、BPM 设计和部署以及银行主控数据管理方法的可能最终目标体系结构。
|
|
如 果您坚持到了现在，那么祝贺您，您已经是一个业余心脏外科医师了！把幽默放在一边，银行必须制定内聚的一致方法来进行核心系统的更新工作。当前系统并不能 满足需要，这些挑战性解决方案还会在很多重要的方面对银行造成阻碍。回顾核心系现代化的历史，我们发现自底向上设计和业务线方法会催生竖井式的 IT 决策，加速这些解决方案的衰退。在不断发展中，我们发现成功的核心系统更新项目需要自顶向下设计。如果没有强大的业务体系结构和支持，现代化项目会面临极 大的挑战。
我们在进行客户的核心系统现代化合作项目的过程中总结了大量的经验教训。其中包括：
-
成功的核心系统现代化项目能够从仅仅关注一个或两个领域的做法获益。与完全替换相比，通过基于业务优先级制定路线图，核心系统中的迭代式改进可减少风险，为不断变化的业务需求提供更好的支持。
-
行业模型方法（如 Information Framework）能提供参考组件来帮助定义目标业务体系结构和总体技术解决方案方法。基于模型的方法能实现更好的业务-技术一致性，为新解决方案的设计和开发提供所需资产（服务和流程）。
-
采用有序的方法（如 SOMA）来进行服务设计对业务相关的解决方案开发极为重要，是应用程序转换、BPM 和主控数据管理更新方法的关键。
核 心系统现代化方法的制定与业务战略直接相关。通过基于业务优先级制定路线图，银行可以像做外科手术一样扩展和替换其“心血管系统”的各个部分。以增量方式 引入应用程序转换、BPM 方法和主控数据管理解决方案是形成完整现代化解决方案基础的活动。对于需要全面核心系统替换的银行，可以采用多种核心系统替换战略来管理风险和提供端到端 核心银行解决方案的 ISV 和自定义方法。核心系统现代化的成功源自战略性的思考方式和战术性的执行方式，通过应用经过验证的方法来支持银行“在马拉松期间进行心脏手术”。
|
|
9103
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
