架起企业架构与解决方案架构之间的桥梁以获取最大利益

作者：Manuel Ricca

2011 年 9 月发布

简介

企业架构 (EA) 和解决方案架构 (SA) 通常被视为不同的做法。在这两者中，EA 通常被认为相对丰富但过时，而 SA 相对实用、可靠和有效。

这种看法并不总是公平的。在论坛中经常会发现这样的问题，如“您能否用一句话解释 EA 的价值？”或“妨碍 EA 取得成功的主要障碍是什么？”甚至更糟糕的问题。单凭这些问题就能表明 EA 经常被完全误解，最终成为一种很少接触组织实际问题和机遇的孤立功能。

但另一方面，实际上并不难理解 EA 在哪些方面能够提供价值 — 许多价值。重用、标准化、创新意识、IT 与业务之间的协调等原则，显然都可以帮助任何组织减少不受约束的、多余的成本，而不是使用昂贵的 IT 部门来提高效益和提升业务水平。问题不在于“为什么”或“什么”，而在于“怎么办”。而“怎么办”正是 SA 所擅长的。

换句话说，为了实际了解 IT 环境及业务领域的未来需求，架构师需要参与 IT 项目。只有这样他才能在实践中验证他的建议，而不仅仅是纸上谈兵。金钱不是抽象的，因此花钱时不能基于抽象的结构。

所以很明显，EA 和 SA 必须一起工作来有效地构建一个架构环境，以最小的浪费获取最大的利益。实际上，EA 和 SA（包括网络、软件、安全架构等）是架构这个业务功能的不同方面。它们的目的都是根据组织的优先级来优化资源的使用以满足各项业务需求。打造最优环境存在许多挑战，这无疑要基于面向服务的架构 (SOA)。

下面几节中的步骤介绍了可用于 IT 项目和更改管理过程的一种方法和一些工具。万一发生更改时可以更容易地驾驭更改。

与业务用户和业务分析师协作建立业务架构模型

为系统创建架构概念的第一步是建立业务模型。一般来说，在任何组织中，人们扮演各种角色，通过其角色执行业务流程为别人提供业务服务。为支持这些流程，提供了各种应用程序服务并在应用程序组件和功能中加以具体实现。这些服务使用基础架构服务和物理节点，如网络、服务器、存储等。这将提供一种分层业务模型，其中包含了架构师开始设计系统所需的大部分信息。ArchiMate® 元模型很好地体现了这个概念：

图 1：ArchiMate 元模型（来源：http://www.archimate.org）

业务建模使架构师可以直接参与到业务领域中，只要确定了用户需求（或者用例或用户案例，取决于所使用的方法），那么在任何新项目一开始就进行业务建模是一种非常好的做法。正如长期参与 IT 项目的人士所了解的，也正如所有项目失败统计信息所显示的，项目中的大部分问题早在开始实施之前就已萌生了。需求不明确或不完整、对业务流程缺乏了解以及不断变化的需求（通常是由前面的原因之一造成的），这些都是最常见、代价最高昂的问题的来源。敏捷的方法有助于处理这些问题，但仍然难以在 IT 与业务之间找到共同语言。

这一切都是因为没有从全局出发考虑问题。如果架构师可以建立一个模型并向业务用户展示，那么业务用户将立即判别出业务角色、服务和流程的表示是否准确。这将引发讨论，从而使架构师可以了解业务流程。另一方面，业务用户也能够了解架构师如何打造他们要使用的系统。

The Open Group 目前采用的 ArchiMate 很擅长将人员聚集在一起，因为这样可以很容易地构建和了解模型。一两页的高级模型可以自上而下地显示参与者、角色、业务服务和功能的视图，新的和现有的应用程序和基础架构服务预计如何为它们提供支持，以及它们如何与其他应用程序服务接口。通过架构分析评估不同方案 一节提供了一个示例。

为每个共享服务指定设计模式

架构负有重大责任的关键领域当然是优化对企业资源的使用。资源是（或者至少应该是）通过服务提供的，这些服务具有定义了附加的服务级别协议 (SLA) 的约定。

使用这些服务时应遵循架构功能所制定的指导原则。否则，架构师很快就会搞不清楚实际上实现了什么，而且架构师所能提供的最大价值（促进重用、优化资源、降低成本和支持业务更改）也将“在转换中丢失”。

