在产品开发生命周期的各个阶段，牢记架构愿景，始终坚持每个决策都符合愿景原则，是避免架构腐化的唯一方式。原文: Architecture Vision — A critical ingredient in building well-maintained software
上一篇文章《软件架构: 一切皆有代价》讨论了成功软件的陷阱，如果不把软件架构作为一流公民和敏捷团队日常工作的关键要素，软件的发展将被置于危险路径。本文将讨论架构愿景如何帮助团队保持架构的健康状态，不断应对业务挑战。
本文将更多的阐明架构愿景，我相信这可能是构建和维护软件系统的好方法。此外，还将提供开发架构愿景的模板，其中指定了愿景的主要组件，并可以根据特定需求进行定制。
敏捷世界中的架构愿景
愿景通常被描述为"想象力的力量"，可以让我们创造未来的心理形象，作为行动指南，并提供目的感。因此，愿景在塑造未来和帮助实现目标方面发挥着至关重要的作用。
"为了采取积极的行动，必须建立积极的愿景。"
架构愿景表示一种理想架构，可以实现满足功能和质量需求的系统。这个一理想图景可以作为目标，为下一版架构提供指导方针和动力。架构愿景试图确保后续版本对软件架构有积极(或至少没有消极)的影响。在每次发布期间，都要努力接近架构愿景所定义的理想状态，因此最新架构的理论可靠性应该比前一个更高。
理想情况下，在开发过程早期创建架构愿景，在整个开发过程中作为团队的参考点，以确保所构建的系统与最初愿景一致。开发过程中，应根据需要对其进行审查和更新，以确保保持相关性和准确性。愿景可以作为与变更相关的指南，帮助维护原始目标，并帮助避免导致架构侵蚀和漂移问题的陷阱。架构愿景有助于保持架构文档的更新，并提高实现下一版本目标的能力。
是否真有可能实现架构愿景目标并不重要，至少有理想的目标可以为之奋斗，作为参考点审查和更新已实现的体系架构，并增加实现下一版本目标的能力。
在软件开发初始阶段，架构愿景有助于获得组织高层管理的承诺，使他们充满信心。此外，有助于在项目开始时以及在开发和管理阶段使架构团队保持一致。此外，在组织层次上，愿景有助于为架构获取更广泛的支持。架构愿景支持软件架构来定义系统范围，指导构建和管理决策。
架构愿景总是基于业务愿景编写，随着业务发展以及环境和技术的变化，需要使架构愿景与需求和业务愿景保持一致，因此需要更新和发展架构愿景。
当然，还有其他不同的方法，比如架构模式、架构表示语言、scrum 开发方法等等。架构愿景并不是一种新模式，相反，它是一种技术或规范，可以在敏捷流程中执行，根据业务目标以及过去和未来的需求，对应用健康状况进行一致、迭代的检查。
"好的软件架构为团队提供清晰、共享的愿景，使团队能够朝着共同的目标一起工作。" —— Jim Highsmith
构建架构愿景
那接下来的重要问题是，如何创建架构愿景，应该遵循哪些步骤，哪些事情需要考虑？
创建架构愿景没有硬性规定或技术，完全取决于业务领域、组织或项目需求。在不同类型的业务领域和组织中，构建架构愿景时需要考虑不同方面，以获得最大好处。
让关键利益相关者参与软件架构愿景开发很重要，因为所选架构会对他们产生影响，并且他们可以提供有价值的输入和见解。这些相关者可能包括业务领导、技术人员和最终用户。当然，如果让包括敏捷团队、管理层和客户在内的所有关键利益相关者都知道架构愿景的重要性，那将非常有价值。
以下是一些常见的指导原则:
业务和技术目标: 创建架构愿景应该考虑长期目标。业务和相关架构目标以及满足这些目标的对象也应该记录下来。架构愿景的开发是非常关键的步骤，必须集中精力编写目标应用的理想(但现实的)图景。
用户需要和需求: 架构应该满足将要与之交互的用户的需要和需求。软件架构愿景还应考虑功能和质量需求，例如性能、可伸缩性、安全性和可维护性。
现有系统和架构: 这是现在所有的，坚持从小处开始，避免从一开始就过度架构。架构愿景应该考虑系统的当前状态，以及新架构如何与这些元素集成或替换。
行业趋势和最佳实践: 在开发体系架构时，很重要的一点是要考虑行业趋势和最佳实践，从而为设计提供有用信息，并帮助确保体系架构的有效和高效。
架构约束: 架构约束需要在系统架构的开发、维护和管理期间得到满足。约束通常是在不同层次上定义，比如企业级、特定于项目的约束(如资源、时间、成本)等。架构愿景需要确保软件架构在任何版本中都不会违反这些约束中的任何一个。
架构原则和框架: 在软件架构和开发生命周期中需要遵循符合架构原则的目标框架。框架从架构愿景中获得灵感，帮助架构以一致方式遵循框架和原则。根据经验，如果团队能够遵循公司或领域的架构原则，囊括其他相关重要原则，在架构愿景中以更具体的形式将这些原则定义出来，将会有莫大的帮助。
应用程序标准: 在整个开发生命周期中需要遵循的应用程序标准可以定义在架构愿景中，并在不同版本中遵循。这些应用标准包括编码标准、命名约定、代码文档标准、体系架构标准等。
体系架构风格: 架构愿景可以包含架构师想要为应用程序采用的架构风格。无论架构师使用什么风格，重要的是在不同版本中都获得遵循。对架构风格的违背将导致架构被侵蚀。
所用技术: 架构师用于应用开发的目标技术可以记录在架构愿景中。许多情况下，软件架构是通过考虑目标技术来构建的，架构中包含了许多特定于技术的东西。因此，通过记录架构愿景中使用的技术，可以在设计以后的版本时通盘考虑。
预算和资源: 预算和可用资源将影响架构的范围和复杂性。在开发架构愿景时，考虑这些约束很重要，当前和未来可用资源的信息对架构师在设计不同版本的架构时非常有帮助。
架构设计决策: 有助于在软件系统的整个生命周期中组织和管理体系架构设计决策。
活动
沟通愿景
在实现软件架构愿景的过程中，沟通架构愿景是重要的一步。包括向利益相关者展示愿景，并获得认可和支持。清晰有效的沟通愿景的好处及其将如何支持组织目标是很重要的方面。
建议花些时间确定所有将受到软件架构愿景影响的关键利益相关者，包括业务领导、IT 人员和最终用户，他们有不同的需求和关注点，应该在沟通过程中加以解决。
架构愿景研讨会
研讨会的主要目的是根据业务愿景绘制应用程序的理想架构。团队对业务的未来发展方向以及如何构建遵循业务目标的技术功能(应用程序)达成共同理解。团队聚集在一起讨论应用程序的当前形态以及将来期望达成的目标。
日程
会议议程如下:
- 跟进之前的行动。
- 当前实现的架构是什么样的。
- 理想架构是什么样的？基于短期和长期业务需求，希望将架构发展到什么程度？
- 是否需要根据最新业务目标对当前的理想架构进行任何更改？
- 未来可以采取哪些新的步骤来接近理想架构？
- 新的行动
- 开放式讨论
输出
以下是研讨会的主要成果:
- 共同理解并记录应用或平台的理想体系架构。
- 应用体系架构的当前状态。
- 为接近理想架构而采取的步骤或行动。
- 共享和修改对业务目标的理解。
频率
- 建议召开会议的频率为每月一次或至少每季度一次。
责任
研讨会由整个团队负责，并保证活动有效。
产品负责人需要从会议中确定行动优先级，团队应该在每个迭代冲刺中留出一些时间来处理这些行动。
重要的是，业务方需要支持/赞助这些会议，没有业务方的支持，不会有多大效果。
跟进架构愿景活动
愿景研讨会输出的任务列表，通常包含两种类型的任务:
- 隐式的(基于内在的)
- 显式的或基于活动的
隐式(内在): 这些是不需要显式创建的任务，更多的是关于正在进行的任务或团队成员需要开始使用的工作方式，没有必要在迭代冲刺中创建特定故事/任务。此类任务包括遵循特定编码风格/标准、遵循新出现的业务需求(故事)的架构原则或模式，等等。团队需要找到一种方法来衡量这些任务的进度，以及这些任务的"完成定义(definition of done)"是什么。
显式: 这些任务更像是需要由团队成员计划、评估和执行的活动，包括重构代码库以获得更好的设计/架构、配置新的支持工具/库、使用新的框架、新的更好的部署策略，等等。
团队需要从愿景会议中获取基于活动的任务列表，放入产品待办事项列表中。至关重要的是，团队和利益相关者需要密切关注任务列表，并在每个迭代冲刺中与其他故事一起确定优先级。
结语
不可否认，愿景是生活的重要方面。然而，讽刺的是，当我们面对生活中的各种挑战时，往往忽视或忘记了愿景。就像日常生活一样，如果团队有共同的愿景，会有很大的价值。我的观点是，大多数个人和团队都有指导他们的愿景，但通常是隐含的，没有明确定义或表达，这是当我们面对交付压力，做出不同选择，从而偏离了真正的精神或价值观的主要原因。
有一种强大的力量和吸引力，使我们明确、讨论、反对、捍卫和共同建设愿景。
敏捷团队赢得了巨大的胜利，不仅是因为他们致力于架构愿景，还因为他们将愿景作为团队日常工作的关键组成部分。最重要的是，没人可以给你愿景，当然，他们可以给你一些想法，但团队需要建立和拥有自己的愿景，并根据需求、环境和挑战进一步构建，使其成为推动每个决策的关键组成部分。
没人给你愿景，是团队创造并拥有愿景，这是唯一的生存方式。
你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。微信公众号：DeepNoMind
