聊聊SAP系统架构有多牛逼?(2)

简介: 聊聊SAP系统架构有多牛逼?

二、SAP架构的特点(PartI)


下文中,对SAP的架构(应用和技术架构)的特点做简要的描述,由于特点较多,因此分为二个章节来介绍,本文是第一部分,后面择机补充完整第二部分的内容。



特点1:对商业世界的高度抽象

企业管理软件本质是对企业(商业世界)的业务活动、业务逻辑进行抽象,通过IT系统实现,SAP在这方面做到了高度的抽象。


给大家介绍一个在SAP中的高度抽象的例子,离散制造领域用的生产订单、流程行业的流程订单、设备维修领域的维修工单、售后服务领域的订单、项目管理中的网络工单,这些单据看上去属于完全不同的领域,但从高度抽象的角度,都属于订单(工单),都有各种日期(计划日期与实际日期),都需要用到BOM、都需要发料、报工,也都需要与财务进行结算,因此这些不同类型的工单在SAP中共享了相同的数据表、很多功能都是共享(类似)的,只是在局部进行了区分。


这种模式,我将其称之为稳健功能强大的后台模型+灵活应对各种场景的前中台应用。


备注:分与合(灵活前台与稳定后台)是这个世界最主要的永恒话题之一,历史上分久必合,合久必分,企业领域有各种兼并、拆分,企业内部管理领域有各种部门的重组,互联网领域的中台、微服务等等本质都是关于分与合。分可以更好让某个业务更独立,让特定场景(业务)运作更好,合可以达到共享、协同、复用的目的。如何很好的处理分与和的问题,是企业管理、产品管理的难点。以SAP咨询行业为例,1家公司有1000个顾问,这1000个顾问应该是整体一个资源池,最大化共享资源,还是说很多顾问直接归属于行业线,更好地服务特定行业。




特点2:SAP是高度参数化设计的软件


在IT系统中要实现一个业务功能,有三种实现方式:

1)、主要在程序中写死

2)、在程序中写死+部分参数

3)、高度参数化,然后在程序中根据参数写业务逻辑,如果业务有变化,通过参数调整,实现更多(不同)功能。


SAP选择了第三种实现方式,高度参数化,这种方式对架构的要求最高,但显然是最能适应各种业务场景、最能满足各行各业的业务需求,这种参数在SAP中称之为配置。


以销售订单为例,典型的配置(参数)包括订单是否需要发货、是否需要定价(如何定价)、是否需要开票(如何开票,如是否可以部分开票)、库存类型是常规库存、还是特殊库存(销售订单库存、寄售库存等),当销售套件时是否需要成套发货,成套发货支持几层成套等各种各样的参数,这些参数之间互相组合,就形成了企业的各种销售业务,这些参数与企业的生产、采购、财务领域的参数组合,就形成了企业各种各样的业务(端到端流程)。


如下图所示,SAP系统中一共近10万个配置表(参数表),这些配置表又分为二大类:完全由SAP控制和由用户(客户)配置的表,绝大部分的配置(参数)可由客户(用户)自己配置。


对于企业来说,新增一个公司、业务类型(采购模式、销售模式、生产模式、质量控制模式等等),在SAP系统中主要是通过配置(参数)的方式来实现的,并且这种参数不是孤立的参数,是可以做到闭环的参数,能够保证端到端的流程跑通。





特点3:SAP可能是提供预配置最多的软件


一方面参数与参数之间存在关系,另外一方面需要给客户(企业)标准化,因此SAP中预配置了大量的参数(配置),并且这些参数大部分是以组合的形式呈现。


以物料为例,在SAP中,预配置了十几种物料类型(成品、半成品、包装、贸易物料、服务、替代物料组、可配置物料、可退回包装等)、十几种生产计划策略、十几种批量方式、十种物料获得的方式(采购、自制、跨工厂调拨、委外、寄售等等)。


对于企业来说,在实施项目时,根据业务特点,选择使用哪一种计划策略、哪一种物料获得方式。


当预配置的标准配置不能满足业务需要时,可以进一步对具体的参数进行微调。


这一点相当于SAP提供了精装修房子、以及样板房,同时还支持对精装修房子自己再去做调整。






特点4:可能是函数量最多、对外接口最多的软件

作为一个高度抽象的系统,系统中必不可少的有很多函数,这些函数代表着封装好的一个功能,比如创建物料、对物料进行库存检查、创建销售订单、根据日期查询工厂日历。


SAP系统中一共拥有54万个函数(API),这些函数可以在SAP系统内部被调用。


同时这50万个函数中有5万个被认为可能会与外围系统发生数据交互的,因此设置为可以被外部系统调用的RFC函数。这5万个RFC函数根据需要也可以转换为Webservice(Web服务)的方式供其他系统调用。最新的系统在接口方面也进一步拓展了Restful的服务能力。


