Vendor Lock-in: Not new. Not gone, no matter what they say.

Oct 26, 2006 by Matt Ammerman

We’ve had our fair share of vendor lock-in (handcuff) discussions on this blog. 

Vendor lock-in issues do in fact exist in SaaS platforms, and although platform providers might use a little smoke and mirrors to avert your attention from the handcuffs that exist, you should be aware that utilizing a proprietary platform means that it comes with some of the traditional enterprise vendor lock-in issues.  Lock-in hasn’t been avoided.  Not yet.

Phil Wainewright clearly and concisely illustrates that new SaaS platforms like Apex and now NetSuite take an approach that appears SaaS-rific on the surface but does, in the end, introduce our old friend vendor lock-in.

No Software! But more programming languages … – ZDNet

read more

Web 2.0 vs. SOA…huh?!?

Oct 26, 2006 by Sinclair Schuller

Although the posts are old and the topic potentially stale, I recently read a few posts creating a Celebrity Death Match style arena for SOA and Web 2.0. Richard Monson-Haefel of the I, Analyst blog posted a comparison highlighting the similarities but describing SOA as missing the “social aspect”, Don Hinchcliffe has a good thorough treatise on trying to make sense of it all here, and Jason Kolb fired up most of this conversation here. John Hagel recognizes SOA and Web 2.0 as two complementary technologies separated by a cultural gap in an article he posted a few months ago.

Whew! After all of that, I have to throw my two cents in (as usual). While I agree with some of these, I’m going to venture off on a slight tangent and make a different suggestion. first, let me say I agree with the notion that establishing a “vs.” between the two seems quite trite. In my opinion, they are far from competitive. I also will not classify them as being analogous to each other.

So what’s the deal? First, let’s define Web 2.0 as an ideology and set of associated tools, data, and concepts whose goal is to incorporate end users into the “architecture” such that the architecture becomes a user-centric model. The primary goal in this model is to allow users to collaborate with each in ways that were previously not possible by allowing them to connect systems and data over the Internet in ad-hoc but powerful fashions. Holy mouthful! I DO NOT see Web 2.0 as RSS, or as REST, or as some other singular, self containing technology. Web 2.0 is much bigger.

Now SOA. SOA is a description of a beautiful systems architecture of loosely coupled components that focus’ on process while reducing dependency. (A much more thorough description can be found here). With this in mind, I’m not sure how the notion of one being “vs.” the other fits. Also, while describing them as complimentary seems much more accurate, I think it may over do it. I think SOA facilitates the implementation of the Web 2.0 ideology, and does so very well.  SOA defines an architectural abstraction that provides one of the many potential underlying implementations of a Web 2.0 participant. An application residing on a server could allow for web-based mashups, but be itself defined in an SOA manner. Remember, when I say SOA, I mean SOA the architecture, not SOAP or anything silly detail like that. The notion of SOA is simply loosely coupled services, which is one of the tenets of Web 2.0 that allow for the user-centrically (new word) motivated infrastructure that is the connectivity of data and systems we call Web 2.0. Software as a a service is something that is part of Web 2.0, whose constituent applications can be built using SOA. SOA seems to be a participant in the Web 2.0 ideology. Make sense? Hope so!

read more

“Get ‘R Done” Architectures Just Won’t Cut It With SaaS

Oct 16, 2006 by Sinclair Schuller

Eric Norlin of the SaasCon Revolution blog posted an article titled “Iteration 2.0” The article outlines point of view (POV) uniqueness when it comes to leveraging the SaaS EcoSystem. The article broke down leveraging into three major POVs: Corporate Deployer, ISV, and Developer. While reading the section “For the ISV”, I had a light-switch moment. The section describes two topics (among others) of importance, one being “product architecture” and the other “drive toward a scalable customer base.” My light-switch moment focused on these two questions, prompting me to write this article to state something that is practically manifest in SaaS, most likely in the back of everyone’s minds, but seldom discussed.

As a display of my shallow sense of humor, before I start this post I need to disclose that I am quite the fan of Blue Collar TV. One of the hosts, Larry The Cable Guy, frequently uses the term “Get ‘R Done”, which is generally used as a command/show of support from one individual to another with respect to completing a task at hand, such as polishing off a whiskey or a beer (or orange juice). One thing to note is that it is a general term and offers no advice or direction as to how to complete the task, only that it “get done” in the quickest time possible. At one of my previous places of employment, “Get ‘R Done” became an inside joke that was frequently used to describe the approach that some of the project managers had to software design and architecture planning. Because of time constraints, we often heard terms that were equivalent to the chiefs saying “Get ‘R Done”, without any regard to how, as long as it was done by the next meeting so that there was something to show. This was true even if it meant sacrificing the technical and long-term integrity of the project. Now, I know this isn’t unique to that specific place of employment, but the “Get ‘R Done” really summarizes the issue.

