「开源」对企业应用和生态有什么样的影响？

在Github上浏览开源软件时，你会发现现在最火的项目大多属于基础设施层面，而应用层面的开源软件尤其少见。你可以在www . OS insight . io找到各个开源项目的统计数据，查看各个领域最受欢迎的开源软件的排名和趋势。

为什么好的开源软件大多是基础设施层？

像操作系统、数据库、Web中间件，使用量都是以“亿”为单位的。这里工程师写的代码起着最高的杠杆作用，基础设施软件工程师可以凭感觉写出漂亮的代码。基础设施层的软件面向机器世界，机器世界的约束边界大多属于已知边界。在已知边界内寻找最优解更容易、更清晰。在一个领域开发结束时，可能只剩下几个最好的产品。当下一次技术变革或业务结构剧变发生时，会有新的发展窗口期。比如，近年来中国开源软件发展迅速，出现了TiDB、TDengine等优秀产品。

画

基础设施层的软件面向机器世界，应用软件面向组织社会。世界的规则是全世界通用的，很容易判断一个产品的好坏。应用是面向人和社会的，不同国家、地区、文化、组织的规则有很大不同。在应用软件层，往往会有大量的定制开发和需求变化，并不是最贵最流行的软件都会适合你的场景。没有第一篇文章，没有第二篇武功，很像基础软件和应用软件的对比。也有人说，信息化是以人为本，数字化是以机器为本。从这个角度来说，做信息化比数字化难多了。

应用软件很难达到基础软件的规模，大家写的代码可能很快就会被修改或者抛弃，所以应用软件很难吸引优秀的工程师全心投入。所以，你可能想知道开源在应用领域能起到什么作用。今天我们就以SAP经典的ERP软件为例，一个30年来没有太大变化的架构系统，谈谈“开源”对企业应用的影响。

SAP ERP软件历史

SAP ERP软件是世界上最流行的企业应用程序。1972年，SAP R/1投放市场；1979年，SAP发布了SAP R/2；1992年，SAP R/2被推进到SAP R/3，奠定了随后几十年的框架，其中SAP内核，R3的技术基础，是几乎所有SAP产品的基础。

如今，ERP经常被一些新概念产品批评为“封闭”或“不够敏捷”。但是专业的SAP顾问和实施顾问可能会有不同的感受。在私有部署软件的时代，与其他平台相比，SAP的ERP是最开放的平台之一。由于其开放性，其产品已成为全球最广泛的企业管理软件低代码定制开发平台，不同行业、不同国家的客户的管理思路都可以在系统中实现。毫不夸张的说，SAP的ERP软件在私有部署时代的大型企业应用中几乎所向披靡。

标准化与定制化的矛盾

时至今日，许多软件厂商仍在产品标准化和定制化的矛盾中苦苦挣扎，希望推出标准产品，觊觎大客户的大定制订单。一旦遇到大规模的定制项目，大量的产品R&D人员就会陷入定制的深坑，未来客户定制版升级时会有很大的隐患。如果面对成千上万的定制软件项目，交付成本和维护成本就会陷入规模不经济的陷阱，影响企业的进一步扩张。所以一个初创的产品团队，对那些财大气粗却要求更多定制的客户，真的是又爱又恨。

检验一个产品的标准化程度的一个有效方法是，该产品是否可以由独立的第三方甚至客户本人来实现。因为第三方团队在和产品公司打交道的时候会损失一定的效率，因为沟通成本和商务成本。如果在初期发现产品的标准化程度可以平衡这种损失的效率，就可以在后期实现有效的规模化扩张。

SAP的第三方生态

在ERP领域有一个广为流传的“五重法则”。例如，如果100万元用于购买软件，那么项目上线的总预算应该计划在500万或更多，其中400万元应该用于管理咨询、业务咨询和实施服务。此外，项目上线后可能还会有运维、内部团队等其他费用。大型ERP项目上线时，波士顿咨询、麦肯锡等管理咨询公司一般会从高层战略开始分析和规划，然后由IBM、埃森哲、德勤等咨询和实施团队做具体的业务拆解和实施。

