别再只谈SaaS了!软件正从工具变为业务,这一新物种正在统治企业级市场

自20世纪50年代初以来，软件已从一门鲜为人知的技术学科，逐渐发展为几乎触及每个人日常生活的领域。起初，这一转变是渐进的，大多数人无法直接接触计算机，但他们与之交互的企业却拥有计算机。计算机被安置在后台房间，悄然改变着企业处理库存、会计和客户关系的方式。

到了20世纪80年代和90年代，计算技术迅猛发展。计算机从一台鲜为人知的机器，变成了每个人桌上、甚至家中的必备品。至少，人们需要掌握基本的计算机技能来完成日常任务。

在过去的20年里，计算技术进一步发展，它不再仅仅是一种实用工具，而是日常生活的基本组成部分，这是好是坏，尚存争议，但这是我们生活的现实，而这一现实需要庞大的技术基础设施。过去企业需要的是建筑，现在他们还需要网站。

要解释这对软件行业产生了什么影响，不妨看看另一个行业。

技艺高超的木匠能够打造出漂亮的桃花心木桌、橱柜或椅子。有些人花费数十年时间来掌握拼接、塑形、打磨和无数其他技艺。经验足够丰富后，他们几乎能打造出任何东西。

但房屋也是由木材建造的，而且房屋必须大规模建造。在快速、高效且大规模地建造房屋方面，存在着巨大的经济压力，用打造精美橱柜的方式建造房屋显然不切实际，因为两者的目标不同。房屋建造必须迅速完成，浪费最少，同时还要符合建筑规范和安全标准。这仍然是木工活，但属于不同的学科，有不同的限制条件。

软件行业也发生了同样的事情，对数字基础设施的巨大经济需求催生了一类新的软件工作，这类工作与传统软件工程截然不同。维持现代社会运转所需的技术，并不要求深入了解计算机科学或计算机的内部工作原理。相反，它要求理解一个由专业工具组成的大型生态系统，这些工具能够组装企业所需的组件。这仍然是软件，但它是受业务基础设施影响的软件。这不是传统软件，但仍然是一种软件。

我称之为业务软件(bizware)。

当你观察企业内部团队的转变时，这种区别就更加明显了。传统软件团队通常围绕深层次的技术问题展开工作：编写编译器、优化数据库引擎或设计新算法。其进展通过正确性、性能和创新来衡量。

业务软件团队则关注不同的问题，如今，大多数企业并非试图开发软件，而是需要部署软件来运营业务。他们通常围绕业务功能来组织团队：支付、认证、内部工具、客户仪表板或分析管道。目标不是突破计算能力的边界，而是利用现有组件快速组装出可靠、安全的系统。

这种定位上的差异改变了成功的衡量标准，在传统软件中，优雅和效率至关重要，而在业务软件中，速度、可靠性和集成性更为重要。系统无需完美无缺，但需要持续稳定地运行并支持业务。

许多计算机科学的传统概念并非业务软件的核心，冯·诺依曼架构、NP完全性或可判定性等概念很少相关。相反，理解认证系统、基础设施工具、安全框架和部署管道要重要得多。

这催生了一整套主要为了解决业务基础设施问题的工具生态系统。

Docker就是一个很好的例子，Docker解决了企业面临的部署问题，它并未解决通用计算问题。构建Docker需要深厚的软件专业知识，但使用Docker的人则是利用它来解决因大规模部署而产生的业务问题，Docker和Kubernetes等平台的兴起反映了向运营软件的这种转变。这些工具的出现是因为企业需要在开发和生产环境中保持环境的一致性。

起初，这些工具很难使用。计算机速度较慢，软件基础设施相对原始。一个人必须了解这些工具并具备深厚的传统软件背景，才能有效且高效地使用它们。随着工具的成熟，传统软件开发知识的重要性逐渐降低。

要在全球范围内部署网站，你不再需要了解NP完全问题的含义或冯·诺依曼架构的细微差别，然而，在业务环境之外，部署很少成为主要关注点。学生、研究人员和爱好者很少像企业那样为部署问题而烦恼。相比之下，编译器或解释器等工具则是通用的，编写软件的每个人都需要它们。

