内容


开发环境架构师的兴起

Comments

超级英雄(Superhero)信息技术对于许多公司来说都是一项至关重要的组成要素。无论公司的信息技术仅仅支持其内部系统,或者支持创造反映其核心业务的软件产品。无论在哪一种情况下,软件都是公司取得成功的关键要素。因此,这些公司自然会寻找以一种能以及时、划算的方式开发高质量软件的开发环境。

寻找这样的开放环境于是就成为了一种挑战;有趣的是,这些挑战同它们所支持的系统所面临的挑战十分相似。举例来说,开发环境必须根据需求的功能和特性(例如性能和可用性)进行交付,往往还必须同遗留的系统(例如:在一个开发环境的例子中,我们是指方法和工具)共同存在,并且必须遵守其他的约束条件(例如开发团队的分布式性质、现已存在的技能和基础结构等)。

总而言之,创建一个良好的开发环境能够加速而不是妨碍项目的实现。这就是 IBM® Rational® 花费许多年时间专注于开发一个理解公司所面临的挑战的服务能力的原因所在。这些公司:1)希望提高开发人员的生产力;2)将它们的开发公司视为一个战略上的区分者,而不仅仅是一个“花费中心”。

我们的经验带领 Rational 团队将软件开发周期中的一个角色定义为“开发环境架构师”。在 2007 年 10 月,一百位来自世界各地的 Rational 的最有经验的开发环境架构师齐聚一堂,出席专门为这一角色所召开的第一次会议,并且分享他们的经验。本文就是这次会议以及相关讨论的成果之一。

在您阅读此处所提出的概念的同时,您也许会问开发环境架构师应当是一个单独的角色呢,还是那些将对开发环境的考虑添加到他们的体系架构关注列表中的软件或者系统架构师呢?我认为,这两种说法都是正确的。此外,无论我们所讨论的“架构师”属于哪一种角色,它总是具备在考虑之下的领域中工作的资格;因此,我们可以将它称为“构建架构师”、“软件架构师”、“系统架构师”、“企业级架构师”,等等。开发环境仅仅是这些域中的一个而已,并且是一个并不传统地关注“软件架构师”角色的域。因此,我认为“开发环境架构师”的角色是一个此前从未被着重强调过的角色。

本文拥有一些目标受众,也就是那些采取行动提高其开发环境的公司,以及那些需要理解开发环境架构师对于其实现力所发挥的指导价值的公司。当然还包括那些负责开发环境的技术内容的公司——也就是开发环境架构师。这是因为本文将这一职责定义为一个角色,这是一个创新的提法。最后,本文可能补充包含在一个开发环境中的材料,用以更加方便地传达它的内容、架构师的角色、以及拥有这一角色所带来的好处。

我们依次讨论如下概念:

开发环境的定义。我要着重强调的是,这样一个环境并不仅仅是方法和工具。这一定义通过为思考一个开发环境的所有方面提供一个框架,为后续的小节做好了准备。

开发环境的体系架构。体系架构的概念,以及这些概念是如何应用到一个开发环境中的。

开发环境架构师所具有的特点。这一小节对于那些希望承担这样一个角色的人们、或者那些希望找到满足要求的候选者的人们来说,是十分有用的。

设计一个开发环境的流程。这一小节对于那些希望更好地理解开发环境架构师所承担的任务的特点的人们来说,是十分有用的。

设计一个开发环境所带来的好处。这一小节对于那些需要传送开发环境架构师的角色的价值的人们、或者在自己企业内部考虑这样一个角色的人们来说,是尤其有用的。

什么是开发环境?

IBM Rational 认为一个开发环境应当由以下要素所组成:

  • 方法
  • 工具(方法的自动操作方面)
  • 授权(在方法和工具中)
  • 基础结构(用以支持方法、工具和授权)
  • 组织(用以支持方法、工具、授权和基础结构)

这些组成要素如图1中所示。下面,我们注意对其进行解释。

开发环境的组成要素

开发环境的组成要素

图 1. 开发环境的组成要素。

方法

对于任何一个开发环境来说,方法都是开发人员遵守的(无论正式地还是非正式地)一个关键的组成要素。方法定义了项目角色、任务、工作产品、以及流程。它还被那些应用到项目中的指导、标准、模板、以及例子所支撑。

工具

