以下文章来源于信息化与数字化 ，作者沈旸
来源：信息化与数字化
导读：熟悉SAP ERP的同学可以从后往前看，有精彩的历史故事。
“开源”对企业应用和生态有什么样的影响？
在Github上浏览开源软件，会发现那些最火的项目大多数属于基础架构层面，而应用层的开源软件，特别火的很少。大家可以在www.ossinsight.io里找到各类开源项目的统计数据，查看各个领域里最流行的开源软件的排名和趋势。
为什么好的开源软件多是基础架构层？
像操作系统、数据库、Web中间件这样，使用量都是以“亿”为单位的，工程师在这里写下的代码发挥的杠杆作用最高，基础架构软件工程师可以为了情怀而写下优美的代码。基础架构层的软件面向机器世界，而机器世界的约束边界多属于已知的边界，在已知的边界里寻找最优解会更容易、更清晰，一个领域发展到最后，可能只会剩下几个最好的产品。等下一个技术变革或者商业格局剧变的时候，才会出现新的发展窗口期。例如最近几年中国开源软件快速发展，出现了像TiDB、TDengine这样的优秀产品。
基础架构层的软件是面向机器世界的，而应用软件是面向组织社会的。机器世界的规则在全世界都是通用的，产品优劣很容易评判。而应用是面向人和社会的，规则在不同的国家、不同的地区、不同的文化和不同的组织之间都有非常大的差异。在应用软件层，经常要面临大量的定制化开发和需求变动，并不是最贵最流行的软件就会适用你的场景。文无第一，武无第二，跟基础软件和应用软件的比较很类似。也有言论称，信息化是面向人的，数字化是面向机器的，如果从这个角度来看的话，做好信息化比做好数字化可要难多了。
应用软件的使用量很难达到基础软件那样的规模，大家写下的代码可能很快就被修改或者弃用，所以应用软件比较难吸引优秀的工程师全身心投入。因此，大家可能会好奇，在应用领域里，开源能够起到什么样的作用。今天就以SAP的经典ERP软件为例，一个三十年基本没怎么变化的架构体系，聊一下"开源"对企业应用的影响。
SAP ERP软件历史
SAP ERP软件是世界上最普及的企业级应用。1972年，SAP R/1开始投放市场；1979年，SAP发布了SAP R/2；1992年，从SAP R/2进阶到SAP R/3，奠定了后面几十年的框架，其中R3的技术底座SAP kernel几乎是所有SAP产品的基础。
今天ERP经常被一些新的概念产品批评为“封闭”或者是“不够敏捷”。不过专业的SAP咨询顾问和实施顾问可能会有不同的感受。在私有部署软件的年代，相对于其他平台，SAP的ERP是最开放的平台之一，因为开放性其产品成为了全世界企业管理软件里最广泛的低代码定制化开发平台，不同的行业不同国家的客户的管理理念都能够在系统里实现。可以毫不夸张地说，在私有部署年代的大型企业应用里，SAP的ERP软件几乎是无敌的存在。
标准化与定制化的矛盾
今天很多软件厂商还在纠结于产品标准化和定制化之间的矛盾，既希望推出标准产品，又垂涎大客户的定制大单。一旦遇上大型定制化项目，大量产品研发人员会陷入到定制化的深坑里，客户的定制版本在未来升级时，也会有很大的隐患。如果面对成千上万个定制化的软件项目，交付成本和维护成本将陷入规模不经济的陷阱，影响企业的进一步扩张。因此一个初创的产品团队对那种财大气粗但是定制要求多的客户，真是又爱又恨。
检验一个产品标准化程度高低的一个有效方法是，这个产品是否可以由独立第三方甚至客户自己来实施。因为第三方团队与产品企业打交道的时候，因为沟通成本和商务成本会损失一定的效率，如果在初期的时候发现产品的标准化程度可以平衡这一部分损失的效率，在后期就可以做到有效的大规模扩张了。
SAP的第三方生态
在ERP领域里有一个广为流传的“五倍法则”。比如用100万来购买软件，那么项目上线的总预算要规划在500万或者更多，其中的400万要花在管理咨询、业务咨询和实施服务上，此外上线后可能还有运维和内部团队的其他成本。一个大型的ERP项目上线，一般先有波士顿咨询、麦肯锡这样的管理咨询公司从高层战略开始分析规划，然后由IBM、埃森哲、德勤这样的咨询和实施团队来做具体的业务拆解和实施。
一个SAP的ERP项目上线，完全可以由第三方的合作伙伴独立完成。许多第三方服务商的专业程度，在自己的擅长领域里经常超过原厂的水平，比如在Gartner象限里SAP的原厂实施能力并不是排第一。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/ target=_blank class=infotextkey>Python和JAVA都要古老。ABAP作为一种面向特定应用的编程语言，最早在20世纪80年代开发，ABAP编程语言最早用于开发SAP R/3平台，客户也可以用ABAP编程开发自定义的报表和界面。到2000年后，SAP的核心ERP系统里的基本功能几乎都是用ABAP编程语言来实现的。
闭源的Kernel基础层和开源的ABAP应用层
以SAP的经典ERP产品在2005年前后发行的版本ECC6.0为例，从技术上来讲，其主要可以分为客户端展示层、应用层和数据库层，它是一个典型的前后端一体的框架。而它的应用层也分为三层：面向前端交互的逻辑层，面向应用的ABAP层以及跟数据库、操作系统、系统管理等打交道的BASIS层。其中BASIS层的内核（Kernel）是由C语言编写的，Kernel是SAP系统的基础技术平台。Kernel向下面对特定的操作系统、数据库，向上架构起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客户端交互为主的ERP企业软件受到互联网的网页端应用的挑战，经常被互联网的竞争对手发出“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全球首席执行官孔翰宁的任期延长至2009年，希望能接CEO位置的夏嘉曦不打算等待联席CEO的位置，在他2007年从SAP离职后，ABAP的架构又成了SAP主要的方向。
现在复盘来看，夏嘉曦的离职结束了SAP在架构方向上的摇摆。Java当时主要是IBM、Sun和Oracle主导的技术，后来在2009年，Oracle通过收购Sun公司获得了Java技术的主导权，假如SAP此时还在摇摆中，那么很可能会陷入被动。在面向全球的复杂的私有部署企业软件里，ABAP可能是当时最合适和最可靠的架构引擎。
个人认为，SAP 经典ERP的架构有如下优缺点：
优点：
1.应用中的Basis层面向机器层，容易找到最优解，无需定制化，不用开放代码，结构稳定。闭源的Kernel层可以保障软件的商业价值得到支付，例如许可管理等。
2.应用中的ABAP层面向企业业务，可以由第三方完成各种定制化开发，利于生态发展，能够很好地适应国际化和各行业的复杂应用定制，鼓励第三方和自由顾问的创新以及解决问题的主动性。
3.代码、应用和数据一体，支持代码热更新、运行时动态调试等，系统升级容易。开发测试生产体系完善，不需要复杂的Devops体系，不需要额外的IDE、Git、Github、Profiling工具，统一集成在一个技术平台里。
4.寿命长的应用代码可维护性好，很多ABAP应用运行了几十年还可以继续发挥作用，接手的团队也很容易处理。
5.复杂的系统问题很容易跟踪和解决，有非常好的体系化的工具和方法论，客户的各种需求和问题会及时反馈到产品里，积累成最佳实践。
6.分层设计优秀，数据、代码、配置，开发和业务容易实现统一，大部分需求可以靠业务顾问通过配置完成，积累最佳实践逐渐迭代成一个偏向业务的低代码平台。
7.系统设计严谨，大部分修改都会留下痕迹，深得第三方审计机构的信赖。
缺点：
1.ABAP脚本语言在性能上不及Java和C语言，比如同样一个Loop循环要慢很多倍，这样的架构设计确实不适合互联网行业所需要的高并发高性能。一些对性能要求高的应用需要调用外界的专业程序或者是数据库的Procedure来加速。
2.原厂开发的代码过于透明，一些质量不佳的代码容易被吐槽。（还好我之前写过的一点注释是用英文名留下的）
3.大部分生态合作伙伴只能靠服务来赚取利润，很难靠在ABAP平台上发布第三方的独立应用来赚取利润，毕竟ABAP代码是透明可见的，跟现在SaaS平台流行的应用商店模式有很大的区别。当年可能有些咨询公司会通过复制一套代码或者配置用于客户不同省份的分公司来赚取多份利润，在信息透明的今天，很难这样操作了。有产品想法的服务商最终可能会做自己独立的产品线，比如汉得。
4.技术架构自成体系，ERP开发工程师的供应有限，高质量的ERP开发需要懂得业务，门槛也比普通的应用开发工程师高，如果有一个敏捷跨技术栈的需求，或则是没想清楚的业务需求，实现起来成本会比较高。
因为Kernel和ABAP这样的封闭和开放架构设计，SAP的ERP系统有着非常鲜明的优缺点。不过针对企业应用这个领域，总体来讲还是优点多于缺点。
总结和展望
在私有部署的时代，基础和应用的分层架构的设计使得SAP的ERP产品保持常年的竞争优势，并且在多个国家多个行业逐渐积累最佳实践。虽然最近十年企业的ERP软件也受到互联网产品、云计算和SaaS产品的冲击，基于ABAP的架构上建立的护城河也被新的技术挑战。但是ERP的场景毕竟跟互联网的场景不同，偏企业内部应用的ERP软件因为企业的员工数量有限（即使是大型企业用户一般也少于10万人），基本上不会碰到应用和数据库的架构瓶颈问题。
分布式数据库的技术团队可能会觉得区块链的性能不能满足高并发高性能的要求，但是很少有人会去挑战比特币和以太坊的架构设计。SAP的经典ERP架构持续了三十多年基本没怎么改变，针对适应它的场景，竞争对手还并不多。即使是跟SaaS软件相比，SAP的经典ERP架构目前还是能保证非常灵活的定制化。今天很多互联网公司号称用"中台"取代大部分行业的ERP，很多时候只是在用不同的场景在做牛头不对马嘴的混淆，架构设计都是在做取舍，很难有完美的架构。
当然，我个人还是对未来的ERP架构有一些期待——
1.能够支持开源的分布式数据库，降低使用成本，进一步增强系统高可用性。
2.能够与未来的数字货币体系相结合，可以把资源管理的体系变成价值管理的体系。
3.能把面向企业内部管理的ERP和企业外部的应用、资源更紧密地结合起来，比如企业上下游。
4.架构适应应用商店，第三方应用能够有商业上的收获，进一步扩大生态圈。
京公网安备 11010802035086号