最近一位负责 IT 组织的副总裁评价说，“我们所进行的不再是传统意义上的软件开发。我们正在通过一个应用软件包或者现有构件的集成来实现我们所有的新需求。当必须自定义软件开发时，我们通常外购以降低我们的生产和交付的成本。”

这一评论反映了IT执行人员的新的现实和IT 购买方面的新的转变范例。今天的IT专业人士需要具备两方面知识：一方面需要对新旧技术有技术方面的了解；另一方面需要了解技术的商业价值以及如何使企业处于竞争优势地位。

今天IT执行人员日益关注的是将应用软件包集成于他们沿袭的开发环境中－－而不是从编写软件程序开始。SOA的出现很好的解释了“可重用的组件”如何对改变角色、职责和面对IT专业人员的挑战产生影响。IT专业人员不仅期望成为“具体细节”的技术专家，而且期望成为能够管理包含遗留代码、现货供应包和一些内部代码的整个软件系统的相互影响的管理人员。在这一方面，今天的IT专业人员做的软件设计和构建方面的工作较少，而做得更多的是交付给最终用户的整个软件系统的管理工作。

在业务上，当涉及到说明自己预算合理性时，IT执行人员往往处于尴尬的位置。对于开放的需求和全权的委托－－如果构建就购买－－的时代已经过去了，取而代之的是，软件开发人员根据一些有力的问题来分配任务：“这个应用软件程序如何帮助我们的公司解决业务需要？”“首先我们如何知道你们正在设计和构建的应用程序的类型是合适的？”“应用程序的投资回报率是多少？”

这篇文章为架构管理引入了一个新的 IBM Rational 策略，帮助IT管理者和架构师们回答这些问题并随时为企业在任何规模上的业务需求变化提供支持。

应对新的IT现实的架构管理

目前 IBM Rational 团队正在把传统意义上被称作分析、设计和构建扩展到架构管理的内容中：这是一门在驱动架构和实施架构代码的需求变更中管理软件构架的规程。这一规程必须确保一个公司独有的资产和发展的业务进程和模型之间的集成性。架构管理反映了软件架构重心的根本转变，是通过业务驱动设计，而非设计驱动业务。

什么推动了对架构管理的需求？

架构管理是在当前改变原本的软件开发的三种力量的带动下发展起来：SOA、区域分布式开发（GDD）以及外包和离岸开发的业务实践。让我们分别看一下每一种驱动力量，了解为什么架构管理对于新的应用软件程序的设计、采纳和部署来说变得十分重要。

SOA 的承诺

有很多关于面向服务的架构（service-oriented architecture），或 SOA，将如何帮助公司使得人员、过程和技术的效率达到最大化的文章。理想状态是，达到采用 SOA 的每一家公司都包含一些方法，通过这些方法使得其IT组织能够保持是灵活的、有竞争力的和高效的——所有这些是为了保证以客户为中心这一重点。在重用现有应用软件或者通过服务模型再利用的部分应用软件的基础上，功能性的 SOA 使得软件开发人员不需要从头设计和构建应用软件。先前做出的有关数据库方案、操作系统、服务器平台和程序设计语言的决策仍然可用并且可在以后再组合。工程师不再在最基本的文件和代码模块层面工作，而是在能够表现他们正在进行的软件的商业价值的更高的抽象层面上工作。由于这一点，应用软件——通过 SOA 转变为服务——被构建，它们可以被存储起来、容易找到并且可以通过重新组合很快地创建出一个新的商业应用软件。

尽管如此，实现SOA的前景仍然是苛刻的要求。很明显您必须要有那些合适的服务来重用它们，您不能再利重用还不存在的东西。更重要的是，您不能只是不加考虑的创建“服务”，他们必须根据一套规定的标准、协议和接口来创建，毕竟这使得它们是“标准的”而且“可重用的”。这是架构管理起到重要作用的地方：您必须架构您的服务使得它们能够以面向服务的架构的样式被重用。

区域分布式开发（GDD）的现实性

