A Brief History Of Salesforce1

(note: this is a similar format to my brief history of SCRM, which was widely successful at the time to explain how SCRM came to be.  This is in no way related to Stephen Hawkins’ masterpiece – but you likely already knew that. my official disclaimer of conflict of interests and such is at the bottom of this post)

I let some time go by after DreamForce 2013 so I could cool off from the heated discussions I had with plenty of people.

If I hear one more person tell me that Salesforce1 (S1) is a client-side app, a mobile client, the culmination of Touch (remember that launch? Not many do) or something similar I will scream (like I did the past few days).  And the problem is that Salesforce.com (SFDC) has such a loyal customer and fan base that they will repeat pretty much what they are told (as well as some of the “influencers” and “analysts” out there – unfortunately analysis is no longer a required activity for analysts).  This dichotomy between what it is and what was presented at the show culminated (at least for me) in an exchange between Marc Benioff and myself on Twitter on Thanksgiving Day (Zachary Jeans did a good job of converting it to a Storify stream; you can find it here if you are interested).

That exchange prompted me to write this, I had only been talking to people about it prior, as a way to preempt the question of what is S1 and why there is so much confusion.

You see, there is so much to what S1 is that is not being covered that it is almost an insult to the people that spent 3-5+ years working on getting it done.  To make justice to the journey, and explain it in more detail that you probably have seen, a little history is in order.

(another note: I have down at the bottom a few other articles I considered worth including here that explain it quite well without the long-winded story, feel free to skip it and read those)

The History

SFDC launched in 1999.  At the beginning their call to fame was “No Software” (still hanging around today, ask TooSaasy) back in the days before we had cloud or SaaS.  In those days the rage was Hosted Applications (also known back then as ASP – which was Microsoft’s version, remember Microsoft? It was pretty big back then).

To put it into perspective, this was about the same time Siebel was dominating the “CRM” (read sales force automation mostly with very bad versions of marketing and passable versions of customer service) market; by promising no software to be downloaded (and very low prices to boot) SFDC was able to take a nice piece of the market from Siebel.

Now, keep in mind this was not a cloud application, this was a hosted application.  That means there was a monolithic architecture (mono=single, lithus=stone – meaning an all-in-one comprehensive solution) that run using browsers as interfaces.  To make this happen, things like multi-tenancy (many users running the same application) and multi-instances (many copies of the exact same application) were necessary.  I already covered why multi-tenancy is a horrible idea for real cloud applications (please read it, extend it to multi-instances as well – applies later in the story).

Bottom line: back then this was all we had.  Other vendors like RightNow Technologies, E.piphany, and many others were doing the same: hosted applications that provided a browser interface to monolithic solutions running in the background.

The problem with monolithic architectures is that is a client-server solution through-and-through and it cannot leverage the basic principles of distributed computing well (which is the basis for cloud computing as well as know).  Thus, running monolithic solutions (even via browsers for interfaces) means that innovation, security, integration, and even the ability to scale the solutions are very limited. The cloud computing promises of infinite elasticity, easy integration via platforms, and vetted and tokenized security to ensure privacy and safety is not possible in hosted applications, just like it was not possible in client-server applications without significant investment and unsustainable methods.

Well, I should say not possible to be done easily – but anyone can “pretend” they can do it by creating more and more complex code and solutions.  Removing the flexibility and elasticity of the cloud computing architecture gave us what we called, incorrectly, cloud for a long time: between 1995 and 2005 there were only hosted applications (with very few exceptions coming from smaller vendors) that could not leverage the promise of cloud computing.

SFDC, as well as most other Enterprise Software vendors, was in this camp.

This was very evident to the people who saw SFDC try to build ServiceCloud in the early days: version after version of a monolithic solution that could not integrate with or work as the other solutions deployed by SFDC and could not compete with the then-reigning-champion:  RightNow Technologies (another hosted solution, still today) or even the smaller customer service vendors.

Sometime in 2006-2007 SFDC realized the problem they had and noticed that distributed computing and three-tier cloud computing was starting to be noticed in the Enterprise Software world (some of the early smaller vendors that were creating innovative solutions for Enterprise Software were beginning to leverage the cloud computing model and break their monolithic solutions into tiers, finding ways to deploy them and leveraging the recently launched AWS services from Amazon and Grid computing from other large vendors).

In 2007 SFDC launched Force.com – their first attempt at a platform.  While the migration of existing code bases was not in the initial plan, the idea was to build a platform layer as part of a three-tier cloud computing model and let developers use that to access SFDC applications.  This was their first attempt at delivering a platform and had, still today has some, many problems: proprietary languages, incomplete service directories, and limited integration into the existing applications of SFDC (SFA and the pretty bad customer service solution back then) were the most noticeable for users; a very complex architecture was the problem for whoever looked behind the browser.

