《软件系统架构：使用视点和视角与利益相关者协作》访谈

《软件系统架构》的第二版出版于2011年11月，其中做了一些重要更新，包括对敏捷项目的架构、一种新的系统环境视点模型和一种新的轻量级验证方法（TARA——小型架构评审方法）的论述以及对UML2建模方法的更新。这本书的核心焦点是架构文档，特别是第一版引入的关于视点模型和视角模型的目录。

《软件系统架构》对软件架构领域进行了广泛的论述，它是软件架构师在架构的整个生命周期中需要理解并实施的一本手册，架构的生命周期开始于为了实现需求管理而与利益相关者进行交流，并经过持续的改进。这本书的重点之一是，根据项目的规模、风险以及开发方法对这样的架构过程进行裁剪，并给出了一组建议。这本书包罗万象，但是本次访谈主要探讨最新版本所论述的一些新主题。 InfoQ：为什么在已经有了如“4+1”和RM-ODP等框架的情况下，还需要一个关于视点（Vierpoint）模型和视角（Perspective）模型的新目录？

最初我们没有打算创建一套视点模型，甚至写一本书。这本书的产生是因为在2000年我们开始研究的时候，并没有多少针对从业者的软件架构书，所以我们就写了一本。我们研究了IEEE 1471标准（它对视图和视点的概念进行了标准化），并且我们认为这个标准提供了一个很好的框架，可以用来组织我们的想法。因此，我们产生了创建一套视点模型的主意。我们有成功地使用“4+1”模型的实践经验，但是我们发现在某些我们参与的项目（企业信息系统）中这种模型不是非常适合。所以，我们针对那些构建企业信息系统的需求，根据我们在这方面的经验，创建了一套自己的视点模型，把它作为已经很成功的“4+1”模型的直接扩展和修改。

在2005年的第一版之前还没有视角的概念，因此这算是我们对这个领域的贡献。我们发现这种模型是有用，我们也希望其他人能够发现这种模型会有所帮助。我们之所以创建视角模型，是因为我们需要一种框架，它能够让我们得到如何实现如可扩展性、安全性等质量属性的建议，而这些质量属性会涉及多个架构视图。这是我们和许多其他架构师无意中做过的一些事情，但是从前没有真正地思考过它们。视角模型只是将这个方法正式化，这样我们可以定义了一个应用该方法的简单框架，再加上针对不同质量类型的指导书和检查单。

InfoQ：为什么将环境视点模型加入目录？

在我们写这本书的第一版时，我们一直认为系统环境图和外部接口定义是系统需求的一部分。因此在开始架构工作之前这些材料应该已经在我们手中了。当然，世界通常不是这样运行的：最重要的架构工作在项目生命周期的早期就已经完成了，但在这个时候不确定性却是最高的，而且项目范围和需求常常没有讨论完或达成一致。我们发现在几乎每一个我们参与的项目中，我们都会创建一个环境图作为架构说明的一部分。因此，通过定义环境视点模型，我们只不过是面对了现实！

InfoQ：借助于移动和云计算技术以及不断增长的对用户体验的关注，IT消费化的浪潮怎样影响架构的角色？

与企业用户相比，消费者更加不能容忍缓慢、不可用、不稳定、不安全或者易用性差的系统，而企业用户通常没有什么选择，不得不使用提供给他们的系统。实现这样的质量属性是软件架构的首要目标，所以随着IT变得更加消费化，软件架构的重要性也许会增强。虽然在某种意义上我们仍然有着同样的问题和陷阱，但是转向以Internet为中心的部署以及使用基于云的服务器和移动设备则引入了很多新的有趣的架构选择和相关的折衷方案。例如，我们发现自己更多地考虑最终一致性（如BASE架构类型）而不是通常使用的“ACIDic”事务，以及在部署到云环境时新的可用的部署选项而不是传统的数据中心。我们认为，作为一个产业，我们现在刚刚开始了解它的影响和前景，未来到处可以看到令人兴奋的产品，正是这些新的架构选择激发了它们。如此颠覆性的新选择和相关的折衷方案对我们的系统架构有着深远的影响，所以当向云计算技术迁移时，每个人都需要更多地从架构上进行考虑。

InfoQ：对于敏捷团队，您建议架构师应该将其工作与Sprint相结合，并且通过创建可执行的模型，以集中精力来简化有效的架构工作？

我们没有建议一定要创建可执行的模型。对一些架构师来说，这些模型非常有用，也很有效果，但是在主流的企业系统开发领域，我们还没有看到它在实践中的应用。我们的意思是，架构师应该创建能够运行或者人们能够使用的有用的东西。它可以是一个Spike原型、一个核心领域模型的实现、一个极其简单的原始系统实现、一个概念运用的证明、一些你想关注的可执行的失败测试集或者用一个Excel实现的性能模型。关键的一点是，它必须有用且可执行，这样人们能够在实践中立即使用它。

InfoQ：软件项目的问题之一是在进行产品开发的同时保持对预先定义的架构的遵从。是否有一套推荐的工具和过程来确保正在进行的开发工作和各种视图之间的符合性和一致性？

老实说关于这方面我们无法推荐，没有这样一套已被证实的强大的工具和实践。这里有两个问题。首先，你如何检查视图之间是一致的？其次，你如何检查实现是否符合系统所需要的架构？除非你的视图是全部可以机读的，并且绝大多数的视图不会同时使用比较正式的类似于UML的标记法、非正式的标记法和自然语言，否则即使通过使用机器，第一个问题也是无法解决的。因此对于使用我们的视点模型所构造的视图，我们定义了一套检查视图之间一致性的规则，它们很有用，但检查工作还是不得不手工去做。就检查实现是否符合系统所需要的架构而言，有许多方法能够起到帮助作用，这包括架构评估法、静态分析（如Structure 101、 Lattix、 SonarJ、 Axivion Bauhaus）和组件系统（如OSGi或者用于Java的Impala）。在现实中，除了架构中最简单的部分之外，检查架构中任何方面的符合性都是一个非常困难的问题，现在的工具和技术无法真正地对付它。当前，专家评审和评判大概仍然是我们所拥有的最好的工具。

关于作者

Nick Rozanski 从1980年开始在IT业为几个大型和小型的系统集成商以及终端用户组织工作，前者包括Logica、Capgemini和Sybase，后者包括 Marks & Spencer和Barclays Global Investors。他在金融业、零售业、制造业和政府的诸多大型项目中担任资深角色。他的技术背景包括企业应用系统集成、软件包实施、关系数据库、数据 复制以及面向对象的软件开发。他还是一名经验丰富的技术讲师和注册的内部项目审计师。

 

Eoin（读作“Owen”）Woods是一家大型欧洲投资银行股票交易技术组的首席系统架构师，负责该机构许多关键系统的架构和设计工作。在此之前，他 在Barclays Global Investors领导了应用架构组的工作，在Group Bull、Sybase、InterTrust和Zuhlke担任软件工程师，他还创办了自己的咨询公司Artechra。

 

 查看英文原文： Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives