Shuffling two decks of cards: Scenarios for the Merged Cloud Architectures of SAP and SuccessFactors

[richard_hirsch]

In my Unwrapping SuccessFactors' Cloud Architecture –  An unconventional treasure hunt,  I examined SuccessFactors’ technical architecture. This time, I’d like to continue my explorations and look at how this architecture  corresponds with SAP’s current and future cloud strategy. 

Background

Currently, SAP’s cloud architecture is based on a division  between Core and Edge (These designations are probably going to change soon).

 

Let’s reduce this architecture to the building blocks that  are most relevant for our discussion and then start rearranging the blocks to  see what possibilities emerge. This simplification allows us to make general  statements about how the two platforms will work together in the future.

Note:  In this blog, I’m not going to  examine the SAP OnDemand offerings in detail. I’m more interested in high level  architectures. If you’d like to get details of these offerings, then I suggest  that you look at my previous blogs on the topic.

The Origin 

Breaking it down to a bare bones diagram, here is what we  have to start out with:

Notes for the diagram:

1. SAP’s OnDemand offerings are largely based on two separate  PaaSs.
2. Although many SuccessFactors applications share a common  heritage in Java / J2EE (for example Plateau  and SuccessFactors), there is really no PaaS in use.  It looks like JBoss is  the core of the environment but this is an Application Server not a PaaS. Before  someone comes back and says that Jam is Ruby on Rails-based, I assume that Jam is also running on  the JBOSS environment.
3. SAP’s Edge Platform / PaaS (Neo) is currently starting its  Public Beta, so the lines to StreamWork and Carbon Impact are dotted – meaning  that they are planned for the future.
4. ByDesign and the other ‘OnDemand’ applications that are  associated with the SAP Core PaaS are often called Line  Of Business (LoB) OnDemand applications.

Adding Cloud Foundry

Recently, SuccessFactors announced  an agreement with Cloud Foundry to allow partners and customers to create  custom applications:

The need to customize, extend and  integrate enterprise applications is a common one.  Doing this for SaaS  applications brings particular challenges, as those applications run remotely  and historically have been limited in terms of programmability.  By bringing  together Cloud Foundry’s robust runtime capabilities with SuccessFactors’  business processes and data, developers get the best of both worlds.

We have to change our diagram accordingly:

 

With this foundation in place, let’s examine what technical  scenarios are possible.

Reshuffle the cards: Cloud Foundry and SAP’s Edge Platform

I assume that in the mid-term SuccessFactors will work  closely with SAP’s Edge Platform team to allow SuccessFactors customers and  partners to use the functionality of the platform to create lightweight  applications based on SuccessFactors’ APIs.  Whether SuccessFactors will support both SAP’s Edge PaaS and the Cloud Foundry to meet this business requirement in  the future is unknown. 

 

Since the agreement with Cloud Foundry is recent (just 2  months ago), I’m sure that many SuccessFactors partners and SIs who were  planning to use Cloud Foundry are now revaluating their choices. For those who  are planning to develop or have already developed such SuccessFactors  applications, I’d enquire in the ability to port from Cloud Foundry to SAP’s  Edge Platform.

Reshuffle the cards: SAP’s Edge Platform and SuccessFactors

Based on the fact that SuccessFactors is Java-based, there  seems to be a perfect match between SAP’s cloud strategy and that of  SuccessFactors.

We have two applications platforms.  For the Core/Suite Application, BusinessByDesign-based applications. For the  Edge / the Java –based Platform as a Service, and SuccessFactors fits perfectly  into that.  So over time, we expect to stay perfectly loyal to this roadmap –  that we have articulated over the year and bring the power of SuccessFactors and  of Mobility and of HANA to every application from our customers whether it is  OnDemand or OnPremise.

-SAP CTO Vishal Sikka from the  SAP / SuccessFactors call on December 5, 2011 [SOURCE]

In a Twitter exchange with Zia Yusuf (Former EVP Global  Ecosystem & Partner Group SAP AG), Vishal associates SuccessFactors with the Edge category.

 

This statement is, however, a very general one. What exactly  are the architectural options that are available?

One idea would be that the SuccessFactors applications run on  the Edge Platform.

 

Initially, I was very excited by this option. If set in  motion, it would be a major boost to the importance of SAP’s new platform. But  after researching the technical architecture of SuccessFactors, I feel that this  option might be unrealistic.

I assume there are some internal investigations within SAP  examing the ability of porting JBoss applications to the Edge PaaS.  Inasmuch as  the majority of SuccessFactors applications are J2EE-based, a port to the Edge  PaaS should be possible. If the SuccessFactors applications were ported to the  SAP’s Edge PaaS, however,  then there would be a functional overlap between the  JBoss Enterprise Application Platform functionality (Hibernate, Caching,  Clustering, and High Availability, Integration and Messaging Services, etc) already used by SuccessFactors' applications and  that offered by SAP’s Edge Platform.  I can assume that SuccessFactors will be  reluctant to start replacing components in its successful unified platform just  to support SAP’s PaaS. 