一个SAP ERP项目上线，可以由第三方合作伙伴独立完成。很多第三方服务商的专业水平往往在自己的专业领域超过原厂的水平。比如SAP的原厂实施能力，在Gartner象限中并没有排第一。SAP原来的实施顾问团队规模并不大，一般负责战略客户、新产品项目，或者大型项目中的新产品模块咨询、项目监理、项目顾问等角色。在2020年的SAP生态系统中，顾问和实施顾问将超过100万，远远超过原来的SAP工厂团队。

私有部署时代，大型企业应用的痛点

今天，SaaS软件已经变得非常受欢迎。大家可能已经习惯了SaaS软件的很多优点，比如敏捷、统一、产品迭代快、维护简单、厂商在线复制解决问题等。十年前，SAP的ERP主要部署在私有环境中。我在SAP参与过全球数百家世界500强企业的短期项目，也和第三方合作伙伴一起参与过上亿美元的长期项目。在全球多个国家和行业的私有部署环境中，定制化开发会遇到哪些困难？

国际化的政策复杂性

比如美国，每个州的税收规则都不一样，针对不同的家庭和经营状况有不同的税收政策，每年都会有新的财税政策调整。在美国，先估算个人的年平均税率，然后每个月的扣除额也差不多。次年4月15日前，重新计算年所得应纳税额，退税政策非常复杂。2019年12月31日，中国公布了新的税收政策。第一个月开始扣税，逐渐增加，年底再重新计算，多退少补。每个国家的政策差异很大，可能会有突变。

这样的政策变化也需要系统的管理和业务规则有相应的变化，但一个软件产品公司不可能在一天之内快速了解各个国家的政策并修补好。很多情况下，需要依靠当地的咨询和实施合作伙伴，在第一时间给出本地化的临时解决方案，经过验证后，SAP会发布正式补丁。

复杂的业务逻辑

每个大型企业都有自己独特的业务和管理规则，自己的ERP业务系统有大量定制的代码，不同模块和组件之间的逻辑关系也非常复杂。作为这些客户的实施顾问，往往需要非常强的行业背景，熟悉业务配置和业务代码逻辑，但不具备专业的开发能力。比如下图是油气行业的解决方案演进过程，其中有很多专业的业务设计。

画

复杂业务系统中的错误不一定是软件的技术平台造成的，可能是业务代码中定制的配置和逻辑错误造成的。这种情况下，如果不能深入了解客户的业务，甚至可能很难重现问题。这些问题只有客户的内部顾问或者第三方服务团队才能重现，甚至可以找到问题和解决方案。

数据安全问题

因为客户数据的安全顾虑，不方便原厂和第三方协助在生产系统上直接测试，比如上市公司合并报表系统。假设某大型上市公司财务合并报表数据不一致。如果将这些数据直接暴露给软件供应商和外部顾问，将会有极大的风险。大型上市公司的ERP团队需要有很强的技术和业务能力。内部团队先做初步定位，用仿真数据重现问题，最后把仿真场景交给第三方团队或者原厂做技术支持。

画

什么样的技术架构可以解决这些痛点？

上一章描述的私有部署环境中的痛点，几乎每个软件厂商都会遇到，尤其是规模稍微大一点的时候。那么SAP的ERP是如何平衡这个问题的呢？很多文章都有不同的解释，比如架构体系的超前设计，原厂克制了自己咨询和实施团队的扩张，抓住了全球化在欧美扩张的时间窗口等等。

不过这几年我接触了更多的开源产品和团队，对之前接触的SAP项目和生态有了一些不同的看法。今天我就来说说开源对SAP生态的影响。

如你所见，解决这些痛点依赖于第三方合作伙伴和客户自身团队的技术能力，而这些能力的构建很大程度上得益于SAP的ABAP开发语言。SAP的ABAP开发平台不是开源协议，但所有业务代码都是开放的，对客户和合作伙伴可见。独立的业务和技术顾问可以通过开发平台的各种工具来跟踪、调试和重现系统的问题；厉害的咨询师甚至在给原厂问题工单的时候附上了问题的解决方案。