软件实际上已经经历了一种物种分化，出现了一个新的、独特的学科，业务软件和传统软件工程需要不同的技能集。两者都很难，都需要深厚的专业知识，但它们强调的是不同类型的知识，擅长其中一种并不意味着自动擅长另一种。

这种区别也解释了AI目前的应用领域，AI在传统软件开发方面举步维艰，它甚至无法取代从事深度技术性传统软件工作的工程师。例如，如果我想设计一种特定领域的语言来描述卡尔曼滤波器，AI几乎毫无用处。这项任务需要跨多个技术领域的深入理解，以及以前所未有的方式创造性地结合这些领域的能力。同时，与业务对业务软件的需求相比，这种工作的市场需求相对较小。

业务软件也面临着与传统软件截然不同的经济压力，企业需要大规模的数字基础设施。这些系统必须在成千上万的企业中快速、可靠且重复地构建。由于问题高度重复，自动化变得切实可行且极具价值。AI通常能提供一个合理的起点，因为模式是众所周知的且被广泛复用。

这也解释了为什么关于AI的讨论常常令人困惑，AI并非对所有软件的影响都是均等的，它在问题重复且模式被充分理解的领域更为有效。

这与业务软件高度契合。

相比之下，传统软件开发往往涉及创造全新的东西。这种工作仍然需要深厚的专业知识，且不易自动化。我在分析硬件和软件开发失败的原因时，探讨了相关的动态，其中不同学科之间的假设不匹配会导致系统性问题。一旦明确了业务软件和传统软件之间的区别，理解AI的应用领域及其不适用领域就变得容易多了。

此外，这种规模还产生了强烈的动机，促使尽可能多地标准化和自动化该流程。云平台、基础设施框架、容器化和编排系统主要就是为了解决这些运营问题而存在的。

传统软件开发则有所不同，它专注于构建新的计算能力：编译器、算法、操作系统、模拟工具和特定领域的系统，这些系统推动了计算机能力的边界。

传统软件开发解决软件问题，业务软件解决业务问题，因此，我们经历了专业知识的物种分化以及学科的分离。

这种分歧有助于解释现代科技公司内部的许多紧张关系，即使技能和目标截然不同，擅长某一学科的工程师也常常被认为可以与另一学科的工程师互换。

业务软件的市场规模巨大，资本主义不断推动优化。随着市场规模的扩大，这种推动力也变得更强，我们在建筑行业也看到了同样的情况，像Reframe Systems这样的公司现在正在制造旨在自动化房屋建造大部分工作的机器人，优化的经济压力从未消失。虽然精湛的木工技艺仍然至关重要，但房屋建造已经变得商品化。

业务软件并非软件的低级形式，正如房屋框架并非比打造精美家具低级的木工形式一样，它们只是为了满足不同的经济需求而存在。

理解这种区别有助于阐明现代软件开发已经变成了什么。

软件并未消失，但曾经围绕计算机科学展开的行业，现在也围绕着大规模运营数字基础设施展开。对公司而言，这种区别具有实际意义。这并非真正的技术区别，而是运营上的区别。

招聘和团队组织专注于保持基础设施的运行并使其保持最新状态，在互联网出现之前，这曾是商店经理的职责，他们需要保持商店的清洁和可进入性。过去是物理基础设施，现在是数字基础设施。

传统软件并未灭绝，也并未走向消亡。如果说有什么不同的话，那就是它比以往任何时候都更重要，然而，人们可能会有这种感觉，因为业务软件的规模已经完全超过了传统开发的规模。

这种物种分化已经发生，我只是试图给它一个名称。这样，人们、企业和组织就能就他们正在做什么以及想要做什么达成一致，因为围绕软件和业务软件等概念的混淆会耗费资金。

如果您在企业IT、网络、通信行业的某一领域工作，并希望分享观点，欢迎给企业网D1net投稿。

投稿邮箱：

editor@d1net.com

合作电话：

010-58221588（北京公司）

021-51701588（上海公司） 

合作邮箱：

Sales@d1net.com