Before its acquisition by SAP, SuccessFactors had the  agreement with Cloud Foundry.   There are a variety of similarities between  SAP’s Edge platform and Cloud Foundry. If SuccessFactors really was interested  in moving away from JBoss, then they would have started examining a port to  Cloud Foundry. I have yet to find any indication that this option is even being  considered. As the announcement with Cloud Foundry emphasizes, this cooperation  focuses on new lightweight extensions rather the core applications.

As I mentioned in my last blog, SAP plans to acquire  SuccessFactors for its success in the Cloud.

In fact, in the same conference  call, [Bill] McDermott underscored SuccessFactors’ unmatched ability to scale  across big numbers of users and indicated that the company has 5 times more  subscribed seats than any other cloud-based business-software competitor:

“Together, with SuccessFactors’  widely respected team and its deep experience in building and bringing to market  scalable cloud solutions, we see tremendous upside to create new business  opportunities,” McDermott said. [SOURCE]

This success is largely partially on the existing  architecture, the processes and associated experience that SuccessFactors has  built up over the last decade. This platform is based on a SaaS-model rather  than on PaaS. Why would SuccessFactors trade these material and immaterial  assets for a port to the new platform? 

A more likely scenario is that SAP Edge PaaS-based  applications and the JBoss-based SuccessFactors applications initially exist  side by side and are both branded as ‘Edge’ applications – apps that can run  Java-based environments.

 

For our analysis, there are two useful aspects when examining  the difference between Edge and Core characteristics as described in SAP’s cloud strategy: technology and application focus.   In terms of Edge referring to a Java-based environment, then  SuccessFactors apps are Edge apps. In terms of application focus, the  SuccessFactors applications are more Core applications. This LoB-associated focus is also apparent in  the the SAP press conference with analysts on Dec. 3:

In addition much of the cloud  market today is a line of business market. These solutions focus on targeted  functionalities and very specific business-users. While companies appreciate the  simplicity of focused cloud solutions, they increasingly require integration  with their core on premise applications. They realize that in a world of hybrid  solutions, they will get most value when they integrate on premise, cloud and  mobile.

That is where SAP comes in with the  acquisition of SuccessFactors. We will be the only company that can offer  end-to-end processes integrating world-class line of business cloud offerings  with the most respected on premise solutions available. [SOURCE]

Thus, you have discrepancies between SuccessFactors’  technical foundation, its application focus and how both fit into SAP’s  existing cloud strategy.

Reshuffle the cards: A new dealer sits at the table

While reading various blogs about the SAP SuccessFactors  deal, I read one paragraph that made me spill my coffee.

SAP is the company that has the  most intellectual property and the most applications for the last 40 years since  Hasso Plattner started this company. We can take all of that IP and put it on  our platform and we can compete in every market—and even more exciting, compete  in markets that never existed before! Create incredibly lightweight,  beautiful applications—more beautiful than the iPad—for all users, everywhere in  the world.

 -SuccessFactors CEO Lars Dalgaard [SOURCE]  [Emphasis is mine]

What exactly does Lars mean?  He is suggesting that SAP  process knowledge / experience (“that IP”) be moved to the  SuccessFactor’s platform. I interpret this as a new line of LineOfBusiness  applications that you might assume to be based on SAP’s Core PaaS but which will  be based on SuccessFactor’s SaaS platform.  There might also be a set of new  Edge applications based on this SuccessFactors platform.

We should also recall that Lars is going will lead SAP's cloud efforts as a member of the executive board [SOURCE], so his intentions aren’t to be ignored.

If this new type of application emerges, it will be curious to see if  they will be marketed under the SAP or the  SuccessFactors brand.  It will also be interesting to see if these new  applications threaten functional areas that are now currently covered by  Business ByDesign.  As ByDesign is a complete integrated suite, it  will definitely be a challenge for Lars to select those use cases currently  covered or planned in ByDesign that might be ideal for the SuccessFactors  platform.  A complete port of the entire ByDesign suite to the SuccessFactors  platform is a technical possibility (remember all that great IP) but is probably  not an option at this point due to the costs (in terms of time to market delays  and development resources) involved in such an endeavor.

Porting the existing LoB OnDemand applications  (SalesOnDemand, Sourcing  OnDemand, etc) might be an option. The tight integration of SalesOnDemand  with the existing SAP Core PaaS would make a port to the SuccessFactors  platform, however, a challenge.  I hoping that the features in these  applications that have emerged over the last year based on SAP’s co-innovation  with customers and design thinking won’t be lost in any future transition.

I see these changes occurring in the mid-term as the cloud  strategies of the two companies co-mingle and the synergies between the two  platforms are explored.

Conclusion

Long-term developments are more difficult to judge.   Obviously, some consolidation is necessary between the offerings / products of  the two companies.   Currently, SAP has a broader approach focusing beyond SaaS  to the creation of two PaaSs that enable the involvement of a wider circle of  developers dealing with a much greater variety of applications than that  currently faced by SuccessFactors. Although very successful with their focus on  single SaaS offerings, SuccessFactors has had the ability to concentrate on niche  products. It will be interesting to see how the involved technology, experience  and processes deal with the new broader scope.  Although Lars heads SAP’s Cloud  efforts and can rightfully brag about his successes in the marketplace, he would  be wise to consider the impact of his expanded mandate and listen to his new SAP  colleagues and their motivations and experience which are the foundation of  SAP’s PaaS platforms.