2.2 解决方案架构师的职责

上一节介绍了解决方案架构师的各种角色，接下来我们将详细了解解决方案架构师的职责。

解决方案架构师既是技术领导者，也是面向客户的角色，它承担了许多责任。解决方案架构师的主要职责是将组织的业务愿景转化为技术解决方案，并作为企业和技术利益相关者之间的联络人。解决方案架构师利用广泛的技术专长和业务经验来确保解决方案的成功交付。

根据组织的性质，解决方案架构师的职责可能略有不同。通常情况下，在咨询机构中，解决方案架构师可能专门负责特定的项目和客户，而在产品型机构中，解决方案架构师可能会与多个客户合作，对他们进行产品培训，并审查他们的解决方案设计。

解决方案架构师在应用程序开发周期的不同阶段承担着各种责任，甚至在项目开始之前就承担了。在项目孵化阶段，解决方案架构师与业务利益相关者合作，准备和评估响应请求（RFR）文档。项目启动后，解决方案架构师将分析需求，以决定技术实现的可行性，同时定义非功能性需求，如可伸缩性、高可用性、性能和安全性。解决方案架构师了解各种项目约束，并通过开发概念验证来进行技术选型。开发开始后，解决方案架构师将指导开发团队，并调整技术和业务需求。应用程序启动后，解决方案架构师确保应用程序按照定义的非功能性需求执行，并根据用户反馈确定下一个迭代。

在本节中，你将了解有关产品开发生命周期各个阶段的解决方案架构师角色的更多信息。总体而言，解决方案架构师主要承担的职责如图2-2所示。

如图2-2所示，解决方案架构师承担着各种重要的职责。接下来，我们将详细了解解决方案架构师职责的各个方面。

2.2.1 分析功能性需求

业务需求是任何解决方案设计的核心，并且在项目启动时，它们就以原始术语进行定义。一开始就必须让不同的团队参与进来，其中就包括识别需求技术能力的团队。业务利益相关者定义了需求，当涉及技术演进路线时，还需要进行多次调整。为了节省工作量，在定义用户需求文档的同时，有必要让解决方案架构师参与进来。

解决方案架构师设计的应用程序可能会影响整体的业务产出。这使得需求分析成为解决方案架构师应该具备的关键技能。一个好的解决方案架构师需要具备业务分析师的技能以及与不同利益相关者合作的能力。

解决方案架构师带来了广泛的业务经验。他们不仅是技术专家，而且对业务领域也有很深入的理解。他们与产品经理和其他业务利益相关者紧密合作，以了解需求的所有方面。优秀的解决方案架构师可以帮助产品团队发现隐藏的需求，这些需求可能是非技术利益相关者没有从整体解决方案的角度考虑过的。

2.2.2 定义非功能性需求

对用户和客户来说，非功能性需求（Non-functional requirement，NFR）可能并不直观，但它们的缺失可能对整体的用户体验产生负面影响，并阻碍业务的发展。NFR包括系统的关键方面，如性能、延迟、可伸缩性、高可用性和灾难恢复。最常见的非功能性需求如图2-3所示。

考虑以下NFR：

1）性能：

● 用户的应用程序加载时间是多少？

● 我们如何处理网络延迟？

2）安全性与合规性：

● 我们如何保护应用程序免受未经授权的访问，

● 保护应用程序免受恶意攻击，

● 并遵守当地法律和审计要求？

3）可恢复性：

● 我们如何从中断中恢复应用程序，

● 并在中断时最大限度地缩短恢复时间？

● 我们如何恢复丢失的数据？

4）可维护性：

● 我们如何确保应用程序监控和告警？

● 我们如何确保应用程序支持？

5）可靠性：

● 我们如何确保应用程序执行一致，

● 检查并纠正故障？

6）可用性：

● 我们如何确保应用程序的高可用性，

● 使应用程序具有容错性？

7）可伸缩性：

● 我们如何满足日益增长的资源需求？

● 我们如何在利用率突然飙升的情况下实现良好的规模？

8）易用性：

● 我们如何简化应用程序的使用，

● 实现无缝的用户体验，

● 让不同的用户可以访问应用程序？

然而，根据项目的性质，可能有某些NFR仅适用于特定项目（例如，呼叫中心解决方案的语音清晰度）。有关这些属性的更多信息，请参见第3章。

解决方案架构师从非常早期的阶段就开始参与项目，这意味着他们需要通过衡量组织中各个团队的需求来设计解决方案。解决方案架构师需要确保跨系统组件和需求的解决方案设计保持一致。解决方案架构师负责定义跨组织的不同组件的NFR，因为他们要确保解决方案的易用性得到全面实现。

NFR是解决方案设计中不可或缺的重要方面，当团队过于关注业务需求时，NFR往往会被忽略，这可能会影响用户体验。好的解决方案架构师的主要责任是传达NFR的重要性，并确保它们作为解决方案交付的一部分得以实施。

2.2.3 了解并接触利益相关者

