如何用社会技术设计改善架构决策

软件开发中的社会技术设计理念的核心是创建一个系统，在这个系统中，人和技术都能蓬勃发展，通过一些赋能约束来促进合作、激发一致性和共享理解，这不仅改善了架构，还使工作更有效、适应性更强，让人更满意。在OOP会议上，Xin Yao 就社会技术设计和变革促进发表了演讲。

今天的软件专业人员需要穿梭在技术、商业和社会复杂性的迷宫中。根据 Xin Yao 的说法，在这个环境中蓬勃发展需要的不仅仅是技术和商业专长，社会技术设计可以帮助我们应对这些挑战。

社会技术设计指的是主动构建一个系统，在这个系统中，人和技术都能蓬勃发展。社会系统带来的不仅仅是创造更好软件的手段，其本身的目标更为重要，正如 Yao 所解释的：

它认识到软件不仅仅是由代码和业务需求塑造的，更是由团队的工作方式、彼此交流和决策的方式塑造的。良好的架构会随着人类合作逐步演变。

在其核心，社会技术设计平衡了结构和自主性，为协调提供了足够的稳定性，同时留有适应和变化的空间。这就像爵士乐一样，Yao 说：有一个框架，一个调性，一个时间戳，还有一些指导性约束，但在这些条件之内，音乐家可以即兴发挥、响应和共同创作。制约太多，系统就会变得僵化；约束太少，就会陷入混乱。

像传统的软件架构一样，一致性是社会技术架构中理想的特质。部分要一个个融入整体，Yao 说。传统方法是自上而下、提前强加一致性，但、而社会技术架构通过赋能约束来自下而上地涌现一致性，这些约束为一致性设定了条件倾向，然后才会形成系统范围内的构成和治理性约束（Alicia Juarrero 的约束框架）。

Yao 提到，赋能约束，如探索性设计、反思性对话、参与式建模和语言化，共同塑造了信息的旅程，也就是知识流经系统以及关系复杂化的过程。这些互动让决策规模大大缩减，使团队能够共同应对不确定性，找出有意义的区别，并完善他们的心智模型：

相比预设的结构，这种方法培养了局部一致性，架构洞察在具体情境中涌现出来，然后固化下来。

Yao 提供了一个社会技术原则改善软件架构的具体例子：

我们来看一个现实世界的场景：一家公司在微服务的混乱中挣扎。他们有完全解耦的服务，每个团队都拥有自己的清晰界定的上下文，但业务却举步维艰。为什么？因为团队不小心过度解耦，失去了对大局的把握。

关键的工作流跨越多个服务，需要不断交接，破坏用户体验，甚至使小的变更也成为官僚主义的噩梦，Yao 说。他们没有进行另一次“回归模块化单体架构”的行动，而是应用了社会技术原则——从赋能约束开始。

Yao 提到，他们引入了反思性对话、参与式建模和上下文映射工作坊，开发者、产品人员甚至客户支持坐在一起。人们提出深入的问题，互相提出难题以定位疑虑和担忧的问题，并讨论以前大家认为不可讨论的问题：

目标是重新发现基本的联系和机会，找出我的位置，找出我们在整体故事中的位置。

结果发现，一些团队之所以拆分服务，并不是因为业务需求，而是因为团队领导没经过验证就假设大家彼此不愿协调优先级，Yao 说。

随着大家都理解了这些新的发现，团队围绕实际业务流程开始自我重组。一些服务合并，其他服务重新定义了它们的接口，她说。构成约束涌现出来，成为稳定的跨团队沟通模式，随着时间的推移，治理约束维持了自主性和对齐之间的平衡。

结果是更快的交付、更少的依赖和更快乐的团队。不仅是软件架构变得更好，工作也更好做了。这一切都始于大家一起提出更好的问题，Yao 总结道。

InfoQ 采访了Xin Yao，讨论了如何进行社会技术设计。

InfoQ：社会技术设计与传统软件设计有何不同？

Xin Yao：与通常将系统视为异源性——由外部工程师作为生产因素而构建的传统软件设计不同，社会技术设计采用了自源性视角（Humberto Maturana：自源性和认知）。

 

我们是我们所设计的更大系统的一部分。软件创造者的福祉不仅仅是创作更好软件的手段；它本身就是一个目标。

InfoQ：技术债务通常被框定为纯粹的代码问题，但你的演讲表明它也是一个社会技术问题。你能解释技术债务是如何受到社会动态影响的，以及团队如何更有效地解决它吗？

Yao：技术债务通常源于由于观点差异、未经验证的假设和缺乏深入设计探讨的合作而匆忙做出的决策。

 

解决这个问题需要提高沟通、决策效率和改善跨团队关系——不仅仅是重构代码。

原文链接：

How Sociotechnical Design Can Improve Architectural Decisions