SAP一个三十年基本没怎么变化的架构体系，"开源"对企业应用的影响SAP ERP软件历史SAP ERP软件是世界上最普及的企业级应用1972年，SAP R/1开始投放市场；1979年，SAP发布了SAP R/2；1992年，从SAP R/2进阶到SAP R/3，奠定了后面几十年的框架，其中R3的技术底座SAP kernel几乎是所有SAP产品的基础 ，今天小编就来聊一聊关于sap系统框架?接下来我们就一起去研究一下吧!
sap系统框架
SAP一个三十年基本没怎么变化的架构体系，"开源"对企业应用的影响。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领域里有一个广为流传的“五倍法则”。比如用100万来购买软件，那么项目上线的总预算要规划在500万或者更多，其中的400万要花在管理咨询、业务咨询和实施服务上，此外上线后可能还有运维和内部团队的其他成本。一个大型的ERP项目上线，一般先有波士顿咨询、麦肯锡这样的管理咨询公司从高层战略开始分析规划，然后由IBM、埃森哲、德勤这样的咨询和实施团队来做具体的业务拆解和实施。一个SAP的ERP项目上线，完全可以由第三方的合作伙伴独立完成。在私有部署软件的年代，相对于其他平台，SAP的ERP是最开放的平台之一可以毫不夸张地说，在私有部署年代的大型企业应用里，SAP的ERP软件几乎是无敌的存在。
标准化与定制化的矛盾今天很多软件厂商还在纠结于产品标准化和定制化之间的矛盾，（验一个产品标准化程度高低的一个有效方法是，这个产品是否可以由独立第三方甚至客户自己来实施。）许多第三方服务商的专业程度，在自己的擅长领域里经常超过原厂的水平。SAP原厂的实施顾问团队规模并不大，只负责战略客户、新产品的项目，或者负责大型项目中的新产品模块咨询、项目监理、项目顾问等角色。实施顾问，往往需要非常强的行业背景，熟悉业务配置和读懂业务代码逻辑，但不具备专业的开发能力。
开源对SAP生态的影响。大家可以看到，解决这些痛点离不开第三方合作伙伴和客户自身团队的技术能力，这些能力的建设很大程度要归功于SAP的ABAP开发语言。SAP的ABAP开发平台，虽然不是开源的协议，但是所有的业务代码对客户和合作伙伴都是开放可见的。独立的业务和技术顾问可以通过开发平台的各种工具，跟踪调试重现系统的问题；顾问在给原厂提问题工单的时候，甚至还附上问题的解决方案。
ABAP语言是一种神秘而古老的语言，比现在常用的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的架构有如下优缺点：
优点：
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平台上发布第三方的独立应用来赚取利润，
4.技术架构自成体系，ERP开发工程师的供应有限，高质量的ERP开发需要懂得业务，门槛也比普通的应用开发工程师高，如果有一个敏捷跨技术栈的需求，或则是没想清楚的业务需求，实现起来成本会比较高。因为Kernel和ABAP这样的封闭和开放架构设计，SAP的ERP系统有着非常鲜明的优缺点。不过针对企业应用这个领域，总体来讲还是优点多于缺点。
总结和展望
在私有部署的时代，基础和应用的分层架构的设计使得SAP的ERP产品保持常年的竞争优势，并且在多个国家多个行业逐渐积累最佳实践。虽然最近十年企业的ERP软件也受到互联网产品、云计算和SaaS产品的冲击，基于ABAP的架构上建立的护城河也被新的技术挑战。但是ERP的场景毕竟跟互联网的场景不同，偏企业内部应用的ERP软件因为企业的员工数量有限（即使是大型企业用户一般也少于10万人），基本上不会碰到应用和数据库的架构瓶颈问题。分布式数据库的技术团队可能会觉得区块链的性能不能满足高并发高性能的要求， SAP的经典ERP架构持续了三十多年基本没怎么改变，针对适应它的场景，竞争对手还并不多。即使是跟SaaS软件相比，SAP的经典ERP架构目前还是能保证非常灵活的定制化。当然，我个人还是对未来的ERP架构有一些期待——
1.能够支持开源的分布式数据库，降低使用成本，进一步增强系统高可用性。
2.能够与未来的数字货币体系相结合，可以把资源管理的体系变成价值管理的体系。
3.能把面向企业内部管理的ERP和企业外部的应用、资源更紧密地结合起来，比如企业上下游。
4.架构适应应用商店，第三方应用能够有商业上的收获，进一步扩大生态圈。
,