开发工具是方法的自动操作方面。举例来说,我们可能使用一个工具保存和管理项目的需求,或者使用一个工具对我们的体系架构和设计进行可视化地建模,或者使用特定的工具测试我们的软件,等等。

授权

对于开发人员的授权(培训和指导),是他们能够使用这种开发环境获得事业上的成功。因此,开发环境的一个方面就是能够被应用的培训和指导原料的定义和创造。授权本身关注于环境内部方法和工具的使用。

基础结构

方法、工具和授权都被某些基础结构(硬件和软件)所支持。举例来说,我们可能希望得到一种网络授权的方法,然后将其配置到公司的企业局域网中,这就需要一台网络服务器和其他一些硬件设备。开发工具往往以一种适当的规范(CPU、内存、硬盘)运行在开发人员的工作站上。培训原料可能通过若干种机制被提供,而不仅仅是通过教室。例如,基于网络的培训将需要一台网络服务器及其相关硬件的支持。

组织

正确的组织是开发环境使用的关键。它包括提供环境的某一方面的专家(例如方法专家、工具专家、培训师和指导者),管理和支持环境的工作人员,以及通过公司的帮助办公桌增强现有的技能集合的工作人员。

除了环境自身需要人员之外,创造(开发)这个开发环境显然也需要人员(包括开发环境架构师)。这可能会导致一些混乱!在图1中以及贯穿本文始终,我们都将方法、工具、授权、基础结构、组织和采用认为是环境自身的一部分。

采用

除了上述罗列出的组成要素之外,开发环境架构师还关注环境的采用。这远比获得相关的硬件和软件、安装和配置环境、以及培训和指导终端用户要复杂得多。采用同等地关注现有资产的移植(例如存在于遗留工具集中的工作产品)和那些根据预期结果对开发环境进行评定的测量法的收集。除此之外,架构师可能需要考虑定制开发环境的每一个组成要素,以便处理给定的业务单元、程序或者项目的特定需求的机制。

开发环境的采用的最重要的方面就是它表现了组织中的变化。由于人们的本性是抵触改变的,所以它提供了若干个架构帮助影响一个组织的改变,请详见 John P. Kotter 的论述。1

交叉要素

除此之外,还有一些因素影响着方法、工具、授权、基础结构、组织和采用的不同方面。这些额外因素横跨上述区域,并且表现了功能性、质量和约束。功能性由一个开发环境所提供,它表现了一个特定的软件工程科目,例如测试。质量表现了由开发环境所展示的特性,例如开发环境支持并发用户数量的能力。约束表现了实现该开发环境的约束条件,例如适应一个特定的操作系统的需要。下面,我们对这些组成要素分别加以详细的讨论。

功能性

功能性表现了一个软件工程科目,需要考虑上面所讨论的所有领域。举例来说,由一个开发环境所支持的测试科目包括:

  • 方法:和测试相关的组成要素(例如测试角色、测试工作产品、测试任务等);
  • 工具:测试方法的自动操作方面;
  • 授权:以测试相关的培训和指导原料的形式出现;
  • 基础结构:以支持测试方法、工具和授权的硬件和软件的形式出现;
  • 一个具有适当的测试技能的组织
  • 测试能力的采用。

这种思考可以被应用到作为开发环境一部分的所有科目之中,例如业务建模、需求、体系架构和设计、实现(编码)、部署、配置管理、变化管理、项目管理等等。

质量

开发环境应当展示的质量也要求对所有领域加以考虑。举例来说,通过开发环境被提供的一个可量测性质量(支持不同数量的并发用户的能力)包括:

  • 方法:组成要素能够被定制,以满足一个项目的大小;
  • 工具:能够被配置,以支持一种可配置的方法;
  • 授权:为不同大小的项目提供适当程度的培训和指导的机制;
  • 基础结构:能够量测以支持并发用户的预期数量;
  • 一个组织确保提供适当程度的熟练正确的资源,以确保项目的成功实现;
  • 使用适当机制的环境的采用

约束

开发环境应当提供的约束也要求对所有领域加以考虑。举例来说,通过开发环境被提供的从一个现有环境进行移植的需要包括:

  • 方法:承认任何一种现有方法的实践,并将它们合并到一个新的方法中;
  • 工具:从一个反对工具集中支持工作产品的移植;
  • 授权:承认当前技能,并且由此进行定制;
  • 基础结构:最大程度的复用现有的基础结构(例如在可能的情况下复用现有的硬件和软件证书);
  • 一个组织提供了一种从“现在的样子”到“未来的样子”的平稳的转变;
  • 承认移植被实现的采用机制。

