了解解决方案架构师的作用
1 .用户需求分析
2 .非功能要求的定义
3 .参与并与利益攸关方合作
4 .处理各种架构的约束
5 .进行技术选择
6 .概念证明和原型开发
7 .设计并坚持提供解决方案
8 .确保发射后的可操作性和维护
9 .充当技术传播者
1 .用户需求分析
业务要求是所有解决方案设计的核心，在项目开始时由原始术语定义。 从一开始就需要让各种各样的团队参加，包括确定需求的技术能力。 商务人士需要定义需求，并在技术进化方面多次调整。 为了省力，在定义用户需求文档时需要雇佣解决方案架构师。
解决方案架构师设计APP应用程序。 这可能会影响整个业务的成果。 这使需求分析成为解决方案架构师的重要技能。 优秀的解决方案架构师需要业务分析师的技能和与多方合作的能力。
解决方案架构师给他们带来了广泛的业务经验。 他们不仅是技术专家，对业务领域也很了解。 他们与产品经理和其他商业利益相关者密切合作，了解需求的各个方面。 优秀的解决方案架构师可以帮助产品团队发现潜在的需求。 非技术人员可能没有从整个解决方案的角度考虑。
2 .非功能要求的定义
用户和客户可能无法直接看到非功能性需求(NFR )，但缺少它们可能会对整个用户体验产生负面影响，阻碍业务发展。 NFR包括系统的关键方面，包括性能、延迟、可扩展性、高可用性和灾难恢复。 最常见的非功能需求如下图所示。
解决方案设计中的NFR
上图考虑了以下NFR :
性能：
使用者APP应用程式的载入时间是多少？
如何处理网络延迟？
安全性和法规遵从性：
如何保护APP应用程序免受未经授权的访问？
如何保护APP应用程序免受恶意攻击？
如何符合当地法律和审计要求？
可恢复性：
如何从中断中恢复APP应用程序？
如果发生中断，如何最大限度地缩短恢复时间？
如何恢复丢失的数据？
可维护性：
如何确保APP应用程序的监视和警报？
如何确保对APP应用的支持？
可靠性：
如何确保APP应用程序始终如一地运行？
怎么检查故障并修正？
可用性：
如何确保APP应用程序的高可用性？
如何使APP应用程序具有容错能力？
可扩展性：
您如何应对不断增长的资源需求？
如何在利用率急剧上升的情况下实现良好的规模呢？
可用性：
如何简化APP应用程序的使用？
如何提供无缝的用户体验？
但是，根据项目的性质，可能存在仅适用于项目的NFR (例如呼叫中心解决方案的语音声明完成度)。 这些属性的第三章，有关属性的解决方案体系结构的信息，请参见。
解决方案架构师很早就参与了项目。 这意味着，您需要通过衡量组织中各组之间的需求来设计解决方案。 解决方案架构师必须确保解决方案设计跨系统组件和要求的一致性。 解决方案架构师负责在组之间和不同组件之间定义NFR，以确保完全实现解决方案所需的可用性。
NFR是解决方案设计的一个不可缺少的方面，如果团队过于关注业务需求，它会变得很滑，影响用户体验。 优秀的解决方案架构师的主要责任是传达NFR的重要性，并确保将其作为解决方案交付的一部分实施。
3 .参与并与利益攸关方合作
利益相关者可以是对项目有直接或间接利益的任何人。 除了客户和用户之外，他们还可能是开发团队、销售、营销、基础架构、网络、支持团队或项目资助组。
利益相关者可以是项目的内部或外部。 内部人员包括项目团队、发起人、员工和高级管理人员。 外部利益攸关方包括客户、供应商、供应商、合作伙伴、股东、审计员和政府。
利益相关者通常根据上下文对同一业务问题有不同的理解，例如，开发人员可以从编码的角度看业务需求，审计员可以从法规遵从性和安全的角度看业务需求。 解决方案架构师必须与所有技术和非技术人员合作。
他们有良好的沟通和协商技能，有助于找到解决方案的最佳方法，让每个人都能参与。 解决方案架构师作为技术资源和非技术资源之间的联系方式填补了沟通的空白。 业务人员和技术团队之间的沟通鸿沟通常会导致失败。 业务代表试图从更多的特性和功能角度看待事物，但开发团队努力构建技术上更兼容的解决方案，有时可能会倾向于项目的非功能性方面。
解决方案架构师必须确保两个团队位于同一页面上，并且建议的功能在技术上也兼容。 他们将在必要时指导和指导技术团队，并将他们的观点转化为人人都能理解的简单语言。
处理各种架构约束
体系结构约束是解决方案设计中最困难的属性之一。 解决方案架构师必须能够仔细管理体系结构限制，并在它们之间进行协商，以找到最佳解决方案。 这些限制通常是相互依存的，强调一个限制可能会夸大其他限制。
最常见的制约因素包括： 听
##解决方案设计中的架构约束
如上图所示，解决方案设计有助于您了解APP应用程序的以下属性：
费用：
有多少资金可用于实施解决方案？
预计投资回收
报( ROI )？质量：
结果应该与功能性和非功能性需求的匹配程度如何？
我们如何确保和跟踪解决方案的质量？
时间:
什么时候应该交付输出？
时间上有弹性吗？
范围：
确切的期望是什么？
需求差距需要如何处理和超级的凉面？
技术：
可以利用什么技术？
使用传统技术与新技术相比，使用哪些灵活性？
我们应该内部构建还是从供应商处采购？
风险：
会出现什么问题，我们如何减轻这种情况？
利益相关者的风险承受能力如何？
资源：
完成解决方案交付需要什么？
谁将负责解决方案的实施？
合规性：
哪些当地法律要求会影响解决方案？
审核和认证要求是什么？
可能存在与项目相关的更具体的限制，例如由于政府监管而将数据存储在某个国家/地区，以及出于安全考虑选择内部开发。处理约束可能非常棘手。通过减少资源来节省成本可能会影响交付时间表。
在资源有限的情况下实现计划可能会影响质量，这反过来又会因不需要的错误修复而增加成本。因此，在成本、质量、时间和范围之间找到平衡非常重要。范围蔓延是最具挑战性的情况之一，因为它会对所有其他约束产生负面影响，并增加解决方案交付的风险。
解决方案架构师必须了解每个约束的所有方面并能够识别任何由此产生的风险。他们必须制定风险缓解计划并在它们之间找到平衡。处理任何范围蔓延对按时交付项目有很大帮助。
5.进行技术选择
技术选择是解决方案架构师角色的关键方面和复杂性。可用的技术范围很广，解决方案架构师需要为解决方案确定正确的技术。解决方案架构师需要拥有广泛和深入的技术才能做出正确的决策，因为所选的技术堆栈会影响产品的整体交付。
每个问题都可以有多种解决方案和可用的技术范围。为了做出正确的选择，解决方案架构师需要牢记功能需求和 NFR，并在制定技术决策时定义选择标准。选择的技术需要考虑不同的角度，无论目标是与其他框架和 API 集成的能力，还是满足性能要求和安全需求。
解决方案架构师应该能够选择不仅满足当前需求而且可以扩展以满足未来需求的技术。
6.开发概念证明和原型
创建原型可能是解决方案架构师懦弱的乐曲部分。要选择一种经过验证的技术，解决方案架构师需要在各种技术堆栈中开发概念证明( POC )，以分析它们是否适合解决方案的功能和非功能需求。
开发 POC 的想法是用关键功能实现的子集来评估技术，这可以帮助我们根据其能力决定技术堆栈。它的生命周期很短，仅限于由团队或组织内的专家审查。解决方案设计 POC 是解决方案架构师试图找出解决方案的构建块的时候。
在使用 POC 评估多个平台后，解决方案架构师可以继续对技术堆栈进行原型设计。开发原型用于演示目的并提供给客户，以便它可以用于确保资金。POC 和原型设计绝不是生产就绪的；解决方案架构师构建的功能有限，这可能是解决方案开发的一个具有挑战性的方面。
7.设计解决方案并坚持交付
解决方案架构师在了解功能需求、NFR、解决方案约束和技术选择的不同方面后开始解决方案设计。在敏捷环境中，这是一种迭代方法，其中需求可能会随时间变化并需要适应解决方案设计。
解决方案架构师需要设计一个面向未来的解决方案，该解决方案应该具有强大的构建块并且足够灵活以适应变化。但是，解决方案架构师需要注意需求的急剧变化并应用风险缓解计划。
对于面向未来的设计，您可以以基于 RESTful API 的松散耦合微服务架构为例。这些架构可以扩展到新的需求，并且能够轻松集成。您将了解不同的体系结构设计，在第6章，听解决方案架构设计模式。
以下流程图显示了解决方案交付生命周期。解决方案架构师参与解决方案设计和交付的所有阶段：
解决方案交付生命周期
如上图所示，解决方案交付生命周期包括以下内容：
业务需求和愿景：解决方案架构师与业务利益相关者合作以了解他们的愿景。
需求分析和技术愿景：解决方案架构师分析需求并定义技术愿景以执行业务战略。
原型设计和推荐：解决方案架构师通过开发 POC 和展示原型来进行技术选择。
解决方案设计：解决方案架构师根据组织的标准并与其他受影响的团体合作开发解决方案设计。
开发：解决方案架构师与开发团队合作进行解决方案开发，并充当业务团队和技术团队之间的桥梁。
集成和测试：解决方案架构师确保最终解决方案按预期工作，满足所有功能和非功能需求。
实施：解决方案架构师与开发和部署团队合作以顺利实施并指导他们克服任何障碍。
运维：解决方案架构师确保日志记录和监控到位，并根据需要指导团队进行扩展和灾难恢复。
但是，整个生命周期是一个迭代过程。一旦应用程序投入生产并且客户开始使用它，您可能会从客户反馈中发现更多需求，这将推动未来增强的产品愿景。
解决方案架构师在解决方案设计期间拥有主要所有权，他们在其中执行以下操作：
记录解决方案标准
定义高级设计
定义跨系统集成
定义不同的解决方案阶段
定义实施方法
定义监控和警报方法
记录设计选择的优缺点
记录审计和合规要求
解决方案架构师不仅负责解决方案设计。他们还帮助项目经理进行资源和成本估算、定义项目的时间表和里程碑、项目的发布及其支持计划。解决方案架构师在解决方案生命周期的不同阶段工作，从设计到交付和发布。解决方案架构师通过提供专业知识和广泛的理解帮助开发团队克服障碍和障碍。
8.确保发射后的可操作性和维护
解决方案架构师在解决方案上线后，在产品的可操作性上扮演着不可或缺的角色。为了处理不断增长的用户群和产品利用率，解决方案架构师应该知道如何扩展产品以满足需求并确保高可用性而不影响用户体验。
在不可预见的事件（例如中断）中，解决方案架构会指导您执行灾难恢复计划以继续业务流程。将溶液建筑师满足组织ř ecovery点目标听（RPO）和- [R ecovery点目标听（RTO）。RPO 是组织在中断间隔期间丢失的数据量（例如，15 分钟的数据丢失）方面可以容忍的数据丢失量。RTO 是系统恢复并再次运行所需的时间。您将了解RTO和RPO在第12章，听的DevOps和解决方案体系结构框架。
如果由于需求增加而出现性能问题，解决方案架构师可以帮助横向扩展系统以缓解应用程序瓶颈或纵向扩展以缓解数据库瓶颈。您将了解不同的缩放机制和自我修复在第9章，建筑可靠性因素。
解决方案架构师计划适应现有产品中因使用模式或任何其他原因而产生的任何新需求。他们可以根据监控用户行为对非功能性需求进行更改；例如，如果加载时间超过 3 秒，用户就会跳出页面。解决方案架构师通过这个工作并指导团队处理发布后可能发生的问题。
9.作为技术传播者工作
布道者是解决方案架构师角色中最令人兴奋的部分，他们作为技术布道者工作。解决方案架构师通过公共论坛传播信息来提高产品和平台的采用率。他们撰写有关解决方案实施的博客并举办研讨会以展示潜在的好处和技术平台的使用。
他们建立对技术的大规模支持并帮助建立标准。解决方案架构师应该对技术充满热情。他们应该是一名优秀的公众演讲者，并拥有出色的写作技巧来扮演技术传播者的角色。