其他45万个函数,假如其他系统真的也需要调用,那么也可以复制出来一个新函数,略作修改,然后设置为RFC函数。


函数(API)的最大的优势在于外围系统只需要输入参数就能实现特定的功能,不需要管具体的表结构和逻辑。


函数的内在逻辑是实现业务的端到端流程,另外一方面给企业的业务流程、给项目实施带来给了极大的自由度,比如用户对SAP中创建物料的界面不满意,完全可以在SAP系统中写代码、设计新界面,然后调用函数,当然企业也可以选择在外围系统写UI界面,然后调用创建物料的函数,最重要的一点是调用函数的方式和直接在SAP中用标准功能创建物料是相同的业务逻辑,执行相同的权限检查。



特点5:可能是最开放、最灵活的系统(增强机制)


这种开放性、灵活性体现在很多个方面,首先SAP的960万个程序99.9%都是源代码开放的,同时SAP已经提供了无数个配置(参数)。


但每个行业、客户还会有特殊的需求,sap的标准功能无法满足,比如需要对订单的特定字段进行额外的逻辑检查,此时一定需要在项目中进行二次开发,但二次开发的难点是如何与标准程序和谐发展,以及当系统升级后,如何保留这些代码,并且还继续生效。


SAP系统中,通过在在程序中预留了很多增强(用户出口)来实现这样的灵活需求,在增强中,客户(项目组)写自己的代码逻辑从而实现特定的功能,包括检查、赋值、调用其他事务等各种功能。SAP增强最大的特点在于他会和SAP标准的程序一起生效,增强与核心逻辑是融入在一起的,同时非常关键的一点在于在增强中写的自定义代码,不会影响SAP系统的升级,系统升级后,这些增强代码仍然存在,也仍然在继续生效。


在增强上,SAP花了很多心思经历在这方面,在过去的几十年内设计了四代的增强。这四代增强今天都仍然继续生效。


1代和2代增强都是上个世纪推出的,其中第一代增强是在程序中预留了空代码的子过程(Form),第二代增强是基于函数的增强,在程序中预留了很多空代码的函数,在这些函数中有输入和输出参数,可以根据输入参数,然后写一些逻辑,改变输出参数。


第三代增强是基于面向对象的增强BusinessAdd-in,2000年左右推出,SAP预留了10000个增强点。第四代的增长是隐式增强,这是一个终极Boss,理论上所有760万个程序都可以写隐式增强。



增强是SAP项目中必不可少的部分,每个项目都会使用到其中的几十个增强,多的项目可能会用到上百上千个增强。在增强中实现特定的检查逻辑和赋值逻辑,如按照特定规则生成批次,实现自定义的信用控制规则。



特点6:成熟的补丁(优化)以及文档的体系


企业在实施/使用系统的过程中,经常碰到如下但不限于的场景:

1)、正在使用的(SAP)系统存在Bug,需要打补丁。

2)、(SAP)系统新推出的功能,企业希望应用这些新的功能,此时需要在系统中引入新的功能增强。

3)、对于(SAP)系统的一些原理有不清晰的地方,此时需要查看一些文档。


对于这些场景(问题)的管理不是一件容易的事情,SAP建立了一套Note系统,每个Note解决一个具体的问题(补丁、新功能、问题解释等),通过几十年的积累,SAP积累了300多万个这样的Note


Note对于产品的生命周期非常关键,比如对于SAP顾问来说,通过查找Note解决问题时是必备的技能,对于SAP公司来说,其会每年更新(发货)其软件的新功能(补丁),这些新发布补丁包,其本质就是几千、几万个Note的组合。对于客户来说,也可以提出自己的问题(想法),SAP最终会以Note的形式来回应。


如下图所示,是今天刚刚发布的一个Note,这个Note是对SAPMDG模块供应商删除功能的一个说明(Clarificationon Mark for Deletion of Supplier)。

Note还有一个重要的特点,很多Note是不断更新的,非常有生命力的。比如如下的Note18163信用管理的检查清单,最新版本是16,代表这个Note从发布后,被更新了15次。


对于Note的管理是一件非常重要的事情,也是一件不简单的事情,软件公司都会有很多个产品,每个产品都有很多个版本,只有通过一个好的机制,才能够保证产品在迭代,始终在进步,而不是有时在开倒车。


很多产品都有开倒车的经历,如果一个产品一代比一代好,那么迭代几十年,产品都不会差,比如小米手机如果能够一代比一代好,今天的小米可能也能占领手机的高端市场了。



特点7:即使有大量二次开发也能实现系统升级的机制

