企业架构随笔

上一篇文章碰巧谈到了“软件吞噬一切”和“AI吞噬一切”，一大早，在2025年的最后一个黎明中，偶然读到了两篇文章，《Palantir高管：为什么软件吞噬了世界，却没有把蛋糕做大？》和《Palantir CTO：技术本身就是问题，货物崇拜式管理是病根》，第一篇是Ted Mabrey（Palantir副总裁、商业事业部负责人）发表于2024年1月7日，第二篇是Shyam Shankar（Palantir CTO），发表于2024年2月2日。现在Palantir还在火着，所以，一些旧文也就经常会被人翻出来学习。

这两篇文章让我感兴趣的点则是对软件带来的实际效率的思考，由于发表的时间先后差不多，自然用的数据就比较接近，都是在谈软件用量的大规模增长和生产效率的实际提升之间的“背离”。我之前在自己的工作坊课程中也常讲类似的事情，这里有我的两页课件可以参考着看看。

这是第一张图，这张图想说明的是，数字化本就是在推动软件的使用，当然，更深层次的则是“数据”这个新的生产要素（最近我觉得并非是简单称之为“新生产要素”，而是“新”在可被“大规模智能化使用”了，毕竟，数据作为要素已经存在很久了）能够在软件的加持下发挥出更为强大的作用了。但是这个过程中，很多企业不得不面对的就是，软件越用越多的自然倾向和越用越多的软件带来的管理难度的自然增大和实际效能的“不可描述”之间的冲突，这也是我谈“数智深化”的原因，需要多到“一线”、多面向“一线”看真实的软件和真实的工作，否则会经常出现“要”的软件和“用”的软件之间的差别。

另一张图跟这两篇文章引用的数据之间有些有趣的联系：

我们总谈使用软件的一大目标——降本增效（2025年这个词经常被戏虐性地改为“降本增笑”），但实际看，规上企业每百元营业收入中的成本似乎“很稳定”，虽然这个数据用的有些“武断”，这个事情我记得在之前的文章中曾经聊过一些，这里不再多讲了。总之，与那两篇文章分析的，软件使用的大规模增长似乎没有带来正相关的经济增长有些相近之处，在这个增长的艰难时期中，这更让如何思考软件的价值、方法的价值多难上几分。

软件行业一直有一个价值衡量方面难以弥补的缺陷，成本容易核算，收益难以核算，此外，还有另一个困难，也就是那两篇文章提到的，互联网行业更像一个“纯净的数据花园”，而很多行业，其价值创造工作有不少是在软件之外的（我的工作坊中在价值链讨论环节经常会遇到这个情况），甚至是“是克服软件障碍才得以实现”，这里既有转型进程的问题，也有实际成本考量后的选择。不少人谈“数字孪生”，无非也就是想把价值创造过程都“塞”进软件中，闭环起来。AI普及就更是如此，毕竟，连基本的软件闭环都进不去的，自然也很难进到AI闭环中，跨越式发展也许只会在一个条件下成立，就是使用AI的成本会比使用普通软件的成本更低、收益更大，这里的成本也包括学习成本。

当然，Palantir两位管理者的文章不只是在聊AI，众所周知，AI是推火Palantir的助力，而Palantir优秀的地方还是其自己的软件理念。“它们并没有从一个更难的问题出发：企业究竟需要什么样的技术，才能真正实现其使命？对“软件边际成本为零”的单一执念，已在企业软件与其客户之间制造了一种寄生关系。对软件公司而言的零边际成本，对终端客户而言却变成了零边际效用。”这种说法虽然“一杆子打翻一船人”，但也确实是很多企业的困惑，是B端软件都在思考的。

““货物崇拜式编程”（cargo cult programming）在工程师群体中广为人知，指的是那些脱离因果逻辑、流于形式的代码实践。这通常表明工程师并未真正理解底层问题，只是机械地套用模式以期得到答案。这一类比很少被延伸用于描述“货物崇拜式管理”（cargo cult management），但后者其实危害更大。在货物崇拜式管理中，企业领导层采用某项技术（通常是软件）以及达成某些财务指标，来替代真正解决问题、获得事实真相。”这方面我觉得他们说的很好，“Palantir因推行“前线部署工程”（Forward Deployed Engineering）模式而遭到无尽嘲讽。投资者指责我们不过是家服务公司，仅仅因为我们不相信把软件“扔过墙”交给顾问去实施是对客户负责的做法。公平地说，许多客户也讨厌这一点，因为他们信奉一种世界观：只要完成正确的仪式（比如采购昂贵的ERP系统），就万事大吉。就像美国国防部的项目管理一样，商业世界普遍认为，实施最好由可互换（标准化）的“独立”顾问团队，按照成本、进度和性能指标来管理。”

