当今组织面临两个重要企业架构需求的挑战：对敏捷性的需要和法律法规治理的开销。可以将这些需求视为相互对立的——如果业务流程必须灵活，则那些流程的治理可能非常困难。本文是包括六个部分的 “企业架构核心”系列中的第六部分，其中探索“将可管理性作为解决此问题的关键企业架构（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可管理性所必需的技能和能力的基础。可管理的软件和系统具有以下主要特征：

　　·进行检测以实现监视和控制
　　·自动化操作
　　·信息或事件驱动
　　·模式支持
　　·基于模型

　　以下各部分将研究这些特征。

　　检测

　　管理人员可以使用监视和控制仪器来查看并可选地修改软件和系统的状态。所检测的软件和系统可以突出体现各种各样的技术，包括：

　　·用于实现脚本支持的简单命令行接口
　　·简单网络管理协议（Simple Network Management Protocol，SNMP）、Web服务分布式管理（Web Services Distributed Management，WSDM）和其他标准
　　·专有技术

　　电信业和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方法包括startApp()、pauseApp()、destroyApp()，以及提供构造函数。当遵守此模式时，该应用程序管理器将负责代码的执行。由于Java 2 Platform, Standard Edition(J2SE?)和Java 2 Platform, Enterprise Edition (J2EE?)往往不在受资源约束的平台上运行，因此它们没有突出体现类似的部署模式。

　　基于模型的操作

　　针对管理的模型支持领域非常零散，例如，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的着重强调提供了一个有趣背景，人们开始重温对作为架构质量属性的可管理性的需要。

　　理解业务流程、IT和服务可管理性

　　本系列 中前面的文章强调了对现有的技术、业务实践和服务进行企业范围分析的重要性。如果存在对EA可管理性的需求，此分析仍然是一项关键性的活动。以下各部分对此进行更详细描述。

　　工具和技术

　　庆幸的是，设计EA并不是全新的工作。存在可用的帮助，一些很好的帮助来源包括：

　　·The Open Group架构框架(TOGAF)
　　·企业统一过程程(Enterprise Unified Process, EUP)
　　·Zachman框架

　　使用这些工具和技术可以帮助从可管理性的角度清楚表达EA远景。特别是，使用EUP可以降低EA项目的成本，因为EUP帮助保留了对RUP的现有投资。

　　TOGAF

　　TOGAF是一种用于开发EA的方法，并包括一个工具箱。TOGAF提供了一个很好的框架，用于将可管理性作为架构质量属性包括进来，因为TOGAF促进了架构组件的结构、架构组件的相互关系、设计和发展的原则和指导方针的定义。TOGAF本质上是一种用于开发架构的方法，并包括最佳实践、对实际案例研究的引用和开发指导原则。TOGAF由三个部分构成，并包括方法、模型和模式存储库以及一组指导原则。

　　TOGAF的可交付内容之一是一组目标架构，这些架构是通过将有关现有实现的优点和约束的信息与变更需求组合在一起而获得的。

　　因此，如果目前可管理性不是需求，TOGAF提供了推迟其实现的方法。换句话说，可以对需求进行记录、建模并在以后可选地进行实现。有关TOGAF的另一个好消息在于，任何企业都可以为开发供组织内部使用的企业架构的目的而下载TOGAF。这还有助于削减生成架构的成本。

　　EUP

　　另一项有用的技术是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框架

　　Zachman框架在现有EA的上下文中也非常有用，因为此框架可用于表示该EA的元素。因此，如果需求是添加对可管理性的支持，则Zachman还可以帮助跳过起点。

　　Zachman是另一个用于EA的框架，并提供了对企业进行定义和建模的形式化和结构化的方法。Zachman框架突出体现了一个二维分类模型，此模型基于六个基本交流疑问词（什么、如何、何处、谁、何时以及为什么）和六种与参与者团体（预言家、所有者、设计人员、构建人员、实现人员和工作人员）相关的不同模型类型的交集。该二维Zachman模型的目的是提供所建模的企业的全面视图。

　　Zachman通常用于检查系统架构或企业级别的技术。Zachman不同于TOGAF和EUP，因为它深受IT架构师的欢迎，而技术开发人员或用户群体却对它没有多大的兴趣。另一方面，Zachman可用于评估给定组织的软件架构。一些批评者认为Zachman产生的文档太多，但是这对于考虑EA问题的组织（即希望了解并且改进其现有架构的组织）来说可能是有用的。因此，Zachman对于正在规划其架构但是不打算全面改造现有架构的组织是有好处的。

　　学习资源

　　在EA可管理性的上下文中，Geronimo和WebSphere Application Server都值得研究。

　　Geronimo

　　与仅讨论理论注意事项不同，Geronimo已经实现了本文中描述的部分想法。基于Java Management Extension(JMX)和反向控制的概念，Geronimo内核中的每个对象都是一个Mbean。Geronimo中的服务是使用Gbean来描述的，后者特定于Geronimo而不特定于Mbean（这非常令人惊讶）。Gbean本身是可管理的单元，并遵循一组有限的特定状态，包括启动、停止、失败等等。

　　Geronimo是一个兼容的应用程序服务器，并且能够承载跨越多台计算机的服务。显然，此类服务的内置可管理性是在EA可管理性上下文中考虑该技术的有力论据。其原因在于，Geronimo从一开始就存在并且已经体现出了可管理性。以此作为起点，对Geronimo的密切研究可以帮助获得实现EA可管理性的方法。

　　WebSphere Application Server

　　与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元素以进行监视和控制？
　　·是否可以实现自动化操作？
　　·EA元素是否为事件驱动的？
　　·该EA是否基于模型？

　　不需要一次全部提供对这些以及其他问题的回答。可以在一段时间后提出这些问题，以确定EA的可管理程度。

　　总结

　　随着SOA趋势的加速，对可管理性的需要很可能会增加。这是因为SOA很可能使现有的IT资源紧张到极点，而SOA仅只是个开始。因此，研究EA可管理性的决定非常重要，其重要性可能随时间而增加。

　　关于作者

　　Stephen Morris是爱尔兰的Omey Communications的CTO。在过去20年中，Stephen曾在一些世界最大的网络公司参与过各种软件项目，包括基于J2EE/J2SE的网络管理系统，帐单编制应用程序、移植和开发SNMP实体、网络设备技术和GSM移动网络应用程序。他是Network Management, MIBs and MPLS:Principles，Design and Implementation（Prentice Hall PTR，2003年）一书的作者，同时也在InformIT和OnJava.com发表过多篇有关网络管理和其他主题的文章。