Insight as a Service refers to action-oriented, analytic-driven solutions that operate on data generated by SaaS applications, proprietary corporate data, as well as syndicated and open source data and are delivered over the cloud.  This definition is meant to differentiate Insight as a Service, which I associate with action, from Analytics as a Service, which I associate with data science, and Data as a Service which I associate with the cloud-based delivery of syndicated and open source data.

It’s excellent analysis and I have been learning from his approach since he first started enunciating it a year ago. The more we go into the age of big data, the more glaring the contrast with our brains, which remain about the same size as ever.

For people to make use of the oceans of data now becoming available, our software will shift away from simply telling people what is, and move towards telling them what it means.

Don’t tell me I have an influence score of 50332.111 μFonzies with a ρ{Laren}  factor of +0.033. Tell me: “Your audience likes it when you joke about your struggles learning how to dance. And knock off the Ernest Borgnine quotes.”

Infographics and analytics are hot topics now, and will retain some luster going forward. But if you are planning to fight the next war instead of the last one, think about Insight.

For those who are putting an application in the cloud for the first time and wondered, perhaps, what challenges they will face, have a look at the short overview I just put together for LinkedSeattle.com.

As evidence, see Scale and Scalability: Rethinking the Most Overused IT System Selling Point for the Cloud Era in IT Expert Voice.

Perhaps, as Name.com’s Sean Leach advises, there’s a lesson to be learned from Twitter: Rather than planning to scale incrementally — which, if a business finds or regains success, may now be impossible — it should plan to rework its fundamental architecture as needed, in phases, as old architectures that met earlier requirements are no longer applicable.

The coefficients of Leach’s formula may sound a bit obtuse, but in light of Twitter, perhaps the sky’s the limit. “Let’s say, the biggest you’re ever going to get is a trillion customers. But instead of designing for a trillion customers, design to a million customers so that when you get halfway there, you can redesign the system over time to be able to support a billion customers. Then when you get to almost a billion… just build it and get it out there, and then you spend your time up front and don’t worry about scaling. Plan in phases where you scale to X, and then when you get close to X, you start thinking about Y…as opposed to waiting until X happens before you worry about scaling,” he says.

The performance requirements that spawned the first generation product will impede the development of the second generation. And the best practices of just a few years ago are no longer adequate to the challenges ahead of us. This trend has only accelerated.  Over the years, Twitter has replaced their original Ruby on Rails technology stack completely, and put in place a new stack based on the JVM with Scala as the primary programming metaphor.

When taking an existing system and moving it to the cloud, you must drive a number of architectural shifts as the audience grows bigger that more or less recapitulate the industry migration from the ASP model to the cloud model. For example:

1. Separating the database systems and the web application so that the CPU and I/O usage of each one can be optimized separately, which leads to:
2. Switching from a database instance per customer to a single database instance with sharding to reduce the cost of deployments and upgrades.
3. Switching from a single database host to a database cluster to permit balancing between read and write operations; web applications are usually very read-intensive.
4. Introducing multiple web application servers to permit more users to be served simultaneously, which leads to:
5. Adding a caching layer in between the application and the database to reduce the amount of I/O required by each web application host, which leads to:
6. Cache coordination between application hosts to further reduce the I/O to the database layer, and reduce the chance of conflicting changes to shared objects, which leads to:
7. Introduction of a formal Object-Relational Layer (ORL) on top of the caching layer, to permit the web application to treat everything as a first-class object and to abstract away the work of persistance in the database.
8. Separating the web application into a set of REST interfaces and a UI tier on top, permitting the same basic structure to serve web users, mobile users, business partners, your vendors.
9. This leads to a realization that a relational database covered by a caching system and an ORL is actually a very expensive way to have an object-oriented or document-oriented database. If the size of the data has not already demanded the switch before this point, this is where teams realize the wisdom of CouchDB, Cassandra, HBASE, or MongoDB.

And so on. No one is making faster processors. They’re just making more of them. If your data structures and algorithms do not permit the work to be broken up and processed by an army of threads working on a grid of unremarkable machines, then you don’t have scalability. You just have size.

