web开发

在定义过体系架构的内涵之后，我们现在将目光转移到对其创造物负责的角色上面——架构师（此处特指开发环境架构师）。架构师的角色被 认为是任何一个开发项目中最具挑战性的角色。从技术的角度来看，他们是项目的技术领导者，并且最终承担项目成败与否的责任。IEEE 1471 标准将架构师定义为“负责系统体系架构的人员、团队、或者组织”。

尽管架构师应当具备特定领域非常深入的技能，但是作为项目的技术领导者，架构师更需要具备的是广博而非深入的技能。在本小节中，我将讨论适用于所有类型架构师的特点，其中自然也包括开发环境架构师。

架构师的角色可能是由一支团队扮演的

鉴于架构师需要具备广泛的技能，所以架构师的角色往往是由一支团队而不是某个人扮演的。这样的话，技能被分散到一群人身上，每个人具备自己的经验。所以在本文中，“架构师”一词是指角色，这个角色是由一个人或者一支团队所扮演的。

[团队] 是指具有互补技能的一小部分人员，他们具有共同的目的、实现目标和分工方法。 ⁸

特别地，开发环境架构师往往利用具备不同技能的专家（例如配置管理主题专家）来增强体系架构团队的实力。

如果架构师的角色是由一支团队来扮演的话，那么找到一位首席架构师就是一件非常重要的事情，他需要负责版本控制和团队协调。如果没有这种团队协调的话，团队各个成员所生产出来的体系架构就有可能是非内聚的，或者团队无法做出有效的决策。

架构师是一位技术领导者

首要的一点是，架构师应当是一位技术领导者。这就是说，除了具备技术技能之外，架构师还必须具备领导能力。领导能力既可以在公司的职位中表现出来，也可以在架构师所展现的素质上面表现出来。

就 公司中的职位而言，架构师是项目的技术领导者，并且应当具有做出技术决策的权利。另一方面，项目管理者更加关注从资源、进度和成本等方面管理项目计划。打 个电影行业的比方，项目管理者就是制片人（确保物资和人员到位），而架构师就是导演（确保拍摄影片的质量）。结果是，架构师更应当在做出创建体系架构的决 策时成为鼓吹者。

就架构师所表现的素质而言，领导能力也可以表现为同团队其他成员之间的交互方面。特别地，设 计时应当通过例子来指引大家，并且显示确定方向的信心。成功的架构师是面向人的，并且花时间扮演团队中的导师和教练的角色。这对持怀疑态度的团队成员、项 目以及公司都会带来好处，这是因为最有价值的资产（人员）变得更加具有技能了。同样地，架构师需要非常关注有形结果的交付，并且从技术角度看必须扮演一个 驱动项目向前推进的角色。他们必须能够做出决定（在压力之下），并且确保那些决定能够被交流、理解、并且最终被确定。

架构师具备业务域的知识

如同掌握技术一样，我们也非常期待（有时是必须）架构师对业务域有很好的理解。

[业务域] 是指由该领域中的实践者所理解的一组概念和术语所表现的一套知识和活动。[UML 用户指南]

这样的知识将使得架构师能够更好的理解系统的需求，并且为之作出贡献。同样地，特定业务域往往同所要应用的体系架构的某组模式相关联。知道这种对应关系对架构师来说很有帮助。

更 加特别地是，开发环境架构师应当不仅理解开发环境的技术方面；而且对于这一环境将要应用到的业务域的相关知识的理解，更是对于开发环境架构师具有重要的帮 助作用。举例来说，金融服务方面的知识可以使得开发环境架构师知道在该环境中必须为某种调节标准提供支持，从而对后续的处理过程、工具的配置等产生影响。

架构师能够“深入进去”

尽管我们希望架构师是万能的，但是他们必须在需要的时候“深入进去”。这意味着他们能够承担系统的某一关键方面的设计，甚至是用某种程序设计语言表现一个关键的算法。

同样的原则也适用于开发环境架构师。举例来说，他们需要理解开发环境内部的安全性实现细节，从而确保对于敏感信息的访问是受到限制的。

架构师是一位很好的沟通者

在 架构师所应具备的所有“软实力”之中，沟通能力无疑是最重要的一个。有效沟通的方式有许多，架构师必须精通所有。特别地，架构师应当具备有效的口头、书 面、以及陈述技能。同样地，沟通是一种双向的活动。因此，除了是一位很好的谈论者之外，设计还应当是一位很好的倾听者和观察着。

