云服务时代的企业架构-企业架构-火龙果软件工程

分享到

云服务时代的企业架构

作者 Fabio Castiglioni,，火龙果软件发布于 2014-04-30

使用混合的软件即服务（SaaS）

本文通过一个混合的软件即服务（SaaS）示例，展示了如何使用企业架构为公共云服务指定需求。企业架构（EA）是一个关键的工具，可以帮助云客户了解如何利用通过技术支持的新业务模型，以及如何将外部服务融入其现有应用程序和技术环境。通过阅读本文，IT 架构师将学习如何使用 EA 标记和 IBM Rational System Architect 与业务用户及其他利益相关者（包括服务供应商）进行有效沟通。

简介

良好的企业架构（EA）是有效采用面向服务的架构（SOA）的主要推动因素，该观点已在数年前提出（参阅参考资料中 Ibrahim 和 Long 的引文），许多客户已经因为缺乏对 EA 的 “尽职调查” 而付出了项目失败或半失败的代价。架构的主要部分（业务流程与 IT 服务之间的端到端连接）以及已建立的企业架构所提供的日常治理机制，这些都是 SOA 保持其改造业务和企业的技术能力承诺的基本要素。

现在，我可以听到您的脑袋里嗡嗡作响，您心里可能在想 “我一定是打开了不对的文章。这本来应该是关于云计算的文章，而不是关于 SOA 的文章。”

事实是，无论我们讨论云还是 SOA，都要处理服务。

“服务” 是指我们愿意承认，对于关于手头特定问题而言，架构 IT 的粒度可能是不是最优的，我们也愿意接受过度设计（over-engineer）的某些组成部分，以便支持更灵活的重新安排的业务操作。（以标准化接口为例。它不是免费的，而且仅当您真正重用其功能时才会获得回报）。这种水平的灵活性本身只是实现灵活的业务流程的一种手段。同样，这些流程只有在支持灵活、明智的业务战略时才会提供有意义的经济回报。

在实现云（或 SOA）架构时，必须将这样的因果链摆在架构师的面前。否则，他们的决策将会永远缺乏对问题的某些关键方面的考虑。

这意味着，转换该领域的企业架构模型就是执行识别业务对 IT 的关系、依赖关系、需求和约束的尽职调查。

在本文中，我们将从云服务的消费者的角度来探讨如何表示这种模型，以及如何通过它去了解需要做什么和为什么这样做。该消费者可能是一个希望利用云技术将更高水平的灵活性注入其运营的组织。

云服务消费者场景

云参考架构，例如 IBM 或美国商务部的国家标准与技术研究院（NIST）提供的云参考架构，从所涉及的角色集合开始架构云业务。每个操作员都有一个明确的角色。

图 1. IBM Cloud Reference Architecture，与 NIST 的云参考架构类似

IBM 参考架构识别了以下角色：

Cloud Service Creator（云服务创建者），开发将通过云基础架构被使用的新服务

Cloud Service Provider（云服务提供者），管理和运营云基础架构

Cloud Service Consumer（云服务消费者），使用在云基础架构中托管的服务

NIST 则列出了以下角色：

Cloud Provider（云提供者，类似于 IBM 的云服务提供者）

Cloud Consumer（云消费者，相同）

Cloud Auditor（云审计者），可以对云服务进行独立评估

Cloud Broker（云经纪人），能够起中介作用、组成 Provider 的服务，并使其增值

Cloud Carrier（云运营商），有能力提供连接到 Cloud Service Provider 的传输服务

如您所见，Provider（供应商）和 Consumer（消费者）是核心角色。虽然供应商的业务和 IT 模型与传统外包商的模型非常相似，但消费者是最充分利用云创新功能的人。

回到 IBM Cloud Reference Architecture，消费者可以选择四种类型的服务：

基础架构服务（被称为 “基础架构即服务”，或 IaaS），消费者使用相当于硬件系统的服务

平台服务（PaaS，平台即服务），其中服务等价于一个完整的硬件和软件基础架构

软件服务（SaaS，软件即服务），消费者使用业务应用程序

业务流程即服务（有时被称为 BPaaS），消费者将部分业务流程外包给外部供应商

提供者和消费者可能是在同一家公司中的两个部门（例如，IT 运营部门和 IT 开发部门），他们使用私有云；他们也可能是两个独立的业务实体，其中一个负责通过云提供服务。后者是最有趣的示例子，因为它涉及到企业业务模型的变更，而不仅仅是它的其中一个组织实体的模型变更。

在这四种类型的服务中，本文集中介绍使用通过云服务（公共 SaaS）提供的业务应用程序获得新业务功能的特定情况。

