敏捷DevOps是反康威定律? - rna

21-10-04 banq

是业务决定技术?还是技术决定业务?是人决定IT,还是IT决定人?这是康威定律与敏捷的区别:

一位叫Melvin Conway学者进行了社会学观察:组织中IT 解决方案的结构遵循组织结构。弗雷德里克·布鲁克斯Frederick Brooks)在他的开创性著作《人月神话》中将其命名为康威定律,而这个名字就一直存在。我认为康威定律——以及它正在发生的事情——表明我们的“信息革命”正在经历一个转折点。

康威定律是指IT方案遵从组织中结构,也就是技术服从于人,也就是说“业务需求导致业务结构导致 IT结构”,由于人的适应性很强,我们越来越多地看到相反来的情况:“业务需求导致IT结构导致业务结构”。

这就是流行语“数字化企业”或“数字化转型”所代表的意思:是我们(灵活的)人类适应世界上的大量(不灵活的)脆弱机器逻辑,IT不是适应我们人类愿望,而是我们人类适应使用IT 需求。

我们越来越多地将自己组织成敏捷/DevOps 团队,围绕 IT 解决方案与“产品负责人”。我们将各种产品团队组合成称为“价值流”的组织实体(例如,在称为 SAFe 的领先敏捷方法中)。换句话说,这不是康威定律提倡的让 IT 解决方案反映组,而是迫使人的组织结构服从与反映 IT 结构。

  

逻辑的脆弱

逻辑尽管有其所有优点,但有一个主要的致命弱点:它是脆弱的。逻辑对正确的输入极其敏感。我们人类可以很好地使用估计和近似值的地方,但是逻辑机器不能。一个小错误导致整个事情可能无法正常工作,甚至可能崩溃。

所有这些脆弱部分之间的依赖关系的复杂性超出了我们人类的处理能力。最重要的是,虽然我们是地球上所有物种中最好的逻辑学家,但我们人类的逻辑实际上很糟糕。我们创造了这种逻辑,但我们无法预见每一种组合,我们会犯错误。其中很多。

那么,鉴于(机器)逻辑的脆弱性已经存在了一段时间,我们通常会做什么来管理使用逻辑的问题?

我们添加更多逻辑!

例如:

  • 我们添加了各种抽象:面向对象、面向服务的架构、框架、虚拟机而不仅仅是物理机;
  • 我们添加了更多相同的内容:例如,我们在“负载平衡器”后面创建了相同硬件的高可用性集群,以应对单个服务器的故障;
  • 我们添加了额外的逻辑行为:输入/状态检查代码、备份、监控、事件管理、更改期间的测试、分析,列表不断。

换句话说:为了解决拥有大量互连的脆弱逻辑的麻烦影响,我们添加了更多(互连的、脆弱的)逻辑。当然,它本身具有额外的脆性。这里有死胡同的味道。

在“数字企业”中,所有机器逻辑中只有一小部分最终与“支付养老金”或“卖书”等主要功能有关。其中大部分是关于 (a) 防止整个逻辑大厦以某种方式分崩离析或倒塌,以及 (b) 保持能够改变它

 

掌控之中?

世界上脆弱的机器逻辑的数量激增。相互依存的逻辑行为的整个世界对于我们人类来说太复杂了,无法完全控制它。多年来,我们已经看到越来越大的自上而下的瀑布式方法来“改变”数字环境,但这种方法现在正在消亡。

相反,我们看到的是解决问题的自下而上的方法,例如敏捷/DevOps。这并不是全新的。软件工程方法,例如面向对象(它应该在 1980 年代在应用程序级别为我们解决相同的问题)或面向服务的架构(它应该在应用程序级别为我们解决相同的问题1990 年代)长期以来一直表现出自下而上抽象的趋势,作为处理相互关联的脆弱复杂性的一种方式。

而现在,这些软件工程诞生的、自下而上的方法已经到达触及了人类组织的水平。IT——机器逻辑——的数量变得如此之大,所有这些相互关联的脆弱性的惯性(“改变的阻力”)变得如此之大,以至于我们人类已经开始适应逻辑而不是试图让逻辑适应我们。毕竟,我们是具有灵活和稳健行为的人。

举个例子:我们越来越多地将自己组织成敏捷/DevOps 团队,围绕 IT 解决方案与“产品负责人”。然后,我们将各种产品团队组合成称为“价值流”的组织实体(例如,在称为 SAFe 的领先敏捷方法中)。换句话说,不是让 IT 解决方案反映组织(康威定律),而是让人的组织反映与服从于 IT 结构。

因此,过去是“业务目的导致业务结构导致 IT 结构”,但我们越来越多地看到“业务目的导致 IT 结构导致业务结构”,这就是“逆康威定律”。

 

接下来是什么?

我们显然还没有适应的是:新的“逻辑行为的首要地位”对我们的社会结构的影响。就像工业革命最终催生了遏制其过度行为的政治运动一样,信息革命仍然需要发生类似的事情。

三个问题在我的脑海中。

  • (1):在我们采取行动之前,过度(已经可见)会变得多糟糕?
  • (2):鉴于我们人类的局限性,我们是否能够(明智地)采取行动?以及
  • (3):在过度行为导致或导致无法弥补的损害之前,是否有足够的时间来遏制过度行为?

 

1
猜你喜欢