| 企业架构核心，第 6 部分: 可管理性 | |||||||||||||||||||||||
| 摘自: IBM developerWorks China 被阅读次数: 11 | |||||||||||||||||||||||
由 yangyi 于 2008-05-08 19:20:57 提供 | |||||||||||||||||||||||
2008 年 2 月 21 日 当今组织面临两个重要企业架构需求的挑战：对敏捷性的需要和法律法规治理的开销。可以将这些需求视为相互对立的——如果业务流程必须灵活，则那些流程的治理可能非常困难。本文是包括六个部分的 “企业架构核心”系列 中的第六部分，其中探索“将可管理性作为解决此问题的关键企业架构（Enterprise Architecture，EA）质量属性”的概念。EA 开发是一个持续的过程，本文的中心思想在于，通过将可管理性作为一个 EA 属性来进行应用，组织流程、系统和软件将变得可管理。 当今组织面临两个重要企业架构需求的挑战：对敏捷性的需要和法律法规治理的开销。可以将这些需求视为相互对立的——如果业务流程必须灵活，则那些流程的治理可能非常困难。对敏捷性的需要越大，治理就变得越困难。将可管理性用作 EA 质量属性可以帮助解决此问题。如果 EA 支持可管理性，则可以对该 EA 的已实现元素进行编排。这反过来允许实现所需级别的业务敏捷性和治理。本文将探索作为关键 EA 质量属性的可管理性概念。文中将描述两个支持可管理性的工具：Apache Geronimo 和 IBM® WebSphere® Application Server。EA 开发是一个持续的过程，本文的中心思想在于，通过将可管理性作为一个 EA 属性来进行应用，组织流程、系统和软件将变得可管理。然后可以将此可管理性用于各种各样的目的，例如按业务需求驱动信息技术 (IT) 基础设施、提供敏捷性，以及促进治理。 本系列中前面的文章讨论了架构对企业的不断增长的重要性。从这些文章中学习到的经验在于，良好的架构可以同时提供业务价值以及为 IT 基础设施提供好处。这是通过设计 EA 将人员、流程和技术有效地联系起来实现的。在本文中，我将研究作为架构质量属性的可管理性问题，以及作为架构质量属性的可管理性如何提供了更大程度的敏捷性和增强的 EA 长期性。但是，可管理性的概念有点抽象——其含义是什么，是否可以举出例子呢？ 简而言之，可管理性 意味着能够查看和修改给定系统或软件部分的状态。管理操作在大小和规模上涵盖从启动计算机到初始化大规模工资单运行的范围。请注意，我举的两个例子分别是计算机级别的交互和业务流程启动。 如果关联的 EA 作为架构质量属性包含了可管理性，则类似如上的操作很容易执行，并且更重要的是，可以实现这些操作的自动化。关联的好处会在整个企业范围内显现出来。 您可能认为启动一个业务流程实际上不是 一个管理操作。此类操作过去是不同于管理操作的单独操作。我认为这种看法是错误的。与系统和软件的所有交互在概念上都属于管理操作。打开一个电子邮件消息是一个由本地用户发起的管理操作。备份一个多服务器数据库也是一个管理操作。显然，后者是由 IT 管理员执行的操作，但这两种操作本质上都是管理操作。两者之间的区别在于范围和规模。 将一个大型文件从一台用户计算机复制到服务器会显著影响可用的本地带宽。因此，每个用户都可以执行对所管理的整体环境（即计算和网络环境）具有实质性影响的操作。由于此类操作会影响所管理环境的状态，因此它们在概念上是（虽然是无意中做的）管理操作。 将应用程序交互和 IT 操作视为单独的规程往往会产生太多的竖井（即非重叠但是相互依赖的实体）。例如，竖井方法的结果使得到面向服务的体系结构 (SOA) 的迁移变得更加困难。 我的论点在于，大多数操作都应该视为管理操作，如果 EA 作为其架构质量属性之一包括了可管理性，则将大多数操作视为管理操作会更加容易。此类 EA 的优点之一是能够基于身份、影响、资源使用等来允许和禁止某些操作，从而维持秩序。 对可管理性概念的理解可以形成 EA 可管理性所必需的技能和能力的基础。可管理的软件和系统具有以下主要特征：
以下各部分将研究这些特征。 管理人员可以使用监视和控制仪器来查看并可选地修改软件和系统的状态。所检测的软件和系统可以突出体现各种各样的技术，包括：
电信业和 UNIX®/Linux® 领域的许多系统专门使用脚本来进行管理。基于脚本的管理工作得很好，但是这种方法遭遇到了规模和复杂性问题。当所管理的实体数量超过某个阈值（通常为大约 50 个节点）时，脚本就会变得非常笨拙。此外，对解释的需要会在使用脚本时导致性能瓶颈。有些管理系统甚至可能提供图形界面，而软件在幕后却采用脚本。 SNMP、WSDM 和诸如分布式管理任务工作组（Distributed Management Task Force，DMTF）等类似标准提供了更高级别的抽象，因为它们本质上是基于模型的。管理数据是预定义和可扩展的，并且提供了简单的协议以允许访问和修改该数据。但是，这两种技术都无法随着系统和软件的增长而很好地扩展。不过，它们仍然是聊胜于无的管理功能。 专有技术包括诸如嵌入式 Web 服务器等解决方案。虽然此类专有方案对于 Web 应用程序交互非常有用，但它们通常具有与性能和规模相关的限制。 真正可管理实体的一个关键方面是自动化操作。无人参与的操作和弹性被视为 IBM 的自主计算活动中的成功端点。这是因为底层细节——例如日志文件检查和自动流程重启——全都可由软件进行处理。通过减少人工输入，实现自动化就变得可能了。因此，封闭的自动化是自主计算系统的可交付内容之一。 信息性实体是自动提供有关状态、负载、故障模式等的定向信息的实体。换句话说，IT 管理人员了解与实体相关的重要问题的最新信息，而不会被数据的海洋所淹没。实现此目的的通常机制是事件——所管理实体在出现某个重要问题时主动发送的消息。事件的一个示例是给定系统上的负载超过了可接受的阈值。系统确定其负载超过了已定义的阈值，并发出一个事件消息。过去，事件的问题在于发出的事件太多，或者更糟的是，事件机制耗尽了所管理实体上的宝贵计算资源。 使用例子来描述模式支持是最容易的。Java™ 2 Platform、Micro Edition (J2ME™) 平台旨在用于受资源约束的小型设备，例如移动电话、个人数字助理（Personal Digital Assistant，PDA）、电视机顶盒等等。有关 J2ME 的有趣之处在于，它支持一个应用程序管理器，此管理器通过确保只能发生有限数量的定义良好的状态转换，从而控制软件在平台上的执行。这为程序员减轻了实质性的负担，并且其唯一的要求是按照特定的模式编写 J2ME 代码。程序员必须编写的 Java 方法包括 针对管理的模型支持领域非常零散，例如，SNMP、公共信息模型（Common Information Model，CIM）、公共管理信息协议（Common Management Information Protocol，CMIP）等等。每种模型各有优点和缺点。过去，最大的缺点是分离。管理功能通常实现为外接程序——在接近开发结束时或（更糟的是）在给定的开发完成之后连接到软件上的东西。 不过，诸如 Eclipse Modeling Framework (EMF) 和最新的 Eclipse Graphical Modeling Framework (GMF) 等新技术可以帮助解决此问题。这些工具提供了在进行主要开发的同时定义模型的方法。实际上，使用 EMF 和 GMF 创建的系统和软件从一开始就是基于模型的。这是可管理的 EA 的更自然的基础——如果组件是可管理的，则总体架构也应该是可管理的。 因此，尽管经过了大约三十年的努力，管理系统和软件的问题仍然没有得到根本解决。为什么会这样呢？主要原因在于：
在开放源代码趋势开始之前，大量的软件对除了开发人员和设计人员以外的其他所有人是封闭的。毋庸直言，这往往意味着管理功能微乎其微、仅满足基础标准、不存在或本质上是专有的。因此，来自供应商 X 的软件需要来自供应商 X 的管理工具——如果的确存在这样的工具的话。 由于没有将可管理性视为竞争优势，供应商通常错过了作为真正的端到端解决方案来提供其产品的机会。由于 EA 是一个新兴的学科，整个可管理性问题重新浮出水面，只不过是以新的形式出现。SOA 的 EA 要求现在通常包括对面向服务、松散耦合、轻松编排的需要和对企业服务总线（Enterprise Service Bus，ESB）模式的支持。这强调了对用于集成诸如服务器、应用程序、数据源、服务等基础设施元素的统一方法的需要。此方法必须是面向消息、事件驱动和面向服务的。 当今对 EA 的着重强调提供了一个有趣背景，人们开始重温对作为架构质量属性的可管理性的需要。 本系列 中前面的文章强调了对现有的技术、业务实践和服务进行企业范围分析的重要性。如果存在对 EA 可管理性的需求，此分析仍然是一项关键性的活动。以下各部分对此进行更详细描述。 庆幸的是，设计 EA 并不是全新的工作。存在可用的帮助，一些很好的帮助来源包括：
使用这些工具和技术可以帮助从可管理性的角度清楚表达 EA 远景。特别是，使用 EUP 可以降低 EA 项目的成本，因为 EUP 帮助保留了对 RUP 的现有投资。 TOGAF 是一种用于开发 EA 的方法，并包括一个工具箱。TOGAF 提供了一个很好的框架，用于将可管理性作为架构质量属性包括进来，因为 TOGAF 促进了架构组件的结构、架构组件的相互关系、设计和发展的原则和指导方针的定义。TOGAF 本质上是一种用于开发架构的方法，并包括最佳实践、对实际案例研究的引用和开发指导原则。TOGAF 由三个部分构成，并包括方法、模型和模式存储库以及一组指导原则。 TOGAF 的可交付内容之一是一组目标架构，这些架构是通过将有关现有实现的优点和约束的信息与变更需求组合在一起而获得的。 因此，如果目前可管理性不是需求，TOGAF 提供了推迟其实现的方法。换句话说，可以对需求进行记录、建模并在以后可选地进行实现。有关 TOGAF 的另一个好消息在于，任何企业都可以为开发供组织内部使用的企业架构的目的而下载 TOGAF。这还有助于削减生成架构的成本。 另一项有用的技术是 EUP，EUP 是 IBM Rational Unified Process® (RUP®) 的一个扩展。EUP 是 RUP 的外接程序的事实有助于降低其使用成本，因为可以扩展而不是替换现有的 RUP 实践。因此，建议的 EUP 采用方法是首先使用 RUP，然后再迁移到 EUP。 正如 RUP 一样，可以灵活地使用各个 EUP 阶段。例如，团队可以从生产阶段一直后退到开始阶段。或者，可以进行从构造到细化的阶段变更。当必须引入或更改某些企业架构需求时，就可能会使用后一种方法。一个明显的例子是引入企业架构可管理性。 EUP 引入了许多企业级别的规程，包括操作和支持以及七个企业规程：
RUP 与 EUP 之间的一个基本区别在于后者处理完整的 IT 生命周期。RUP 仅处理该生命周期的软件开发部分。TOGAF 与 EUP/RUP 之间的一个明显区别在于 EUP 允许您重用 RUP 投资。这可能代表有用的成本节约。 Zachman 框架在现有 EA 的上下文中也非常有用，因为此框架可用于表示该 EA 的元素。因此，如果需求是添加对可管理性的支持，则 Zachman 还可以帮助跳过起点。 Zachman 是另一个用于 EA 的框架，并提供了对企业进行定义和建模的形式化和结构化的方法。Zachman 框架突出体现了一个二维分类模型，此模型基于六个基本交流疑问词（什么、如何、何处、谁、何时以及为什么）和六种与参与者团体（预言家、所有者、设计人员、构建人员、实现人员和工作人员）相关的不同模型类型的交集。该二维 Zachman 模型的目的是提供所建模的企业的全面视图。 Zachman 通常用于检查系统架构或企业级别的技术。Zachman 不同于 TOGAF 和 EUP，因为它深受 IT 架构师的欢迎，而技术开发人员或用户群体却对它没有多大的兴趣。另一方面，Zachman 可用于评估给定组织的软件架构。一些批评者认为 Zachman 产生的文档太多，但是这对于考虑 EA 问题的组织（即希望了解并且改进其现有架构的组织）来说可能是有用的。因此，Zachman 对于正在规划其架构但是不打算全面改造现有架构的组织是有好处的。 在 EA 可管理性的上下文中，Geronimo 和 WebSphere® Application Server 都值得研究。 与仅讨论理论注意事项不同，Geronimo 已经实现了本文中描述的部分想法。基于 Java Management Extension (JMX) 和反向控制的概念，Geronimo 内核中的每个对象都是一个 Mbean。Geronimo 中的服务是使用 Gbean 来描述的，后者特定于 Geronimo 而不特定于 Mbean（这非常令人惊讶）。Gbean 本身是可管理的单元，并遵循一组有限的特定状态，包括启动、停止、失败等等。 Geronimo 是一个兼容的应用程序服务器，并且能够承载跨越多台计算机的服务。显然，此类服务的内置可管理性是在 EA 可管理性上下文中考虑该技术的有力论据。其原因在于，Geronimo 从一开始就存在并且已经体现出了可管理性。以此作为起点，对 Geronimo 的密切研究可以帮助获得实现 EA 可管理性的方法。 与 Geronimo 一样，WebSphere Application Server 也是兼容 J2EE 的产品，并且包括全面的管理支持，其中包括：
WebSphere Application Server 还支持 J2EE 管理应用程序编程接口 (API)，此接口允许用户以编程方式执行管理操作。选择 Geronimo 而不是 WebSphere Application Server 主要是一个购买决定。本部分的目的不是推荐任何一个产品——每个产品都有各自的优点和追随者。 理解 EA 可管理性的关键第一步是定义适当的需求。可以使用 “技能和能力” 一节作为开始定义某些需求的模板。就 EA 来说，可管理性定义包括关联质量属性的详细信息。 下一个主要任务是理解 EA，您可以使用前面描述的用于此目的的工具之一。如果给定的组织目标是开发一个 EA，则您可以使用 TOGAF 或 EUP。如果已经对 RUP 做出了投资，则 EUP 也许是合适的，因为它是 RUP 的扩展。另一方面，如果需要理解 EA，则 Zachman 也许是合适的选择。 创建一个将可管理性作为质量属性的 EA 是一项充满挑战的任务。但是，现有的工具和技术表明，这实际上是一个可持续项目。此外，可管理性的主要元素得到了充分理解，一些平台和产品已经提供了对部分需求的很好支持。 如果假设已经创建了某个具有可管理性的 EA，如何判断其成功与否呢？要回答这个问题，您必须回顾需求并确定那些需求是否已得到满足。对以下问题的回答可作为很好的指导：
不需要一次全部提供对这些以及其他问题的回答。可以在一段时间后提出这些问题，以确定 EA 的可管理程度。 随着 SOA 趋势的加速，对可管理性的需要很可能会增加。这是因为 SOA 很可能使现有的 IT 资源紧张到极点，而 SOA 仅只是个开始。因此，研究 EA 可管理性的决定非常重要，其重要性可能随时间而增加。 学习
获得产品和技术
讨论
| |||||||||||||||||||||||