云模型的能力所涉及的最后一点是 “平台”。当然，目标是提供服务，但所提供的服务的质量取决于平台所提供的技术和业务支持功能（IBM Reference Architecture 中的两个粉红色方框）。

IBM Cloud Reference Architecture 识别以下支持服务：

服务产品目录及管理

服务请求管理

订单和订阅管理

合同和协议管理

定价、计量和计费

客户帐号管理

等级

结算与交收、应付账款、应收账款

服务交付目录

服务自动化管理

变更与配置管理

映像生命周期管理

配置

事件和问题管理

IT 服务水平管理

监控和事件管理

IT 资产和许可管理

容量和性能管理

平台和虚拟化管理

这些服务中，有些明确支持提供者的业务和技术流程，有些则需要消费者的参与，对他们而言，有些服务实际上可能是新服务，如服务的支付帐单、外部监测信息的关联（用于控制所购买服务的质量），等等。

注意：

即使我们建议将他们的（EA）分析作为采用任何基于云的服务的技术尽职调查的一部分，但本文篇幅有限，不会重点介绍它们。

TOGAF 框架和 ArchiMate 模型

The Open Group Architecture Framework（TOGAF）是一个企业架构框架。在 1995 年开发了 TOGAF Version 1，它以 Technical Architecture Framework for Information Management（TAFIM）为基础，TAFIM 由美国国防部开发。TOGAF 的核心是 Architecture Development Method（ADM），它描述了一个流程，该流程在 8 +1 个阶段中管理企业架构的开发。

ADM 在三个层面上进行迭代：在整个过程中、在各阶段之间，以及在阶段内。它是一种通用的方法，可以定制 ADM，以满足组织的特定需求。例如，一些使用 ADM 的美国联邦机构开发了针对其特定部门需求的架构可交付成果。

ArchiMate 是一个 Open Group Standard，是一个开放和独立的企业架构建模语言，它提供了一些工具，以明确的方式描述、分析和可视化在业务、应用和技术领域之间的关系。

正如在经典建筑结构的建筑图描述了建筑物的建设和使用的各个方面，ArchiMate 提供一个通用语言来描述业务流程、组织结构、信息流、IT 系统和技术基础架构的建设与运营。这种洞察可以帮助利益相关者设计、评估和沟通这些业务领域内部以及它们之间的决策与变更结果。（来源：The Open Group）

ArchiMate 的组织包括三个核心层和两个扩展。

业务层

这一层模拟组织结构和它产生的服务、业务角色和流程，以及产品与合同等业务对象。

应用程序层

它描述了应用程序组件和它们的交互、逻辑数据实体和它们之间的关系，并向上一层（业务层）提供所生成的服务。

技术层

这一层模拟硬件和软件系统，以及连接网络，显示如何将它们转化为提供给上一层（应用层）的服务。

AchiMate 2.0 规范对核心层增加了两个扩展。

动机

动机的概念用于模拟影响、引导或限制企业架构的某个部分的设计或变更的动机或原因。

实现和迁移

这个扩展包括的概念可用于模拟变更项目和迁移规划，以及支持计划、组合和项目管理。

图 2. ArchiMate 表示法的示例

与任何良好的架构模型一样，除了架构层以外，ArchiMate 规范还支持观点。观点用于沟通架构的特定方面。这些方面由利益相关者的关注点决定。因此，特定的观点和不应该包括的内容应该完全取决于利益相关者的关注点。

本文使用了 IBM? Rational? System Architect 的 Corso ArchiMate 2.0 插件，用架构的非功能性观点补充动机业务、应用程序和技术模型，该观点如 Castiglioni 和 Pedulla 的描述（参阅参考资料）。

使用 EA 在企业中集成云服务

即使这里只是一个粗略的介绍，也可以明显地看出，ArchiMate 模型的重点是服务和服务实现。这非常适合于云模型。

我们可以很容易地定义一个 SaaS 应用程序服务，支持通过应用程序组件实现的业务流程。

我们还可以模拟使用一个 PaaS 作为技术服务（或服务的集合），支持某个特定应用程序的组件和数据，这样做也很容易。
因此，SaaS 的功能要求可描述为：

所涉及的利益相关者的动机

它必须支持的业务模型

向其他应用程序或从其他应用程序暴露的接口

如果云和内部系统之间需要连接，则提供消费者的技术水平所要求的服务

SaaS 解决方案的非功能性方面

示例场景：将流程外部化到云

为了更好地理解 EA 模型的使用，从而指定如何使用 SaaS 解决方案，我们将扩展来自 The Open Group 的 ArchiMate 示例。此示例使用一家名为 Archinsurance 的虚构保险公司，该示例假定 Archinsurance 已将现有的 CRM 应用程序确定为实现其业务目标的阻碍。

