Think Historically When Choosing a SaaS Platform

Oct 11, 2006 by Matt Ammerman

At the turning point in the plot of my favorite ‘just for fun’ movie, Antitrust, the crooked software mogul Gary Winston mistakenly exposes his evildoings to the hero software programmer, Milo, by making the following statement:

“The answer’s not in the box, it’s in the band” 

In the movie, the phrase is used in reference to compression algorithms that Gary stole from Milo’s friend.  However, permit me to use this simple statement to illustrate my point:

As far as success in service delivery goes – the answer’s not in the application (the box), it’s in the platform that delivers it (the band).  After all, this is what SaaS developers struggle with – they know how to make software, but this new way of delivering it presents a few serious problems.  And of course the solution is found in delivery platforms - constructs that take the delivery concerns out of SaaS applications.  So, what makes a successful delivery platform, and what should you look for as a developer when choosing one for your SaaS application?

As Sinclair hinted in an earlier post, we need only look at the history of our industry to see the difference between what will work well and what will change the world.

In the SaaS world, what we have right now is a bunch of proprietary platform-esque offerings (perhaps the most touted being the newly announced Salesforce.com Apex).  Actually, Apex is a good example for this point - it’s got it’s own language.  Now, suppose I want to create an entire application that does things that the platform does not provide for – I’m on my own as far as I can tell, and while I can make API calls from the outside… I am no longer utilizing (or benefitting from) the band, am I?  I have to provide my own delivery mechanism anyway.  As far as my clever analogy goes – these platforms are Apple Computers circa the early 1980′s.

I think you might be able to tell where I’m going with this by now.  What did Microsoft and IBM do?  They created a software platform that made hardware accessible to application developers in a standardized fashion, while dictating very little about how the applications themselves conducted their core business logic.  Application developers were able to focus on software and worry little (and less over time as the operating system evolved) about how that software was delivered to computer users.

Now, let’s complete the analogy – if we equate SaaS delivery requirements of today with the personal computer hardware of the early 80′s – then history teaches us that we need standardization.  We need a platform that facilitates delivery, but allows developmental freedom.  Developers need to be able to create the software applications they create because of their talent, skillsets, resources, and native technology stacks… not the software they are only able to create because of the capabilities provided by the platform they choose for delivery.

Imagine if Pope Julius II had commissioned Michelangelo to paint the Sistine Chapel and said “Please paint the ceiling.  Here are your paints, but you can only use black and white.”

As the awareness and adoption of SaaS broadens, it will become more and more evident that the path to success for SaaS developers is in the freedoms and powers that their chosen delivery platform affords them, not the proprietary featuresets (read: limitations) and closed constructs of current platform attempts.  The answer is in fact, in the band.

read more

Where’s the “App” in AppExchange?

Oct 11, 2006 by Sinclair Schuller

Ok, ok, I’m starting to feel bad writing about Salesforce.com. Well, maybe not. Someone has to do it, right? This week is Dreamforce, where Salesforce runs ’round town tooting their own horn much to the chagrin of individuals who feel their vision isn’t so hot. In all seriousness, why do some of us not see Salesforce as the save-all answer or as a “shining star” in the industry? Well, a prior post of mine discusses the introduction of Apex as one reason, but what else? Let’s start with finding the apps in AppExchange.

AppExchange, based on my interpretation of the very clear  marketing message delivered by Salesforce, is an online market place where users can subscribe to applications built by Salesforce.com partner vendors. It is generally dubbed to be a parallel of eBay, or more appropriately iTunes, for on-demand applications. This is a great concept: a central place or “marketplace” online where an end user can subscribe to on-demand apps. Building up such a marketplace is hard work, requiring a certain self fueling network effect of attracting developers to build applications that will attract end users, thereby making the marketplace more appealing to a new set of developers. Salesforce.com is keenly aware of this, and their goals of bolstering the AppExchange probably push them to embrace the said network effect. So what sounds more appealing if you are a prospective vendor recruit: to say that you will participate in an AppExchange that has 350+ (actually, today they say 400+) applications with no qualifiers as to what an application is defined to be, or to participate in an AppExchange with an appropriate taxonomy that could yield a much smaller number? If I was considering Salesforce.com as a platform for me to develop, I would definitely hope to exist within the well established AppExchange version that has 350+ applications! Keeping the network effect flywheel spinning is important to the success of AppExchange. Making sure that the numbers are high add that much more of needed mass to maintain the momentum of that flywheel.

