2.3.1 把架构视为交流工具

软件架构是一张蓝图，IT系统的设计、构建、部署、维护及管理，都要依照这张蓝图来进行。很多利益相关者都想对系统架构有一个良好的理解，然而单单从某一个视角来切入系统架构，是无法满足所有人的。由于不同的利益相关者可能有着不同的需求与期望，因此，我们需要从多个角度来观察架构。

为了把架构的实质内容准确地告知利益相关者，我们需要从各种不同的角度来进行沟通。比如，在与业务的发起方进行沟通时，架构师一定要采用与业务有关的说法来交谈，例如要清晰地阐明该架构是怎样解决业务需求的。在与业务方面的利益相关者进行沟通时，架构师也要使他们确信：这个架构并不是那种原来已经尝试过但却没能取得成功的架构。架构师所选取的表现形式，应该要能展示出这套架构为了满足某些宏观的业务用例，是怎样把一个或多个ABB的能力结合起来的。这种表现形式（也就是观察点，本章稍后将会详述它）及展示形式，同时还要凸显出架构蓝图的价值，并把这套蓝图视为整个系统得以设计和构建的基础。架构蓝图的这种效用，按照业务术语来说，就叫做价值驱动力（value driver），我们最终需要依靠这种驱动力，来确保该架构能够获得足够的投资，这些资金，至少要能够使系统得以部署并稳定地进行运作。

架构的表现形式有很多种，技术团队可以根据自身所处的技术领域选用适当的形式。比如：

应用程序架构师（application architect）需要理解系统的应用程序架构，需要专注于功能组件、组件的结构以及组件之间的依赖关系，也就是说，他们需要从功能架构的视角进行观察。

基础设施架构师（infrastructure architect）可能对服务器的拓扑结构、服务器之间的网络连接状况以及服务器中各个功能组件的排布状况感兴趣（然而他们所关注的问题并不局限于这些），也就是说，他们需要从操作架构的视角进行观察。

业务流程的拥有者（business process owner）当然要了解架构所支持或加以自动化的各种业务流程，这些流程是通过对系统所提供的特性与功能进行编排而实现出来的，其实现方式，通常是把一个或多个业务组件所具备的各种能力加以协调。业务流程的拥有者所感兴趣的这些问题，可以用静态的业务组件视图及动态的业务流程视图来进行展示，也就是说，他们需要从业务架构的角度进行观察。

针对架构问题进行有效的沟通，可以促使我们就正确的解决方案与方法展开有益的讨论，并对各种方案进行分析及权衡，以做出相应的决策。这不仅可以确保利益相关者的意见受到关注，而且还能够提升架构本身的质量。

我们要用各种方式与多位利益相关者进行沟通，使他们都能够明白架构的价值，并且了解价值中与自己有关的那个方面，同时还要使他们积极参与架构的演化过程，这对架构是否能够适当地延续下去，会起到很关键的作用。