Overtime, the “Get ‘R Done” joke was perturbed into a category of enterprise architecture. We frequently found ourselves short-cutting sound design for deadlines. Now, to be clear, I understand the short-term (and occasional long term) benefit of meeting the deadline and sacrificing soundness. Many times, this is acceptable with very little in terms of side-effects (in my example, it went way beyond acceptable). Now comes the obvious that I alluded to in the first paragraph: These sort of stability and integrity sacrifices have little to no place in SaaS architectures. As Norlin stated, ISVs need to focus on “product architecture” and “drive toward a scalable customer base” as part of their ability to leverage the SaaS ecosystem. ISVs are stuck between a rock and a hard place when it comes to architecture. Product architecture is very closely aligned with ability to support various levels of success. For example, let’s assume as an ISV, you have a product with phenomenal functional quality, and as a result, you are signing up subscribers faster than you can sharpen a pencil (not sure why I used that, but bear with me). Now, assume you wanted to get to market quickly to seize an opportunity, so you took a “Get ‘R Done” approach to your architecture. What’s going to happen as a result of your rapid increase in load? Your architecture will buckle! Now how useful was it to get to market early? Not very, seeing as how you can’t handle additional load and your existing customer base may leave because of SLA violations. Handling Internet scale load is very delicate to begin with. Couple that directly to your business’ stability, long term viability, and strategic capability, and the importance of a good, solid architecture has grown ten fold. “Get ‘R Done” architectures and all of the silly shortcuts associated with it not only violate your technical integrity when it comes to SaaS, but can shake your company down to its very foundations. Having a killer product and watching it go from success to buried because you wanted to take Larry The Cable Guy’s advice would suck. Buying more servers might help, but it might not. Trying to re-architect in a fly-by-night fashion might work, but it might not. The only true solution, one with minimal risk, is to have your product backed by a solid architecture that can help you amplify your success.

If you hope to leverage the SaaS ecosystem from Norlin’s ISV point of view, concentrate on getting rid of a stumbling block to success by being architecturally sound, and minimizing risk. Risk is something that businesses hate; if risk metrics had a flavor, your company would undoubtedly tell you that large risk numbers taste like crap. You wouldn’t feed yourself something that tastes like crap, so don’t feed it to your business.

read more

Going From Software Developer to SaaS Developer Without Giving Up The Ghost

Oct 13, 2006 by Matt Ammerman

Is transitioning from traditional enterprise software development to SaaS delivery becoming a necessary evil of a tech boom that makes established development firms quiver in fear?  We know how platforms aim to empower SaaS startups; the buzz about Apex earlier this week illustrates that much.  But while enablement solutions – platforms – aim to lower barriers for new vendors, are they actually fueling reluctancy on the part of established development firms?  The underlying thing here is this:  platforms are great if you can build a sustainable business from start to success, but what if you already have a successful business?  Platforms, right now, do little to ease the business concerns that exist for established software vendors.

Salesforce.com knows that Apex will appeal to vendors who can build a business on it from inception.  Perhaps that’s why the Apex incubator was included (read touted) as part of the initial Apex announcement.  Salesforce.com knows that their platform will appeal more to the brand-spanking new startup than the established enterprise software development firm.  I use Apex as the example here – but there does exist a wider void in SaaS enablement… and who’s going to be sure that all those existing companies don’t fall through the cracks while waiting for someone to help them make the jump?

A look at the extra hurdles that existing companies face is in order.  Here are a few of them:

Identity

The first, and most important, concern of making the transition is maintaining your identity.

You’re a software developer with an established customer base and a brand familiarity with the platform you’ve been developing on for years.  You’ve got skills and knowledge.  Perhaps you’re a Microsoft Certified Solutions Developer, or a member of the Apple Developer Connection.  You’ve worked hard and spent a lot of money on building up the developmental skillsets that benefit your product, the network that gains you market exposure, and ultimately the customers that increase your bottom line.  Now ask yourself:  If you had to throw that all away to pursue SaaS, would you?  You won’t read this in marketing materials from any of the early SaaS players, but as it stands right now SaaS is in fact a level playing field.  It’s a new school.  The SaaS market doesn’t care what you were in the old school called “Software”, you have to establish your SaaS-dentity just like everyone else.  You can choose to go it alone… make a pure play SaaS application and attempt to carve out your space in the industry all over again.  In this instance, you may be able to utilize some previously garnered skills, but damn, those SaaS requirements like multi-tenancy and data partitioning are just a huge hurdle right now and by the time you figure it all out a startup down the street might put you out of business.  No good.  You could choose to develop on a SaaS platform such as Apex and let them handle those hurdles for you… but then you’re REALLY throwing away your identity (you’re a vehicle for the platform instead of the platform being your vehicle).  Forget your MCSD, you’ve got to learn a new proprietary programming language – or no programming language at all (SaaSWYSIWYG?).

