你是一家小型初创公司的一部分。您脑子里只有一件事：运送产品并快速找到适合市场的产品。代码为王！软件架构？但是，事实证明，每个系统都有一个架构。无论它是不是好产品，特别是在产品起飞，从初创阶段转向规模扩大阶段时，你才会发现它。
Picnic团队首先在荷兰的一个城市提供杂货，然后在全国范围内提供杂货，后来扩展到德国，最近扩展到法国。我们得到了产品并找到了我们的市场。
Picnic 的系统和团队也在以相应的速度发展。大约 20 个产品团队构建和维护从最初的核心系统发展而来的服务。在过去的一年里，我们的技术团队规模增加了一倍多。尽管如此，跨这些服务的软件架构仍然是一个临时且相当隐含的问题。
从团队的角度来看，架构选择似乎是最佳的，但从整个系统来看，它们往往不是。在这篇文章中，我们将探讨如何通过赋予软件架构更突出的作用来改进这一点。这篇文章不会涉及特定的架构风格或技术：这实际上取决于您正在构建的产品。我们可以分享的是我们为提高系统架构质量而设计的流程。
虽然产品团队自主构建和交付（微）服务很棒，但在扩展时会出现一些问题。特别是围绕更大的计划，开发跨越多个产品。不止一次，关键的技术依赖是在流程后期发现的。这会导致重复工作或返工。再举一个例子，多个团队转向了更多基于事件的架构，但以不同的方式和不同的时间线。更一般地说，关于如何有效应用那些仍然局限在孤立团队中的新技术的见解。
架构工作组
在这一点上，我们认为从长远来看，完全分散的架构决策（或缺乏架构决策）会损害我们的使命。同时，钟摆也不应该完全向另一个方向摆动。在扩展环境中，完全集中所有架构决策既不可行也不可取。守门行为会减慢团队的速度并破坏自治。
因此，架构工作组 (AWG) 应运而生：由来自各个产品团队的经验丰富的工程师组成的小组，他们提供部分时间为整个技术团队解决架构问题和挑战。AWG 的目标是授权各个产品团队做出正确的决策。为此，团队需要对架构上重要的开发有一个粗略的概述，以及一个从团队收集输入并向团队提供反馈的过程。
我们决定采用轻量级流程，邀请产品团队为重大开发编写架构提案。重大意味着它要么是一个大项目，要么涉及许多团队和系统，因此会带来独特的风险和挑战。
架构提案作为 AWG 审核流程的输入。这样，架构工作组就有机会权衡即将发生的架构重大变化。通过引入此过程，可实现以下结果：
- 协调：可以预先发现产品团队之间的潜在冲突或机会，避免重复工作。
- 质量：通过对架构提案提供整体反馈，我们提高了整体架构的一致性和质量。
- 文档：重要的架构决策通过架构提案进行记录，每个人都可以使用。
AWG 与团队一起确定即将到来的重大发展，并确定哪些可以从提案和审查中受益。在一个团队在 Confluence 中完成他们的提案后（稍后将详细介绍格式），架构工作组的两名成员开始审查。直接针对提案本身提供反馈，并计划与提案作者进行一次反馈会议。通常所有跟进点都由产品团队解决，但如果反馈导致提案发生较大变化，则可能会安排另一轮审查。
同样，此过程的目标不是阻止计划，而是帮助产品团队提出和回答正确的架构问题。我们希望营造一种鼓励预先设计和讨论重要决策的文化。
架构提案模板
以这种深思熟虑的方式思考架构变化并不是每个人都自然而然的。AWG 开发的工具之一是供团队使用的模板。这是一个简单的 Confluence 模板，要求作者至少解决以下几个方面：
- 目标/要求：描述提议变更的业务成果。如果这部分不能写清楚，就无法判断提议的架构更改的有效性。有时，提案会被搁置，直到对实际目标和要求足够明确为止。
- 当前解决方案：简要描述当前域模型的相关部分，并提供现有服务及其交互的上下文图。
- 提议的解决方案：描述变更及其架构影响，重点关注新服务、API 设计、数据建模、与现有系统的集成以及可能采用的新技术。我们提供有关何时使用组件图或序列图的指南。
- 操作问题：概述负载和性能目标，以及更改的任何安全注意事项。此外，如果提案中有 API 更改或其他需要管理的依赖项，则团队应提供推出计划。
- 风险：架构总是要权衡取舍。在架构设计阶段识别出的任何风险，以及影响评估和缓解策略都应记录在案。
每个部分都包含有关哪种图表类型最适合的指针，以及预期的抽象级别。所有提案（包括反馈）都对整个技术团队开放。这样，每个人都可以学习并与其他团队保持同步。
微调流程
自从我们在 2020 年底启动 AWG 并引入提案流程以来，我们在此过程中吸取了一些教训。
最初，我们将流程与我们的季度计划周期保持一致。所有技术负责人都将被邀请参加联合会议，以揭示需要架构提案的主题。然后，提案将在季度开始之前按照严格的时间表完成，从而做出明确的通过/不通过的决定。不经意间，我们将 AWG 变成了某种变革咨询委员会，给围绕季度路线图规划的已经拥挤的时期增加了压力和不确定性。所以我们改变了这一点。现在，我们不举行大型季度会议。相反，我们在滚动的基础上组织 AWG 与产品团队的个人签到，以确定他们的需求并反映团队架构的当前状态。我们希望就他们的关键变化向团队提供建议，而不是在困难时刻阻碍或加重他们的负担。
编写架构提案并不容易。拥有好的例子，并与其他团队分享这些确实有助于人们开始。我们根据最初提案的反馈改进了模板。很明显，编写提案通常会发现与计划的目标和要求有关的重要问题。无论提案的其余部分有多好，如果基本面不正确，也没关系。为了解决这个问题，我们现在要求团队首先迭代目标和需求部分，直到所有利益相关者都同意。只有这样，团队才能编写剩余的部分，充分详细地设计架构。
我们接下来要做什么……
引入具有轻量级提案流程的架构工作组对于 Picnic 来说在扩大规模的同时非常有效。我们没有定义每个团队都应该遵循的大型集中式架构。相反，我们希望将架构思维融入所有开发人员的思想中。AWG 不会限制人们的创造力，而是帮助评估架构选择在更广泛的野餐环境中是否有效。它还在技术层面将团队聚集在一起，致力于跨越多个产品的雄心勃勃的计划。
我们当然还没有达到我们的最终状态。随着越来越多的产品团队加入 AWG，我们扩大了团队以跟上。最近也发生了从季度“拉动模式”到更多自助服务模式的转变（从产品团队的角度来看）。在让 AWG 参与的时间上找到适当的平衡是一个持续的过程。到目前为止，我们已经从许多架构建议中受益，这些建议预先产生了有价值的见解，提高了我们系统的质量。