Skip to Content

Unwrapping SuccessFactors’ Cloud Architecture – An unconventional treasure hunt

The recent announcementthat SAP planned to acquire SuccessFactors quickly gained tsunami–like speed in the Twittersphere – overwhelming any other enterprise software news on the otherwise quiet weekend.  Since the announcement, there have been a variety of blogs detailing the decision.  What has been largely absent from this discussion, however, is an analysis of the underlying technology stack that SuccessFactors currently uses and how this fits into SAP’s current and future cloud strategy.  

To be truthful, I find this absence intriguing.  As evidenced by the following quotes from the press release, one of the main reasons given by SAP to acquire SuccessFactors was its cloud-related experience and technology:

  • SuccessFactors’      cloud expertise and know how, rapid cloud innovation and proven success      running large scale cloud deployments will help SAP customers more rapidly      adopt cloud applications.
  • The      cloud is a core of SAP’s future growth, and the combination of      SuccessFactors’ leadership team and technology with SAP will create a      cloud powerhouse
  • “The      depth and experience that SAP brings to customers via our cloud and      on-premise portfolio fit elegantly with SuccessFactors’ world-class      expertise in providing high-performing, low-cost, native cloud      applications that customers are passionate about,” said Jim Hagemann      Snabe, Co-CEO, SAP.

Yet, any details about how this technology fits into SAP’s various OnDemand platforms are missing.   Since Christmas is rapid approaching, I had a flashback. I saw the SuccessFactors technical architecture as a wrapped gift that your parents tell you is awesome but to wait until Christmas day before unwrapping it. As a child, I was always curious – and sometimes suspicious – about the contents of that present.  Your parents were often right and the present blew you away.  In this blog, I’m going to rip off a corner of the colorful wrapping paper and take a peek at what is in the package.  

Note: This blog isn’t going to look at HCM-related aspects of the acquisition – there are other blogs (for example from Naomi Bloom) which have already done this. I’m also not going to compare SuccesFactors’ architecture with that of other Cloud vendors (Workday or SalesForce).

There is one official pagefrom SuccessFactors with a very high level description of the architecture which includes a few relevant paragraphs but otherwise there is no information publically available at the SuccessFactors site. This total lack of information is also fascinating – in a twitter conversation Dan McWeeney suggestedthat details on such SaaS architectures are often well-guarded secrets, because they can be the source of a company’s success.  Mildly irritated by the lack of information on the main SuccessFactors site, I decided to take a deep-dive and start researching via more unconventional means.