利益相关者可以是对项目有直接或间接利益的任何人。除客户和用户外，还可能是开发团队、销售团队、市场营销团队、基础设施团队、网络团队、支持团队或项目出资团队。利益相关者可以在项目的内部或外部。内部利益相关者包括项目团队、赞助商、员工和高级管理人员。外部利益相关者包括客户、供应商、生产商、合作伙伴、股东、审计人员和政府。

通常情况下，利益相关者根据其所处环境对同一业务问题会有不同的理解，他们从自身出发看问题，例如，开发人员可能会从编码的角度来看待业务需求，而审计师可能会从合规性和安全性的角度来看待业务需求。解决方案架构师需要与所有技术和非技术利益相关者合作。

解决方案架构师拥有出色的沟通技术和谈判技巧，这有助于找出解决方案的最佳路径，同时让每个人都参与其中。解决方案架构师作为技术资源和非技术资源之间的联络人，填补了沟通上的空白。通常，业务人员和技术团队之间的沟通差距会成为失败的原因。业务人员试图更多地从特性和功能的角度来看问题，而开发团队则努力构建一个技术上更兼容的解决方案，有时可能会倾向于项目的非功能性方面。

解决方案架构师需要确保两个团队的观点一致，同时确保其所建议的特性与技术方案的兼容性。他们根据需要对技术团队进行指导和引导，并将自己的观点用简单的语言表达出来，让大家都可以轻松理解。

2.2.4 明确约束

架构约束是解决方案设计中最具挑战性的属性之一。解决方案架构师需要仔细管理架构约束，并能够在它们之间进行协商以找到最佳解决方案。通常，这些约束是相互依赖的，强调某种约束可能会放大其他约束。最常见的约束如图2-4所示。

如图2-4所示，解决方案设计可以帮助我们了解应用程序的以下属性：

1）成本：

● 有多少资金可以用于解决方案的实施？

● 预期的投资回报率（ROI）是多少？

2）质量：

● 结果与功能性及非功能性需求的匹配程度如何？

● 如何确保和跟踪解决方案的质量？

3）时间：

● 什么时候应当交付产出？

● 时间上是否有灵活性？

4）范围：

● 确切的期望值是什么？

● 需求差距需要如何处理和适应？

5）技术：

● 可以利用什么技术？

● 对比传统技术，使用新技术能提供什么灵活性？

● 应该由公司自建还是从供应商那里采购？

6）风险：

● 什么地方可能出问题？

● 如何降低风险？

● 利益相关者的风险容忍度是多少？

7）资源：

● 完成解决方案的交付需要哪些资源？

● 谁将负责解决方案的实施？

8）合规性：

● 可能影响解决方案的当地法律要求是什么？

● 审计和认证要求是什么？

可能会有更多与项目相关的具体约束，比如，由于政府监管需要将数据存储在某一区域，或者出于安全考虑而选择自建。处理约束可能会非常棘手。解决方案架构师需要平衡约束并分析每个约束的权衡，例如，通过减少资源来节省成本可能会影响交付时间。

在资源有限的情况下实现进度可能会影响质量，而质量又会因为不需要的故障修复而增加成本。所以，在成本、质量、时间和范围之间找到平衡点是非常重要的。范围蔓延是最具挑战性的情况之一，因为它会对所有其他约束产生负面影响，并增加解决方案交付的风险。

解决方案架构师必须了解每个约束的所有方面，并能够识别任何由此而产生的风险，这一点非常重要。他们必须将风险缓解计划落实到位，并在两者之间找到平衡。处理范围蔓延会对项目的按时交付有很大帮助。

2.2.5 技术选型

技术选型最能体现解决方案架构师角色的关键性和复杂性。现在可用的技术种类繁多，解决方案架构师需要为解决方案确定适合的技术。解决方案架构师需要对技术有广度和深度的了解才能做出最佳决策，因为所选的技术栈会影响产品的整体交付。

每个问题都可能有多种解决方案和可用的技术范围。为了做出正确的选择，解决方案架构师需要牢记功能需求和NFR，并在创建技术决策时定义选择标准。所选择的技术需要考虑不同的维度，无论目标是能够与其他框架和API集成，还是能够满足性能要求和安全要求。

解决方案架构师应该选择不仅能满足当前需求，还能根据未来需求进行扩展的技术。

2.2.6 概念验证和原型开发

创建原型可能是作为解决方案架构师最有趣的部分。为了选择一个经过验证的技术，解决方案架构师需要在各种技术栈中开发概念验证（POC），以分析它们是否适合解决方案的功能性和非功能性需求。解决方案设计POC是指解决方案架构师试图找出解决方案的构件。

开发POC的思路是实现关键功能的一部分来评估技术，这可以帮助我们根据其能力来决定技术栈。它的生命周期很短，并且仅限于由团队或组织内的专家进行评审。

在使用POC评估多个平台后，解决方案架构师可以继续对技术栈进行原型设计。开发原型是出于演示的目的，将其呈现给客户，以便可以获得资金。POC和原型设计绝不是可以投入生产的。解决方案架构师构建的功能有限，但足以验证解决方案开发中具有挑战性的某个方面。