ABAP是一种神秘而古老的语言，比Python和Java还要古老。ABAP作为一种面向应用的程序设计语言，最早是在20世纪80年代开发的。ABAP编程语言最早用于开发SAP R/3平台。客户还可以使用ABAP编程来开发定制的报告和界面。2000年以后，SAP核心ERP系统的基本功能几乎都是用ABAP编程语言实现的。

封闭的内核基础层和开源的ABAP应用层。

以2005年左右发布的SAP经典ERP产品ECC6.0为例。技术上可以分为客户端展示层、应用层和数据库层，是典型的前端集成框架。其应用层也分为三层:用于前端交互的逻辑层、面向应用的ABAP层和处理数据库、操作系统和系统管理的基础层。基础层的内核是用C语言编写的，内核是SAP系统的基础技术平台。内核面向特定的操作系统和数据库，构建ABAP运行平台。可以看到，Kernel面向机器层，几乎不需要定制，对性能有要求。用C语言写的，属于封闭代码模块；应用层用ABAP语言编写，更为业务定制，属于开放代码模块。

画

所有的ABAP程序都驻留在SAP数据库中，而不是像Java或C++程序那样单独存放。从这个角度来看，SAP的系统更像是一个基于数据库层面的应用操作系统，实现了代码、数据库、应用的良好融合。在SAP的系统中查看代码时，系统从REPOSRC等数据库表中读取源代码，然后调用生成动态代码并运行。如果源代码改变或者数据库结构改变，下次运行时会自动生成新的代码。ABAP作为一种开放的脚本语言，解决了很多应用问题，比如热更新、版本管理等。

在传统的软件设计中，代码、编译后的应用程序和数据是分离的，但在SAP ERP中，这三个对象被很好地结合在一起。另一个实现数据、代码、应用统一的应用应该是以太坊的智能合约，但是以太坊的每秒交易吞吐量不足50%。

由于ABAP业务层代码开放，第三方服务商可以充分发挥其智能提供各种解决方案，ERP平台中的各种bug和问题都可以被客户或合作伙伴发现并解决，充分发挥了生态的力量。如果一个应用系统是封闭的，创新和解决问题只能靠厂商，生态参与的强度和专业性会和原厂大不相同。而原厂很难用自己的资源覆盖这么多国家和行业的不同客户，管理上容易出现“规模不经济”。SAP的整个ERP生态系统可以看作是一个开放的社区，可以共同构建，以对抗大型应用软件的复杂性。

浅谈建筑的利与弊

历史上，关于SAP中ABAP架构和Java架构的争议很多，也有精彩的故事。

在2000年互联网泡沫的巅峰时期，基于PC-client交互的ERP企业软件受到了互联网的web应用的挑战，经常受到互联网竞争对手“ERP已死”的言论的冲击。2001年4月，SAP以4亿美元收购了以色列技术天才Shai Agassi创立的TopTier。被收购的TopTier更名为SAP Portals，是一款基于Java技术框架的门户产品。2002年4月，在加入SAP仅一年后，夏嘉熙成为SAP全球执行董事会最年轻也是第一位非德国籍成员，负责SAP的产品和技术团队。他也是SAP历史上第一位被任命的CTO，一度被认为是最有潜力的CEO接班人。在那段时间里，SAP的未来架构设计一直在ABAP和Java之间摇摆。但在2007年，因为SAP全球CEO孔翰宁的任期延长至2009年，希望走上CEO岗位的夏嘉熙并不打算等待联席CEO的位置。2007年他离开SAP后，ABAP架构成为SAP的主要方向。

现在回想起来，夏嘉熙的离开结束了SAP在架构方向的摇摆。当时Java是IBM、Sun、Oracle三家主导。后来在2009年，甲骨文通过收购Sun获得了Java技术的主导权。如果SAP此时还摇摆不定，很可能会陷入被动。在面向全球的复杂的私有部署企业软件中，ABAP可能是当时最合适、最可靠的架构引擎。

