Today there’s a lot of “buz” around Software as a Service – SaaS. But what is it? Is it really going to happen this time? Simply put, the current most common definition of SaaS is “Software deployed as a hosted service and accessed over the Internet”. I have seen it come and go a couple of times over the past 15 or so years (yes, I’m getting old), but this time I think it can be big and that it can be different…

 

Background

In the late 1980s, I worked for an ISV doing hotel reservation software – both as packaged software and as a service. We bought and hosted a mini computer, wrote a hosted application with shared logic and data and sold the customer green terminals and leased lines. We where hosting hundreds of hotels on this one physical, but logically separated system. Through the magic of configuration, different modules and customized UIs were presented to the user.

 

But maintenance fees for the mini computer was high, telecommunication was expensive and PCs where getting cheaper and more stable, so the trend shifted to packaged software that was installed locally at each hotel.

 

In the mid 1990s the trend seemed to shift back again with the rise of the Internet. Visionary people predicted that applications would be provided as a service over the Internet. Well, that didn’t really take of for a couple of reasons; the platform was immature, bandwidth was limited, connectivity was not reliable etc. There was also a big resistance in the market against having company data hosted outside the company and against some of the business models behind SaaS (such as pay per use). But the biggest problem, I believe, was that the ISVs where not ready with real SaaS applications. At that time, they where building client/server architectures with fat clients and the picture of what SaaS was really about got “clear as mud” when hosting companies offered these non-SaaS applications over Citrix etc. and called is SaaS.

 

Why this time?

Today this resistance seems be gone to some extent and we see more and more ISVs adapting the SaaS concept again. The benefits (such as no high initial cost, pay only for what you need/use, no local admin etc) seem to overshadow the concerns (such as security, integration etc). Today we see customers signing up for CRM solutions, effectively outsourcing their customer database including leads/prospects they currently work, over the public Internet. We see new business and payment models emerge with a big element of targeted advertising. Through the use of computers in everywhere (desktops, mobile phones, TVs, cars etc)  and by linking services from many providers together over standardized protocols (such as XML Web Services), we can take SaaS to a completely new level and provide services we didn’t even dream about in the late 1980s.

 

Architecture

Whether you do SaaS on a mini computer with green terminals and leased lines or if you do it on a cluster of PCs with browsers and broadband Internet connection doesn’t really change the concept – only the technology. The benefits for customers as well as the architectural characteristics and inherent problems remain:

 

The main architectural characteristics:

  • Designed to host multiple clients on separate instances on shared servers. This is sometimes referred to as multi-tenancy (analogy with multiple tenants in an apartment complex).
  • Designed for scalability and availability. Serving hundreds or thousand of customers from the same physical system requires a high degree of availability and changes for one customer must not affect up-time of another. And, as the number of customers grows, the system must be able to scale by adding servers which obviously requires the application to architected with this in mind.
  • High level of configurability order to service many different customers with the instances of the same application. White-labelling and skinning is also an important factor since the application can be consumed in many different ways. 

The main architectural problems:

  • Hard to integrate with local packaged applications. No application is an island, and if a company decide to use an ISV solution as a service, this solution will have to integrate with the locally installed applications and hardware devices. As an example from the hotel reservation system I mentioned earlier, we had to integrate with phone centrals, video check-out systems etc. With SaaS, it’s easy to provide check-out functionality for a cashier to use in a browser application. Then try to integrate this with a video check-out system (with a 10+ year old RS-232 interface) where the guest view/approve the bill on the TV and picks up the printed bill in the reception when walking out of the hotel.
  • Hard to customize to the same level as sophisticated packaged applications offer. Many sophisticated ISV applications allow customization at many levels through configuration and custom code. Customizations can be made by one or more VARs as well as by the end customer. With SaaS this poses some architectural challenges and security concerns. Can we allow VARs to upload custom code? What is this code allowed to do in order not to affect the other customers system?
  • Security. With SaaS there are many concerns around security. Just to mention a few:
    • Protecting data in transport between the service provider(s) and service consumer.
    • Storage of corporate data outside the company.
    • Identity and access management such as integrating the service provider’s identity system with the consumer’s identity system, very fine grained access control depending on who the consumer is etc. 

Talk to me and the ISV team in EMEA (Europe, Middle East & Africa)!

In Microsoft’s Technology Centre for EMEA based ISVs where I work, we have seen more and more interest for SaaS and we expect to spend a significant amount of time the next 12 month with ISVs giving architectural guidance on SaaS during our engagements.

 

I want to take the learnings from these labs and provide them as architectural guidance in this forum, but I would like to hear your feedback.

  • Do you already do SaaS or have plans to do so next 12 month?
  • What are the most important architectural topics that you would like to see guidance on first?
  • Other issues/concerns arouns SDLC process or tools that relate to SaaS
  • …

The ISV architecture forum is dedicated to discuss these and other architectural issues with ISVs.