企业软件复杂度的逐步累积
从硬件导向到数据导向
早期的软件开发几乎完全围绕计算机硬件展开。机器语言与汇编语言要求开发者深入理解 CPU 指令、寄存器和内存地址，软件的表达方式高度依赖具体硬件体系结构。例如 SSE 指令集中用于比较字符串的 pcmpistr，无法运行在不支持该指令集的 CPU 上。这一阶段的软件极其昂贵、开发周期漫长、可复用性极低，应用范围也因此被限制在政府、科研机构和少数大型企业的核心场景中。
随着电子工业的发展，计算机开始进入企业管理领域。跨行业、跨规模推广计算机应用的关键，在于找到一种足够通用的抽象方式。
1970 年，IBM 的 E.F.Codd 博士在 ACM 通讯杂志上发表的论文《大规模共享数据银行的关系型模型》，为解决这一问题提供了一种切实可行的技术路线。该路线中，现实世界中的业务单据、业务流程和管理决策，被统一抽象为数据的存储、处理与分析，而执行这些操作的软件被统称为'关系型数据库'。企业的用户只需要一个连接到数据库软件的终端，就能用一套近似于英语的、统一的语言来操作这个软件，以此实现所有的业务操作。
比如想要查询姓名中包含'李'的员工档案，输入如下 SQL：
SELECT * FROM STAFFS WHERE NAME LIKE '%李%'
界面上就会呈现出纯文本呈现的员工档案信息。
图：早期的数据库服务器与操作终端
关系型数据库的出现，标志着企业软件第一次在抽象层面实现了规模化。通过关系模型描述业务实体及其关系，通过统一的数据操作语言处理不同业务场景，数据库成功降低了企业信息化的技术门槛，也显著扩展了软件需求的边界。
'壳'的出现与复杂度外溢
当数据库从档案管理走向财务、库存、成本核算等复杂业务场景时，一个新的问题随之出现：直接操作 SQL 对最终用户并不友好，一个业务操作需要多次打印和重复输入，导致操作员工作负荷高、出错概率大。为此，行业选择将数据库抽象为数据模型（数据模型可近似理解为数据库的结构，由数据表、列和表关系构成），在模型之上构建应用软件。这种做法很像是给数据库'套壳'，让用户操作应用，应用去操作数据库，而非用户直接操作数据库。
这一决策带来了企业软件形态的根本变化。业务逻辑开始在数据库与应用程序之间重新分配，用户交互界面成为差异化竞争的核心。随着抽象度更高的新一代高级语言（如 C++、Java）在应用层的普及，企业软件正式进入'高级语言 + 数据库'的长期技术范式。
图：DOS 时代的企业软件操作界面
然而，这种分层结构也埋下了复杂度累积的种子：
- 数据模型持续膨胀：一个小型订单管理系统可能只有十几张表，但经过几年演进后，堪比 ERP 的系统重，表数量可能增长到数百张
- 业务规则不断叠加：每次业务流程调整都会增加新的验证规则、计算公式和例外处理逻辑
- 交互逻辑日益复杂：从简单的表单录入发展到复杂的向导流程、多标签页面和实时校验
- 应用规模和生命周期显著拉长：企业软件往往需要运行十年甚至更长时间，期间不断打补丁和加功能
企业软件不再是一次性交付的工具，而是需要多年演进、持续维护的复杂系统。