上一篇「随着时代进步,SAP系统愈加聪明了」里，我们说到了SAP在技术上的创新，例如把机器学习算法嵌入到大家都熟悉的业务流程里面去，让原本工具化的SAP S/4变得智能。
可这样就是SAP所构想的「智慧企业」的全部了吗？
不，这才刚刚开始。
SAP宇宙
像我一样喜欢电影的人说不定对「漫威宇宙」的概念很熟悉。漫威从2008年的《钢铁侠》开始，一步步打造起了自己的漫威电影宇宙。许许多多的超级英雄聚集在一起，对抗宇宙中的黑暗势力。灭霸的那一个响指，你肯定还记忆犹新。
在我看来，SAP作为一个企业软件公司，其实也在做着类似的事情，那就是打造「SAP宇宙」。
我们或许可以把SAP S/4HANA类比为钢铁侠，C/4HANA类比为美国队长，Ariba类比为黑寡妇[手动狗头图片]。但就像电影里最吸引人的永远是包含了很多英雄的《复仇者联盟》一样，SAP也在着力把它的拳头产品都集中到一起来，协同发力。
要想实现这一切，首先要解决的，就是不同SAP产品之间的「集成性」。
集成，是一门艺术
集成，说白了就是不同软件之间能互相通信，交换数据，这可不是什么新话题。
SAP里相关的接口技术和概念非常多：RFC，IDoc，ALE，EDI，Web Service，XI，PI，PO，Gateway，OData，包括SAP产品云端化之后着重推的API Hub。
这些技术都是用来解决不同企业软件之间的对话问题。如果着眼点只在彼此对话的两个软件之间，没问题，很有效。
可很明显，SAP的眼光不止于此。
让我们想一下，在HR领域，或者说在Recruit to Retire这个大流程里，SAP能提供的解决方案包括SF，S/4，Fieldglass，Concur，Identity Management等等。虽然它们的侧重点各不相同，但却需要能彼此集成。
用传统的接口开发方式是否可行？可以，但不够有效率，也不够优雅。因为传统方式都是点对点的，是解决双方之间的具体问题的。
可现在的SAP软件太...多...了。
就像当年秦始皇统一六国后，搞的「书同文，车同轨」一样，在SAP宇宙里，建立标准变得非常重要。
依旧是刚刚HR领域的例子，每个解决方案里肯定都有「员工」的概念，那怎么确保在SF，S/4，Fieldglass，Concur这一堆不同的SAP产品之间，能保持员工主数据结构上的一致性？
答案并不难想——搞一个抽象出来的API层，在上面去定义跨不同SAP产品的主数据和业务数据规范。
还继续说员工主数据，在SAP宇宙里，可以给员工一个通用的主数据定义，也就是员工数据应该有多少个参数，每个参数的含义是什么。这个定义，是跨产品的，跟具体的SAP软件无关。
例如S/4里员工主数据的具体字段，跟SF里可能并不一致，但只要S/4跟SF交换数据时，它们就可以使用这套通用的员工主数据定义，就能确保沟通无碍。
这就像在中国，各省人民都有方言，词汇发音等等都不尽相同，但只要跨地域交流时大家能都说普通话，问题就迎刃而解了。
SAP就是要定义一套这样的普通话，还给它起了个名字，叫ODM（One Domain Model）。而ODM也会是SAP云平台的一部分。
SAP One Domain Model
我实在不知道怎么翻译One Domain Model，所以就暂时以缩写ODM来指代了。
刚刚说了，ODM就是SAP宇宙里的普通话。有了ODM，才能把各种SAP软件真正集成到一起，上演「复仇者联盟」。
当然，ODM这个概念面世的时间不长，很多具体的内容还不完全明确。现在能知道的就是SAP是使用CDS（Core Data Services）格式来定义各种业务对象的，这里说的业务对象就是类似员工这样跨SAP产品的数据。
CDS本身已经是一种广泛应用于SAP各种产品的技术了，包括SAP HANA，SAP S/4HANA Cloud，ABAP RESTful Application Programming Model（RAP）和SAP Cloud Application Model（CAP）都用CDS来描述数据模型。
想想现在SAP宇宙里有多少产品？S/4，C/4，SF，Ariba，Concur，还有其他各种云。
再想想有多少个业务对象可以被通用化？员工，客户，订单，成本中心，产品...太多了。
这是个野心勃勃的计划，建立一套通用语言可不是一件小事。为此，SAP建立了一个叫SAP Graph的网站，逐渐开始提供一些API，其中就包括我们前面说的员工、产品、成本中心等等。
下图这个例子，就是产品这个业务对象，是如何用CDS来定义的。
当然，ODM也不仅仅能用在SAP系统之间的集成上，只要遵守这套规范，它也可以用于跟第三方产品的「沟通」中。
小结
智慧企业，一手是创新，一手是集成。创新有AI，集成有ODM。
当然，还是那句话，一切才刚刚开始……SAP宇宙的大幕，才将将掀起一角……
