购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

2.2 准备迎接新架构思维

不仅仅是领导层,所有参与构建、设计和制定架构决策的人员都需要掌握现代架构的思维方式。虽然传统方法与现代方法间存在显著差异,但许多人因长期使用传统方法而对现代方法缺乏了解,或不愿放弃熟悉的传统方法。

2.2.1 准备采纳康威定律

每个参与架构工作的人都应该理解康威定律。这个定律表明:“设计系统的组织往往会创造出反映其内部沟通结构的系统设计。”也就是说,一个系统的设计很大程度上会受到设计和构建它的人们的沟通模式和组织结构的影响。

对康威定律效应的幼稚理解或忽视可能导致多种问题,如软件紧密耦合、过度复杂以及团队间依赖性过高等是一些最常见的问题。要最小化这些问题的可能性及康威定律的其他负面影响,非常重要的就是采用社会技术思维来考虑架构,即软件架构和组织设计需要一起优化,而不是由不同团队分别设计。

在开始架构现代化转型前,确保组织内对康威定律有广泛的理解至关重要。通过寻找组织内部的实际例子来使其具体化。康威定律的应用无所不在,你会发现很多例子。观察不同团队的组织和协作方式,然后对照其架构设计进行分析。例如,我合作过的一家公司,其团队目标高度独立,促成了垂直的思维模式,导致团队间更改互相影响、数据孤岛问题,以及内部和外部UX的碎片化。

2.2.2 准备采纳协作式架构实践

康威定律突出了采用社会技术方法的重要性,指出与松耦合软件架构对齐的团队能更加快速和高效地工作。尽管康威定律没有详细说明团队与架构如何保持同步,如图2.1所示,但松耦合的架构要求有清晰定义的领域边界。这样,当团队开发新功能时,他们仅需专注于与自己代码库对应的特定业务子领域的变动,而不需要与其他团队进行协调。

图2.1 领域之间的松耦合

除了采纳康威定律外,领域建模也是架构现代化不可或缺的核心理念。更进一步,采用协作式的领域建模和架构方法也很重要,因为这种方法能够带来更优秀的设计思路。正如第1章中所讨论的那样,采用诸如事件风暴这样的注重协作的现代方法,可以集合来自不同背景的专业人士,利用他们的专业知识共同找到最佳方案。但我注意到,由于这种方法与传统方式大相径庭,因此在实践中往往面临较大的阻碍。

以下是我在2023年与一位技术领导者对话的例子,展示了思维差异在实践中的表现:

“尽管我们公司使用遗留系统取得了巨大成功,但我们还是面临着几十年来系统堆积的问题。领导层开始认识到,现有架构阻碍了我们快速适应变化的能力,一些想要实施的项目(如对外开放内部数据和功能)根本无法实现。然而,在参加了一个研讨会并了解到事件风暴等技术后,我意识到我们的架构方法完全错误。我们的架构师已在此工作了16年,却单独行动,为整个系统设计了集中式的单体数据库架构。”

在本书后续部分,你将会看到各种技术及采纳这些技术的建议。但现在是个好时机,反思一下这种架构方法与你当前所用方法的区别。在架构现代化之旅的准备阶段,尽早尝试事件风暴等协作研讨会是个不错的主意,这对评估其适用性非常有益。

2.2.3 准备将架构与战略连接起来

“我的CEO说我需要更具战略眼光!”一位工程副总裁的这句话突显了释放现代架构和方法潜力所需的另一种思维转变。架构师和工程师仅仅关注技术选择和时尚的架构模式是不够的;他们需要能够将架构现代化决策与业务结果联系起来,并证明每个决策是如何优化所需的业务结果的。

实现这个目标的其中一个有效方式是让所有人参与到战略规划中,使战略流程更具协作性和包容性。第5章介绍的沃德利地图是连接架构与战略的一种有效工具。现在你需要问自己:“业务和技术团队一起讨论战略的可能性有多大?”如果你的组织传统上采用自顶向下的战略规划方式,那么考虑尽快采用更具协作性的方法,如举办一个涉及多个角色的沃德利地图研讨会。

2.2.4 准备打破业务和IT的壁垒

将业务和IT视为独立的单元而非一个整体的传统做法限制了创新,并妨碍了共同目标的实现。这种团队间的隔阂导致流程缓慢,IT人员对他们所需构建的内容缺乏深入理解,从而延长了功能实现的时间。

成功的架构现代化需要把业务和IT视作同一枚硬币的两面。然而,在一些组织中,采纳这样的思维模式可能会遇到阻力。有时IT仅被看作将需求转化为代码的程序员团队。向以产品为核心的现代思维方式转变是一个重大的改变,这种改变可能不会在一夜之间就能实现。在这种思维方式中,各团队被赋予了做出产品决策和控制他们发展路线图的权力。

现在是评估你所处的位置和想要达到的目标的绝佳时机,并且可以开始考虑如何向更加整合的运营模式迈进。我曾采用John Cutler的“产品团队之旅”信息图作为工具(如图2.2所示),与多个组织共同进行一个活动。在此活动中,我会邀请所有人(包括领导层和个人贡献者)标记他们认为自己当前所处的位置,以及他们期望达到的目标位置。然后,我们将讨论阻碍他们前进的因素,以及如何克服困难达到目标的解决方案。

图2.2 产品开发方法:从瀑布式到授权产品团队(来源:John Cutler, Amplitude, https://amplitude.com/blog/journey-to-product-teams-infographic)

图2.2所示的信息图是讨论这些主题的理想辅助工具。它提供了一个框架,助力人们思考不同的工作方式,并在更宽广的背景中评估自己当前的做法,非常值得推荐。 LrBwl0dI1/VTjEsosCuzYHlC0UMZ38uuK1cEocBbYz/EXZo+kcNwWQAOtd4ktxgM

点击中间区域
呼出菜单
上一章
目录
下一章
×