2.2.7 设计解决方案并持续交付

解决方案架构师在了解功能性需求、NFR、解决方案约束和技术选型等不同方面后，着手进行解决方案设计。在敏捷环境中，这是一种迭代的方法，其中的需求可能会随着时间的推移而发生变化，并且需要适应解决方案设计。

解决方案架构师需要设计经得起未来考验的解决方案，该解决方案应具有强大的基础构件，并且足够灵活，可以适应由于用户需求或技术增强而可能发生的变化。例如，如果用户需求增加了十倍，则应用程序应该能够扩展并适应用户需求，而无须对架构进行重大更改。同样，如果引入新技术（如ML或区块链）来解决问题，你的架构应该能够适应它们，例如，使用AI在电子商务应用程序的现有数据之上构建推荐系统。

然而，解决方案架构师需要谨慎对待需求的剧烈变化，并实施风险缓解计划。对于面向未来的设计，可以参考基于RESTful API的松耦合微服务架构。这类架构可以通过扩展来满足新的需求，并且更易于集成。第6章中会有更多关于不同架构设计的内容。

图2-5显示了解决方案交付的生命周期。解决方案架构师参与了解决方案设计和交付的所有阶段。

如图2-5所示，解决方案交付生命周期包括以下内容：

● 业务需求和愿景。解决方案架构师与业务利益相关者合作，以理解他们的愿景。

● 需求分析和技术愿景。分析需求，定义技术愿景以执行业务战略。

● 原型设计和推荐。通过开发POC和展示原型进行技术选型。

● 解决方案设计。解决方案架构师根据组织的标准，与其他相关团体协作设计解决方案。

● 开发。与开发团队合作开发解决方案，并作为桥梁连接业务和技术团队。

● 集成与测试。确保最终的解决方案在所有功能性需求和非功能性的需求下按照预期工作。

● 实施。与开发和部署团队合作，以确保方案顺利地实施，并在团队遇到障碍时提供指导。

● 运营和维护。确保日志和监控到位，并根据需要指导团队进行扩展和灾难恢复。

整个生命周期是一个迭代的过程。一旦应用程序投入生产，客户开始使用，就可能会从客户反馈中发现更多的需求，这将推动产品愿景的长远优化。解决方案架构师在解决方案设计过程中拥有主导权，他们可以执行以下操作：

● 记录解决方案标准。

● 定义高层设计。

● 定义跨系统集成。

● 定义解决方案的不同阶段。

● 定义实施方案。

● 定义监控与告警的方案。

● 记录设计选型的利弊。

● 记录审计与合规性要求。

解决方案架构师不仅负责解决方案的设计，还帮助项目经理进行资源和成本估算，定义项目的时间表和里程碑、项目的发布及其支持计划。解决方案架构师的工作贯穿解决方案生命周期的不同阶段，从设计到交付及发布。解决方案架构师通过提供专业知识和对项目广泛的了解，帮助开发团队克服重重障碍和壁垒。

2.2.8 对解决方案进行扩展

解决方案发布后，解决方案架构师会在产品可操作性方面发挥不可或缺的作用。为了应对不断增长的用户群和资源利用率，解决方案架构师应该知道如何在不影响用户体验的前提下，对产品进行伸展以满足需求，同时确保高可用性。

在诸如停机之类的突发事件中，解决方案架构师将指导基础设施、IT支持和软件部署团队如何执行灾难恢复计划，以保证业务流程的延续。解决方案架构师满足组织恢复点目标（RPO）和恢复时间目标（RTO）。RPO是指组织能够容忍的数据丢失量，即在停机间隔期间丢失的数据量，例如，15min的数据丢失。RTO定义了系统恢复正常运行所需的时间。我们将在第12章中了解更多关于RTO和RPO的信息。

在因需求增长而导致性能问题时，解决方案架构师会通过水平伸展系统以缓解应用程序瓶颈，或通过垂直伸展以缓解数据库瓶颈。在第9章中可以了解更多关于不同扩展机制和自我修复的信息。

解决方案架构师会计划让现有产品能够适应因使用模式或其他原因而产生的任何新需求。他们可以根据监控到的用户行为，对非功能性需求进行修改，例如，如果加载时间超过3s，用户就会跳出页面。通过这些工作，解决方案架构师会指导团队处理发布后可能出现的问题。

2.2.9 担任技术布道者

布道者是解决方案架构师角色中最激动人心的部分，他们在这部分的职责就是作为技术布道者来工作。解决方案架构师通过在公共论坛上广为宣传来增加产品和平台的采用率。他们撰写有关解决方案实施的博客，并举办研讨会，以展示技术平台的潜在优势和应用。

他们为技术建立大规模的支持，并帮助创建标准。解决方案架构师应该对技术充满热情。他们应当是优秀的公众演说家，并拥有卓越的写作技巧，才能担任技术布道者的角色。