Alas, it was a good first step and it was welcomed by the developers and customers as a way to extend the existing solutions SFDC offered back then.

The Evolution

What follows was a list of steps that helped them realize the potential and power of the platform (trying to shorten this post, which is going to be long anyway):

• In 2008 SFDC acquires Instranet, a French customer service solution that was very strong in knowledge management but not so much in other areas.  The great part of that acquisition was getting Alex Dayon, a young technologist who understood the power and the concept of the cloud computing model and was willing to rebuild service cloud as a platform-based solution.
• In 2009 Vetrazzo, an SFDC customer, built ERP functions in force.com in one-third the time and cost of buying an ERP solution to run their organization.  This was not done with SFDC but it was heavily advertised by then once it was done. This proved that motivated customers with access to Force.com could do anything they wanted.
• In 2009 FinancialForce launched using Force.com as their underlying platform to offer accounting solutions to SFDC customers.
• In 2010 Kenandy launched using Force.com to create a standard ERP solution, still standing today and used by multiple SFDC customers.
• In 2010 SFDC launched Chatter, which was initially launched as a hybrid of platform solution and monolithic architecture software. Very important later as it was another data point in showing that platform-only solutions (see above) were better.  It also became the “guinea pig” of migrating SFDC applications to become platform solutions.
• In 2011 and 2012 SFDC acquired several “dot-com” properties (some of them later became data.com, work.com and desk.com) as well as Heroku (a platform focused on letting developers write smaller apps that could be deployed via web or mobile using different languages)

All these steps were essential to the development of S1, for different reasons:

• Instranet, which later became a working model of ServiceCloud – the first-one ever to be honest – was a proof-of-concept that platform based solutions could be done.  The development of this solution as ServiceCloud was done (approximately) between 2009 and 2011.
• Chatter was further proof that monolithic applications were a horrible idea if they were going to be used as a platform.  When Chatter was first launched it could only operate as a stand-alone solution, another entire solution separate from existing applications, and integration into the code-bases of ServiceCloud and SalesCloud was nearly impossible – something that a platform-based service could’ve done with little effort if any.
• The varied dot-com acquisitions, and platform-based launches by their partners, were important to prove that (since they were real three-tier cloud solutions) platform based services could be used and leveraged across different applications, and to prove that cloud-computing was a far better model than monolithic solutions (I wrote about the acquisition of Assistly, now desk.com, and covered some of these points).

Now it is 2011ish (not very precise, some of the points above came more clear as the development of S1 was underway, but it is the right timeframe going forward).  SFDC already knows that Force.com is not cutting it as a platform (it was proven when they could not launch Chatter as a platform service) and they need to do something.  What follows is one of the hardest decisions to take as an Enterprise Software vendor – but one that will have proven incredible beneficial for SFDC: they needed to re-architect Force.com.  This was the genesis of S1 (not the original name, and certainly not any name that was used during development).

SFDC makes the decision to re-architect the platform that was supposed to be basis for everything they do – and to fully embrace the three-tier model of cloud-computing.  The new platform will not only be extensible, secure, and elastic – it won’t have the interface code it had before (that becomes the true SaaS) and will have to separate the database and connectivity layers form the platform as well (this was the hardest thing to do, but this is another long story).

Among the many things they had realized once they got going was the power it can confer.  Take Chatter for example, one of the best examples of this change.  Chatter was a stand-alone solution that could, in the original implementation, bring some details from files and users into an activity stream.  It was not possible at the beginning to use Chatter for the new ideas that were emerging: make the stream part of all applications and functions, integrate it directly into groups and files to launch communities, and even worse – make it the basis for the social enterprise model that SFDC had then espoused.

Chatter was redone – the second time was done as a full platform-based solution: a service-based application that can operate within the platform to serve functions to any other application. The re-launch of Chatter as a platform (done in 2012) was a showcase of the power of what Force.com (then) could do: it quickly became part of everything that SFDC offered, its functions were easily accessible by not only other applications but also by customers, partners, and even competitors (the back story on Chatter and the database licenses it required, and how that became a roadblock for its growth was solved in the deal reached in2013 with Oracle– also another great story for later).

The Proposed Solution

And now we are at the end of 2012, beginning of 2013 with three incredible important accomplishments:

