2.3 为什么需要做软件架构
笔者是这样一种人：除非我能确信自己真的需要去做某件事，并且了解它的重要性和价值，否则，我就很难全身心地投入其中。如果读者也是这样的人，而且你也想了解软件架构的价值到底体现在哪里，那么就请继续往下看吧。
本节将会给出一些理据，来说明软件架构的重要意义。笔者之所以会极其热衷地从事架构工作，正是由于这些理据能够使我感到信服。
2.3.1 把架构视为交流工具
软件架构是一张蓝图，IT系统的设计、构建、部署、维护及管理，都要依照这张蓝图来进行。很多利益相关者都想对系统架构有一个良好的理解，然而单单从某一个视角来切入系统架构，是无法满足所有人的。由于不同的利益相关者可能有着不同的需求与期望，因此，我们需要从多个角度来观察架构。
为了把架构的实质内容准确地告知利益相关者，我们需要从各种不同的角度来进行沟通。比如，在与业务的发起方进行沟通时，架构师一定要采用与业务有关的说法来交谈，例如要清晰地阐明该架构是怎样解决业务需求的。在与业务方面的利益相关者进行沟通时，架构师也要使他们确信：这个架构并不是那种原来已经尝试过但却没能取得成功的架构。架构师所选取的表现形式，应该要能展示出这套架构为了满足某些宏观的业务用例，是怎样把一个或多个ABB的能力结合起来的。这种表现形式（也就是观察点，本章稍后将会详述它）及展示形式，同时还要凸显出架构蓝图的价值，并把这套蓝图视为整个系统得以设计和构建的基础。架构蓝图的这种效用，按照业务术语来说，就叫做价值驱动力（value driver），我们最终需要依靠这种驱动力，来确保该架构能够获得足够的投资，这些资金，至少要能够使系统得以部署并稳定地进行运作。
架构的表现形式有很多种，技术团队可以根据自身所处的技术领域选用适当的形式。比如：
应用程序架构师（application architect）需要理解系统的应用程序架构，需要专注于功能组件、组件的结构以及组件之间的依赖关系，也就是说，他们需要从功能架构的视角进行观察。
基础设施架构师（infrastructure architect）可能对服务器的拓扑结构、服务器之间的网络连接状况以及服务器中各个功能组件的排布状况感兴趣（然而他们所关注的问题并不局限于这些），也就是说，他们需要从操作架构的视角进行观察。
业务流程的拥有者（business process owner）当然要了解架构所支持或加以自动化的各种业务流程，这些流程是通过对系统所提供的特性与功能进行编排而实现出来的，其实现方式，通常是把一个或多个业务组件所具备的各种能力加以协调。业务流程的拥有者所感兴趣的这些问题，可以用静态的业务组件视图及动态的业务流程视图来进行展示，也就是说，他们需要从业务架构的角度进行观察。
针对架构问题进行有效的沟通，可以促使我们就正确的解决方案与方法展开有益的讨论，并对各种方案进行分析及权衡，以做出相应的决策。这不仅可以确保利益相关者的意见受到关注，而且还能够提升架构本身的质量。
我们要用各种方式与多位利益相关者进行沟通，使他们都能够明白架构的价值，并且了解价值中与自己有关的那个方面，同时还要使他们积极参与架构的演化过程，这对架构是否能够适当地延续下去，会起到很关键的作用。
2.3.2 对项目规划施加影响力
我们在前面讲过，宏观层面上的软件架构，可以由一系列ABB以及这些ABB之间的相互关系和依赖情况所确定。我们也说过，ABB还可以继续向下分解为一系列组件，这些组件之间，依然有着相互依赖的关系。在一般的软件开发过程中，我们通常要根据很多参数来排列系统的各项功能，以决定其优先顺序，这些参数包括：是否需要立刻展示系统的特性、是否需要先解决棘手的问题（用软件架构的术语来说，这些问题通常称为架构上重要的用例），以及季度的资本支出预算等。无论具体原因是什么，我们一般都需要对系统中某些特性之间的优先顺序进行规划。对软件组件的实现进行规划时，可以参照ABB之间的依赖情况来进行，如图2-2所示。
以图2-2为例，组件C2和组件C3，都依赖于组件C1的功能，而组件C2与组件C3之间，则是相互独立的，于是，架构师就可以利用这一现象来对项目的规划过程施加影响。比如，如果有足够的资源（也就是有足够多的设计师），那么架构师就可以并行地规划C1、C2和C3的设计工作，此外，（在有足够资源的前提下）也可以先把C1实现出来，然后再去并行地实现C2和C3。要想做好项目规划工作，就一定要对架构及其组件有适当的了解。架构师通常是项目经理的好搭档，在进行项目规划时，尤其如此。
架构师可以给项目的规划过程提供帮助，但是另一方面，项目规划团队通常也想更多地参与到架构事务中。架构组件的复杂程度，会对时间和资源（也就是专业技能和各种水平的专业知识）的指派和分配造成影响。
如果利益相关者不能够彻底地理解架构，那么对于具有一定规模的系统来说，其后续的设计、实现、测试计划以及部署等阶段，就会遇到巨大的困难。
2.3.3 关注非功能方面的能力
对软件系统在非功能方面的能力加以关注，是软件架构的一项关键职责。我们通常都说：如果在进行系统架构工作时没有对非功能型需求（nonfunctional requirement，NFR）给予足够重视，那么系统通常就会出现故障或发生崩溃，事实也确实如此。
在系统的非功能型需求中，可扩充性（extensibility）、可伸缩性（scalability）、可维护性，以及性能和安全程度，是其中比较重要的几个需求。NFR的特殊之处在于，它们本身虽然未必是组件实体，但是却需要架构中能够有一个或多个功能组件对其进行特别的关照。就这一点来说，架构中的非功能型需求，可以对这种功能组件的属性施加影响，并促使我们去增强其属性。考虑这样一个用例：系统需要把响应时间控制在1秒以内。系统架构师决定把C1、C2和C3这三个组件结合起来，以实现该用例。在这种情况下，组件的特性所具备的本质特点及复杂程度，就规定了每个组件必须要在多长时间内完成其职责，例如C1可能必须在300毫秒内完成，C2可能必须在500毫秒内完成，C3可能必须在200毫秒内完成。由此或许可以发现一些线索，使我们能够看出为了展现、支持或遵照某些特性，还需要给ABB添加哪些属性。
要想做出设计精良、考虑周到的架构，就应该对系统中那些非功能型需求给予适当的关注。在软件开发的生命期中，这些需求应该放在架构定义阶段来考虑，而不能等架构确定好之后再去考虑。
从技术角度来看，如果我们在进行系统架构时，能够适当地关注并考虑非功能方面的需求，那么系统的故障风险就会大幅度降低。
2.3.4 与设计团队和实现团队做出约定
软件架构中的一项重要内容，就是确立工作原则、指导方针、工作标准以及架构模式，架构师要对这方面的问题进行记录，并与设计团队和实现团队进行沟通。
在进行沟通时，架构师不仅要谈论架构中的ABB以及各ABB之间的接口和依赖关系，而且还要谈到工作原则、指导方针、工作标准以及架构模式等问题，这些问题合起来可以构成一套约束规则及边界条件，从而为系统架构和系统实现工作的确立与开发划定出一个范围。有了这样的约束规则，设计团队和实现团队就可以避免一些毫无必要的创新活动，他们会把注意力放在如何遵循这些约束上，而不会想着去打破它们。
在沟通过程中，架构师应该确保设计团队和实现团队能够意识到这些约束的重要性，并且使他们意识到自己不应该去违背架构原则与系统约定。在特殊情况下，如果确实存在强有力的理由，那么可以容许某些违背约束的做法，但这只能是特例。
2.3.5 为影响力分析提供支持
有一种状况对大家来说应该不会太过陌生，那就是由于新需求失控而导致的范围蔓延（scope creep）。为了防止出现这种状况，项目经理需要对新需求进行理解和评估，以确定其对当前项目的工作日程所造成的影响。
如果项目经理是个经验比较丰富的人，那么就会在第一时间去询问项目的主架构师，并且请该架构师进行必要的影响力分析（impact analysis）。
前面我们说过，软件架构可以确定架构中的各个ABB，也可以确定这些ABB之间的相互关系、依赖情况以及互动情况。因此，架构师可以对将要实现的新用例进行某种分析，以判断出架构中有哪些组件必须为此做出修改。架构师还可以根据新用例所需的信息交换和数据交换等操作，判断出架构中各组件之间的依赖关系是否也要进行修改。需要进行修改的组件数量、修改的幅度以及实现新用例所需的额外数据或数据源，都与新用例对项目的工作日程所造成的影响有着直接的关系。我们还可以进行更加深入的分析，以判断出这些修改对项目所造成的影响，以及项目成本和相关风险的提升程度。在考虑成本问题时，组件的特征是相当关键的指标，因为组件的设计成本、实现成本以及后续的维护和增强工作所需的成本，在很大程度上都与组件的特征有关。
笔者刚才提出了5项理由，用以证明软件架构的重要性。读者或许还能提出更多的理由，以论证其重要性。尽管如此，但笔者还是决定就此打住，因为我觉得上述理由已经足以令自己确信其重要性了，而且这样做也与本书的主题相一致。在本书中，如果笔者感觉对某个话题已经讲解得恰到好处了，那么就会继续讲下一个重要的话题。笔者的目标，就是要通过这本书来分享自己的经验，告诉大家怎样才能把软件架构中的各项原则运用得刚刚好，读者可以把这个水准当成参考基线或参照系，并按照自己的需求来进行调整。