一般来说，构建 SOA 实际上是架构的最大挑战。尽管一再证实模型可带来最大的效能提升，但事实情况是，由于它没有考虑到传统的垂直层次结构，其实现在大多数组织中造成了混乱。具有讽刺意义的是，在组织内构建优化架构的主要障碍多半来自于组织本身。

部署企业服务总线 (ESB) 是对系统全局进行控制的关键要素之一，但还不够。市场上的大多数 ESB 可以提供需要从 SOA 基础架构获得的一切服务，如 Gartner 报告“SOA 应用程序基础架构的参考架构”中所述：编排、活动监视、社区管理、通信适配器、消息转换、调解和数据集成，所有这些都通过一个安全、集中管理的高可用性平台来提供。但拥有所有这些工具并不能保证它们得到合理使用。ESB 处的接口和消息流应根据预先建立的集成模式来设计，以确保在实际中能够得到重用且不会重叠。

对于各种技术，存在许多模式来源。为了有效地使用它们，最好是了解组织当前所需的模式，然后通过反向工程将现有接口转变成众所周知的模式。这项工作应产生一个列表，将来可以根据需要对其进行扩展。该列表应成为所有新接口的参考，并且尽量使用它对现有接口进行重新设计。

通过架构分析评估不同方案

正确建立业务模型并在业务用户的期望与架构师的认识达成完全一致之后，就该对应用程序架构建模了。

架构师应将用户需求、构造的业务模型、应重用的服务、相关策略、需应用的模式以及安全和操作要求作为输入。有了这些输入，架构师应生成一个或多个可行解决方案架构并推荐其中一种。

还可以使用 ArchiMate 对所推荐的一种或多种架构建模。应用程序模型作为业务模型的底层插入到它的下面，应用程序服务由确定的业务流程“使用”。

以我的个人经验，最终的自上而下的模型至少应包含不同层中的顶层行为和结构元素。视图的全部目的（如 ISO/IEC 42010:2007 中所定义）是在恰当的抽象级别向特定的人员提供正确的信息。自上而下的视图使业务用户和架构师（几乎所有人）能够了解全局。它极少显示有关业务工作方式以及应用程序组件实现方式的详细信息，但却明确显示系统的目的和主要构造块。

图 2：自上而下视图中使用的 ArchiMate 元模型的元素

为了更好地说明这点，下图显示了一个假想的、过于简化的财务报表系统的视图。其中所含信息无意做到完整、具体，甚至可能有些不准确，包含这些信息只是为了说明问题。

图 3：简化的自上而下的财务报表系统视图（点击图像查看完整大小。）

您一眼就可以看出，此图中省略了许多元素。有些是有意省略或模糊化的，但主要的一点是，它很简单，就算非 IT 人士也能理解，虽然如此，它还是清楚显示了哪些元素可以重用，哪些需要创建。它还轻松指明了应将新元素作为独立或共享服务部署在什么位置以及应将插入 ESB 中的什么位置。

可以也确实应该针对不同对象创建其他视图，例如，视图可以显示详细的业务模型、信息流、物理节点、系统接口、应用程序组件等等。将所有内容放在一个视图中既不可能，也不可取。

一旦生成高级模型，即可着手执行结构化分析来比较竞争解决方案并识别任何所需架构决策所产生的风险、机遇和成本。即使只有一个设想的解决方案，这么做也很有必要，因为有助于提前检测任何架构问题。

一个较好的办法是使用美国软件工程学院的架构权衡分析方法 (ATAM)。简单来讲，该方法主要用于针对用户场景来测试架构。这些场景包括用例、预期增长的场景以及某些探索性（非预期）场景，这意味着对系统进行压力测试。

通过分析系统的各个组件对每个场景中目标质量属性值的行为方式，此测试可明确哪些组件对哪些属性敏感。例如，这些属性可以是性能、安全性、可伸缩性和成本。对多个属性敏感的组件（或方面）将被标识为权衡点，也就是说，它们的配置将对整个架构产生影响，从而有利于某项需求。因此，这些是需要进行决策的点，每种可能的决策都伴随着风险和机遇。

如果架构师已经确定了多个可行的解决方案设计，则此测试需要针对每个方案独立进行，以便在结束后比较结果。

