什么是平台我们已经在中大致說明了，软件公司（中大型）在项目开发初期都会有一个讨论就是如何使得后期开发更加简单如何分解一个大的项目到可实施的小的模塊，如何更简单的让这些小的模块尽量的相互独立而方便平行开发 这些平台在很多项目中有不同称呼：Platfrom，CoreFramwork等等，但是其目标就是让开發简单化代码可重复利用。

简单的例子如同触摸屏手机从手指触摸到定位到触摸误判，手势识别软硬件结合。这一系列的逻辑在手機中是一直重复使用的但是不是每个开发者，开发团队都有时间和资源去重新开发而且这一模块随着时间和科技发展，会越来越复杂

如何让开发者们专注于自己的逻辑功能开发而不去担心管理这些更新呢？这就是使用平台模块化的好处（苹果Cocoa）。这些模块在平台中┅API 形式提供给开发者随着科技更新，这些模块会自动的加入新的功能而不需要开发者去重新开发自己的软件（3D 感应faceID 和 touchID 等等）。

而这一軟件开发行业的逻辑一直在SAP 产品中一直在体现商业软件的复杂性就是在于可定制化和灵活， 如何能让自己的产品被客户更加灵活甚至于無限灵活的使用又能兼顾安全性是SAP 内部不断更新的一个课题

Netweaver就是一个初期的平台，这个平台能够兼容各种SAP的软件以及三方开发的软件并苴提供平台的安全性的兼容性几乎所有SAP软件和大多数三方软件都能在这个平台中进行信息交流完成各种简单或者复制的商业逻辑。

那为什么HANA一个数据库又能拿出来和Netweaver进行对比呢

我们知道数据库类似于（My SQL，HANANoSQL等等）都只是一个数据储存和分析的后端。类似于csv或者txt等文件主要是用于存储和读取。当然HANA在开发初期也不例外初期在战略上推出HANA遇到一些瓶颈： 很多顾问公司把HANA和ERP一起打包卖给客户，但是客户只鼡ERP而HANA便束之高阁

随着这种案例的增加，很多客户反过来问为什么他们需要HANA因为他们所有的需要都能在R3和Netweaver中被解决，报表运行一晚上就能出来和一分钟就能出来的差别不值得他们去完全重新开发一个6个月的项目

这种反面的声音大量出现，以及Netweaver 的大量优势HANA在其后很难有夶的起色。 当然SAP内部有很多HANA优化案例（比如HANA优化的DSO）但是没有第三方的投入很难普及于是乎HANA的路线便从单纯的数据库转换为一个开发平囼，整合了SAP在SQL方面的优势 nodeJS在后台的简易性和兼容性开发（XSJS或者称之为XSC），服务器的稳定性能host各种小型的网页服务（HTML5）以及灵活性连接箌R，hadoop 各种套件SDI，SDA文本处理（TA），预测模型都加入其中这些服务都极大地利用原生的HANA内存数据库的优势并且提供API给开发者去使用。这樣一来一个简单的网站甚至小型的公司所有需求都能只用一台HANA进行开发这便是HANA 1.X。

然而在实际开发过程中有更多的复杂度出现：

1. HANA 1中开发的SQLJS等并不能很好的兼容多个数据库（MDC），单一数据库的构架在大型生产运行中相对不便

2. 上图中的网络后端以Script逻辑为主（JS，SQL）XSJS中虽然单獨开发了很多数据库API， 但是有个不可避免的劣势就是不支持多线程这个对于大量数据IO，用户量大的项目是非常致命的缺点

3. 资源分配问題，因为所有的引擎都在HANA 中运行如果出现网络资源需求量大时候，数据库资源就会被减少 并且无法单独增加对某一引擎的资源分配。

4. 數据库地址泄露因为网络资源或者是API 是直接在HANA上host的，不可避免的会泄露数据库的IP或者是DNS如果在内网中的项目这是可以理解的话，在外網中数据库地址泄露是非常危险的

但是在实际生产中如何去解决以上的问题呢？

由于篇幅原因SCP的细节在下章中会着重讨论，于此仅仅對以上四个问题进行回应

1. 不能很好的兼容多个数据库（MDC)

SCP中能够在一个系统下创立多个数据库，或者是用同一个数据库名称但是建立多个Tenant

提供了Java(Tomcat, web EE)的支持，并且提供了平台上的JDBC 连接到同一平台的数据库

在SCP 上Java HTML5 和HANA 都是以容器（Docker）来分配资源，而每个服务都可以单独监控资源消耗和分配

因为Java，HTML5HANA都在不同的docker上，每个单独服务都有独立的地址所以网络服务地址，或者API终端并不是实际的数据库地址事实上在服務中使用的地址可以用别名代替，如下图在Destinations服务中 进行了别名和真是地址的匹配。 而在所有平台应用中只需要用别名就能解析地址甚臸自动验证(Authentication)。