同开发环境的实现相关联的另一个重要的约束就是投资回报(ROI),它同样要求我们对所有领域加以思考。为了获得成功,我们必须交付同业务案例相协调的积极成果。开发环境的每一个领域都以成本和收益的形式对投资回报产生着影响;特别是开发环境的采用,可能需要将一些关注放在对使用该环境所带来的结果的测量上面。

什么是开发环境的体系架构?

在定义过组成开发环境的元素之后,什么是开发环境体系架构工程师所关注的东西呢?软件和系统开发的领域能够帮助您解答这个问题。

正如我们将在这一小节以及后面的小节中所看到的,开发环境工程师的角色同其它类型的工程师有许多相同之处。本文的内容适用于任何类型的架构师,比如开发环境架构师、软件架构师、系统架构师等等。实际上,大部分资料都是基于我所撰写的对软件架构师这一角色的描述之上的。2 然而,本文中包含这些相关资料是为了提供一个开发环境架构师的更加全面的评述。这些资料已经被浓缩了,并且更加针对开发环境架构师这一特定角色。

体系架构的定义

关于“体系架构”的定义都是正确的;甚至还有专门收集这些定义的网站。3 本文中我所使用的定义来自于 IEEE Std. 1471。定义如下,其中关键的特性用黑体字突出显示:

体系架构指是系统在其组成要素、它们之间的关系、以及它们同环境之间的关系中被具体表达的基本的组织结构,以及指导其设计和发展的原则

尽管这个定义关注的是软件系统,但是我们也可以将其应用到一个开发系统之中。在我们的例子中,系统就是开发环境,组成要素就是方法、工具、授权、基础结构和组织。定义中所说的环境表现了开发环境所处的上下文,例如现有的处理过程、现有的工具、现有的技能、现有的硬件、以及现有的组织等;通常情况下,当我们定义一个开发环境时,我们也必须承担其中的约束。开发环境的组织,开发环境内部和外部各个元素之间的相互关系,以及这道设计和发展的原则等,是开发环境体系架构的核心。

体系架构的其他定义认为体系架构既关注结构也关注行为,认为它仅仅关注重要的决定,可能符合一种体系架构风格,受到其涉众和环境的影响,并且根据基本原理具体化决定。所有这些内容都将在下面加以讨论。

体系架构负责定义结构

如果您请人描述“体系架构”,十有八九他们会谈到结构、与建造的关系、或者其他民用工程的内容,例如桥梁。尽管体系架构存在其他特性,例如行为、适切性和美学等,但是它的结构话特性却是最相似的和最被经常提及的,对于一个开发环境来说也是如此。诸如方法、工具、授权、基础结构和组织这样的组成要素表现了组成开发环境的结构化的元素。

体系架构的许多定义不仅考虑结构化元素本身,而且考虑结构化元素的组成法、它们的关系(以及支持这些关系所需要的任何连接器)、它们的接口、以及它们的划分。再次指出,我们能够将这一思想应用到开发环境之中——也就是说,我们必须定义组成它的元素的各个方面。举例来说,我们必须定义角色、任务、以及包含一个方法的工作产品、任何工具之间的集成、它所包含的培训课程、包含基础结构的硬件和软件,以及组织内部的角色和职责等。除此之外,需要重点强调的是这些元素并不是孤立存在的,它们彼此之间存在着相互关系。举例来说,组织中的一个成员将扮演一个或者多个在环境方法中所定义的角色,使用运行在适当基础结构上面的适当工具,并且将接受适当的培训。

体系架构负责定义行为

如同定义结构化的组成元素一样,体系架构定义了这些结构化元素之间的交互作用。正是这些交互作用提供了我们所期望的行为。

我们将这一思想应用到开发环境之中。当方法实现时,它指导开发人员的工作,确保项目按照预先的设想进行并且交付预期的结果。当工具实现时,我们期望工作产品的生产。当授权实现时,我们期望开发人员接受培训和指导,从而掌握技能。当基础结构实现时,我们期望某些质量(例如工具的性能)从开发环境中被展示出来。当组织元素实现时,我们期望开发人员从开发环境中得到他们所要求的支持。

体系架构关注重要的组成要素