Back in the old days (ca. 2001), if we wanted to build a software-as-a-service business, we had to put it all together ourselves, lashing together web servers, databases, load balancers, and piles of software. We did the engineering, the marketing, the sales, the PR, the billing, the accounting, the operations support, and the advertising.

Then we’d walk in the snow (this was Boston, after all) uphill both ways to and from meetings with investors who would beat us with their riding crops while telling us every reason why no one would ever buy software that didn’t come in pretty boxes sitting on store shelves.

Things are different now. Here are ten kinds of services that you can use to get your idea up and running quickly and start taking orders:

Cloud Hosting

First, the easy one: You have to put your cloud service somewhere. Actually several “somewheres.” For each machine you have in production, you usually need at least one more identical machine for staging. Then another for development. And another for penetration testing. And, when your service gets large enough, scalability testing. If you’re not thinking “virtualization” by this point, then you’re not caught up to the rest of the class.

Depending on your favorite technology stack, you’ve got Amazon Web Services, Heroku, Engine Yard, Google App Engine, Rackspace and TerreMark Cloud.

Subscription Billing

In the old days, we built subscription-based businesses because we thought it would let us get paid while we slept. (Wrong on both counts.)

When the bulk of your payments come in repeated credit card charges, you need a system to manage products, pricing, promotions, charges, and dunning.

Online services like Chargify, Zuora, and Recurly will handle all of this for you, and they’ll do it for much less than you would spend building and maintaining the necessary code yourself.

Accounting

Great, so you’re making sales. Next up: counting them.

When your volume goes beyond a handful of sales a week (and, if not, you’d better be selling a really high-margin SaaS product), then you’re going to need an online accounting system. Choose one with an API so that you can extract real-time profitability metrics and publish them to your dashboards. (More about that below.)

Popular choices include IntAcct, Freshbooks, and Kashoo. While Intuit does have an online version of QuickBooks, its API is still in beta.

System Monitoring

Once a system alert or a customer issue interrupts date night with your spouse a couple of times, you may wish you weren’t monitoring. But, of course, you have to.

Choose something with an API and use it to attach monitoring to the internals of your design, not just the externally visible elements. How are the processing queues doing? Are tasks moving through the system or hanging up? Are errors occurring and are they being handled?

Pingdom and Amazon CloudWatch are on the list here. For high-end sites, especially with users in many countries, there’s also Gomez.

Dashboards

Every business owner wants a shiny dashboard with their key performance metrics on it, and almost every one of them has a hand-drawn design somewhere that describes what it will look like someday, when they have the time to build it instead of building new features for those pesky customers.

Or, you can outsource that work, too: Services like MixPanel and GeckoBoard give you instant dashboards and analytics based on data from anywhere in your system.

For bonus points, collect data from your billing service and your accounting service to show profitability metrics like customer long-term value, churn, and monthly recurring revenue.

Data Feeds

So you’ve discovered the killer algorithm to help people share their favorite breakfast food choices with strangers who happen to have the same first letter of their middle name. It’s the ultimate social application, for sure, and you need to have it ready in time for SXSW.

Trouble is, you need data to feed to your algorithm to make your service compelling. Hard as it may be to believe, there was a time when all data in the world was not stored in a computer. (I know: weird, right?)

Nowadays, we live in the era of big data and you can buy what you need: Socrata, Factual, and InfoChimps are companies you can get to know in this field.

API Support

Do you have an API for your service? Sure you do, you have to. If you want to play the big game, you have to empower your users to make mashups. But planning for security on your API and scaling it are both hard problems. On the day the realization hits that “we have an API” means “we have a wide-open attack surface and a denial-of-service attack waiting to happen, all rolled up into one,” you need API help.

This is a new area, and Apigee is stepping into the breach. Protect your APIs with OAuth and manage their traffic volume all at once. If you target enterprise customers, you can also add SAML integration this way.

Cloud Integration

It’s annoying when the data your customers want to integrate with your service isn’t in your data center. If you serve business customers, particularly large enterprises, you’re going to find they need you to connect your service to some other large dataset outside your control. Very large datasets. With many delightful idiosyncrasies.

Trust me, you don’t want to do this yourself. Whole generations of programmers have suffered permanent psychological scars from the rat’s nest of Perl scripts and ETL systems that have grown around this problem. I shudder to think of the cost of the therapy alone.

