软件架构是一门艺术

    尽管软件架构被认为是一门科学，但有些时候具备一定的创造力是十分必要的，在处理一些从未见过的奇特的系统时这一点就尤为重要。在这种情况下，可能没有成形的经验可以借鉴。就如同一个画家在面对一张空白的画板时需要灵感一样，架构师们有时会视他们的工作为一门艺术而不是一门科学。当然在很大程度上，软件架构的艺术层面是很小的。即使是面对一个极为新奇的系统，通常的做法也是借鉴别处的解决办法，处理之后使其适应用这个系统。

    随着软件架构过程日渐成为主流，它极有可能不再被认为是只有“被挑出的极少数人”可以理解的一系列神秘的实践行为，而是一系列被广泛接受的、建立在科学基础之上的、定义明确并通过检验的实践行为。

    软件架构跨越很多学科

    在软件开发过程中架构师需要涉及许多学科。架构师涉及最多的学科是软件设计，尽管如此，架构师也很关注其他的一些学科。例如，在需求分析里，架构师要确保对于利害关系的需求条件尤为了解，同时也懂得区分这些需求的优先次序。架构师参与实现工作，他们详细地说明用来组织源代码以及可执行的工作产品的实现结构。架构师们还参与测试工作，确保架构结构具有可测性并能通过测试。架构师负责开发环境中的一些特定元素，特别是建立一些特定的指针。架构师们还帮助制定配置管理策略，因为配置管理结构（用来支持版本管理的）经常影响已经定义好的软件架构。架构师与项目管理人紧密合作，正如这个文章系列中的第二部分所提到的，架构师已经成为项目计划中的一员。

    当谈及软件架构的范围时，我需要提到架构和设计的关系。尽管架构师尤为重视设计学，但并非所有的设计都可以认为是软件架构。因为一个架构只是关注那些十分重要的元素，而并不是所有的设计元素都对架构有重要意义。例如，用户界面屏幕的详细设计通常认为对架构没有任何意义，最好是留给用户界面设计者来完成。这种思路同样应用于其他的系统元素，例如那些支持业务逻辑或数据逻辑的元素。架构师只在必要时加以限制，而许多设计方面的决策都是留给设计者们来完成的。

    架构是时刻进行的行为

    经验表明，软件架构并不是在项目初期一蹴而就的事情，而是贯穿整个项目的始终。在整个项目里，通过交付给可执行软件的一系列迭代递增的程序，软件架构也日趋成熟。在每一次交付过程中，软件构架都会变得更加稳定完善。这就很好地解释了什么是架构师贯穿项目始终的重点。

    成功的软件架构行为是以结果为导向的。因此，架构师的重点会因预期结果随时间变化而变化。这一点如图2所示，图2由Bran Selic绘制。

 
　　　　　　　　　　　　　　　　　　图2：随时间变化的工程重点

    图2表明，在工程早期，架构师着眼于发现，重点是理解系统所涉及的范围并识别其主要特征及所有相关的风险——所有的要素对软件构架都有显著的影响。然后重点转向创造，主要是开发一个可以为整个实现过程提供牢固基础的稳定的构架。最终，重点放在了实现上面，这个时候大部分的发现和创造开始起作用。

    应该注意到，发现、创造和实现并不是严格按顺序来的。例如，随着架构模型的建立，在项目早期会有一些实现过程。而随着过程的深入理解和实现架构中某些元素的不同策略的提出，在项目后期将会有一些发现。

    请记住，直到系统交付架构过程才被完成，因此，架构师必须一直关注软件构架直至项目结束。一旦一个项目的软件构架稳定下来，人们总是希望架构师离开这个项目，将这一珍贵的资源用于其他的项目。然而，直到项目后期仍有一些架构方面的决策需要制定。实际上，还有介于两者之间的情况，一旦影响软件架构的重大决策制定出来，架构师就成为项目组中的一名兼职人员。不管怎样，架构师不应该完全脱离这个项目。当然还有一种更加灵活的情况，那就是由一个团队来履行架构师这个角色，这个团队里的一些成员可能去参予其他的项目，而另外一些则留下来继续确保这个系统架构的完整性。