SAP系统支持一代又一代的升级,并且在升级的时候可以保留客户系统的二次开发以及历史的数据,因此SAP的客户理论上,即使在几十年前上线了SAP系统,可以逐步的迭代升级到最新的系统。这背后意味着很强的产品架构能力,这种架构能力给客户带来很大的价值,客户可以相信SAP系统可以长久使用几十年,同时通过升级的方式保证有机的生命力。


对于软件企业来说,自身的软件系统升级时,如何不覆盖掉客户的自定义的配置和二次开发,这是一个难点问题。


SAP通过各种方式,如配置的命名规则、以及在程序中预留增强,来确保用户自定义的配置和程序不会在升级时被覆盖,并且即使数据结构发生了变化,也可以带历史的数据升级。


本质上哪怕一个SAP系统有上万个二次开发(客开)都不会影响SAP系统的升级,你可以始终在SAP的船上,不会被迫下船,就像《海上钢琴师》一样,并且这艘船自身还在不停的升级,从蒸汽船变成电力的,再到智能的。




三、特别注意点

上文中的很多数字,(如几万个配置点/表)看上去比较夸张,这是因为SAP中大概有40个模块,减掉系统必须、一般都不会使用到的基础架构性质的内容,每个模块算下来不会超过1000个表,也不会超过1000个配置项,给用户操作的事务也不超过200个。


取决于客户的复杂性以及应用的深入情况,平均下来,项目中每个模块实际用到的是其中的20~30%,数量级一般是小于100个表、小于200个配置、小于50个给用户操作的事务。



四、小结

如上的特点让SAP可以同时在保持稳健的基础上做到高度的标准化、灵活性(定制化)。


特点1代表SAP对现实世界的的理解,体现了SAP的应用架构的高明之处,体现了抽象能力,这是应用架构层面的基础性工作。

特点2本质是通过配置(5万个)实现各种功能,且配置管理方便,这一点带来了标准化以及灵活性

特点3本质是预留了大量的标准配置供参考,提供了“最佳”的业务实践,这一点带来了管理软件最需要的最佳实践参考,也是标准化的一部分。

特点4内部有大概50万个函数,高度抽象、重用,这一点带来了标准化+灵活性

特点5本质是增强机制,预留了大量的增强(上万个),同时源代码开放,这一特点带来了基于标准化下的高度灵活性

特点6是Note体系,使得产品在持续迭代,使得产品有生命力,方便了SAP、咨询公司、以及客户,确保产品在持续进步


特点7是解决大型客户的忧虑,大型客户并不希望经常换系统,SAP通过良好的架构,使得企业即使有大量二次开发也能实现系统的持续升级

相关文章
|
Java API 数据库
基于 SOA 的组件化业务基础平台
原文:基于 SOA 的组件化业务基础平台 前言 业务基础平台是业务逻辑应用和基础架构平台之间的一个中间层,解决 “应用软件的业务描述和操作系统平台、软件基础架构平台之间的交互与管理问题”。
2000 0
|
11月前
|
算法
【系统架构】系统架构因何而来
【系统架构】系统架构因何而来
57 0
|
11月前
|
运维 安全 前端开发
聊聊SAP系统架构有多牛逼?(1)
聊聊SAP系统架构有多牛逼?
421 0
|
11月前
|
JavaScript API 项目管理
聊聊SAP系统架构有多牛逼?(2)
聊聊SAP系统架构有多牛逼?
183 1
|
开发框架 缓存 前端开发
SpringCloud微服务实战——搭建企业级开发框架(四十三):多租户可配置的电子邮件发送系统设计与实现
SpringBoot提供了基于JavaMail的starter,我们只要按照官方的说明配置邮件服务器信息,即可使我们的系统拥有发送电子邮件的功能。但是,在我们GitEgg开发框架的实际业务开发过程中,有两个问题需要解决:一个是SpringBoot邮箱服务器的配置是配置在配置文件中的,不支持灵活的界面配置。另外一个是我们的开发框架需要支持多租户,那么此时需要对SpringBoot提供的邮件发送功能进行扩展,以满足我们的需求。
381 1
SpringCloud微服务实战——搭建企业级开发框架(四十三):多租户可配置的电子邮件发送系统设计与实现
|
存储 机器学习/深度学习 缓存
Tinder 系统架构
Tinder 系统架构
650 0
Tinder 系统架构
|
开发框架 运维 Java
盘古开发框架,开发架构模式选型对比
「盘古开发框架」是完全独立于 Spring Cloud 生态的一套轻量灵活、成熟可靠的工业级分布式微服务开发和治理框架(兼容垂直单体分层架构)。它基于 Apache-2.0 协议开源发布,且是免费的。我们希望不仅是开源的受益者,也能成为开源的贡献者,与开源社区一起「共建共享开源生态」
543 1