对软件开发组织来说，在各个地理上分布的区域拥有开发员工已经成为标准而不是特例。很多次GDD通过合并和收购发生：公司不是马上重新部署和共同部署员工或者关闭一项业务并且/或者将他们合并。通过远程通信和远程技术的利用，公司发现在不同的地方保持合适的员工更加划算和实用。

IBM Rational组织提供了一个很好的例子：它在许多地方都有开发中心（IBM 称之为实验室），并且它的软件开发人员都可以在相同的产品和版本上工作。这种劳动力配置的新样式引发出一个问题：“当开发人员分布在不同地方时如何做‘架构’？”更重要的是，“如何保持架构的完整性？”如果有人说，“给我展示一下您的架构”，您的回答需要符合与其关联的实现。从业务角度来看，架构首先需要符合驱动架构的最新的业务需求。保持需求、设计和实现同步的这一需要已经成为一个挑战，并且只在GDD的环境系中触及。

外包和离岸开发业务

许多公司热衷使用一些外包和离岸开发的版本。这些是GDD的特殊形式，开发分布不是跨越主持研究计划的组织，而是分布到通常距离较远的外部人员。一个极端情况（一个不太常见的场景）是外包所有IT需求的客户——例如，公司总部位于安大略湖，而在印度班加罗尔有一家公司，提供公司全部的IT职能。总部可能正在做一些业务建模，而印度的承包商做的是所有的架构、所有的设计、所有的编码以及所有的测试。

IBM Rational 预期的更为普遍的场景是内部保持需求和架构(设计&构建)而外包“核心”的实现工作的客户。这类客户想要或者需要密切关注他们的业务需求以及它们如何转变成设计，但是受到做更多实现工作的较低的劳动力成本的推动。在这一场景中，架构将由一些“真实性”或者正确性的程度来实现，但实际上，那将不是完美的。经选择的或者不经意的实现将不可避免地背离设计，导致某种程度的架构降级（architectural degradation）。架构降级可以发生在GDD或者其他（例如，您可以协同工作，您的实现团队可以在隔壁或者在楼下而您仍可以体验它）任何场景中。正如早期规定的，GDD使其变得更难，而且外包甚至更难，因为它是不同的公司、不同的时区以及具有不同的通信和/或者语言障碍。在这个例子中，外包的公司编写代码之后，它回到要评定的客户。提出的基本问题是：“承包商是按照已经写明的方法实现的吗？”可能在某种程度上答案是“否定的”。

这里存在着挑战：根据最初设计，以及最终业务需求所驱动成果，架构管理必须能够帮助软件架构师评估“建成的架构”。为了进行对比，寻找不同点并且最终使得这些不同之处在部署之前得到处理——这是架构管理的主要目的。

架构管理的含义是什么？

随着架构管理原理的逐渐形成，今天在商业IT的管理方式上将会发生变化。因为架构管理规程重点是在业务驱动程序上，并进而推动技术中更高的抽象等级，我们可以期待在那些参与应用程序开发项目生命周期的全体员工中看到“向左移位”。也就是说，开发中的每一个阶段的角色自身将继续保持不变，但是现今执行那些角色的人员将移至左侧。因此，过去的程序员将变成设计人员，过去的设计人员将变成架构师；过去的架构师现在变成了分析师或者企业级架构师。实质上是被称作“企业架构”的规程正日益成熟。如果我们可以更好地管理软件架构——这基本上是我们在 Rational 环境中所用到的定义——应该会使软件架构管理之外发生一些人员、时间、资源和全体员工上的变化：也就是说，管理包含企业架构的其他任何事情。

在软件构架管理方面做得更好，我们便可以引入软件、硬件、数据和操作环境，并将这些整合在一起放在协作的工具或系统下，以便完全不同的和不相连的建模工具中的信息能够整合起来，可以在一个统一的模式下找到。例如，假设我提出这样一个查询：“请列出公司里拥有第六版A42模块架构的所有计算机，并列出与之连接的数据库是哪些”。如今，这是十分难回答的问题。严格来说这是一个手动工作，包括了解数据库的工具，了解软件模块的工具，了解硬件和部署的工具；但是没有一个单一的工具或者是一套工具可以在一个工作流程中来自动地操作这样一个查询命令程序。