这里难免有“竞争者”的味道，但事实上也确有类似问题，无论是自研软件、采购软件、学习标杆、引入方法，都有类似问题，“货物崇拜”都是真实存在的。分工虽然依旧很有价值，但是AI的领军企业也几乎都出现了“横纵一体化”的倾向。

“Palantir从未就实施服务单独收费，因为我们希望将成本与痛苦内化。唯有全身心投入解决整个问题，才能真正改进软件实施。”此处虽然有些自我标榜，但我认为最该内化“成本与痛苦”的其实是企业自己，毕竟，软件是给企业用的，软件公司、顾问们获取的是利润（这里没有不敬之意，我自己也是顾问），企业付出的是成本，到底谁该更“痛苦”些才真的会解决问题呢？做好软件的核心原则不应该是“从问题出发”吗？那“问题”到底是谁的呢？“瘤子”长在哪里你才会不着急？

文章中还有个有趣的话题，“到了1970年代，技术复杂度达到一个临界点，若无抽象就无法继续推进”、“但如今，这些抽象反而成了障碍”、“由于缺乏将资源投入实施环节所需的激励机制，企业转而创建一种抽象，用以定义“正确”的做事方式”，又成功地回到了“仪式感”这个问题，这也是企业架构领域常被质疑的地方吧，到底是在做正确的事情，还是只在试图定义一个正确的做事方式？二者似乎有区别，似乎又难以截然分开，而避免掉入这个逻辑混乱的关键也许就在于正确地梳理“问题”。

2025年初，我自己总结了“数智八问”：

这八个问题经常变着样儿出现在我的工作坊、轻咨询中，通常来讲，正着回答，大多数企业过不了第三个问题，倒着回答，基本过不了第七个问题，之所以没说过不了第八个问题，是因为这个问题经常是可以胡诌一下的。

分别作为正反两个开头的第一问和第八问，就是要企业自己多注意梳理自己的问题，因为什么要做一个系统？自己要成为什么样的企业？多试图回答这些问题，才有可能避免“货物崇拜”的发生。“瘤子”长在别人身上，对自己开刀不就是“笑话”了？没搞清楚自己的问题，要怎么精准解决问题呢？

企业架构是不是个仪式，很难说它不是，毕竟方法论不是都挺有“仪式感”吗？按照一套流程做下来，期待获得一个“更好”的结果，有些“许愿”的意味。说企业架构是个仪式的话，又有那个方法不是呢？但做好企业架构绝不仅是个“仪式”问题，同样是“求雨”，各类神话中衍生下来的“求雨”方式也是千奇百怪的，不过，即便是现代的“科学求雨”——人工降雨，也是条件够了才行的，不是飞机上天雨就一定能落下来。“仪式”结果的好坏，可能在于“感”的强烈与否，对企业自身问题的“感”，对解决问题的方向的“感”，内化“成本与痛苦”的过程，这要看自己的投入情况，是把软件当成生命线去做，还是打个辅助，有了就行。当然，如果是前者，还需要论证下是否真的是企业的生命线，但这个问题就不是一概而论的了，关乎领导者自己的判断，所以，那两篇文章里还说了句，“如果我们继续只吃奇多（Cheetos）薯条，又会走向何方？”2026年国央企的考核定位又有了新的变化，创新要求更高了。当然这种定位变化并非只对国央企成立，对很多企业也是一样的，不都是很努力也才勉强做到原地奔跑吗？

我在之前写《聚合架构》这本书时，也提到一个观点，就是我们持续挣扎在“软件缺口”与“软件混乱”之中，新的需求不断涌现，软件规模不断增大，数据与功能的混乱一直困扰着企业端开发，而这时我们又迎来了AI的强势介入，是雪中送炭还是雪上加霜，是一本万利还是血本无归，要回答这些，恐怕还是要回到一切的原点，问题，到底要解决的问题是什么？这些问题适合使用企业架构方法吗？适合使用AI吗？适合现在就用它们吗？

2025年的最后一个黎明在冉冉升起的朝阳中结束了，2026年的第一个黎明也将很快到来，时间留下的会是什么，在做出选择时似已确定。有因必有果，缘决定的大概只是因果之间的时间跨度，所以我也常说做企业架构需要讲缘分，“因”早就种下了，只是“缘”未到而已，这个“缘”也许在人、也许在AI，也许更在人机协同。