It sounds harsh, I know.  But this is still one of the existing barriers to widespread Software –> SaaS developer migration.  SaaS isn’t yet accessible to the developer who isn’t willing to give up all the things that consitute the identity they’ve worked hard to establish.

Needed: An enablement technology that SaaS-ifies a developer’s identity, skillsets, knowledge base, product, and even market exposure without a single drop of blood spilled.

Ingenuity

To be perfectly accurate, ingenuity can be considered a feature of identity.  You are known by what you do that others don’t.  The current problem is that short of building your own SaaS technology stack (potentially catastrophic to your bottom line) you’re going to have to fit all of your ingenuity into the constructs of an enablement platform.  Is this going to hurt your ingenuity?  Perhaps.  After all, you’ll be as ingenius as the platform says you can be.  But what’s more is that all-important translation from technological ingenuity to business model – aka. competitive advantage.  As far as ingenuity and competitive advantage: for some developers moving from Software to SaaS would be like trading a dollar for a nickel.  Sure, the metal is shinier but the dollar’s still worth more.

Needed: An enablement technology that respects (fosters, even) ingenuity and doesn’t shortchange competitive advantage.

Integration

Take a look at your rolodex.  You’ve made a lot of contacts over the years.  Your network is huge.  Your developers know this too because they’re on the phone with partners every day working on tightening integration between your application and theirs.  Your strategic partnerships are a HUGE competitive advantage and in most cases mean the difference between sale or no sale.  Now imagine giving all that up to pursue your SaaS application. 

Of course there’s APIs, but you’ll have to relearn them.

Needed: An enablement platform that leaves your integration capabilities intact, perhaps even untouched.  Your focus should be on the software and cultivating those integration capabilities the same way you always have.  

Exit Strategy

To tie it all together let’s assume that none of the three previous issues have deterred you and you’re ready to jump head first into the SaaS waters.  Not so fast.  What happens if you fail?  More importantly, what happens if your approach leaves you no option but to give up the ghost?  Well, going for broke and developing a standalone solution (application with SaaS tenets rolled into it) is perhaps the riskiest bet – and leaves you with essentially no room for error because as soon as it doesn’t work your bottom line dips.  Not to mention the enormous outlays in infrastructure and development costs.  So perhaps you turn to enablement platforms – they’ll take care of the SaaS for you and you keep just doing what your doing.  Again, not so fast.  As Sinclair popularly pointed out, current platforms introduce vendor lock-in that leaves you feeling a bit used (and broke, and without reusable code) should something go wrong.

SaaS does not need to be do or die… although it might seem that way right now.

Needed: Enablement technology that breaks up with you gracefully and gives you your stuff back in case it doesn’t work out.  That would sure help warm cold feet.

Ok, sure, this post has a tongue-in-cheek tone to it.  But I assure you that the issues raised are indeed quite serious to software developers who currently feel that they’ll have to give up their bread and butter enterprise business, company identity, and all the ingenuity they’ve accomplished in order to pursue SaaS, and without the benefit of a safety net.

Needed: A SaaS safety net.

So, I ask you software developers out there:  If you’ve considered developing a SaaS offering either on your own or via an existing hosting platform but chose NOT to just yet… what was the deciding factor?

read more

The State of SaaS

Oct 12, 2006 by Sinclair Schuller

For all of my technological ranting related to Salesforce.com and Apex, as well as the mini debates that unfurled around it, I would like to take a moment and reflect over the past year and include Salesforce in a congratulation of sorts. I know, its not a new year or anything, but the release of Apex and its surrounding buzz is a milestone. Not because Salesforce.com was the first to release a platform (this is hotly contested, especially by Netsuite and their CEO. And didn’t WebEx release the Connect platform?), but because of what it means for the industry in terms of maturation.

A little more than a year ago, people would talk about SaaS in a very ad-hoc, roundabout way. There was little structure behind some of the online readings or conversations. Now, it seems like the notion of SaaS and its deliverables are much more in tune. The announcements by WebEx, Salesforce, etc. really highlight the fact that SaaS is gaining mainstream momentum, even as we speak. The difference between WebEx’s announcement, NetSuite’s Netflex/SuiteScript announcement, and Salesforce.com’s announcement is that although all claim to be first, Salesforce successfully broke down the barrier and helped define a higher level of acceptance for a platform concept while the others simply “made announcements” of a new product. They drove “platform” home, and not product. In reality, Salesforce’s move is good for the industry, providing a level of SaaS validation that just wasn’t there a few months ago. Now, the question remains on whether any of these platforms can move SaaS from a validation phase to a realization and value derivation phase.

read more