May 17, 2010 by Dieter Steiger
SAP Marketing has a long tradition of always using the latest buzzwords. SAP Cloud Computing is “the next big thing.” That’s why SAP is talking about cloud computing. Making SAP available as a cloud-based product means offering all SAP functions via Web browser. But there’s more to it. If individual users want to access SAP functionality in the cloud – data management and parameterization of systems and SAP Business Processes for individual customers must first be completed. This is easier said than done by SAP in my opinion. But why? Other packaged software producers have long been offering such cloud-based products. In order to answer the question, it is helpful to understand how SAP is technically constructed. SAP is software that has undergone numerous, sometimes dramatic phases of evolution to become what we loosely call “SAP” today. A brief introduction to SAP R/3 software architecture provides deeper insight.
1. Software package: Four IBM software specialists launch SAP with one of the first mainframe-based transactional models. SAP R/2 is born. Initially, with modules for accounting only, followed by modules created using the SAP-developed programming language ABAP for new areas such as logistics.
2. Client server: The client server wave spills over to SAP. SAP first ports R/2 to IBM AS/400. But the system never runs adequately. In a rapid second attempt, porting to HP Unix is successful. The result is the ABAP-based client server application SAP R/3, which in contrast to R/2, provides a graphical user interface. As with R/2, subsequent new business functionalities are developed, and additional releases appear up to SAP R/3- Release 3.0. SAP R/3 now consists of numerous modules that can be summed up as accounting, logistics, and human resources.
3. Redundant systems: With SAP R/3 Rel. 3.0, SAP managed to become the market trendsetter. The term ERP becomes a virtual synonym for SAP R/3. Through growth and large-scale implementation as well as immense scalability requirements, challenges to basic technology and business functionality increase. In order to satisfy growing expectations, SAP ALE (Application Link Enabling) is launched. As one of the first packaged softwares, SAP institutionalizes the concept of controlled redundancies in a software suite.
4. Internet: Internet euphoria is rampant, and SAP has a technological answer to the trend: SAP R/3 Rel. 3.1 with SAP ITS (Internet Transaction Server). SAP ITS is in a position to convert the SAP-internal SAP GUI log into HTTP and vise versa. This allows a direct jump from simple HTML pages into the SAP R/3 business application.
5. SAP component architecture: In order to integrate new, popular applications into the platform, SAP attempts to separate the strong SAP basis kernel from the SAP application kernel. A similar separation is completed at the application level. The entire HR module is decoupled in terms of ABAP from the remaining primary accounting and logistics modules. As of this point in time, communication between applications is based only on SAP ALE.
The separation of the SAP basis also forms the foundation for additional business functionality that is no longer classified solely as enterprise resource planning: SAP BW (Business-Warehouse) and SAP CRM (Customer Relationship Management). SAP is now still based on ABAP but consists of various ABAP application components – ABAP heterogeneous!
6. Single sign-on: SAP quickly recognizes that as a consequence of ABAP heterogeneity, logging on users with different systems must now be eliminated. With SAP R/3 – Release 4.5, SAP launches an ABAP-based workplace. This makes a single sign-on based on SAP GUI possible, which controls jumps to the various ABAP production systems.
7. SAP Portal: The entire market is talking about portals, and with its ABAP-based Portal Workplace, SAP can absolutely not satisfy the demands of modern portals.
SAP therefore buys Top-Tier, which at the time had already developed an interface based on the SAP HTML-GUI. With this acquisition, SAP takes over a non-ABAP-based technology for the first time. SAP Java and ABAP enter into a landmark relationship.
8. SAP Application Server: Now with the technological Java/ABAP heterogeneity of components, SAP launches the marketing construct SAP NetWeaver with the goal of using each of these very different technologies through a shared platform. SAP NetWeaver incorporates the following seven purchasable product suites:
• SAP NetWeaver Application Server ABAP – ABAP-based business systems are stacked and made available here.
• SAP NetWeaver Application Server Java – Java-based systems are stacked and made available here.
• SAP NetWeaver BI (business intelligence – previously BW)
• SAP NetWeaver PI (process execution, initially called XI)
• SAP NetWeaver Portal
• SAP NetWeaver MDM (master data management)
• SAP NetWeaver Mobile
9. Service-oriented architecture: SAP Marketing then jumps onto the next largest IT architecture wave after client/server: service-oriented architecture (SOA). The company SAP ESOA, now known as SAP SOA, is launched. Among other things, this allegedly allows SAP to fulfill conditions for offering cloud computing products.
Data management for business processes
This evolution of SAP provides an impression of the complexity and extensive nature of an SAP system built from components. With SAP Enterprise installations in which the entire SAP Business Suite is deployed, an SAP system with an architecture that includes a number of production systems with databases in the upper double-digit range quickly came into being – for historical reasons and due to customer requirements – but still without upstream development, testing, staging, prototype, and training systems. This SAP complexity can be very difficult for a customer to manage. And now the next marketing wave – SAP Cloud Computing. Such a system is to be built to meet the on-demand requirements of individual users? On demand in the cloud for users from hundreds of different customers with differing requirements in terms of system alignment?
With the knowledge of previous history and SAP software architecture, SAP Business by Design is based on a logical, unique SAP installation for each customer. How does SAP intend to manage the individuality of each of these unique installation systems, not to mention understand what this means for individual systems with a reasonable amount of complexity? Lifecycle Management in the cloud and beyond is a challenge that is too immense.
Through the illustration of the SAP evolution model, one can conclude what this means for SAP to provide the SAP business functionality of an SAP backend module within a browser that is based on user-specific roles. This is why SAP is expanding its R/3 client/server world to include additional architecture levels as support for this Internet technology. SAP must now enhance infrastructure areas with additional and more productive server levels, which will cause the complexity of the system and maintenance to increase even further.
SAP functionality including data in the cloud
Thanks to the latest SAP phase of technological evolution, namely SAP SOA, SAP business functions are available on the Web – but with an SAP standard with only a single-digit percentage of SAP functionality. It is noteworthy that SAP Web functionality often does not correspond 1:1 with installed SAP functionality at the customer. SAP is running on two tracks simultaneously: one for the long-established ABAP users and one for the new “Java freaks.” And they are not yet running in sync.
SAP cloud computing – conclusion
Can business functionality based on a 20-year-old concept and the associated system environment handle the demands of modern cloud computing as described in the first paragraph? From my perspective, cloud computing-supported virtualization, scalability of the system world and data management for transactional processing of extensive business data (which is based on individual settings) are unrealistic and not feasible, at least not if we want to remain within a reasonable degree of complexity. SAP is attempting once again to ride a marketing wave from the outset – to “fly along in the cloud.” Could this cloud build up to dangerous storms for SAP?
Previously, SAP ensured that changes to its own code were under control and that is was providing support to customers with software upgrades. With SAP as a cloud computing product, this has come to an end. Now SAP must stack unique customer environments and maintain them throughout the lifecycle – and not only SAP code, also the entire configuration and all systems. Tools such as SAP Solution Manager are not created for this comprehensive SAP change management task and are only of limited use. Problems previously left for the customer to resolve are becoming a challenge for SAP itself.
Is this the reason why the SAP cloud product Business by Design is making only sluggish progress? In any case, a quick increase in the number of Business by Design users without corresponding, effective, customized SAP customer provisioning and an SAP Lifecycle Management solution would be fatal for SAP.
In principle, this is not a problem for SAP Business by Design customers, as long as the SAP cloud product is priced right and is technically sound. But is SAP really in a position – beyond marketing messages – to deliver such a product at an affordable price? It’s up to SAP to prove this. If unsuccessful, either SAP or SAP Cloud Computing users could pay dearly for the attempt.
Sphere: Related Content
SAP Template – basic rules for successful rollout
