了解解决方案架构师的职责
1.分析用户需求
2.定义非功能性需求
3.参与并与利益相关者合作
4.处理各种架构约束
5.进行技术选择
6.开发概念证明和原型
7.设计解决方案并坚持交付
8.确保发射后的可操作性和维护
9.作为技术传播者工作
1.分析用户需求
业务需求是任何解决方案设计的核心,它们在项目开始时以原始术语定义。从一开始就有必要让不同的团队参与进来,其中包括识别需求的技术能力。业务利益相关者定义需求,并且在技术演进方面需要进行多次调整。为了省力,有必要在定义用户需求文档时聘请解决方案架构师。
解决方案架构师设计应用程序,这可能会影响整体业务成果。这使得需求分析成为解决方案架构师应该具备的一项关键技能。一个好的解决方案架构师需要具备业务分析师的技能以及与不同的利益相关者合作的能力。
解决方案架构师为他们带来了广泛的业务经验。他们不仅是技术专家,而且对业务领域有很好的了解。他们与产品经理和其他业务利益相关者密切合作,以了解需求的所有方面。一个好的解决方案架构师可以帮助产品团队发现隐藏的需求,非技术利益相关者从整体解决方案的角度可能没有考虑过。
2.定义非功能性需求
用户和客户可能无法直接看到非功能性需求(NFR),但它们的缺失可能会对整体用户体验产生负面影响并阻碍业务发展。NFR 包括系统的关键方面,例如性能、延迟、可扩展性、高可用性和灾难恢复。最常见的非功能性需求如下图所示:
解决方案设计中的 NFR
上图显示了以下 NFR 供考虑:
性能:
用户的应用程序加载时间是多少?
我们如何处理网络延迟?
安全性和合规性:
我们如何保护应用程序免受未经授权的访问?
我们如何保护应用程序免受恶意攻击?
我们如何满足当地法律和审计要求?
可恢复性:
我们如何从中断中恢复应用程序?
发生中断时,我们如何最大限度地缩短恢复时间?
我们如何恢复丢失的数据?
可维护性:
我们如何确保应用程序监控和警报?
我们如何确保应用程序支持?
可靠性:
我们如何确保应用程序始终如一地执行?
我们如何检查和纠正故障?
可用性:
如何保证应用的高可用?
我们如何使应用程序具有容错性?
可扩展性:
如何满足日益增长的资源需求?
我们如何才能在利用率突然飙升的情况下实现良好的规模?
可用性:
我们如何简化应用程序的使用?
我们如何才能实现无缝的用户体验?
但是,根据项目的性质,可能存在仅适用于该项目的 NFR(例如,呼叫中心解决方案的语音清晰度)。您将了解更多有关这些属性的第3章,属性的解决方案架构的。
解决方案架构师从很早的阶段就开始参与项目,这意味着他们需要通过衡量组织中跨组的需求来设计解决方案。解决方案架构师需要确保跨系统组件和需求的解决方案设计的一致性。解决方案架构师负责定义跨组和不同组件的 NFR,因为他们确保全面实现解决方案所需的可用性。
NFR 是解决方案设计的一个不可或缺的重要方面,当团队过于关注业务需求时,它往往会滑倒,这会影响用户体验。一个好的解决方案架构师的主要责任是传达 NFR 的重要性并确保它们作为解决方案交付的一部分得到实施。
3.参与并与利益相关者合作
利益相关者可以是对项目有直接或间接利益的任何人。除了客户和用户之外,还可能是开发团队、销售、营销、基础设施、网络、支持团队或项目资助组。
利益相关者可以是项目内部的或外部的。内部利益相关者包括项目团队、发起人、员工和高级管理层。外部利益相关者包括客户、供应商、供应商、合作伙伴、股东、审计师和政府。
通常,利益相关者根据他们的上下文对同一业务问题有不同的理解;例如,开发人员可能会从编码的角度来看业务需求,而审计人员可能会从合规性和安全性的角度来看它。解决方案架构师需要与所有技术和非技术利益相关者合作。
他们拥有出色的沟通技巧和谈判技巧,有助于找出解决方案的最佳途径,同时让每个人都参与其中。解决方案架构师作为技术和非技术资源之间的联络人,填补了沟通空白。通常,业务人员和技术团队之间的那些沟通差距会成为失败的原因。业务人员试图更多地从特性和功能的角度来看待事物,而开发团队则努力构建一个技术上更兼容的解决方案,有时可能会倾向于项目的非功能方面。
解决方案架构师需要确保两个团队在同一页面上,并且建议的功能在技术上也是兼容的。他们根据需要对技术团队进行指导和指导,并将他们的观点转化为每个人都能理解的简单语言。
处理各种架构约束
架构约束是解决方案设计中最具挑战性的属性之一。解决方案架构师需要仔细管理架构约束,并能够在它们之间进行协商以找到最佳解决方案。通常,这些限制相互依赖,强调一个限制可能会夸大其他限制。
最常见的制约因素如下:听
如上图所示,解决方案设计帮助我们了解应用程序的以下属性:
费用:
有多少资金可用于解决方案实施?
预期投资回报( 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.作为技术传播者工作
布道者是解决方案架构师角色中最令人兴奋的部分,他们作为技术布道者工作。解决方案架构师通过公共论坛传播信息来提高产品和平台的采用率。他们撰写有关解决方案实施的博客并举办研讨会以展示潜在的好处和技术平台的使用。
他们建立对技术的大规模支持并帮助建立标准。解决方案架构师应该对技术充满热情。他们应该是一名优秀的公众演讲者,并拥有出色的写作技巧来扮演技术传播者的角色。