评论专栏: 核心银行转型最差实践和其他可怕事件

当大型 IT 项目不安全时

在追求目标解决方案架构的过程中有许多可怕事件,这一点许多架构师都可以证明。有时,这些情况出现的原因是缺乏经验,但如果不以合理的架构视角来审视给定场景,也会出现可怕的事情。本文将检查几个实际场景及其关联的解决方案,以期防止类似的灾难。 本文来自于 IBM WebSphere Developer Technical Journal 中文版

Scott Simmons, 执行 IT 架构师, IBM

Scott Simmons 是 IBM Worldwide Banking Center of Excellence 的首席银行解决方案架构师。在供职于 Banking Center of Excellence 之前,Scott 曾经是 Worldwide SOA Technical Architecture 团队的首席架构师,是全球 50 多个 IBM SOA 架构师的技术领导者。Scott 既是 IBM 认证的高级 IT 架构师,也是 Open Group 的总 IT 架构师。Scott 擅长于为客户和合作伙伴设计、开发及实现 SOA 体系架构,他还是一个认证的 SOA 解决方案设计师。Scott 在很多杂志上发表过文章,包括 WebSphere Developer Technical Journal、Web Services Journal 和 WebSphere Journal。在 IBM 工作之前,Scott 曾经是 Chief Technology Office 的首席架构师,在 Peregrine/Extricity 担任技术解决方案主管。Scott 在集成、消息架构以及采用 Vitria、Illustra/Informix 和 Sybase 的数据架构设计/部署方面具有广泛的经验。


developerWorks 投稿作者

2010 年 10 月 21 日

这是一次黑暗、激烈的设计会议......

小时候,我是恐怖电影迷,喜欢的电影比如 The Creature from the Black Lagoon(黑湖妖谭)The Blob(变形怪体)。即使现在,我也喜欢恐怖故事,尽管我从来没有想象过有一天会遇到比真实生活中的可怕事件更恐怖的事情。

但是,在我担任 IBM® Worldwide Banking Center of Excellence 的解决方案架构师期间,我偶尔会看到一些客户情形,这些情形可能会使一位架构师感到毛骨悚然。我想和您分享我在帮助一些银行开发核心银行现代化战略时遇到的一些更可怕(和难以置信)的事情。我不是要在这里谈论妖魔鬼怪或其他生物,而是一些可怕得多的东西,原因是它们真的存在:最差实践

我将在下面与您分享的一些实际言论是某些组织的阴影中潜伏着一些可怕事物的有力证据。我的目标是将这些可怕事物从它们黑暗的藏身处拖出来,将它们展示在光天化日之下,帮助您判断类似的 “小鬼” 是否可能会给您的工作带来巨大破坏。