If we look at this “ecosystem” of 350+ applications, what is the breakdown? What might a stricter taxonomy look like? I recently compiled a list of these 350+ applications (I came up with 343, but I may have missed 8+) to do a little investigation. I found some wonderful tidbits of information. Did you know that at the time I retrieved the data (week of October 2, 2006)…

• …24% of all listed applications were built by Salesforce.com rather than by partner vendors
• …that 6 out of the 8 (that’s right, 75%) “Most Popular” applications are apps built by Salesforce.com and that are free.
• …many of these apps extend the Salesforce.com main application functionality in ways that would traditionally classify the said “app” as a “plug-in” (Seriously, would anyone classify Clippy or the Microsoft Equation Editor as applications, or analogously would you buy a “song” on iTunes that was a Snare Drum Loop?)

While to some this may seem unimportant, it is in fact quite important when trying to create a metric for measuring AppExchange’s effective mass. I doubt a doctor taking your weight during a physical exam would accept 80 lbs of lead in your pants as part of your weight, which is why I look at AppExchange from this “no lead in the pants” perspective. Deducting the 24% of AppExchange entities (I will not call them “apps” until I know which are, in fact, “apps”) that are built by Salesforce.com, somewhere near 260 of the remaining AppExchange entities are built by partners. Of these vendor entities, some subset would normally be classified as true applications. (Please, do not misconstrue this as a poke at the vendors. They are exercising an opportunity, so Kudos to their efforts;-)) In addition, 75% of AppExchange’s most popular offerings share two things in common: they are made by salesforce.com and are free. While there is a certain “duh” factor associated with “free” and “popular”, one should not discount the fact that more valuable items that cost money are not outranking something of much lower value, even if it is free.

So I ask, where is the app in AppExchange? Is Apex their vehicle to allow for the permeation of the more traditional notion of “software functionality” into the AppExchange? Is their another player that can deliver something better? Only time well tell. My gut feeling is that some of these questions will be answered sooner rather than later.

read more

Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand

Oct 10, 2006 by Sinclair Schuller

When I first read of the Apex rumor, (Salesforce.com’s new “on demand programming language and platform”) over at Salesforcewatch.com, I started monitoring some of the various blogs and sites I regularly read for related news. I was hoping to find some tidbits of information that aren’t part of Salesforce.com’s marketing spiel. After Salesforce’s official Apex announcement, I found an excellent article that Dan Farber wrote about his discussion on Apex with Salesforce.com co-founder Parker Harris.

Harris discussed Apex in various contexts, defining it as a language with syntax that is a hybrid of SQL-esque style statements mixed with Java, and that the learning curve should not be a problem, allowing developers to quickly build on-demand applications. This sounds enticing and definitely has a lot of “wow factor” fluff associated with it. But once we get past all of this rhetoric, what substance are we left with? What trade-offs are we required to make? The answer is as easy as looking at the history of the industry.

As an industry, we’ve struggled hard and continue to struggle against being “held down” or “locked in”. The ramifications of requiring that an entity or development firm be veritably tied to another are massive, and quite frankly, the proposition sucks. Granted, working with a company like Salesforce.com gives a vendor exposure to a large customer base. This has an inherent value associated with it, but what about long term strategy and what about risk? Harris describes the language as new and powerful, but never mentions lock-in and limiting. We’ve reached a day in age where the advent and proposition of SOA allows use to start forgetting about implementation details and to focus on solving problems, not working around vendor lock in. We have a plethora of languages and implementation platforms that are very good at what they do, and are very open. We know Sun has promised to fully open-source Java giving the community control over much of its definition. Microsoft has published an open specification for the .NET platform and for C#, allowing developers to build new languages for a powerful platform, or build .NET implementations from scratch, such as Mono for Linux. As a whole, the industry is moving more toward interoperability and openness, where reinventing the wheel and building difficult to break proprietary locks is looked at as both silly from technological and strategic standpoints. Why then, has Salesforce.com opted to peddle proprietary nonsense as their on-demand platform and language? Because Benioff wants to handcuff vendors, preventing them from ever leaving. After all, watching AppExchange’s “application” count only go up through the blocking attrition by making it expensive to decouple your business from Salesforce.com is quite nice…

