德国Picnic创业公司如何在规模扩展阶段时才发现架构的重要性? - Sander

21-08-22 banq

你是一家小型初创公司的一部分。您脑子里只有一件事:运送产品并快速找到适合市场的产品。代码为王!软件架构?但是,事实证明,每个系统都有一个架构。无论它是不是好产品,特别是在产品起飞,从初创阶段转向规模扩大阶段时,你才会发现它。

Picnic团队首先在荷兰的一个城市提供杂货,然后在全国范围内提供杂货,后来扩展到德国,最近扩展到法国。我们得到了产品并找到了我们的市场。

Picnic 的系统和团队也在以相应的速度发展。大约 20 个产品团队构建和维护从最初的核心系统发展而来的服务。在过去的一年里,我们的技术团队规模增加了一倍多。尽管如此,跨这些服务的软件架构仍然是一个临时且相当隐含的问题。

从团队的角度来看,架构选择似乎是最佳的,但从整个系统来看,它们往往不是。在这篇文章中,我们将探讨如何通过赋予软件架构更突出的作用来改进这一点。这篇文章不会涉及特定的架构风格或技术:这实际上取决于您正在构建的产品。我们可以分享的是我们为提高系统架构质量而设计的流程。

虽然产品团队自主构建和交付(微)服务很棒,但在扩展时会出现一些问题。特别是围绕更大的计划,开发跨越多个产品。不止一次,关键的技术依赖是在流程后期发现的。这会导致重复工作或返工。再举一个例子,多个团队转向了更多基于事件的架构,但以不同的方式和不同的时间线。更一般地说,关于如何有效应用那些仍然局限在孤立团队中的新技术的见解。

 

架构工作组

在这一点上,我们认为从长远来看,完全分散的架构决策(或缺乏架构决策)会损害我们的使命。同时,钟摆也不应该完全向另一个方向摆动。在扩展环境中,完全集中所有架构决策既不可行也不可取。守门行为会减慢团队的速度并破坏自治。

因此,架构工作组 (AWG) 应运而生:由来自各个产品团队的经验丰富的工程师组成的小组,他们提供部分时间为整个技术团队解决架构问题和挑战。AWG 的目标是授权各个产品团队做出正确的决策。为此,团队需要对架构上重要的开发有一个粗略的概述,以及一个从团队收集输入并向团队提供反馈的过程。

我们决定采用轻量级流程,邀请产品团队为重大开发编写架构提案。重大意味着它要么是一个大项目,要么涉及许多团队和系统,因此会带来独特的风险和挑战。

架构提案作为 AWG 审核流程的输入。这样,架构工作组就有机会权衡即将发生的架构重大变化。通过引入此过程,可实现以下结果:

  • 协调:可以预先发现产品团队之间的潜在冲突或机会,避免重复工作。
  • 质量:通过对架构提案提供整体反馈,我们提高了整体架构的一致性和质量。
  • 文档:重要的架构决策通过架构提案进行记录,每个人都可以使用。

AWG 与团队一起确定即将到来的重大发展,并确定哪些可以从提案和审查中受益。在一个团队在 Confluence 中完成他们的提案后(稍后将详细介绍格式),架构工作组的两名成员开始审查。直接针对提案本身提供反馈,并计划与提案作者进行一次反馈会议。通常所有跟进点都由产品团队解决,但如果反馈导致提案发生较大变化,则可能会安排另一轮审查。

同样,此过程的目标不是阻止计划,而是帮助产品团队提出和回答正确的架构问题。我们希望营造一种鼓励预先设计和讨论重要决策的文化。

 

架构提案模板

以这种深思熟虑的方式思考架构变化并不是每个人都自然而然的。AWG 开发的工具之一是供团队使用的模板。这是一个简单的 Confluence 模板,要求作者至少解决以下几个方面:

  • 目标/要求:描述提议变更的业务成果。如果这部分不能写清楚,就无法判断提议的架构更改的有效性。有时,提案会被搁置,直到对实际目标和要求足够明确为止。
  • 当前解决方案:简要描述当前域模型的相关部分,并提供现有服务及其交互的上下文图。
  • 提议的解决方案:描述变更及其架构影响,重点关注新服务、API 设计、数据建模、与现有系统的集成以及可能采用的新技术。我们提供有关何时使用组件图或序列图的指南。
  • 操作问题:概述负载和性能目标,以及更改的任何安全注意事项。此外,如果提案中有 API 更改或其他需要管理的依赖项,则团队应提供推出计划。
  • 风险:架构总是要权衡取舍。在架构设计阶段识别出的任何风险,以及影响评估和缓解策略都应记录在案。

每个部分都包含有关哪种图表类型最适合的指针,以及预期的抽象级别。所有提案(包括反馈)都对整个技术团队开放。这样,每个人都可以学习并与其他团队保持同步。

 

微调流程

自从我们在 2020 年底启动 AWG 并引入提案流程以来,我们在此过程中吸取了一些教训。

最初,我们将流程与我们的季度计划周期保持一致。所有技术负责人都将被邀请参加联合会议,以揭示需要架构提案的主题。然后,提案将在季度开始之前按照严格的时间表完成,从而做出明确的通过/不通过的决定。不经意间,我们将 AWG 变成了某种变革咨询委员会,给围绕季度路线图规划的已经拥挤的时期增加了压力和不确定性。所以我们改变了这一点。现在,我们不举行大型季度会议。相反,我们在滚动的基础上组织 AWG 与产品团队的个人签到,以确定他们的需求并反映团队架构的当前状态。我们希望就他们的关键变化向团队提供建议,而不是在困难时刻阻碍或加重他们的负担。

编写架构提案并不容易。拥有好的例子,并与其他团队分享这些确实有助于人们开始。我们根据最初提案的反馈改进了模板。很明显,编写提案通常会发现与计划的目标和要求有关的重要问题。无论提案的其余部分有多好,如果基本面不正确,也没关系。为了解决这个问题,我们现在要求团队首先迭代目标和需求部分,直到所有利益相关者都同意。只有这样,团队才能编写剩余的部分,充分详细地设计架构。

 

我们接下来要做什么……

引入具有轻量级提案流程的架构工作组对于 Picnic 来说在扩大规模的同时非常有效。我们没有定义每个团队都应该遵循的大型集中式架构。相反,我们希望将架构思维融入所有开发人员的思想中。AWG 不会限制人们的创造力,而是帮助评估架构选择在更广泛的野餐环境中是否有效。它还在技术层面将团队聚集在一起,致力于跨越多个产品的雄心勃勃的计划。

我们当然还没有达到我们的最终状态。随着越来越多的产品团队加入 AWG,我们扩大了团队以跟上。最近也发生了从季度“拉动模式”到更多自助服务模式的转变(从产品团队的角度来看)。在让 AWG 参与的时间上找到适当的平衡是一个持续的过程。到目前为止,我们已经从许多架构建议中受益,这些建议预先产生了有价值的见解,提高了我们系统的质量。

猜你喜欢