个人认为，SAP classic ERP的架构有以下优点和缺点:

优势:

1.应用中的基础级是机器级，很容易找到最优解，不需要定制和开放代码，结构稳定。封闭的内核层可以保证软件的商业价值是付费的，比如许可证管理。

2.ABAP对企业业务的应用可以由第三方定制，有利于生态发展，可以适应各行业的国际化和复杂应用定制，鼓励第三方和免费顾问的创新及其解决问题的主动性。

3.代码、应用、数据一体化，支持热代码更新、运行时动态调试等。，系统升级也很容易。开发和生产系统完善，没有复杂的Devops系统，没有额外的IDE、Git、Github和Profiling工具，集成在一个技术平台上。

4.长寿的应用程序代码具有良好的可维护性。许多ABAP应用程序在运行了几十年后还能继续运行，接手的团队也很容易管理。

5.复杂的系统问题很容易跟踪和解决，有非常好的系统化工具和方法论。客户的各种需求和问题会及时反馈到产品中，积累成最佳实践。

6.分层设计优秀，数据、代码、配置、开发、业务易于统一。大部分需求可以由业务顾问通过配置来完成，最佳实践积累下来，逐步迭代成面向业务的低代码平台。

7.系统设计严谨，大部分修改都会留下痕迹，深得第三方审计机构的信任。

缺点:

1.ABAP脚本语言在性能上不如Java和C语言。例如，同样的循环周期要慢很多倍。这种架构设计真的不适合互联网行业要求的高并发、高性能。一些对性能要求高的应用需要调用外部专业程序或数据库程序来加速。

2.原厂开发的代码太透明，一些质量不好的代码很容易被吐槽。(还好我之前写的一个小评论留了英文名)

3.大部分生态伙伴只能靠服务盈利，在ABAP平台发布第三方独立应用很难盈利。毕竟，ABAP代码是透明可见的，这与SaaS平台流行的应用商店模式有很大不同。在那个年代，一些咨询公司可能会通过复制一套代码或为客户在不同省份的分支机构配置代码来获取多重利润。在信息透明的今天，很难做到这一点。有产品思路的服务商，最终可能会做出自己独立的产品线，比如Hand。

4.技术架构自成体系，ERP开发工程师供应有限。高质量的ERP开发需要懂业务，门槛比普通应用开发工程师高。如果有敏捷的跨技术栈需求，或者业务需求不明确，实现成本会更高。

由于内核和ABAP的封闭和开放的架构设计，SAP的ERP系统具有明显的优势和劣势。但是在企业应用领域，总体来说，利大于弊。

总结与展望

在私有部署时代，基础和应用的分层架构设计使SAP的ERP产品常年保持竞争力，并逐渐积累了多个国家和行业的最佳实践。虽然最近十年企业的ERP软件也受到了互联网产品、云计算、SaaS产品的冲击，但是基于ABAP架构的护城河也受到了新技术的挑战。但是，ERP的场景毕竟不同于互联网。由于企业员工数量有限(即使是大企业的用户一般也不到10万)，偏于企业内部应用的ERP软件基本不会遇到应用和数据库架构的瓶颈问题。

分布式数据库的技术团队可能会觉得区块链的性能达不到高并发高性能的要求，但是很少有人会去挑战比特币和以太坊的架构设计。SAP经典的ERP架构30多年来基本保持不变，适应其场景的竞争对手并不多。即使与SaaS软件相比，SAP的经典ERP架构仍然可以保证非常灵活的定制。如今，很多互联网公司宣称用“中间平台”取代大部分行业的ERP，往往只是混淆了不同的场景。架构设计都是在做取舍，很难有一个完美的架构。

当然，我个人对未来的ERP架构有一些期待——

1.它可以支持开源的分布式数据库，降低使用成本，进一步增强系统的高可用性。

2.可以和未来的数字货币体系结合，把资源管理的体系变成价值管理的体系。

3.可以更紧密地将企业内部管理的ERP与企业上下游等外部应用和资源进行整合。

4.架构适应应用商店，第三方应用可以有商业收益，进一步拓展生态圈。