当体系架构定义结构和行为的同时,它并不参与定义所有的结构和所有的行为。它只关心重要的组成元素:即那些具有长远和持续影响的元素,例如主要结构元素、同本质行为相关联的元素、以及那些处理诸如依赖性和可量测性等重要质量问题的元素等。一般而言,体系架构并不参与这些元素的具体细节。

那么什么才是开发环境的重要元素呢?我们可以依次考虑开发环境的每一个方面。开发环境架构师参与识别环境中的角色、工作产品和任务,但是并不参与它们的细节。他们参与识别环境中的工具以及要求的集成,但是并不参与任何配置的细节。他们参与培训课程,但是并不关心每一门课程的细节。他们参与支持开发环境所要求的硬件和软件,但是并不需要了解每一项的详细规格。总之,我们所关注的是需要被适当安排的组织结构和角色,而无需考虑每个角色的详细职责。

体系架构平衡涉众的需要

体系架构被创建出来,最终是为了处理一组涉众的需要。然而,要满足所有需求往往是不可能的。举例来说,涉众可能要求某个特定的时间框架中的功能性,但是这两种需要(功能性和时间框架)可能是互相排斥的。要么减少其中一个的范围来满足进度安排,要么所有的功能性在一个扩展的时间框架内被提供,不同的涉众可能会提出彼此矛盾的需要,而这些需要不可能在同一个解决方案中实现。因此,妥协和权衡就成为设计流程中的一个本质方面,谈判是架构师的一种基本特性。

这一思想也可以被应用到一个开发环境的体系架构之中,开发环境架构师必须在各种需要之间寻求平衡(举例来说):

  • 开发人员:参与和开发环境相关联的直觉的和正确的行为、性能、依赖性、可用性、有效性、以及安全性;
  • 系统管理员:参与开发环境的直觉的行为、管理、以及辅助监控的工具;
  • 客户:为开发环境出资并且参与成本、投资回报、稳定性和时间进度;
  • 开发环境的实现者:参与清晰的需求和一个简单和一致的设计方法;
  • 维护人员:参与可理解的、一致的和记录的设计方式,并且能够轻松地对开发环境进行修改;
  • 发起人:参与根据任何相关的业务或者技术策略,从改善开发能力中不断调整预期的结果。

另一群经常被忘记的涉众就是那些策略支持者,他们可能提供了工具、培训、基础结构、以及第二线或者第三线的支持。他们的输入帮助架构师作出适当的决定,反过来,这些决定也影响到他们的提供。这不仅是一种技术关系。举例来说,业务关系的一个方面就是卖主的价格模型,它可能会影响到某个特定产品的选择。

体系架构将基于逻辑的决定具体化

如同体系架构本身一样重要的就是它以这种方式存在的基本原理。您应当确保决定随着作出这些决定的基本原理一起被记录,这是因为这一信息同许多涉众相关,特别是那些必须维护系统的涉众。当架构师需要第二次访问决定背后的基本原理的时候,这一信息通常对于架构师本身也是有价值的。这一信息还被用在体系架构被回顾的时候,以及架构师需要证明所作决定是正确的时候。

开发环境架构师必须能够提供作出决定的基本原理,例如选择某种工具、请求新的硬件来支持开发环境、或者请求公司内部目前缺少的技术人员。与 ROI 相关的体系架构决定的含义也是这一基本原理的本质要素。不仅开发环境架构师应当记录他们的决定以及作出这些决定的基本原理,而且应当通过遵循一种方法实践他们所鼓吹的内容。他们应当在需要的时候通过工具进行自动操作,通过训练和指导收到适当的授权,被适当的基础结构所支持,等等。

体系架构可能遵从一种风格

大多数体系架构都来源于共享一个相似关注集合的系统的体系架构。这种相似性能够被描述为一种体系架构风格,它也被视作一种特殊的模式,虽然它通常是一个复杂的和复合的模式(被一起应用的大量模式)。

[模式] 是指在一定上下文环境中解决某种共同问题的共同解决方案。5

同模式类似,体系架构风格反映了被归纳和整理后的经验,寻找复用这些经验的机会对于架构师来说是一种很好的实践。

[体系架构的风格] 从一个结构化组织的模式的角度定义了一个系统家族。更加特定的是,体系架构的风格定义了组成要素和连接器类型的词汇表,以及将它们联合起来的一组约束。6