In comparison to the relative openness of SAP regarding developers (for example SCN) and the availability of many API descriptions (for example, the Enterprise Services Wiki, I found the total absence of such material at SuccessFactors’ site rather disconcerting.   

A Caveat:. In my attempts to understand the SuccessFactors technical architecture, I had to do some dumpster diving (for example, analyzing SuccessFactors job postings) and looked at past versions of the SuccessFactors site via the WayBackMachine. There is a classic taleof three blind men each touching different parts of the elephant and saying that the animal is something different. The clues I discovered in various corners and attics of the Internet reveal one picture of the SuccessFactors architecture. Without insider knowledge of the architecture, I’ll be one of those blind men trying to describe the whole elephant when I can only feel one part of the whole animal.  This approach means that much of this blog will be speculative in nature (such blogs are more fun to write anyway) and must be taken with a grain of salt.

This blog will focus on my analysis of the SuccessFactors technical architecture. A second blog will speculate on how this architecture fits with SAP’s existing and future cloud strategy

SuccessFactors’ Technical Architecture

SuccessFactors was founded in 2001 – it was one of the original players to offer cloud-based solutions for enterprise customers. It focuses on human capital management (HCM) solutions. SuccessFactors recently made various acquisitions (CubeTree, Inform, Plateau, etc), so there is some diversity in terms of the different technical architectures that are present in its product palette. The core suite is called the Business Execution (BizX) Suite and focuses on the three pillars of Business Execution excellence—Business Alignment, Team Execution and People Performance [SOURCE].

SuccessFactors has been in the cloud since the origins of the company – here is one description from 2001. offers an Application Service Provider (ASP) option, a flexible delivery solution to help you quickly and easily start using our applications. Instead of licensing and installing an application at your location, the ASP option lets you use an application that’s hosted on a remote server located in our secure data center. Designated users then easily access the application through a standard Internet browser.

The ASP option eliminates the hassle and cost of running an application at your location. installs, configures, builds and supports your application. You can easily license a subscription, run test pilots or extend the application throughout your organization. Plus, manages your application service completely, with an experienced, single point of contact for quick problem resolution.

The first time SuccessFactors mentions ‘OnDemand’ offerings was in 2005.

Via the wonders of the WayBackMachine, I discovered a page on the SuccessFactors site from 2009 that provides a detailed history of the technology used in SuccessFactors from the years 2001 – 2006. This page is very instructive and demonstrates the level of experience in ASP/OnDemand/Cloud technology in the company.  This page is currently not available on SuccessFactors’ site.

Note: I could only find material on the past and existing SuccessFactors architecture; I have no idea what or if the company is planning a new architecture based on its   acquisition by SAP.


The official version of the SuccessFactors architecture

If you look at the official SuccessFactors site, you will find one page(!) that describes the company’s cloud architecture.  The total lack of details might be disturbing but when I started to look at the site’s history via the WayBackMachine, I discovered that this current description has basically been unchanged since 2007. I found the first version of the page in 2007. The versionfrom December 13, 2007 is almost identical from the actual version–   same images, critical textual passages as well.

It could be that SuccessFactors has had so much business that updating the public architectural description never had the highest priority but as I kept reading this description and trying to understand what SAP had purchased, I kept hearing a whispering voice in the back of my head  – “Could it be that the SuccessFactors architecture hadn’t changed in 4 years?”  I giggled uncontrollably and then had a different thought – ‘Could that be the reason for its success? A stable cloud platform whose technical foundation hasn’t changed.  No sexy avant garde programming languages so often present in the consumer space. No experiments with NoSQL technologies”.

I decided that it would be useful to take a closer look at this architecture – to explore its characteristics.



As Vishal Sikka noted on the call last weekend, SuccessFactors is a Java-based platform.

This use of Java in the platform has been present since 1997/1998 when Java Applets and Java RMI were being used.    The platform later migrated to J2EE.  Java still plays a dominant role in the platform as demonstrated by recent SuccessFactors job listings (Lead UI Developer, Senior-Lead Java/J2EE engineer, and Release Manager). Here is how one recent job offering describes the SuccessFactors environment:  “Say goodbye to painful waterfall processes and boring outdated technologies and hello to Agile development and leading edge commercial and open source Java + J2EE technologies such as Seam, Hibernate, AJAX, Lucene, YUI, Flex to mention but a few.”  One of these recent offerings (February, 2011) describes the experience necessary for a Senior-Lead Java/J2EE engineer for a “a critical component of the SuccessFactors Enterprise SaaS product offering” :  

· 5 years of experience with enterprise programming in Java/J2EE, Enterprise Applications, OOD, Oracle

· Experience with Hibernate or other ORM technologies

· In-depth knowledge of Unix, Windows, JVM, web and application servers

· Expert knowledge of J2EE (EJB, Servlets, JSP, XML, JDBC, JMS) [SOURCE]

With the acquisition of other companies, such as CubeTree (now-called Jam), other languages have also entered SuccessFactors. A job offering for Jam shows that this application is based on Ruby on Rails-based.  



In 1999 SuccessFactors architecture moved to one of the first versions of WebLogic. In 2003-2005, the company transitioned to JBoss. There was a JBoss announcement from 2006 “JBoss Extends Certification to Software as a Service Applications” in which there is a quote from the SuccessFactors CTO:

“As a longtime JBoss partner that’s been supporting JEMS in our on-demand software infrastructure, we see the value in being ‘JBoss Certified,’” said Jeremy Bauer, CTO, Success Factors. “Our customers rely on Success Factors to provide high quality software as a service with continuous uptime and performance. Ensuring that our hosted applications conform to JBoss’ quality assurance standards is critical.”

The official history of the SuccessFactors architecture ended in 2006, so I was curious to see what had happened in the meantime. I found some requests for help on the JBoss forums from 2007.  In the one page that describes the actual architecture of SuccesFactors, there is still a mention of the use of JBOSS SEAM Web framework to deal with an abstraction layer for UI creation.  Of course, it might be possible that the JBOSS SEAM could be used without the JBOSS core but it isn’t likely.    I dug some more and found a recent message in the jRebel forum that appears to show that SuccessFactors is still using JBoss. If you look at the exception in the forum post, you will find some interesting clues:

2011-11-14 16:22:13,504 WARN [] Not resheduling failed loading task, adingTask@bf6ba9{classname: com.successfactors.platform.util.Messages, requestingThread: Thread[main,5,jboss], requestingClassLoader: or{ url=file:/home/xiaohan/workspace/jboss-eap-4.3/server/main/deploy/sfv4.ear/ ,addedOrder= 48}, loadedClass: nullnull, loadOrder: 2147483647, loadException: java.lang.ClassFormatError: Invalid constant pool index 64575 in class file com/successfactors/platform/util/Messages, threadTaskCount: 0, state: 1, #CCE: 1}

1560 java.lang.ClassFormatError: Invalid constant pool index 64575 in class file com/successfactors/platform/util/Messages

What is jboss-eap?  It refers to the ‘JBoss Enterprise Application Platform’ :

JBoss Enterprise Application Platform balances innovation with enterprise class stability by integrating the most popular clustered Java EE application server with next generation application frameworks. Built on open standards, JBoss Enterprise Application Platform integrates JBoss Application Server, with JBoss Hibernate, JBoss Seam, and other leading open source Java technologies from into a complete, simple enterprise solution for Java applications. [SOURCE]

Now I have no idea if this forum post refers to the core of the SuccessFactors OnDemand application, if the poster of the message even works for SuccessFactors or if this refers to another version of the application but this stack trace would fit the other descriptions mentioned in the job listings.

If you look at the technologies mentioned in the description of the JBOSS EAP (Hibernate, SEAM, etc), you will be also see some overlap with the requirements mentioned in the SuccessFactors’ job listings. 



In the high-level description of SuccessFactors architecture, there is a description of the usage of Oracle:

SuccessFactors utilizes a highly flexible mixed approach that allows for the best of each method of data manipulation and modeling. While all data is stored in a standard Oracle RDBMS, the table structure is highly simplified, and all the core entity data is self-described within the XML based Object Model.

There has been some discussion in the blogosphere wondering how long before HANA replaces Oracle at SuccessFactors but I’d take a look at how the SuccessFactors core accesses the database (via Hibernate??) before making any rash judgments.   I found the statement “the table structure is highly simplified” interesting and am reminded of the some of the HANA-related descriptions.

If you look at SuccessFactors history, you see that the early ASP model from 2001 was also based on Oracle.

What is also interesting here is that there is no use of MongoDB or Hadoop that is prevalent in so many start-ups in the consumer space.  The approach here is very traditional and is another indication of SuccessFactors solid foundation in the enterprise software arena rather than consumer space.  This also means that it is a better fit to the development heritage at SAP (strong Java focus, etc).



There is currently no indicator if SuccessFactors is performing their own hosting. If you look at past versions of SuccessFactors site, you find references to the use IBM data centers as early as 2004and as late as 2009.   In a presentationgiven in China last year, SuccessFactors VP Cloud Tom Fisher describes “Why do some Cloud providers use Amazon and other do not” (Slide 23) mentions cost and security as important considerations. Although I found no specific evidence, I assume that SuccesFactors prefers private cloud rather than public cloud hosting. 


Multi-tenancy / XML

Here is how SuccessFactors describes its multi-tenancy approach:

SuccessFactors selected a unique hybrid approach to its database architecture. While the core of the approach is multi-tenant with identical database table schemas for each customer, SuccessFactors leveraged the self-describing attributes of XML to abstract much of the unique customer data requirements into its Object Model. With this approach, SuccessFactors is able to retain all the advantages of a highly scalable and secure multi-tenant model with an identical schema at the database level; while still offering customers the ability to experience an application that is highly configurable.

The focus on XML is interesting and surfaces once again in discussions about the object model.

SuccessFactors utilizes a highly flexible mixed approach that allows for the best of each method of data manipulation and modeling. While all data is stored in a standard Oracle RDBMS, the table structure is highly simplified, and all the core entity data is self-described within the XML based Object Model. This approach allows for the flexibility in what may be perceived as traditional data model changes, but is in effect modifications at a level higher than the RDBMS in the technology architecture stack. Moreover, this approach allows SuccessFactors the potential future option of interfacing (offering and receiving) services across a SOA environment.

Based on the description of the company’s history, this use of XML to support multi-tenancy was started in 2002-2003 (Generation 4); thus, I can assume that SuccessFactors has had the opportunity to perfect its usage of this technology.


Other interesting discoveries 

  • Since there are a variety      of SuccessFactors partners, there are obviously APIs that are present but      after a two hour search I found no details that might provide any new      insights.  I found an old description of the SuccessCloud that provides some broad details on integration possibilitites but no technical details. 
  • If you look at the job      offerings from SuccessFactors, I never saw any mention of REST although      there was some indication of the use of Web Services. The only mention of      REST APIs was found in a job description     for JAM.     


As I said in the beginning of this blog, much of my analysis is based on speculation and could be totally incorrect. However, if my assumptions / descriptions are correct, it becomes apparent that SuccessFactors has a very mature architecture that it has perfected over the last 10 years.  I once described this architecture as unsexy especially in comparison to many start-ups (take a look at the description of Instagram’s architecture) but SuccessFactors now has over 8 million users and 3,000 companies, so its stability and maturity appears to be proven.

The technology used by SuccessFactors (JBoss, Java, Hibernate, SEAM, etc) could also be found in many enterprises today.

My next blog will describe how this technology stack maps to SAP’s current and future cloud architecture. 

You must be Logged on to comment or reply to a post.
  • A career in investigative journalism beckons 😉
    Some really interesting bits of information, great work in finding it and putting it together in a very readable format – Thanks!
  • did you mention the (high-performance) Hierarchical Data Algorithm? That’s probably an important IP to quickly access hierarchical data

    “In the 2001-2002 timeframe, the expanding SuccessFactors technology team implemented a hierarchical data structure called “L&R Trees”-a term coined by the SuccessFactors technologists-to provide security for the data and support high-performance data search and retrieval (quick traversal of hierarchical data).”

  • Hi Dick,

    A year down the road, have you managed to find out much more? I don’t think there has been any additional data publicly released to support your fascinating and, quite frankly, amazing investigation.

    Best regards,


    • I haven’t had time to return to my SuccessFactors archaeological digs.

      I doubt that they’ve changed anything. Right now, SAP and SuccessFactors are taking small steps regarding consolidation in more auxiliary areas (for example, social with Jam and Streamwork) rather than messing with the core technology.


      • My understanding is that the platform will eventually be unified and this does have a level of priority because of the introduction of SAP HANA Cloud Integration. However, I don’t think the unification will be ahead of priorities such as integration and making EC enterprise-standard in terms of functionality.

        • Have to say – this “eventually be unified” certainly is at odds with what I’ve heard. But then again, things change rapidly in the cloud world 🙂 .

          • I’m not sure there is a clear strategy, but for true integration from other platforms (e.g. HCI) then the platform needs to have some level of unification and integration. I heard this from a someone from SuccessFactors at SAPPHIRE Madrid, so things might have changed since you heard it or I heard it.

  • Luke’s comment, brought me back here, so I thought I’d write a little on what I’ve found out.

    From what I have heard, the architecture is quite heterogeneous – that is to say, not everything runs the same way, as different application purchased and merged from different developers go to making up the entire SuccessFactors stack. This isn’t one mega based on ABAP ERP like the SAP we know and love.

    Some see this as a disadvantage, whereas I’d put it the other way. Because of the XML data model that is the common way for data to be passed between the various SuccessFactor applications, the different apps can be optimised and buggered around with independently, rather than needing a whole of solution change. This means for example the analytics portion of SuccessFactors will likely get HANA first, and this can happen since it is running separately from the rest of the solution.

    Anyway, I have no solid quotable references to back any of this up, just what I’ve heard from chatting to people, and may be that I’ve misunderstood – so refer to it at your own risk 😉