Freigeben über

Enabling the Long Tail of SaaS Providers

  • Artikel

I love the long tail metaphor. It explained the business model behind Amazon, Netflix, Web 2.0 and now SaaS.

In my first SaaS paper, I used the long tail to explain the potential business software buyer market.

Lately, I’ve been thinking about the long tail of potential software service suppliers.

I’ve talked to many SaaS ISVs and have not ceased to be amazed by the foray of applications that are being offered as SaaS. Among those whom I spoke to was a Wall Street currency trader who got tired of life on the fast path and thought he would retire to a less demanding job of selling trading software to big banks and small time brokers. Although he found his software career more interesting and dynamic, he was in for a surprise when the new career did not allow him to spend more time with his family, as given the current state of technology, offering scalable SaaS is no small feat.

In another conversation with friends, I learned that one of their ex-MBA classmates is doing really well offering operations and logistics planning business consulting services and may entertain the idea of automating and charging for his business expertise as software services.

Through these interactions, I’ve discovered that SaaS offers a really nice opportunity for people with specialized business domain knowledge to scale their services. Looking into my crystal ball, it’s not hard to imagine human resource VPs, real estate brokers, wealth management consultants and SOX auditors all wanting a piece of the SaaS action. They are what educators would call “the future of software industry”. I refer to them as the long tail of mom-and-pop SaaS ISVs.

But didn’t I just say that our currency trader friend is not having such an easy time making that SaaS career switch? Yes indeed, and you can blame it on the three-headed monster that haunts every SaaS ISV. In my first paper, I had mentioned that every SaaS architect needs to think about three things: scalability, configurability and being multi-tenant efficient. So from now on, you can think of single instance, multi-tenancy as the three-headed monster, each with a unique haunting personality. This is not good as this three-headed monster is dampening the mood in the SaaS provider market.

The following figure shows that because of the technical challenges of delivering single instance, multi-tenant application, the existing market size of SaaS providers is still very small compared to the total market potential. It’s then logical to conclude that by removing the technical barriers for delivering multi-tenant software services, we should see more competition and more choices in the SaaS provider ecosystem, which is represented by the long tail of SaaS providers.

 

 

Unfortunately, today’s software development tools and platform is yet to mature to the level where mere mortals can just focus on implementing code for their domain specialization, and not have to worry about the three-headed monster architecture exercise.

At Microsoft, we classify our software development tool users into three categories of sophistication: Einstein, Elvis and Mort. You can read more about these personas here if you’re interested. The point I want to make here is that our ex-currency trader friend above is the new Mort in the SaaS world. Our new Mort is smart and has deep business domain expertise, but is not a programmer and really don’t have time for all the multi-tenancy mumbo jumbo. In a nutshell, they need a lot of help in order to become a mom-and-pop SaaS ISV.

For now, they will have to look for high caliber architects and developers to help realize their SaaS ambition. So the million dollar question is what should the new generation of mom-and-pop SaaS ISV enabling tools and solution offer? I think it falls into two main categories.

The first category is software tools that allow our new Mort to build multi-tenant vertical applications without writing code – this means GUI-based application designers that reduce the gap between business and technology and application platform runtime that respects multi-tenancy:

· Mort needs a business entity designer for defining domain-specific concepts. For example, a human resource application will need to understand the notion of an employee as having properties such as name, department, reporting manager etc. The same designer can also be used for designing an inventory control application which will define the notion of a catalog business entity which consists of properties like catalog number, quantity etc. Once the business entities are defined, they are converted into logical and physical data representations in relational databases. You may say that such designer tools are already coming. You are right. In fact, you may want to read up on this most excellent article about upcoming technology in this area. Having said that, many existing entity frameworks assume that the business entities remain static once it is defined, and/or the runtime environment is single-tenant. Such assumptions are limiting as SaaS application providers may want to allow their tenants to customize the pre-defined entities. Therefore, a multi-tenant business entity framework must store meta-data that describe how each tenant has evolved the default entities. The framework must also provide a corresponding runtime that is capable of reconstructing the customized entities for every tenant that is using the SaaS application. And all these have to be accomplished without the SaaS provider writing custom code for every tenant. Mort will be most happy when all he has to think about is creating the default set of business entities for his application.

 

· Once the business entities are defined, Mort will want to define the workflow and include business rules that describe the domain specific business processes which operate on the configured business entities. Again, ideally, this can be accomplished through GUI designer tools. Like the multi-tenant business entity framework, the multi-tenant workflow and rules designer must maintain metadata of how the processes are customized for each tenant and a runtime component that will rehydrate the customization appropriately.

 

· The last one in this category is a multi-tenant UI designer that let’s Mort defines menus and controls for activating and displaying results from the business processes that are previously defined. The gamut of UI customizations should range from eye candy type features like background color, frame layout to filtering information displayed by UI controls. By now, you may have guessed that Mort’s tenant should be able to customize the application UI and therefore we need metadata for describing the look and feel of the UI skins.

After wiring up the application, Mort, given the nirvanic environment, should be able to just with a simple click of a button, deploy the application to a SaaS hosting site. Mind you, this is not your grandpa’s hosting provider. Instead, the new breed of SaaS hosting provider should provide additional value-added services, such as taking care of the tenant provisioning, order management, metering, billing and reporting as well as monitoring and enforcing the infrastructure SLA on behalf of the mom-and-pop SaaS provider. (Some of these may sound suspiciously familiar to folks from the OSS/BSS world)

In other words, to further lower the bar of entry for the mom-and-pop SaaS ISVs, SaaS shopping malls and equivalent infrastructure services need to be built. Shopping malls are apt analogy here if you think about what they provide for the small retailers: physical buildings, utilities, sizable consumer visibility, parking structures etc. Without shopping malls, retail businesses will not be as vibrant today due to the higher cost of entry and smaller consumer reach.

Currently, hosters contemplating getting into this kind of shopping mall SaaS hosting business need to worry about the risks and liability of hosting third party code, which may not be secure and reliable. Such concerns also provide the impetus for the kind of multi-tenant Mort development tools mentioned above. By minimizing the amount of code people have to write, and relying more on the sandbox that the development tools is providing, SaaS hosters can actually have higher assurance that they are not hosting fragile applications.

These days we often hear colleagues saying everyone wants a piece of SaaS, but I postulate that until we see better multi-tenant aware application development tools integrated with functional SaaS shopping malls, we will not see the full economic potential of the SaaSy long tail unleashed.

Comments