具 备有效的沟通技巧是项目成功的基础之一。很明显，同涉众进行沟通对于理解他们的需要并且同他们达成一致意见十分重要。同项目团队进行沟通也是十分重要的， 这是因为架构师不仅负责向团队传达信息，而且负责推动项目的进行。特别地，架构师负责交流（和加强交流）系统的图景，从而使得这一图景被大家所分享，而不 仅仅是架构师自己所理解和相信的东西。

架构师能够做出决定

那些不能够在情况不明的、没有足够时间探索所有可能性的、处于交付的压力之下的环境中做出决定的架构师是无法生存下去的。这样的环境是客观存在的，成功的架构师接受这一现实，而不是试图去改变它。因此，架构师可能不得不修改或者放弃自己所作出的决定。

软件架构师的生活就是在半昏暗中不断地做出未达到最佳标准的设计决定。 ⁹

无法做出决定将会对项目产生慢性地破坏。项目团队将会对架构师失去信心。真正的危险在于架构师没有对体系架构作出并且记录决策，然后团队成员将会自行解决，作出他们自己的（很有可能是不正确的）决定。

架构师明了公司的政策

成功的架构师不仅要关注技术，而且需要清醒的知道公司的实力所在。从而他们能够确保同正确的人进行沟通，并且他们的项目在正确的轨道上运行。忽视公司的政策是十分愚蠢的。实际的情况是，有许多项目之外的因素影响着系统的交付，这些因素必须被考虑进来。

架构师是一位谈判代表

鉴 于架构师需要同许多涉众进行交互，所以他们需要具备谈判的技巧。举例来说，架构师尤其关注的是如何尽可能早的最小化项目的风险，因为这一点直接关系到稳定 体系架构所需要的时间。由于风险是同需求相关联的，所以消除风险的一种方式就是移除或者减少同风险相关的需求。因此，架构师需要将需求“推回去”，进而在 涉众和架构师之间达成一致意见。这需要架构师能够清楚地表达出不同权衡的结果。

架构设计一个开发环境的流程

在描述过开发环境体系架构的意义和开发环境架构师的特点之后，现在我们将考虑设计一个开发环境的流程这一主题或者特性，也可以从零开始创造一个环境，也可以从一个现有的开发环境中提炼。依照 IEEE 1471 标准：

[软件设计表现] 定义、记录、维护、提高和证明一个体系架构的适当实现的活动。

架构设计既是一门科学，也是一门艺术

设 计虽然仍然处于形成阶段，但它已经是一门经过验证的科目了。然而，随之而来的是对技术、处理过程和资产的关注，它们的关注点是提高设计流程的完备性。推进 这种完备性的方法之一就是从现有的知识中汲取营养。概括地说，架构师在开发一个体系架构的时候会寻找已被证明为有效的解决方案，而不是自己闭门造车，从而 他们能够避免许多不必要的工作。以参考体系架构、体系架构和设计模式、以及其他复用组成要素等形式归纳整理的经验都将扮演很重要的角色。无论如何，设计时 的经验总是会关系到项目的成败。

尽管设计被视为一门科学，但有时提供某种程度的创造力对它来说也是必要的。当 处理新颖和空前的系统是更是如此。在这种情况下，也许并没有现成的经验可以套用。就像一位画家面对一张空白的画布寻找灵感，架构师也可能将他们的工作视为 一门艺术而非科学。然而，在大多数情况下，艺术方面的因素在设计中只占很小的部分。即使是在最新奇的系统中，通常还是有可能从其他地方找到相似的解决方 案，然后对其加以改造并且使之适应我们所考虑的系统的。

因此，开发环境架构师在其工作中将会把其他成功的开发环境考虑进来，但是也将会根据需要创建具有一定的创造性。

架构设计涉及到许多科目

架 构师在处理过程中会涉及到许多科目。显然地，架构师涉及最深的核心体系架构活动就是定义一个需求的解决方案。当然，架构师还会涉及到其他许多科目。举例来 说，架构师可能对所有需求进行排序，从而确保那些他们感兴趣的需求被捕获到（特别是那些非功能性的需求，例如性能和可用性）。架构师和项目管理者也会紧密 协作，因为架构师拥有项目计划活动的输入。

架构设计是一项正在进行的活动

