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

　　小时候，我是恐怖电影迷，喜欢的电影比如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项目，因此，也遇到过（在大多数情况下也解决了）许多这样的挑战。许多中型银行正在与这些挑战搏斗，希望本文已经指出了一些需要考虑的关键问题，帮助您预防您的解决方案成为另一个可怕事件。

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