SaaS Blogs

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.