经验显示，架构设计不是在项目早期一次性完成的工作。相反，设计被应用在整个项目周期之中，它不断的增长并且迭代交付。每一次交付时，体系架构都会变得更加完整和稳定。问题产生了，在整个项目周期中，架构师的关注点是什么呢？

成功的设计努力是结果驱动的。因此，架构师的关注点随着时间的推移而不断改变，就像期望结果的改变一样。如图2中所示，据说这是 Bran Selic 为了和 Philippe Kruchten 进行交流而画在餐巾纸上的。

图 2. 架构设计强调随着时间的过去发现、发明和实现。

这 幅图显示了在早期，架构师非常关注发现。强调的重点在于理解系统的范围和识别关键的特性以及任何相关的风险。这些组成要素对于体系架构具有明显的影响。强 调的重点随后转变为发明，此时首要的关心就是开发一种稳定的体系架构，它能为全面的实现努力提供基础。最后，强调的重点转变为实现，此时大多数发现和发明 都已经完成了。

架构设计是由许多涉众所共同推动的

正如前面所描述的，体系机构需要满足大量的涉众的要求。因此，设计的流程（包括一个开发环境的设计）必须满足所有这些涉众以确保他们的关注，特别是那些有可能对体系架构产生影响的关注。将相关的涉众引入任何一个关于这些关注的解决方案的回顾之中，也是十分必要的。

设计流程中所涉及到的满足所有涉众的努力，并应当被低估。涉众们影响到处理过程的许多方面，包括需求被聚集的方式、体系架构被记录的形式、以及体系架构被评估的方式等。

架构设计经常涉及到权衡的问题

鉴 于影响体系架构的众多因素，体系架构的流程很明显会涉及到权衡的问题。通常，权衡是在需求之间作出的，可能还会请涉众帮助做出决定。一个在成本和性能之间 做出权衡的例子是，将网络压缩技术引入到分布式环境中将会提高性能，但是需要一定的成本。这就是一对矛盾的需求，假设架构师已经探索了所有的选项，那么剩 下的就是需要涉众做出决定了。做出权衡有时是不可避免的。架构师需要考虑所有选择，并且从中做出取舍，这是设计流程的一个至关重要的方面。

设计承认此前的经验

架构师很少从零开始工作。正如前面所提到的，他们积极地寻找那些能够被归纳整理为模式和现成的解决方案的先前经验。换句话说，架构师寻找复用资产。只有最无知的架构师才不会考虑这些事情。

复用资产是对重现问题的解决方案。复用资产是指在头脑中被复用开发的资产[RAS]

从开发环境架构师的角度来看，复用资产可能是一个方法插件程序、一个工具配置、一个培训课程、一个基础结构规范、或者一个角色定义。

架构师不仅会考虑使用复用资产，而且会考虑将复用资产贡献给公司的资产库。

架构设计既是自顶向下的，也是自底向上的

许 多体系架构常常是以一种自顶向下的方式被考虑的，涉众的需要被捕获并且需求被开发，在体系架构被定义之前，组成要素被设计并且随后被实现。然而，很少有体 系架构是完完全全的自顶向下的。体系架构也可能被自底向上地驱动，例如一个体系架构的概念的证明。成功的架构师承认这两种方式都是必要的，并且他们所创建 的体系架构既是“自顶向下的”，也是“自底向上的”。这也被称之为“从两头到中间”的设计方法。

架构设计一个开发环境所带来的好处

概括地说，设计在降低成本、提高质量、及时交付和满足需求方面发挥着关键的作用。在这一小节中，我将详细分析设计一个开发环境所带来的好处。

架构设计处理了系统质量

设计的流程不仅要关注必需的功能性需要，还要确保系统的质量达到要求。举例来说，为了处理性能需求，它可能必须考虑体系架构中每一个组件的实现时间，以及组件之间进行通信的时间。

从开发环境架构师的角度来看，根据不同的组成要素考虑应用不同的质量是值得的。举例来说，一种方法可能关注可用性和可配置性，一个工具集可能关注性能和可靠性，授权可能关注可用性，一个基础结构可能关注性能，一个组织可能关注可部署性（随时间变化的能力）等等。

架构设计推动了意见一致

设计的流程推动了不同涉众达成一致的意见，这是由于它提供了对解决方案进行争论的平台。为了支持这样的争论，设计的流程需要确保体系架构能够被清楚地沟通和理解。有效沟通的体系架构使得决定和权衡能够被争论，促进了回顾，并且最终取得共识。