走向光明

  • 言论:“我们可以稍后对非功能性要求进行文档记录 — 现在只需关注功能设计。”

    在一次关于 Internet 银行解决方案设计的会议期间,Bank A 的一位架构师提出一个问题:他们的终端用户登录需要超过 25 次单独跳转才能验证外部客户的访问。那位架构师表达了对性能和可用性的忧虑。但该银行的 IT 安全团队的一位核心成员回答说,安全架构是固定的,项目架构师应该 “将安全问题留给专家处理” 并且 “现在只需关注功能设计”

    这种言论为何可怕:

    主要的两难处境是关于功能和非功能(包括安全性)方面的架构决策需要在项目早期、基于每个项目进行分析。作为解决方案设计的一部分,架构师需要关注解决方案的所有非功能方面。尽管安全基础架构也许会被视为固定的,但评估其他方案的要求是一个完整解决方案设计的关键部分。对于这个特定情况,架构团队继续评估其他方案以解决安全性能问题,并最终实现了一个安全设备,作为解决方案的一部分。

  • 言论:“作为您的关键 ISV,我们的目标是支持您的所有需求......我们有一个灵活的解决方案,能够轻松实现新功能。”

    在 Bank B 的一个战略核心银行项目期间,一名 ISV(独立软件供应商)说出了这一惊人言论。很明显,那个包正在被增强和扩展,作为特定客户的实际项目实现的一部分。

    这种言论为何可怕:

    一方面,调整已打包应用程序以适应客户需求的能力是一个关键特性;但是,那些增强远远超出了简单的调整。我们知道出现这种情况的原因是匆忙的 RFP(征询方案)评估,我们督促客户确保需求清晰,并在评估过程中全面审查那些需求。我们建议使用一些适当工具来支持需求定义,并使用这些工具来支持需求验证。在评估期间,组织需要确保供应商的答复完全清楚地阐明产品功能,而不是提供模糊的未来功能承诺。

    另一个问题是,我们发现核心银行应用程序(尤其是那些由客户直接完成的应用程序)中的基本更改常常导致版本锁定,以致于不能随着新发布升级;结果,客户必须评估升级方面,作为解决方案设计的一部分。

    这个客户获得了一个宝贵的教训,但代价高昂:项目启动 18 个月之后,IT 执行团队取消了项目,那家银行现在正在审查替代方案,在此过程中,他们聘请 IBM 作为可信顾问。

  • 言论:“我们需要再添加两个功能需求到最新发布中 — 但它们只是微小的更改。”

    Bank C 的一位重要股东在与项目设计机构进行的一次设计会议中提出这一点。那家银行正在致力于通过基于他们的内部 CICS® 的核心银行解决方案的服务来与一个第三方银行包集成。

    这种言论为何可怕:

    核心银行现代化项目(以及一般的大型复杂 IT 项目)需要严格的规划和项目管理才能成功。由于核心银行项目中拥有大量依赖项,因此基本更改控制是强制性的。尽管需要制定一些例外情况,但例外情况必须作为正式治理和项目管理流程的一部分进行管理。管理和协调更改请求可能比较困难 — 客户应该使用适当的项目管理工具和方法来确保基线项目控制。在这个特定案例中,该股东没有意识到更改(不管多么微小)将转换为时间、金钱和风险,这种行为照常执行。

    那家银行最终由于项目交付的持续延误而放弃了该项目 — 一个有效的项目设计和治理机构应该能够改变这种不幸的结果。IBM 正在与那家银行合作,以建立一个更严格的项目管理功能,从而避免将来发生类似的情况。

  • 言论:“我们能够将我们的 CICS 事务映射到我们的 SOA 解决方案中的服务吗?”

    在一项部署 Bank D 的 CICS Web 服务的工作中,这个问题反映了该银行没有遵循任何服务设计方法系统。

    这种言论为何可怕:

    随着时间推移,该银行已经构建了 3,000 多个 CICS 事务,从简单的数据查询到复杂的事务功能。在我们的工作之前,该客户已经决定为通常使用的 CICS 事务实现 CICS Web 服务,但不进行业务或技术需求评估。本质上,该客户正在从资产分析直接迁移到候选服务。我们建议采用 SOMA (Service Oriented Modeling and Architecture) 来支持项目中的服务设计,并将其用作该组织的一个参考方法系统。具体而言,我们建议客户关注服务识别中的步骤,以确保候选服务的识别,并建议他们使用 SOMA Service Litmus Test 方法系统来确保实现正确的服务。

    这个客户案例的结果是积极的:我们增强了客户的服务设计方法。作为一个一般原则,您不应该为了减轻上市时间压力而牺牲良好的服务设计。

  • 言论:“我们不能只用我们的现有消息传递技术来支持内容管理需求吗?”

    在设计一个帐户管理解决方案的过程中,这个问题被提出来,当时 Bank E 正在定义文档管理需求。鉴于他们使用 IBM WebSphere® MQ 并拥有用户界面开发技术,开发人员最初提议编写一个自定义的轻型内容管理解决方案。

    这种言论为何可怕:

    尽管该团队为解决方案开发了一个基于 SOA 的可行设计,但这种方法并不是解决这种类型的需求的正确方法。评估内部开发的关键标准是 TCA(采购总成本),但由于对是否应该解决 TCA 挑战犹豫不决,该银行没有评估内容管理需求的范围和代码维护的长期影响。

    我们不断看到有一些组织针对基础架构需求开发自定义解决方案,只是为了降低成本。作为团队顾问,我们说服了客户避免构建内容管理功能。该银行不再试图开发一个自定义解决方案,相反,他们实现了一个基于供应商的内容管理解决方案来支持这些需求。尽管所选解决方案提供的功能超出了项目的实际需求,但从维护和开发角度看,供应商解决方案提供了长期的成本节约。

  • 言论:“服务规范是 WSDL。作为开发人员,这是开发服务需要的惟一文档。”

    在 Bank F,一位关键开发人员在一个贷款处理解决方案的设计审查讨论中发表了上述言论。

    这种言论为何可怕:

    服务设计的一个关键方面是:服务必须很好地进行文档记录,作为开发生命周期的一部分;设计应该定义功能和非功能需求,包括服务交互方面、服务水平协议(SLA)、服务所有权、服务政策、服务构成方面、以及其他相关元数据。简言之,服务规范不仅仅只是 WSDL。另外,服务设计需要作为整个治理机构的一部分进行管理,开发机构需要积极参与这一管理过程。

    这个示例中提出的挑战是一个设计流程(或设计流程缺乏)问题,也是需要提供一些工具来支持服务设计和资产重用的需求问题。这个案例的结果是采用了一个更广泛的服务设计方法并引入了一个服务注册表和元数据管理工具,以支持更完整的服务定义 — 这促成了一个经过优化的服务设计和提高的资产/服务重用率。

  • 言论:“系统测试需要太多资源,且非常困难 — 我们没有足够的硬件来正确执行系统测试。”

    Bank G 的一位 IT 执行官在回顾他们的基于 SOA 的核心银行项目时非常坦率地发表了上述言论。

    这种言论为何可怕:该银行显然有一个主要问题:它需要支持 7 个环境(单元测试、集成测试、系统测试、用户接受度测试、压力/性能测试等),有 30 多个打包和内部应用程序,使用多个不同的数据库。我们建议引入自动化配置解决方案,增强测试调度和请求,以便提高效率。这些改变解决了眼前的困难,但不能解决长期挑战。结果,此客户现在正在评估一个开发/测试私有云的实现。

    核心银行转型项目非常复杂,我们认为实现虚拟化和人工配置不能完全解决风险和资源管理问题。展望未来,随着许多世界级银行寻求实现或现代化现有的核心解决方案,我们预计测试/开发云的实现将成为一个受人喜爱的架构。

显然,您可以从我们在全世界范围内看到的一些核心银行项目(或任何大型 IT 项目)中吸取一些经验教训。大多数大型银行已经实现了大型 SOA 项目,因此,也遇到过(在大多数情况下也解决了)许多这样的挑战。许多中型银行正在与这些挑战搏斗,希望本文已经指出了一些需要考虑的关键问题,帮助您预防您的解决方案成为另一个可怕事件。

于我而言,我很高兴地说我偶尔仍然会遇到一些可怕事件,但我乐在其中 — 这是件好事,因为它们肯定会使我的工作充满乐趣!

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere, Open source, SOA and web services
ArticleID=551933
ArticleTitle=评论专栏: 核心银行转型最差实践和其他可怕事件
publish-date=10212010