与所有利益相关者分享动机

Motivation 模型捕获利益相关者的动机和要求。如图 3 的流程图所示，CEO 的动机是双重的：

1.增加对给定客户的重复销售次数

2.在年终之前赚钱

CFO 在现金紧张的时期关注的是资本开支的 ROI，而 CIO 主要担心的则是现有数据中心地板上的可用空间。安全部门的人会反对每一个异地解决方案，因为他们担心客户记录等公司重要数据被盗或丢失，并要求执行公司进行安全实践。

图 3. 新 CRM 的 Motivation 模型

从 CEO、CFO、CIO 和安全部门的要求来看，似乎要在云计算解决方案和更传统的外包之间进行选择，并且更倾向于前者。但是，安全要求难以得到满足，并会将合资格的供应商限制为能够对运动中的数据和静止数据都提供数据加密的供应商。

此外，选中的 SaaS 解决方案不能是一个 “纯” 云服务，因为它必须包含保护机制，避免数据受到未经授权的访问，并且保证云和数据中心之间的数据一致性。因此，它将是一个混合解决方案。

识别来自业务模型的功能性要求

正如前面提到的，该示例假设新应用程序支持前一个应用程序的业务模型和流程。我们的 EA 业务模型将提供指导，以确定需要支持什么。

例如，目前的 CRM 提供了客户管理服务和印刷服务，以支持索赔处理流程。以这种方式识别的服务将是新的 SaaS 解决方案的功能性要求（例如：“索赔的打印输出必须包含以下数据：”）以及非功能性要求（例如：“索赔的格式和打印不得超过 3 分钟“）的来源。

图 4. 受到新 CRM 影响的应用程序服务

设计新的应用程序模型

当我们对未来的 SaaS 解决方案可以满足所有功能性要求感到满意时，下一步是设计如何验证它与其他应用程序（内部应用程序，甚至在云上的应用程序）的接口要求。

图 5. 新的应用程序组合

在本例中，Archinsurance 应用程序组合将改变从图 5 左边的组合修改为右边的组合，其中 CRM 已经成为企业外部的组件。CRM 组件的作用不变，但重要的是要仔细考虑它与其他组件（如，客户数据访问和策略数据库管理）的接口，因为无论是签名（被交换的数据）还是协议（用于交换的技术），都可能会发生变化。（请注意，在 ArchiMate 中，关系的方向与 UML 模型中的关系方向相反。）

为了强调这一方面，我们重新绘制了应用程序模型，让应用程序接口和技术组件（如果有必要）显式实现它们。对于图 5 所示的两个接口，鉴于 SaaS 实现的技术功能，这意味着在我们的网络边缘添加 ESB 技术组件，这些组件能够向公司数据提供 Web 服务接口。我们将对企业数据仓库使用一个安全的 ESB 和一个安全的 FTP 服务，以满足该公司的安全管理人员的要求。

对于 Web 门户的接口，我们已经确定，真正的需求是单一用户 ID 和密码模式可以支持的一个简单的 HTTP 重定向。因此，接触代理将使用一个 ID 和密码对来登录到内部系统和新的 CRM 应用程序。

接口位于 LDAP 数据与云中的 CRM 所使用的身份验证机制中的数据之间（在本例中，我们将 LDAP 更新作为事件推送到 CRM）。LDAP 身份验证和 CRM 合作，以提供（新的）用户身份验证功能，就像 CRM 数据和内部数据集市合作，提供了新的数据仓库功能。

新的应用程序模型将指导我们设计利用现有的内部基础架构来适应新的 SaaS 服务所需的变更。

图 6. 修订后的应用程序模型图

描述非功能性观点

我们需要考虑的最后一个项目是非功能性观点。

我们的重点在于以下两个方面：

SaaS 解决方案必须能够支持哪些非功能性要求（NFR）

我们需要做什么来连接两个系统，这将如何影响内部基础架构的 NFR

事实上，新服务必须满足一组复杂的 NFR，其中一些 NFR 源于业务需求（例如，打印时间），另一些来自其他利益相关者，如安全管理人员。

此外，可能会增加一些要求，形成强调新服务的复杂组合（例如，有大量并发用户时的响应时间），在我们宣布可以接受 SaaS 解决方案之前，必须验证这些要求。

服务供应商的内部架构和基础架构并不是我们所关注的（尽职调查除外）。因此，无论我们执行何种验收测试，都将执行一个黑箱测试。但是，必须考虑到基础架构。在我们的模式中，必须对保护 Archinsurance ESB 的 XML 防火墙和 HTTP/FTP 防火墙进行配置，以便考虑到公司与服务供应商之间的新流程。

图 7. CRM SaaS 非功能性观点