Apex, based on the description, seems like an evolution of SAP’s ABAP Objects (Advanced Business Application Programming Objects) language and NetWeaver, only evolved for on-demand and some quasi-OOP platform. While I appreciate Apex’s resemblance to Java, its still proprietary, just like ABAP and NetWeaver. While SAP touted ABAP as the end-all app development language and NetWeaver as the premiere platform for building business applications, we know full well that your general purpose technologies and languages as a whole have trumped things like NetWeaver time and time again. Granted, NetWeaver lets you use Java through some tight “hooks” to NetWeaver if you don’t want to ABAP, but your still “hooked.” NetWeaver and ABAP are not “mainstream” (how often do you see Digg/Slashdot/Red Herring articles on powerful applications or companies built on NetWeaver?). Apex presents the same proposition as NetWeaver: build your applications using Salesforce.com’s proprietary stack and you get to NOT have the flexibility of easily moving from Salesforce.com to another platform, of NOT being able to use for-sale and open source libraries in your applications, and having the pleasure of existing within Apex’s limitations. We’re in a day in age where we do not need YAPL (Yet Another Proprietary Language) or YAPP (Yet Another Proprietary Platform). I can’t imagine that Apex will be well accepted by the mainstream because of its lack of openness, flexibility, and overall stink-of-Salesforce aroma that surrounds its essence.

This makes me question Salesforce.com’s motivation. Why not embrace the many, many (and maybe one more ‘many’) well built technologies as the core implementation proposition to your vendors? Why provide something that is proprietary and less powerful, all while reinventing the wheel; according to Harris, they haven’t quite figured out debugging yet and have yet to come up with a way for vendors to build a UI because they “…need to build a pretty radical UI layer “. Excellent, I can’t wait for Apex UI Super Duper Extreme, the language for “on demand UI development”. My take on it: (1) Marc Benioff wants to keep the vendor close by making it expensive to build on and strategically unfeasible to leave the Apex platform and (2) they already have plenty of time and money invested on their own internal platform, which wasn’t originally designed for public use, and have retrofitted it to be a general purpose platform. Number (2) is very reasonable and any company would have done the same. We don’t need a specialized stack for on-demand. The power of on-demand and SaaS as a distribution model can be realized with the knowledge and technologies we have. The notion that a specialized “language” knock-off is needed to facilitate on-demand is absurd. The full power of on-demand can be provided without it, through a platform that embraces current technology.

*Gasp* Imagine if you could write an application using your existing knowledge set and a well accepted technology stack and still deliver it through a platform, on demand with oodles of multi-tenancy, single instance, high availability fun?! Nah, that could never happen…well, at least not until someone steps up to the plate…

Update: As per Mr. Joseph’s comment, I have removed the following sentence from the post:

I doubt a big Apex movement will be started on Sourceforge, seeing as how becoming a Salesforce partner developer costs more than an XBox 360

Mr. Kingsley pointed out that there is no fee for being a developer. After some research at some other sources, it is only for “certifying” the application that a vendor is required to pay a $10,000 fee.

read more

On Service Delivery Platforms for SaaS

Oct 6, 2006 by Sinclair Schuller

As usual, Fred Chong has posted another great article, this time directly addressing the space of what he calls an SDP, or “Service Delivery Platform.” In short, an SDP is a platform that allow for the deployment and delivery of a SaaS application. This notion of SDP is what will be one of the driving forces behind SaaS adoption. A good SDP disconnects the delivery model from the application, allowing application developers the ability to concentrate on their application functionality and not SaaS intracacies. Imagine how much it would suck if developers had to write/rewrite kernel or I/O code everytime they wrote an app. They don’t (at least not anymore). Why? Because nowadays, that’s the duty of the operating system. Because of SDPs, more developers and software vendors will be able to realize SaaS as a delivery method, and most likely make it their delivery method of choice.

Fred makes some architectural references in his post. It’s important to realize that the architecture of an SDP will be a defining factor in its success. Generally, I do not take the technologist approach of closely relating success and technological prowess of an offering. After all, we have many examples of junk technology that is popular (MySpace, anyone?) and stellar technology that remains in the deep dungeons of SourceForge. However, the architecture of an SDP is what will really allow aggregation of economies of scale and a “trickle down economics” sort of value to end users that are consuming the application functionality. As the end users absorb the savings dictated by a good architecture, the popularity of the applications will increase, thereby bolstering SaaS as a delivery method.

One other quick note is Fred’s mention of having to modify an application so that it could take full advantage of an SDP. This is important because it outlines the effort required by a vendor to be able to deploy applications on an SDP. Keep this in mind, we’ll revisit the topic of effort in the future.

read more

Kudos to the U.S.A.

Oct 4, 2006 by Sinclair Schuller

I just wanted to say that I’m impressed with our country’s results in the awarding of Nobel Prizes! So far, people from the U.S. have secured all the prize announcements, which have been: medicine, physics, and chemistry. Who says the U.S. is behind in the sciences? The remaining prizes are economics, peace, and literature. Let’s see how we fare!

read more