1. A newly re-architected platform (yet unnamed) that could change the Enterprise Software world
2. A new version of Chatter that not only serves as the proof of concept for this platform, but also the epitome of the many acquisitions and partnerships it took for SFDC to get to this point.
3. The burning question of how to deploy and leverage this the best way possible.

Enter S1.

I am not yet sure of how and when S1 was named so, and it does not matter. What matters is what it can do: it has the power to change SFDC from a hosted application (fine, hybrid hosted and cloud application if you prefer) vendor to one of the few solutions in the market with the clout and power to change cloud computing and ensure the adoption by organizations (IBM and Microsoft are the closest – but that is a whole different story also, trying to stay focused).

Here comes DreamForce 2013 – the chance to introduce S1.

During the keynote(s) (there were many more than one) the emphasis for S1 was on the use as a mobile client (it’s an app you can download today in the app store – don’t wait!), as a platform and an app (as if you could be a car and a highway system at the same time), and as many more things than what it is.  My blood pressure rose several points each time someone asked me what I thought of the “new mobile app: S1” or tried to convince me this was the culmination of Touch (that was a release SFDC did to address HTML5 “clients” about two years ago, a total failure – still exists somewhere in the chatter mobile and other apps, but nowhere near what the expectations were at the time).

To be fair, SFDC partners, most of them, I talked to were very smart about it and are already working on very interesting modules that leverage S1. The understanding of a three-tier model for cloud computing and how SFDC is working to incorporate it into their solution was not beyond comprehension by partners, it was poorly explained by SFDC.

The fact that some of SFDC employees were repeating this mantra of “mobile client” was what made it more cumbersome to me: knowing the effort and time it took to build it – why belittle it by calling it a mobile client?

S1 could be a mobile client – well, not really.  It can be displayed via a mobile client (mobile is an interface, not a client) as well as a desktop, a laptop, a tablet, a smartphone, a partner application, a custom app, an embedded item, a connected machine, even a connected customer and anything else in between.  Because it is a platform, any change you make to a service is IMMEDIATELY reflected in all clients and interfaces – that is the beauty of the three-tier cloud computing model.

There are many benefits to S1 (the platform) that are not being discussed (which I will make the ending of this book-long post).  There are some I will miss in this short post (yes, short – I once wrote a 45+ pages simple explanation of how cloud computing works).

Let me explain some of the things you can get when you stop calling it a mobile client and focus on the power of the platform (and we will extend that to ecosystems of platforms in another post):

1. Any client, anywhere can access any service offered by the platform.  This means that once you authenticate with a platform, anything else you want to access that is trusted to that platform is also accessible (PaaS to PaaS integration is far safer and scalable than point-to-point integration or security as done today by monolithic solutions)
2. Any interface (mobile, computer, watch, a “thing” in the internet of things) can access the functions and data (once properly secured and authenticated) and display it – you cannot have an “internet of things” or even an “internet of customers” without an ecosystem of trusted platforms (well, not a sustainable one at least).  This will lead to the rise of “atomized apps” (usually called apps).  These apps are found in mobile devices and are single-function solutions that require no further logic (think about it this way, if your job involves checking people’s credit scores before approving an application for a loan – wouldn’t you prefer to have a simple app that does just that? If your smartphone or table can do it, why not your organization? It now can)
3. The concept of multi-tenancy finally disappears (yay – I cannot tell you how happy I am) together with the concept of multi-instances.  We move to elastic single-instances with single-tenancy: each customer can have their own service (managed via systems management and metadata quite easily) and instantiate is as many times they need – and make any changes they want in the process. No longer are customers constrained (either in data model or functionality) to what’s offered as they can extend the functionality quite easily by making another service call (to any providers) without having to worry about changing the core service.  (note: vendors will try to tell you how expensive this is as compared to multi-tenancy, but ask you yourself how “cheap” it was to use multi-tenancy and what benefits you as the customer derived from that – or read my previously linked post for that answer).
4. SFDC can create more modular “API calls”.  They introduced this at the same time as S1 but they failed to mention why this was possible: any API is a library of many calls to different parts of the monolithic application to leverage their functions and data.  API calls require complex transacting for security, scalability, and even integration that can reduce the granularity (read complexity or simplicity – either work – if you prefer) of how you can interact with it.  By using services that leverage tokenized security and inheritances (core benefits of cloud computing) the calls can be far simpler, and far many more, while performing at the same or better level.  Completing more service calls will use fewer resources and time that doing the same via API calls.  Bottom line: you can use more granular functions with far less resources.
5. Incorporating Enterprise Application Stores (EAS) into their cloud computing deployment will allow any organization to create as many atomized apps as they would like to, thus reducing the complexity of the solutions used by the customers, the training and support costs, and enabling and empowering their customers to build and use their own “custom” version of the Enterprise Software they have running.  The device and operating system they run is irrelevant as long they are supported in the EAS (SFDC announced, very quietly, the first version of their EAS at DreamForce).