我从设计开发环境中所学到的经验之一就是,确实存在能够被复用的共同的模式。模式本身非常依赖这样一些因素:公司的业务域、公司的规模、以及开发环境所支持的技术(例如:特定的编程语言)。

体系架构受到环境的影响,同时也影响着环境

系统位于环境之中,这个环境影响着体系架构。有时我们将其称之为“体系架构上下文”。从一个开发环境的角度来看,体系架构可能受到诸多方面的影响,例如:现有的方法和任何调整的或者组织的标准,任何委托工具,应当构成部分培训内容的现有课程,在硬件和连通性方面现有的基础结构,以及现有的组织结构和技能等。

相反地,正如 Len Bass 等人在 Software Architecture in Practice7 中所描述的那样,体系架构还有可能影响它的环境。举例来说,它可能将复用资产贡献给公司。更为特别的是,开发环境可能向公司贡献新的方法、工具、授权原料、基础结构以及技能。

体系架构出现在每一个系统之中

也没有必要每一个系统都有一个体系架构,即使这个体系架构没有被明确地记录,或者如果这个系统十分的简单,比如说,只包括单一的一个组成元素。记录体系架构通常十分有价值——否则的话我们很难(如果不是不可能的话)证明它满足一定的需求。没有被记录的体系架构目前看起来是大多数,趋向成为意外而非故意。

对于开发环境来说亦是如此。很少有公司在历史上对他们的开发环境的关键组成要素加以记录,他们倾向于仅仅关注记录某一方面,例如方法或者训练课程。正如图1中所包括的,一个开发环境中内部的不同元素并不是彼此独立的,记录开发环境体系架构通常带来很大的好处。举例来说,这样做能够帮助我们从冗余的基础结构方面识别潜在的最优化方案,或者帮助我们从方法、工具、授权、基础结构、组织和采用等方面理解改变某一特定科目(例如测试)所使用的实践后所产生的影响。

开发环境架构师的特点是什么?

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

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

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

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

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

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

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

架构师是一位技术领导者

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

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

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

架构师具备业务域的知识

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

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

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

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

架构师能够“深入进去”

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

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

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

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

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

架构师能够做出决定

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

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

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

架构师明了公司的政策

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

架构师是一位谈判代表

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

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

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

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

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

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

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

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

架构设计涉及到许多科目

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

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

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

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

设计强调随着时间的过去发现、发明和实现

设计强调随着时间的过去发现、发明和实现

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

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

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

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

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

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

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

设计承认此前的经验

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

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

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

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

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

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

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

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

架构设计处理了系统质量

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

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

架构设计推动了意见一致

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

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

架构设计支持了计划流程

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

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

架构设计推动了完整性

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

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

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

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

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

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

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

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

架构设计降低了维护成本

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

总结

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

感谢

感谢 Thomas Bichler、Dave Brown、Jos Jennekens、Mike Perrow 以及 Ton Van Velzen 对本文所提供的帮助和支持。

注释

  1. John P. Kotter,Leading Change,Harvard Business School Press,1996.
  2. 参见本系列的第 4 部分,包含了所有四部分的链接,其位于 进行软件架构设计的益处
  3. 例如,参见 Software Engineering Institute (SEI) Architecture Web 站点 -- 架构定义:How Do You Define Software Architecture?
  4. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std 1472000)。IEEE Computer Society,2000 年。
  5. The Unified Modeling Language User Guide。Grady Booch,James Rumbaugh 和 Ivar Jacobson,Addison Wesley,1999 年。
  6. Software Architecture: Perspectives on an Emerging Discipline。Mary Shaw and David Garlan,Prentice Hall,1996 年。
  7. Len Bass,Paul Clements 和 Rick Kazman,Software Architecture in Practice,第二版 Addison Wesley,2003 年。
  8. The Wisdom of Teams。Jon R. Katzenbach 和 Douglas K. Smith。Harvard Business School Press,1993 年。
  9. "The Architects -- The Software Architecture Team",Philippe Kruchten,Proceedings of the First Working IFIP Conference on Software Architecture (WICSA1)。Patrick Donohoe(编辑),Kluwer Academic 出版,1999 年。

相关主题

  • 您可以参阅本文在 develperWorks 全球网站上的 英文原文

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=309153
ArticleTitle=开发环境架构师的兴起
publish-date=05152008