Converting my lessons learned from Sapphire into compelling future architectures
After attending the recent Sapphire in Orlando, I absorbed the information from the event (the keynotes, the meetings with executives, those thousands of tweets, blogs by analysts and bloggers and hallway conversations) and tried to figure out what it all meant. I wanted to do more than understand the messages that emerged from the event. I was more interested in the practical application of my lessons learned from the event.
The Sapphire is always a very optimistic / upbeat event (as demonstrated by the Late-Night Talk Show format of the second Keynote) which attempts to demonstrate that SAP is able to equip its customers with the tools necessary to respond to future developments in technology and society at large (as seen by the first keynote on Tuesday dealing with broader future trends). This year HANA was being pushed as the new panacea with various events showing the promise of the new technology (for example, the The complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in OrlandoThe complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in OrlandoThe complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in OrlandoThe complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in OrlandoThe complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in OrlandoThe complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in OrlandoThe complete series of SAP HANA InnoJam demos during SAPPHIRE NOW 2011 in Orlando), its customer relevance (the testimonials from a variety of companies in the third keynote) and the ability of SAP to deliver on this promise (the demo-pods showing live demos of the technology). Yet despite all this “positive energy”, there were a few sharp rocks which were visible underneath the smooth surface of the “Sapphire Kool-Aid”.
Although SAP largely steered clear of these obstacles, the challenges still exist and must now be confronted following the successful conclusion of the event.
Let’s take a closer look at two of these challenges and then I’ll suggest one possible solution to meet the resulting requirements.
Challenges
1. Dealing with the established base of largely OnPremise customers and their concerns
Of all the videos and content that emerged from the Sapphire Now, I found the video that Dennis Howlett and Jon Reed made with board members Otto Schell and Andreas Oczko of the DSAG (The German-speaking SAP User Group) the most revealing. Both representatives attempted to bring SAP back down to earth and described the essential issues of lowering TCO and increasing ROI on their existing OnPremise assets as the primary concern of these “legacy” customers.
The fundamental issue involves the conflict between the requirements associated with existing systems and the new innovations that SAP is proposing.
A recent report by Constellation Research principal analyst and CEO Ray Wang finds that many SAP customers are struggling to maintain their legacy systems while also dealing with the intense pressure from perceived IT innovation demands, he writes in the report: “The Market for SAP Optimization Options.”
…
Three areas, in particular, are causing customer angst, according to Wang’s survey research of more than 100 SAP customers: “Higher cost of ownership that reduces overall ROI; an aging and brittle infrastructure that hampers innovation; and increasing complexity that hampers greater adoption.” [SOURCE]
The idea of timeless software assures that no disruption should occur but some suggest that much of this anxiety reflects a feeling that innovations emerging from SAP at a rapid pace are not made with an awareness of the constraints with which many customers are confronted on a daily basis.
The technology gaps among where existing SAP customers are in their systems landscape and where SAP is headed is widening even more, and customers face difficult decisions as to strategic direction and budgets. Keeping current with SAP NetWeaver, Business Objects and other technologies could be an expensive proposition and as noted, SAP has now put on-demand HANA on the table for long-term consideration. [SOURCE].
This sentiment isn’t only present regarding HANA, the cure-all of new mobile applications is also questioned by some:
With a global business, the proverbial “sweet spot” for mobile applications was travel approvals, so Birnley had his team build out a mobile app for BlackBerry to speed up the approvals process. Then he ran the metrics on it.
“We were only getting 3-4% usage of these tools which we only used internal resources for,” he said. “I was expecting 30%. When you hear all the noise [about mobile applications], in my opinion [usage] is low.” [SOURCE]
It is not that business users are not interested in this technology (indeed Dennis Howlett commented that “the mobile part of the show was packed”); the main problem is that a detailed business case describing the actual TCO / ROI effects is often necessary for the use such new technologies.
Note: Based on my discussions with SAP reps on the show-floor (for example, those demoing the hot new product “SalesOnDemand), I’ve come to understand that the marketing of many of these new innovations is primarily for the existing customer base. Of course, BusinessByDesign also focuses on winning new customers in the SME market but the attention being paid to subsidiaries in this area is also focused on existing customers by demonstrating the integration possibilities involved with the ByDesign–based subsidiaries and their OnPremise headquarters.
Thus, you have a conflict between SAP’s marketing focus of its innovations – the existing customers – and the ability of these customers to really use these innovations.
In this blog, I’m going to going to concentrate on the ROI-related aspects of this challenge – especially, the ability of OnPremise customers to use their existing environments in a new innovative ways with a limited impact on the associated costs. If you think that my proposed solution includes NetWeaver Gateway – you are right – but Gateway by itself isn’t enough.
2. The need to increase the number of SAP users
Recently, SAP announced an ambitious goal 1 billion users by 2015 and the use of mobility-related innovations to achieve this goal.
“The pervasiveness of mobility and impact on consumers to businesses make it one of the most profound transformations in IT history, and it is a key driver for enabling SAP and Sybase to reach 1 billion people by 2015,” said Dr. Raj Nathan, executive vice president and chief marketing officer, Sybase. [SOURCE].
Of course, the key word in this quote is “reach”. The implication is that these 1 billon users won’t be SAP customers but, in all likelihood, will be the customers of SAP customers. The ability of SAP to meet this goal is largely based on the new innovations (In-memory, on-demand, on-device) that were promoted at the Sapphire.
The questioning by investors of the ability of SAP to meet the associated sales goals also reveals that there is some doubt as to whether these expectations are realistic and whether the existing strategy with its strong focus on HANA is correct.
SAP needs to be “more precise about what the different innovations will contribute in terms of sales and profit,” Hans- Martin Buhlmann, president of Vereinigung Institutionelle Privatanleger, a Cologne, Germany-based shareholder proxy group, said at today’s meeting, which is attended by 3,300 shareholders. “We want to know how much money we’ll make when, from these innovations.”
….
“Many investors believe SAP’s product portfolio has potential, but we want to see proof and we probably won’t see that for another two years, three years,” said Thilo Mueller, a portfolio manager at MB Fund Advisory GmbH in Limburg, Germany, who helps manage 120 million euros including SAP shares. “I haven’t yet had the big ‘Aha!’ moment with the new management.” [SOURCE]
Thus, the goal in itself isn’t being questioned but rather it is the ability of SAP to meet this goal. The problem is that there is no detailed description provided by SAP to show how these new innovations will meet the goal of 1 billion “reached users”. The vague depiction of the potential of Sybase technology (assumedly in the form of the Sybase Unwired Platform ) doesn’t satisfy investors demanding to “see proof”. It is not the fact these innovations do not yet exist that is the problem but rather that the details on how they will be used (and the associated timelines) that are absent.
My compelling future architecture
Note: The section header reminds me of the famous Monty Python skit (Anne Elk‘s Theory about Brontosauruses)
Caveat: My proposed solution obviously reflects my interests and my subjective experience at the Sapphire. There are a myriad of other solutions that are possible and some of which are now being certainly being discussed in the hallways and drawn on the whiteboards in Waldorf and Palo Alto and other locations around the globe. My intention is not to malign these other solutions.
I placed all my experiences from the Sapphire in a proverbial blender and then hit the Liquefy button. Every time a solution emerged from the blender, I looked at the result and tried to poke holes in it. A very specific idea emerged from this process and is based on my desire to meet the challenges mentioned above.
Note: A first attempt to describe this idea is present in the video I made with Jon Reed and Dennis Howlett on day after the SapphireNow conference
My architecture in one sentence:
Focus on customer-facing micro-applications – preferably mobile – that use data from OnPremise environments (either via Gateway or HANA in the Cloud) that are hosted on the OnDemand Edge PaaS environment.
Here is a very high-level diagram of this scenario.
This architecture isn’t dogma. The diagram above shows all the possible components involved. However, depending on the use cases involved, other related architectures are possible. For example, the following related architecture shows a scenario in which data from multiple companies are used to create applications.
My solution has a variety of moving parts which increases its complexity; furthermore, some parts are more important than others. I’m not assuming that the entire solution is possible right now (Indeed, I know that this is not possible based on the fact that some parts are currently not available) but I feel that only in its entirety with all parts working in tandem will it be able to demonstrate its full potential.
Some might say this idea is nothing new. Indeed, Jim Hagemann Snabe, SAP’s co-chief executive presented a similar idea which he discussed in a recent interview with FT.com.
That means companies can use mobile devices to reach out all the way out to consumers. So for example in retail, loyalty programes can be on the mobile phone and companies can optimise their advertising and trade promotions for the user.
In the banking industry, financial institutions can reach out to people who have no means of getting to a bricks-and-mortar bank and can use their mobile phone instead.
Suddenly you have all these scenarios where the consumer is the end user and companies can have a real-time link to and from the consumer.
If you look at my idea, you’ll notice that I’ve made Jim’s suggestion more concrete – adding more details about the type of application, sources of data and where it will be hosted.
A general description of the technology architecture involved was also drawn by Vishal Sikka and described in a blog by Dennis Howlett.
If you look at my solution in comparison to that presented by Vishal, there are some interesting differences. I’ve focused more on the “cloud” aspects of the solution and I’ve placed more emphasis on HANA in the Cloud rather than OnPremise uses of HANA.
I’d like to divide the following description into two parts – the “what” and the “how”. The first part will examine the particular market segment and the characteristics of the applications in question and the second part will examine how SAP should implement / support these applications.
Let’s examine each characteristic in detail and describe the particular experiences at Sapphire that led me to realize its importance.
Trait: “customer-facing“
Level of Importance: high
I’m interested in applications that will empower the existing SAP customer base to better help their customers. These users are consumers of the goods and services of SAP customers rather than being SAP customers directly. SAP customers should be provided the technology and methodologies to create more than just “business apps” or even “productivity apps” – I want SAP customers to be able to create applications that enable them to attract new customers and enhance the brand loyalty of existing customers. Based on the number of potential users, the target audience is much larger than that usually focused on by SAP’s marketing efforts.
If the SAP customer is a brewery, then I want to figure out better ways to interact with all those beer drinkers. It is also important to state that these users for these applications can still be “business users” rather than consumers. The same brewery should also be able to create applications that assist those selling their products – restaurants, grocery stores, etc. The diversity of SAP customers is enormous, so the characteristics of the users of these new applications will be just as diverse.
Every company knows that its customers and the relationship to its customers are its most valuable asset. The creation of applications to meet these requirements is nothing new. Extranets for customer usage have existed for years and provided customers with a variety of data – the proposed type of interaction is different from that provided by these older applications.
SAP’s customers include most of the Fortune 500 companies. In the past, SAP has focused on the internal landscapes / environments of these customers. Optimizing internal processes through standardization (for example, in the form of proven blueprints) or increasing efficiency (for example, through the speed enabled by HANA-based analysis). Improvements in internal processes have an indirect benefit on those customers of SAP customers through faster or more efficient service. Yet, the emergence of Social CRM and social media in general has shown that this interaction can be enhanced and direct interaction can bring even more benefits. New rules apply in the marketplace and SAP must adjust accordingly.
Many of my closest colleagues believe SAP is conflicted. On the one hand it has a track record of success for what it does that is second to none. On the other hand it is striving to remain relevant in a world dominated by Google, Facebook and Apple. SAP can learn from these players. [SOURCE]
If SAP is to evolve and change how the market views it, it must change its image and its relationship with its customers.
Lessons Learned from “Guten Appetit”
On Monday night at the Sapphire, the SAP HANA InnoJam finals took place and various applications were evaluated by a panel of judges. Of all the applications that were presented, one in particular caught my attention – this was the first application that was presented and enabled users with food allergies to examine merchandise – using bar-code technology- to see if the products could be eaten or not. The app had the following characteristics [SOURCE].
- Process the large and growing database of food ingredients and listing of allergens.
- Provide real time response of ingredient list in the desired format as per the consumer allergy-profile over the existing telecommunication infrastructure.
- Handle large number of concurrent users both consumers and the company that is maintaining and accessing the food database.
The screenshots from the application – which was created by a team largely made of SAP Service consultants (not developers!) – show that it is focused on the needs of end-users – not the typical business users associated with SAP technology.
I was intrigued by the technology, because it showed that its creators looked beyond the typical SAP focus on the enterprise market and thought about how HANA could have a wider societal impact than just providing BI data in record times to managers. As Kaj van de Loo, SVP of Technology Strategy said while judging this application, “You want to reach consumers at the point of decision-making”. This high degree of personalization is critical to assure brand loyalty.
Yet, this consumer focus doesn’t mean that the relationship to existing SAP customers and their needs is ignored. This application is perfect for SAP customers in the food industry who are trying to increase or maintain their market share. Such companies are now able to use the information usually locked in the ERP systems to benefit their consumers directly. The ability to provide coupons for the consumers via the app (just think of combining this functionality with the features described in recent announcement of the Google Wallet) also provides direct financial incentives for such companies to create such apps.
The idea of combining the food-related data with the personal health data of the end-user (taken from a user’s health provider) also shows that data from different industries / companies can be combined in innovative ways. The application shows the potential of data-based cooperation / collaboration that looks beyond the boundaries of the firewall.
The application is also an excellent example of design-thinking. Furthermore, it also demonstrates that the people-centric design philosophy that is often connected with the LoB OnDemand applications – such as SalesOnDemand – can also be applied to the broader consumer market with equal success.
Yet, as a comment on a blog written by Vinnie Mirchandani demonstrates, many still view SAP as being limited to the enterprise and are not ready to see the broader implications of this new technology.
Vinnie – Am surprised none of those top contesting applications are business related. With decades of experience in various verticals, SAP could have demonstrated much more stronger use cases/application of HANA rather than showcasing something like diet advisor kind of apps. I see a significant innovation deficit. [SOURCE]
It is critical to understand that I’m not only restricting my proposed architecture to potential consumers based on purely capitalistic motives. If we remember the ever increasing importance of CSR activities, many corporations are looking to support solutions that help the general public to deal with societal problems (such as clean water, hunger, nutrition, etc).
Trait: “micro-applications“
Level of Importance: medium
By micro-applications, I’m referring to small applications with limited functionality that is developed rapidly. These are the typical mini applications with which users familiar with iTunes, etc. see on a daily basis. Such applications are either free or cost very little.
Dennis Howlett makes one step in the right direction when he suggests using mobile applications – largely based on the Sybase technology – to create new applications for the existing SAP customer base.
I ran some ‘back of fag packet’ numbers that suggest even if SAP is 100% successful in selling the Sybase PaaS, the revenue it derives will pale into insignificance compared to operating the equivalent of an Apple AppStore. It would need to largely ditch its addiction to $1+ million deals in favor of business apps priced at $2-5 per user per month. Based upon another back of fag packet estimate of total user numbers in the SAP universe plus the number of SAP developed mobile apps I saw on the show floor, SAP could blow the on-premise model to pieces and still come out ahead.
Dennis’ figures show the financial relevance to SAP of creating micro-applications but for me, this step doesn’t go far enough. Dennis’ idea is restricted to apps created directly by SAP / Sybase and focused on internal users – I’m more interested in expanding the creators of such applications to SAP customers so that they can supply such apps to their customers.
For me, the limited functionality of such applications isn’t paramount – rather the speed of development is critical. SAP’s increasing use of agile development methodology that focuses on fast sprints and involving customers at an early stage shows that they also realize the importance of such new development paradigms
Once again, the experience of the InnoJam Finals in which many applications were developed in 30 hours represents a change in how “enterprise software” is developed. Blogger Vinnie Mirchandani describes the impact in this manner:
If small teams can build fairly ambitious HANA applications part-time in a matter of days, SAP’s and its partner’s project time scales need to be similarly compressed. if on-demand benchmarks are showing frequent upgrades and importantly instant propagation throughout the customer base, SAP cannot afford to have old-school and grudging multi-year customer base migrations at the core. [SOURCE]
Of course, this market may not relevant for the usual enterprise user – as demonstrated by a tweet from Sameer Patel.
The use cases relevant for these applications are different.
The challenge is identifying the use cases that fit such applications and responding rapidly to such opportunities. This is another sign that SAP customers must move closer to their customers to be able understand their needs and respond quickly to such changes. If you look at tools such as Radian 6 where social media in all its forms is tracked and analyzed in real-time, the economic potential of meeting such needs is increasing in importance. The challenge is being to create the applications that meet such needs rapidly.
Low costs are another important concern for such applications – mega development projects are no longer acceptable. Micro-applications usually have lower costs based on their limited scope. Of course, this does not mean that this limited scope might not have greater impact on the experiences of individual users. Once again, the stress is on design thinking and developing apps that reflect this philosophy.
Trait: Mobile
Level of Importance: high
How do you want to reach the intended market? Of course, browser-based applications are also possible but due to the increased number of mobile devices used by many end-users, mobile-based solutions appear to be optimal. What is also critical is to understand that we aren’t restricting the suggestion solutions to smartphones. Many of the markets in developing countries do not yet have the technical infrastructure to support such technology; thus, using other mobile technology (SMS, etc) should also be considered.
Lessons Learned from the SAPMentor Outreach App
A Proudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG OrlandoProudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG OrlandoProudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG OrlandoProudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG OrlandoProudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG OrlandoProudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG OrlandoProudly Presenting the SAP Mentors Outreach Mobile App for Android – Connect with SAP Mentors at SAPphireNOW/ASUG Orlando – the first version was an Android application- developed largely by Thorsten Franz, was finished shortly before the Sapphire started. The application allowed users to search for SAP Mentors via various criterion as well as display details about specific Mentors. The application’s data is stored in River – the new OnDemand Edge Development Environment and accessed via REST APIs.
Currently, other versions for the iPhone and iPad are being developed and will hopefully be available in time by the upcoming TechEds. [As a side note, much of the organizational work for these applications is being done in StreamWork].
Of interest to me in the context of this blog was the rapid speed with which this mobile application was created, its rapid acceptance by end-users and the ability to push the app rapidly to users via the Android Marketplace. The fact that it was a mobile app also made certain use cases possible (meeting a Mentor on the show floor and accessing his profile, etc) that would have been otherwise impossible to implement.
The role of the Sybase Unwired Platform
The purchase of Sybase with its Sybase Unwired Platform (SUP) was an attempt by Sap to meet the demands for such mobile applications. With the SUP, SAP has ability to let developers easily create mobile applications that run on a variety of mobile platforms. Approximately new 30 mobile applications were demonstrated at Sapphire – many of those based on SUP.
The various other components described in my architecture may provide all the necessary ingredients to fill an application with data but there is no component that can create a mobile user interface (UI). Ideally, this function would be provided by SUP. If SAP / Sybase make the use of SUP difficult or expensive (see SAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – FastSAP is Building its Mobile App Ecosystem – Fast for more details), then widespread usage of the SUP may be hampered.. SUP should be THE platform for developers who are creating mobile apps based on SAP data. In my opinion, SUP should be provided free of charge to interested developers. This must also been done to meet SAP’s goals (as seen in this tweet from fellow SAP Mentor Kevin Benedict) in this area:
Note: I often see the SUP being primarily associated with mobile applications for the enterprise – I’d like to see it also used for the broader consumer-market as well.
The SUP should also have a tight integration with the Edge PaaS platform and Gateway – such features should be available out-of-the-box without incurring additional costs. Remember the goal here is 1) to assist the OnPremise customers to increase the ROI of their existing applications by easily allowing their data to be turned into new applications and 2) to support the Edge PaaS.
Trait: data from OnPremise environments
Level of Importance: high
As expressed in the first part of this blog, we are interested in increasing the ROI of existing OnPremise customers. This requirement will be met by providing data from OnPremise environments for use cases that involve previously untapped user groups.
Of course, SAP must provide the tools that assure that this access occur safely to prevent unauthorized access to corporate data. Furthermore, it must be guaranteed that, if desired, that such access is monitored to assure that a corporation is remunerated accordingly for the use of its data.
Trait: HANA in the Cloud
Level of Importance: medium
As I mentioned above, it is critical to be able quickly create applications. However, the ability to rapidly develop apps isn’t enough; the data in those applications must also be displayed rapidly. In a marketplace full of applications, slow applications in which requests take a minute or so usually die rapidly.
Another one of more interesting aspects of the Sapphire was the idea of HANA in the Cloud which “will allow customers to upload data to the vendor’s own cloud setup for processing, rather than deploy related infrastructure in-house” [SOURCE].
HANA in general can rapidly analyze data, return results quickly and make certain types of analysis possible that were previously impossible due to the time / cost involved in calculation. Usually, HANA is seen as part of the internal infrastructure (see the architecture proposed by Vishal mentioned in the beginning of this blog) and can be used to quickly create reports for managers, etc. The various customer testimonials during Vishal’s keynote show the myriad internal use cases for which HANA is the optimal solution.
In the solution proposed above, however, a HANA installation behind the firewall isn’t going to help much. We need an environment that can be quickly set-up and which may only be used for a short time. For example, a sponsor of a sporting event (for example, the Wimbledon tennis tournament) that takes place for a few weeks can create an application using their data stored in the HANA in the Cloud and then remove the data after the event. Such actions are usually very difficult in terms of Corporate IT where the lead times for the ordering of such infrastructure-related decisions are unfortunately quite long.
HANA in the cloud is also interesting, because various SAP customers (for example, SMEs) that might not be able to afford the HANA technology in their own environments could still use it for various use cases. This offering enables such companies to take advantage of the advantages of OnDemand environments ( not just HANA in the Cloud) . Thus, TCO concerns are also dealt with such technology.
One SAP customer (Medidata) is already using HANA in the Cloud to support its customers.
Medidata, which makes a SaaS (software as a service) application to help run clinical trials, is thefirst partner to begin building on the HANA cloud, said president Glen de Vries, who appeared on stage with Sikka. HANA will give Medidata the ability to provide its customers with analytics on large volumes of clinical trials data in seconds, he said. [SOURCE]
Just because a corporation is using HANA in the Cloud to store its data doesn’t necessarily mean that the corporation in question must develop its own applications that use this data. It is now common knowledge that SAP is creating a new store for its OnDemand offerings. Usually, this store is seen as selling applications in a variety of forms for a variety of platforms. What if this store also offered data that was stored in HANA in the Cloud. (NOTE: This idea isn’t mine alone but emerged in my brainstorming with Heike van Geel and Hwee Lin Lee on the last day of the Sapphire). Corporations could sell their data to other application developers for a per-use or monthly fee. SAP would take a cut based on usage fees of HANA in the Cloud and a percentage of the charges associated with the store. There are already a number of government agencies (cities, etc) that would like to provide citizens with data (traffic, weather, pollution, etc) to promote open government. Using HANA in the Cloud to provide this data would make life easier for such entities and would allow them to concentrate on their core competencies. What would also be exciting about opening this data up to external developers is that new innovative use cases might be possible that hadn’t been considered by the companies providing the data.
Trait: Gateway
Level of Importance: high
HANA was the princess at Sapphire and all eyes were on her. There was another announcement that occurred at the event that was of equal importance. The revelation that Project Gateway would emerge from its cocoon and join the NetWeaver product line was intriguing and reinforced my feeling that SAP is seriously about resurrecting the NetWeaver brand . Gatewayhttp://www.sdn.sap.com/irj/sdn/gateway unlocks the information in OnPremise environments and provides it to external applications.
The SAP NetWeaver Gateway is a set of ABAP add-ons to your existing SAP ERP system that provides easy access to your business information in a simple, people-centric manner and lowers the data consumption barrier to the point that no prior knowledge of an SAP system’s internal workings is required. [SOURCE].
One of the challenges that I mentioned above was the ROI-related concerns of existing OnPremise customers. Gateway (and NetWeaver Live) both deal with this issue by allowing such customers to easily participate in SAP innovations. For our architecture in question, Gateway focuses on providing easy access to data that exists in the back-ends of SAP customers.
However, the architecture of the Gateway Server isn’t really enough to provide the platform that is necessary in a PaaS environment and to meet the demands involved to supply all those potential customers. The following picture below shows Gateway’s architecture:
[SOURCE]
In the last section, I mentioned HANA in the Cloud – a question may now arise: If we have HANA available in an OnDemand model, why do we need Gateway?” In my opinion, the use cases are different. HANA is only really appropriate when you have a critical mass of data (usually this is read-only access). Gateway, however, has a different focus – it provides access to the processes that are usually present in the BusinessSuite but were only accessible in the past via SAP-proprietary interfaces. Such access could also provide write-access to data as well Previously, I Quick thoughts on on-demand and on-premise environments and their innovative potentialQuick thoughts on on-demand and on-premise environments and their innovative potentialabout the Treasure Chest of process information that SAP must open up – Gateway now allows this to happen. Indeed, it is very easy to think of applications that could combine the functionality of HANA in the Cloud with that of Gateway.
Trait: OnDemand Edge PaaS
Level of Importance: high
Note: Alternative section title: Thinking about River on the Lazy River – I started thinking about the various parts of my architecture the morning after the Sapphire while I was swimming in the Lazy River at the Hilton. I started with River – a new Development platform that will be part of SAP’s future Edge PaaS – and then I begin filling in the other pieces of the puzzle.
Without focusing on any particular PaaS environment, what are the typical characteristics of such environments [SOURCE]:
- Services to develop, test, deploy, host and maintain applications in the same integrated development environment
- Web based user interface creation tools
- Multi-tenant architecture
- Integration with web services and databases
- Support for development team collaboration
- Utility-grade instrumentation
A PaaS allows developers to rapidly create applications by providing basic functionality out of the box. Developers no longer have to deal with such things such as persistence or user management. The advantage is that such environments allow devs to create applications quickly. For our architecture, a PaaS enables applications developed and deployed quickly and made easily available to end-users.
OK – now some may be thinking, why do I even need a PaaS? Gateway and HANA in the Cloud should be enough to create applications. Or perhaps, SUP in combination with Gateway might be enough as well. In terms of Gateway, the architecture is such that the appliance resides behind the firewall – and may not be able to adjust to changes in load quickly. Gateway and HANA in the Cloud only provide data – they aren’t designed to host applications. Furthermore, other necessary components such as billing, monitoring, links to SAP’s app stores are also missing. Gateway might be perfect for some scenarios in which a restricted set of internal business users are accessing a limited set of backend data but use cases in which the number of potential users can only be determined with difficulty, it might not be ideal.
SAP’s OnDemand PaaS offering is broken down into two parts – Edge and Core. Why can’t we just use the Core PaaS? If it is good enough for Business ByDesign and the other LoB OnDemand apps, we can use it as well? The Core PaaS is largely associated with internal customers (in other words, SAP’s direct customers) and, if you look at ByDesign – an association with processes dominates such applications based on this environment. OK – the LoB OnDemand applications with their people-centric focus demonstrate that the technology involved in the Core PaaS don’t have to be process-centric. The Edge PaaS was designed for lightweight / collaboration applications and thus, the micro-applications that we’d like to build are better built and hosted in this environment.
I’d be curious to know of any restrictions that will be placed on applications in either the Core or Edge PaaS environments. Currently, only applications created by SAP are running in these environments. Yes, partners are creating add-ons for Business ByDesign but such developments are restricted by the development model imposed by the ByDesign SDK and the configuration possibilities inherent in the platform. I’m assuming that there will be fewer restrictions placed on those applications in the Edge PaaS environment.
There are a variety of PaaS environments (Force.Com, CloudBees, CloudFoundry, etc) that are currently in the marketplace or which are currently in Beta. Why should the developers using our architecture even use the SAP PaaS environments? The main advantages of such environments must be the tight integration with other SAP offerings – especially regarding the interaction with existing / OnPremise customers. StreamWork has done a good job in this area with its tight integration with CRM and other BusinessSuite products. Its efforts should be emulated.
Once NetWeaver Gateway is in GA, I could integrate it into applications hosted on SalesForce using the new APIs. Such integrations must be easier in SAP’s OnDemand PaaSs to provide these environments with a competitive advantage versus other platforms where this functionality is not standard and often require partner solutions.
Conclusion
What initially fascinated me about the GutenAppetit application was the use case. It got me thinking and broadened my horizons to look beyond my typical focus on the business side of enterprise software. I started thinking about other types of apps that were based on this innovative technology but were targeted at new groups of users.
This blog has primarily focused on a new architecture. However, without the innovative use cases that apply this technology, the architecture is largely irrelevant.
Recently, I’ve been working with other SCN “activists” to bring more design thinking and diversity into the SAP ecosystem / community. I’m participating, because I’m curious in learning about these new use cases and the involved methodologies.
Hopefully, we will be to combine these new methodologies and SAP’s technological innovations at upcoming events (TechEds, InnoJams, etc). So, if you are ready to join us in this new adventure, I guess I see you there.
Disclaimer: SAP paid my T&E for the conference.
What does DSS mean?
D.
D.
It was fun to write - it just took a while - it was like a short story - once you get the whole plot figured out you can't leave anything out.
D.
I love the fact that you challenge the opinions and reviews of other of my favorite movers, shakers and analysts and was intrigued that you choose to rebut some of the conclusions other smart minds have come to. Triggers even more thinking and review on the part of readers such as myself.
Thanks for raising the invitation to join the community in "Design Thinking".
There will definately be opportunities before the series of SAP TechEds to participate in Webinars, community virtual meetups, streamwork activities. And changing and challenging the ERP/Enterprise focus will be indeed refreshing. I'm looking forward to seeing the mini apps highlighted and their merits discussed/debated. Those interested please begin to raise your hands to join us in this exploration.
D.
Great blog. Full points!
I believe your statement that, the suggested high level architecture is just one of the options, is important to keep in mind. With HANA being marketed as the next big thing, it is becoming even more important to rationalize decisions to use it. As they say, when you have a hammer in your hand, everything looks like a nail 🙂
From the discussions we have had with customers, they want to throw HANA at about everything without actually understanding the product positioning and value. Also, they overlook the architectural implications of a particular approach. For example, while your proposed architecture could be augmented by Orchestration layer to deliver end to end integration between PaaS, HANAC(HANA in the Cloud) and OP applications, the implications of this approach are that organizations need to move massive amounts of data from OP systems to the cloud to use HANA functionality. This is similar to BIOD from SAP which offers BI toolset in the cloud. With an explosion of data volumes, compliance requirements, and increased security threats, the pros vs cons have to be weighed carefully.
I find your proposed architecture to be quite relevant to organizations using ByD as their core ERP platform. In this case, I'd like to see HANA as part of the PaaS offering from SAP to enable customers to use native HANA features while running apps in the cloud. Data from other systems can then be pulled into HANAC for reporting and analysis purposes.
However, organizations with significantly large OP systems should consider HANAP (HANA on Premise) and consider SaaS apps like SFDC or ByD as one of the sources of data. Even then, it is important to understand the actual business requirement for data integration vs. data federation. Do you really need to move data from source into HANA or can you live with a snapshot of this data?
The arhcitectural complexity of SAP landscapes is ever increasing due to the technology choices we have today to deliver business functionality. What I find missing from SAP as a technology vendor are the following:
1. Reference Architecture (product agnostic),
2. Architecture Patterns,
3. Solution Blueprints utilising 1 and 2 above
4. Governance Approaches
As technology offerings mature and portfolio enriches further, SAP needs to take a step forward and help customers/partners turn experiences into insight. In-memory is not a new thing for SAP or for the rest of the industry. So it would be good to see architectural best practice guidelines from SAP across the complete technology portfolio of on-premise, on-demand, on-device, and in-memory products.
Regards,
Shehryar
You're right. The GA of HANA is just the first step in a successful penetration of the marketplace. Of more importance is guidance from SAP regarding which use cases are appropriate for its usage. In some cases, HANA On Premise may be more appropriate than the HANA AppCloud. The challenge for SAP and the SAP ecosystem will be the discovery of such rules and their efficient and rapid dissemination to SAP customers.
D.
Congratulations on this well-written post.
Re point 1: The day-to-day clients I'm dealing with are PRECISELY facing those problems. All of them long-standing OnPrem customers.
Amidst all this innovation they are feeling left behind, like moving ahead slowly within a cloud of dust whilst the sports cars have pulled away. Caught in a mix of cost pressures/ROI on one side and pressure to come up with "new stuff" on the other, they want help with their current issues.
I've heard a lot about comparing Apple and SAP recently, which to my mind is not apt for one single reason: Apple understands better where they have to pick up their existing customers.
"no one wants to hear about ERP" - A quote from a recent conversation. From where I stand, I can't help but disagree.
I think we often forget that one definition of "legacy" refers to "a gift by will especially of money or other personal property" and has positive rather than the negative connotations associated with the use of "legacy" in IT circles. The presence of OnPremise SAP customers is reality. Period. The main question is whether we (and the SAP ecosystem) view these customers as an opportunity or a threat.
D.
Thanks for sharing your insights. While you make a great case for PaaS, its really about how to build vertical specific "data stores" at internet scale and then have micro apps on top. While shipping "industry standard biusiness processes" is challenging enough having a PaaS with multi-tenant vertical data is where industry seems to be heading with social CRM leading the way.