2.4 增强干系人之间的沟通

        软件架构代表系统的通用抽象，系统的大多数（如果不是所有的话）干系人可以用它来作为建立相互理解、协商、形成共识及互相之间沟通的基础。架构，或架构的部分，能够充分地抽象，以便很多非技术人员能够充分地理解它，特别是在架构师的指导下，而且这些抽象可以被提取为充分丰富的技术规范，用于指导实现、集成、测试和部署。

        每个软件系统的顾客、用户、项目管理者、开发人员、测试人员等等这些干系人——会受到受架构影响的系统的不同特征影响。例如：
        (1) 用户关心系统是快的、可靠的，并且在需要时是可用的；
        (2) 顾客关心架构可以按计划和预算实现；
        (3) 管理者担心（除了关心成本和计划外）架构将允许团队最大可能的独立工作，以有纪律和受控的方式进行交互；
        (4) 架构师担心达成所有目标的策略；

        架构提供了通用语言，使用通用语言，即使对于大型复杂系统，也可以在智能上可管理的级别上进行表达、协商、解决不同的关注点。没有这一语言，就很难充分地去理解大型系统，从而做出影响质量和有用性的早期决策。架构分析（后文会阐述），都基于这个层级的沟通，且会增加这一沟通水平。

        下文展示了干系人以及他们的深层次担忧：

---

“当我点击这个按钮的时候会出现什么？”架构作为干系人的沟通工具

        项目审核在没完没了的进行。政府资助的开发项目落后于计划，超出了预算，规模之大足以引起国会的注意。政府现在正在通过组织马拉松式的审核会议来弥补过去的忽视。承包商最近经历了一次公司收购，但并没有什么帮助。那是第二天的下午，会议的方程是将被提出的软件架构。年轻的架构师——系统首席架构师的学徒——在勇敢地解释大规模系统的软件架构如何实现严苛的即时、分布式、高可用需求。他的描述很可信，提供的架构也很可信。听起来非常合理。但是跟这个项目关系紧密的来自管理和监察部门的30个不同角色的政府代表都觉得很累。有些人甚至在想，也许他们应该投身于房地产行业，而不是忍受另一场马拉松式的“让我们最终把它做好”的评审。

        视图展示，在半正式的框线注释中，主要的软件元素是在系统的运行视图中。年轻的架构师给的名字都是首字母缩写，没有解释就没有语义意义。线条显示了数据流、消息传递以及进程同步。元素是内部冗余的，架构师正在解释。“如果发生故障”，他开始说，使用激光笔指着其中的一条线，“通过这条路径触发重启机制当...”

        “按下模式选择按钮时会发生什么情况？”听众成员中有个人打断问道。他是代表了这个系统的用户社区的政府与会者。

        “麻烦你复述一下你的问题”架构师说到。

        “模式选择按钮”，他说，“当按下它时会发生什么？”

        “呃，会触发设备驱动中的一个事件，在这”，架构师开始解释，使用激光笔指着。“然后会读取注册表并解释事件代码。如果是模式选择，那么它会向黑板发送信号，而黑板又会向订阅该事件的对象发送信号。”

        “不，我的意思是，系统做了什么？”提问者打断道，“会重新设置显示器吗？以及，如果在系统进行重新配置时点击这个按钮，会发生什么？”

        架构师看起来有一点吃惊，并关掉了激光笔。这不是一个架构性的问题，但由于他是一个架构师，且因为对需求很了解，他知道这个答案。“如果命令行是在设置模式，显示器就会被重新设置，”他说。“否则控制台控制器就会显示一条失败信息，但这个信号会被忽略。”他重新把激光笔打开。“现在，我刚刚说的重启机制......”

        “哦，我只是很担心，”用户代表说。“因为我从你的报表中看到，显示器控制台正在发送信号到目标位置模块。”

        “那应该发生什么呢？”另一个听众向第一个提问者问到。“你真希望用户能够在重新配置期间获取到模式数据？”。接下来的45分钟，架构师看着观众们争论在各种深奥的状态下系统的正确行为，以此消磨时间。

        这些争论与架构无关，但是架构（以及它的图表表现形式）是这次争论的诱因。架构除了作为架构师和开发人员的沟通基础外，干系人将之作为沟通基础也是比较常见的：例如，管理人员参考架构来组建团队和分配资源。但用户呢？毕竟，架构对用户是不可见的；为什么他们要把它作为理解系统的工具呢？

        而事实上，他们正在这样做。在本例中，提问者花了两天来通过视图考虑关于功能、操作性、用户接口和测试的所有内容。但这是架构的第一页PPT——即使他很疲惫，而且想回家——他意识到他有些内容不清楚。出席过的很多架构审核告诉我，用一种新的方式看系统能够刺激思维并带来新的问题。对用户来说，架构通常是一种新的服务，并且用户提出的问题通常是更行为化的。在几年前的一次令人难忘的架构评估中，用户代表对系统将要做什么比系统要怎么做会更感兴趣，这也很正常。在此之前，他们与供应商的唯一联系，就是销售人员。架构师是对他们来说，是他们能够接触到的第一个系统专家，他们没有任何犹豫就会抓住这个机会提问。

        当然，谨慎且全面的需求规格说明书会对这种场景有改善，但因为不同的原因，它们并不总会被编制出来，或者说不总是可用的。由于需求规格说明书的缺失，架构说明书经常用来触发一些问题以及提升清晰度。这可能会更清晰地识别这个事实而不是去抵制它。

        有时候这种练习会揭露不合理需求，然后可以重新审视这些需求的效用。这种审视强调需求和架构之间的协同让本故事中年轻的架构师摆脱了困境，让他在总体评审会议中占有一席之地，以处理此类信息。并且用户代表不会感觉到像脱离水的鱼一样，在一个明确不恰当的时机去问这些问题。

——PCC

---