Enter cloud integration. Partners like SnapLogic and Temboo can help you route data from where it is to where you wish it were.

Graphic Design

Maybe you’re already great at the magic of design. Or, maybe you have trouble color-coordinating your jeans and t-shirts. You can partner with a design genius, or you can hire the talent you need from a pool of gifted creatives and have your pick of the designs.

That’s what 99Designs and CrowdSpring specialize in. The former appears better suited to the bootstrapping phase, while the latter may work better for more established firms. Either way, you can run design competitions faster and cheaper than hiring directly.

Content Creation

Let’s face it, you didn’t major in creative writing and your idea of sophisticated prose is a slashdot post that isn’t about Linux. But you still need a lot of written material to have a successful cloud product. Things like instructions, descriptions, calls to action, error messages, email messages, promotional messages … someone has to write them.

Mentioned above, CrowdSpring also does copywriting, and keep an eye on MediaPiston, which is inviting users to a private beta as of now.

Got Other Ideas?

This is just a short list of sample tools that you can use right now. What are your favorite cloud application accelerators? Let me know in the comments.

Metrics for metric’s sake are not very useful. Instead the goal is to provide a detailed look at what management must focus on to drive a successful SaaS business. For each metric, we will also look at what is actionable.

The piece also includes some guidelines. Did you know, for example, that the lifetime value of a customer should ideally be greater than three times the cost to acquire that customer and that you should aim to recoup the cost of acquiring that customer in less than a year?

Skok’s article is a crash course in SaaS economics. If you’re serious about a SaaS business, read the whole thing.

Delivering software as a service is much more than a technological challenge. It is, fundamentally, an organizational challenge and its lifeblood is coordinating business activities at a scale and cost efficiency that packaged product can’t touch.

Case in point: When I made my first foray into SaaS in 2002, the principal problem I was solving wasn’t a technical problem, but a business problem:

• How can a small company that can’t afford to build traditional sales channels possibly compete with a larger competitor with the resources to put boxes on store shelves?
• How can we afford to shorten our product cycles and accelerate our pace of innovation when upgrading customer installations is patchy and error-prone?
• How can we keep the cost of development and support down and provide high reliability regardless of customer hardware and operating system?

We answered these questions with SaaS. I didn’t think we were forging a revolution in software at the time; we were just trying to deliver value to the customer within the resources we had available.

I had one advantage at the time that played well to the strengths of SaaS, though it took some time to recognize that: Our relatively small team size meant that the communications burden across company functions was quite low. We could literally make interlocking strategy, marketing, sales, product, and technology decisions within hours and implement them within days.

When taking an existing application to the SaaS delivery model, one with an established customer base and company sales and marketing apparatus, I find that making these interlocking decisions quickly and effectively is probably the most important hurdle that you face, and the key area to pay attention to if you want your SaaS products to succeed. 

When the company needs to succeed in SaaS product delivery, I make it my priority to break down communications barriers and build teamwork and cooperation. 

Of course, setting teamwork as a goal and achieving its benefits are two different things. To know when we’ve achieved our goals, we need metrics. Here are some of the areas of measurement you should thinking about if you want to know whether your efforts are bearing fruit:

• Trial Provisioning Speed
  How long does it take, in minutes and seconds, from the time when a prospect requests a trial to the time when their trial is ready?
• Customer Provisioning Speed
  How long does it take, in minutes and seconds, from the time when a customer purchases to the time when they are online and able to use the offering?
• Content Management Speed
  How long does it take for changes to the web application content or the surrounding marketing web content to be edited, reviewed, approved, and published? Does it take a full product release to change some of the content?
• Value Creation Speed
  How many times each year can your team deliver new features, improvements, optimizations, and enhancements?
• Deployment Speed
  How quickly can you deploy your application once a complete installation package is ready?
• Customer Support Speed
  How long does it take for a simple customer support request to be answered and closed? How long does it take for a complex request?

These are the first things to examine because speed is a key part of the service that software as a service brings.

SaaS is about reducing and removing the cost and friction involved in conceiving, designing, building, deploying, evaluating, buying and using great software.

When you’re doing SaaS right, you’re going faster.