相 反的，不能有效沟通的体系架构就不会导致这样的争论的发生。从而导致一个低质量的体系架构。与此相关的是，体系架构能够推动架构师和新的或现有成员之间达 成一致的意见。再一次说明，体系架构必须是有效沟通的，这样我们才能获得好处。那些清晰地知道自己将实现什么任务的开发团队更有机会生产出期望的产品。

架构设计支持了计划流程

架 构设计的流程支持大量的科目，特别是支持不同的项目管理活动，例如：进度安排、工作分配、成本分析、风险管理以及技能开发。这就是架构师和项目管理者之间 应当建立起紧密关系的主要原因之一。大部分支持都来自于体系架构识别出解决方案中重要组成要素以及它们之间的依赖关系这一事实。

举例来说，对解决方案做出改变的成本需要一定程度的影响分析，依次地，按照组成要素之间的依赖关系来决定哪些被影响。在进度安排方面，依赖关系指出每一个组成要素被实现的顺序。在工作分配方面，体系架构可以再次帮助我们识别出需要分配特定技能和资源的区域。

架构设计推动了完整性

架 构设计流程的一个首要目的就是确保体系架构为设计人员和实现人员所承担的工作提供一个坚实的架构。很明显，这远比传达一个体系架构的观点要复杂得多。为了 确保结果体系架构的完整性，架构师必须清晰地定义体系架构本身，从而识别出体系架构重要的组成要素，例如解决方案的要素、它们的接口以及它们的交互作用。

架 构师还必须定义适当的实践、标准和指导，这些将指导设计人员和实现人员的工作。体系架构的目标之一就是消除设计人员和实现人员部分上不必要的创造力，这一 点是通过加以必要的限制而实现的，背离这些约束将导致体系架构的破坏。有助于确保体系架构的完整性的另一个方面是适当回顾和评估活动的采用。这些活动的关 注点是考虑设计人员和实现人员的工作，并且决定采用适当的体系架构标准和指导。

架构设计帮助了对复杂性的管理

今 天的系统（包括开发环境）比以往任何时候都要复杂。我们需要对这种复杂性加以管理。由于体系架构只关注那些重要的组成要素，所以它提供了一个系统的抽象， 并且从而提供了一种管理复杂性的方式。通过递归地将系统分解为各个要素部分，关注体系架构也是一种很好的将大型问题分解为一系列小型问题的方式。

管理复杂性的另一个方面是使用那些允许体系架构的抽象被沟通的技术。采用那些允许抽象被表达的工业标准，例如统一建模语言（UML），今天已经被广泛用于记录不同类型的解决方案，其中也包括开发环境。

架构设计提供了复用的基础

设计的流程既能够支持复用资产的使用，也能够支持复用资产的创造。实践已经证明，复用资产能够降低系统的整体成本，并且能够提高它的质量，所以复用资产对于公司来说是十分有好处的。

体 系架构的创造误支持鉴定复用机会的可能性。举例来说，体系架构重要组成要素及其相关的接口和质量的鉴定，支持现成的组成要素、现有的系统、以及打包的应用 程序等的选择，它可以被用来实现这些组成要素。从开发环境的角度来看，也许有一种方法或者方法内容能够被复用、工具或者工具配置能够被复用、过程能够被复 用、基础结构能够被复用、甚至组织角色也能够被复用（例如一个现有的帮助办公桌）。

架构设计降低了维护成本

设 计的流程能够通过许多方式有助于减少维护的成本。首要的一点，设计的流程总是应当确保系统的维护者是一个关键的涉众，他们的需要应当格外受到关注。结果不 应当仅仅是一个为了减轻解决方案的维护压力而被适当记录的体系架构——架构师还将确保将用于维护系统的适当机制合并进来，并且将在创建体系架构的时候考虑 系统的适应性和扩展性。

总结

本文详细阐述了开发环境、开发环境的体系架构、开发环境架构师所扮演的角色、以及设计一个开发环境的流程的相关内容。本文总结了从一个设计良好的开发环境中我们所能得到的好处，以及这些好处是如何给那些真正关心自己软件开发能力的公司带来价值的。

千万不要忘记顶下原帖：http://www.ibm.com/developerworks/cn/rational/edge/08/apr08/eeles/