The $64,000.00 Question

If you followed all this so far, thank you.  I know it is a bit to consume.

You are probably saying by now, is that Saleforce1? Is the platform they launched and announced as a mobile-client / platform / everything what it is? Is it working yet?

Lots of questions, one simple answer. No.

Let me explain.

Salesforce1 at this point is a very well developed concept, an idea that has been partially implemented and (like i said above) it has a lot of potential.  It has the potential to change how we do Enterprise Software and Cloud Computing forever.  It has the potential to change the way software vendors work with each other.  It has the potential to change how organizations think about ecosystems, about systems of engagement, and about everything from personalization to revenue models.

It has all that potential – but it needs to be realized.  By my estimates, it is about 60-70% complete right now.  Most of the basic APIs have been moved over to the new service-style granular API model and a large number of customers have been running in the new platform without knowing it.

A development environment, an extension of existing Force.com IDE, already exists and service calls are working and available.  There are development manuals and directions, guides on how to do it, and even a “mobile client” (think Chatter mobile and you get a good picture) to allow anyone working with it have a mobile interface to it.  The majority of the pieces are there, but it is not complete.

I talked to a few partners and they had been working with it for some time.  They have been, and continue to, developing new solutions leveraging what Salesforce1 has to offer for some time now.  They have plans, new ideas, and the desire to build new models and new execution paths to fulfill the needs of their customers.  They are working on it and are doing quite well from what i saw.

I also talked to a few, very few, early adopters that are beginning to explore and see what they can do with it.  Admins and Developers are getting a closer-to-the-ground look at the potential and power of the platform and creating very interesting apps and applications for it.

However, none of these are released (there are a few apps in the AppExchange that say Salesforce1 ready – but I have not found any customers using those versions yet).  By my estimates, we are at the very least six months away, but more likely nine-twelve months from having some extraordinary solutions with momentum.  We are one-to-two years away from revolutionizing the way we use those apps, and three-to-five years away from changing revenue and business models to accommodate this new platform (including the core concepts of cloud computing).

Of course, timing will change from industry to industry, and company size to company size.  There are no guarantees of how long it will take to get there, but this is for sure – although Salesforce1 is not 100% ready today, it is excellent progress towards the realization of one of my visions – and the delivery of significant value to the users, customers, and partners.

Time will tell.

This is a very, very brief summary of the many discussions I had over the past few days with different people.  There is a lot more than I can put in here, please contact me if you would like to discuss this in more detail.

I made the offer over Twitter before and I will make it again: I would be more than happy to invest the time and effort in helping anyone understand why S1 is far more than a mobile application or client.

The potential to change the game of Enterprise Software is phenomenal – let’s just hope SFDC does a good job of explaining it.

Yeah, you better believe I will send them. I will share via this blog following…

Thoughts?

Notable Posts (that means I agree with them)
Ben Kepes, amazing cloud dude
Brian Vellmure, analyst extraordinaire
Ken Yeung, interesting and smart reporter

disclaimer: These are my opinions; by no means they are official words from SFDC.  This is my understanding and it is not endorsed by anyone at SFDC.  I have not run this by them, not have I sought approval.  Any errors, omissions, or mistakes are mine and mine only – Safe Harbor does not apply here, I am just telling a story as I see it.  Feel free to correct me in the comments or debate me as well.  I don’t monitor comments, even if WP does, I always approve them.

disclaimer-2: I said this before, Salesforce is one of the smart companies that took me on the offer to become my client.  I am very appreciative for the years we worked together, the incredible access to information, the many debates we held (still hold, never ending) about cloud and software, and their friendship and support for my work.  They also pay for me to attend Dreamforce every year, including hotels, meals, the registration fee, and a few parties here and there as well as a nice analyst swag bag.  I won’t deny it, they spoil me.  However, as you can see throughout the text, that does not mean I will be nice to them or not call them in their mistakes (yes, many through history).  As anybody else I chose to invite to be my client, they listen and sometimes work on their mistakes, sometimes they don’t (but all I can seriously ask is that they listen).  Everything they gave me to date has resulted in a stronger understanding of the potential that Salesforce1 has to change Enterprise Software (and not via more Marketing, as Marc Benioff mentioned in a tweet).  I just hope they realize it, it would make many of my long-held visions begin to come true (you know it is all about me, right?)