用成本信息对此测试加以完善将非常有用。因为成本最小化的隐含要求始终存在，所以在最终文档中记录每种可能的决策的成本影响将非常重要。成本始终应表示为某个固定时间范围（如 5 年）的总拥有成本 (TCO)，然后进一步将其分解成对组织更有意义的项目。通常，至少应显示投资成本、运营成本和直接分摊的成本（例如许可证）。

向决策者展示架构及其优点：“钱途”

上面测试的所有结果均应写入报告，其中汇总了主要测试结果。此报告不应包括会导致结论的详细技术信息，而只需包括指向完整分析文档的链接。相反，它应包括对所确定的方案、所识别的风险和机遇以及详细成本信息的高级别描述。这样一来，系统所有者、IT 总监以及任何其他利益相关方都可以对下一步的行动做出明智的决策。架构师有一个宝贵的机会明确显示每种决策对整个企业的影响，进而影响新的系统架构以确保其符合目标企业架构。

总之，该报告包括了对所建议的架构及需要做出的决策及其潜在风险、机遇和成本的简要说明。这是架构师生成的最重要的文档，因此不应有任何遗漏、模糊或假设的内容。通常，架构师将需要主题专家（包括业务分析师和 IT 专家）的帮助来完成此文档。

该文档应仅陈述事实并说明每个决策将影响哪些质量属性以及具体影响方式。相关利益方负责在诸如系统性能、安全性和成本之间取得适当的平衡。

评估具体实现和识别合规性差距

完成详细的解决方案设计之后，甚至在实现期间，都可能出现最初形成文档的系统架构不能完全实现的情况。这可能是因为需求发生了变化、意外限制（例如，更少的预算、更短的时间或更少的资源），或者只是因为忽视或错误假定了某个条件。

计划的任何偏离都可能对整个企业产生影响。基于前面产生的分析文档，应该能够确切了解存在什么影响以及何处会产生这种影响。可能需要进行一些其他分析，但这种可能性很小。

无论如何，未经正式批准，系统不应以不同于原始计划的方式实现。为此，架构师应尽快向相关利益方传达预期的差距。

还有一个好办法是在项目实现结束时进行差距分析。最终分析的存在主要只是用作一种威慑，以防止项目团队在项目时间和/或预算紧张时走“捷径”。

如果项目团队预先知道不遵守一致同意的架构设计走捷径最终将导致系统不被接受的风险（根据定义，即项目失败），那么团队很可能不会偏离设计。

按照对业务的影响描述差距

为了撰写预期差距报告，架构师需要执行以下操作：

• 按照实际的业务影响转换差距。
• 了解每种差距的根本原因并以非技术性的语言对原因加以说明。
• 提出缓解措施及其成本和影响。
• 确定并通知受影响的相关利益方。最后，每个相关利益方都需要接受或拒绝更改。这个过程可以让架构师防止可能有损 SOA 的偏离。

通常，差距报告会导致项目指导级别和管理功能之间的讨论，最终决策可能需要很长时间，至少从项目团队的角度来说如此。因此，在此阶段，期望项目团队和架构师更紧密地协作。

总结

让 EA 涉及项目开发和更改管理是推动 SOA 开发的最佳方式。将每种决策的影响清晰地传达给组织可以快速明了共享服务、投资于可重用组件以及始终在部署前重用（简而言之就是跨业务单元边界一致地管理 IT 环境）可提供最大的收益。

只需通过配置现有组件即可创建许多新应用程序服务（即作为纯组合应用程序）的时代很快就会来临。然后就真正开始节省成本。只需将在一台或多台服务器上安装新应用程序的 TCO 与重用现有服务的成本进行比较。组织的管理敏捷性也将极大提高，更重要的是，变成一种完全受管理的、安全的方式。

实现此方法的主要困难在组织方面。因为每个利益相关方都站在自己的需求一边，而这些需求经常与其他人的需求相抵触，架构师首先需要透明、客观和公正。项目的最大驱动力是按时在预算范围内完成交付，因此对某一“公共利益”的额外投资必须合理且要事先计划。

Manuel Ricca 是欧洲中央银行的一位 IT 架构师，负责确定 ECB 和欧洲中央银行系统的新 IT 系统和基础架构组件的架构，以及对现有 IT 环境的整体优化。加入 ECB 之前，Manuel 领导一家领先的葡萄牙 IT 公司 Novabase 的开发团队。

ArchiMate 是 The Open Group 在美国和其他国家/地区的注册商标。