源于架构管理的机会是什么？

架构管理提供了改进设计和开发软件方法和用这种方法管理需求、设计和代码的变更的机会。通过在生命周期中将重点进一步“左移”，可以使我们的IT员工更了解并将时间更多地用在现有的业务需求上。这样做还可以不断地提高整个软件交付进程的质量和生产力。

但是为了实现这些利益，我们需要认识到现今大多数组织上存在的障碍。在实现架构管理的过程中我们基本上面临两项挑战，主要集中在1)教育和引导IT管理和员工，2)软件交付生命周期的前端方面所需要的更加全面的自动化。

教育和引导

即使架构管理很大程度上是分析、设计和构建这些传统概念的扩展，但它已经足够与通常我们应该期待来自于IT购买的面的阻力与众不同了。软件开发和交付工作已经进行很多年了，开发组织有适当的体系来完成这项工作。更改那些系统的提议从未被轻视，即使这些提议已经被接收，但改变通常是十分困难的。正如需求变更的任一情况，教育和信息是成功采用的主要因素。

理解和评价架构管理所需的教育开始于承认这一规程不是那么新的，因为这是还需要做得更好的事情。设计人员和开发人员必须一直管理架构。但是随着早期提出的驱动因素付诸实施——SOA、GDD和外包——已经约定了按照他们一直所用方法做的事情的可测量性。您可以在一周里只工作这么长时间，您可以只雇佣这么多人员，您可以训练他们在有限的时间创建工作区。使得开发团队克服困难、密切关注在员工、时间甚至员工消耗上的趋势可能是开始的最好教育。

全面的自动化：前端重新使用工具

在认识到管理架构的全面需要优于以往的实践之后，将自然产生一个合乎逻辑的选择：在软件行业里有两种趋势，把市场引入正好相反的两个方向。一个是“廉价劳动力”的使用（例如，外包）；另一个是通过现代化的工具实现高度的自动化。从这一方面看，我们今天所了解的开发人员看起来将十分不同。他们或者选择以外包的形式操作、以过时的方式编写代码，因为比起购买昂贵的工具并教会员工新的方法，雇佣廉价的人员将更加便宜。或者他们转向做前端的工作，因为那是发起组织需要他们的地方。并且通过这种关系的自然分离，后面的工作将要么是外包的，要么可以自动化。

我们了解外包的动力。从工具角度看，一个人可以想象，在不太遥远的未来世界里生命周期前端的工具是如此强大，以至于它们不需要外包我们今天所了解的核心实现工作——甚至不需要廉价的、低档的劳动力的购买。随着生命周期前端工具日益完善，出租给手工实现团队的工作的需要将明显减至最少。这意味着我们将看到两个极端情况，正如一个沙漏转向某一边：沙子流向一边或者另一边，两边中间有一个狭窄的接口。一堆工作将进入廉价劳动力那一面，因为在IT行业一直这样进行了很多年。对于那些在外包劳动力市场没有商业利益的公司来说，他们将走向另一边，也就是说，他们将开发工具来自动化前端业务，在那里架构师们极大地体现其价值。

结束语

文章的开头我们引用了一位负责IT组织的副总裁的一段话，他注意到了软件如何被交付的过程中发生的显著变化。这些趋势正再次形成技术方面的需要、组织IT员工的方法、我们需要使用的工具种类以及我们如何理解业务模型和实践。SOA、GDD和外包每一个都是独立的推动力，在这些趋势中扮演他们自己的角色。这三种推动力结合起来已经促使我们对分析、设计和构建规程进行调整以更好地管理软件架构。门槛会不断提高，因为随着我们处理不断变更的需求和未完成的实现工作，我们需要更好地掌控我们的 IT 方法。

在采用架构管理作为最佳实践方面将会有一些挑战。但是对于面对这些趋势的那些组织来说，这是值得的，因为它将提供一个更好的、更加有效的方法来管理软件架构。这样，事情将能够集中在他们知道如何做得最好的事情上：他们的业务。