An MSDN Architecture Chat About Software as a Service, with Gianpaolo Carraro


Diego Dagum
Microsoft Corporation

April 2006

Applies to:
   Application Architecture
   Software-as-a-Service (SaaS)

Summary: In the first of a new architecture chat series on the MSDN architecture center, Diego Dagum sits down with Gianpaolo Carraro, an architect on the Architecture Strategy team at Redmond to talk about Software as a Service (SaaS) and the implications for enterprise architects and Independent Software Vendors (ISVs). (5 printed pages)

This interview previously appeared in South Cone Architect Newsletter.

Gianpaolo, welcome. Thanks for taking the time to chat with us.

GC: No problem. Great to be here.

So please introduce yourself, Gianpaolo. Tell us who you are, and what you do.

GC: Well, you know my name. I lead the solutions architecture group in the Architecture Strategy Team in Redmond. We provide thought leadership and guidance around topics such as SOA, Software Factories, and Software as a Service (SaaS), of course. Fred Chong in my team is the key architect on the SaaS architecture guidance. You might remember him for his work around identity in the past few years.

Great! The first question I have is for those architects not yet aware of what SaaS is. So, what is Software as a Service?

GC: Simply put, it is "Software deployed as a hosted service and accessed over the Internet"—as opposed to what we call "on premise," where the software is deployed at a customer site. There are several "flavors" of SaaS: some target the consumer market and are the base of many "Web 2.0" companies (photo sharing, e-mail, and so on—for example, Flickr and Hotmail). Others target the Enterprise Line of Business (LOB) applications market (for example, I tend to concentrate more on the LOB ones. Note that, although there are some differences, all the "flavors" are fundamentally very similar.

Is it just a re-launching of the former Application Server Provider (ASP) model, or do both commercial models differ in some way? Maybe some of our readers may think this is the same concept with just a new name.

GC: Those readers would not be completely wrong. Both ASP and SaaS allow customers to access software without hosting the software themselves. However there are large differences: ASPs were hosting an application for you, but usually you were paying the software through a "regular" license (typically an initial high license fee, plus yearly maintenance). You would be paying the ASP for the hosting; the hosting of the software was the service offered by the ASP, not the software itself. Also, ASPs usually hosted one customer per instance of the software, and therefore were not benefiting from the economy of scale of multi-tenancy. SaaS Independent Software Vendors (ISVs), as we describe above, offer the software and the hosting as one package. Also, most SaaS ISVs have multi-tenant architectures, and therefore can offer their software at a more cost-effective price. There are a few "survivors" of the ASP era who are now repositioning themselves as SaaS hosters, providing a set of shared services (metering, billing, dynamic provisioning, and so on) to SaaS ISVs so that they don't have to build those themselves.

I see. Compared with the traditional ASP, SaaS implies outsourcing more than infrastructure. So let's imagine I am a software architect in a traditional companysay, a bank, a retailer, or a telco. Why should I be aware of this software delivery model? How do you consider SaaS impacts current enterprise architectures for this kind of company?

GC: There are two types of "impact," the first related to delivering the software as a service, the second related to consuming software as a service. From the consumption side, there are a lot of similarities with consuming a Web service hosted by a partner in a B2B scenario; a typical issue is integrating services with the local "in house" systems. Another big change compared to "on premise" software is the configuration/customization aspects. With SaaS, there are usually less customization options, and in many cases, there is no possibility to add custom code. This said, advanced SaaS companies offer customization options through detailed configuration of their software through the website. From a delivery side, there are three important architectural aspects that need to be introduced: multi-tenancy, scale, and customization, whilst also attending to reliability, performance, and, above all, security concerns.

These are today more a preoccupation of ISVs, as they are (mostly) the one offering SaaS. There are some enterprises I talked to who want to deliver SaaS and, in some respect, become partly ISVs. These enterprises are interested in offering SaaS to their subsidiaries or to their franchisees. Imagine a large petroleum company wanting to offer software to their thousands of retail stations (that is, gas stations) which they often don't directly own, or a large fast food company offering some promotional software to their various retail outlets (franchises).

I understand: it offers an opportunity to those retail channels of improving efficiency, without being worried on technical details. So, now, let me change tracks here: I'm the software architect of an ISV or any other kind of software company. If the SaaS model prevails, what should I consider when I think about architecting SaaS-based applications? What do you believe will have to change?

GC: For ISVs the impact on the architecture of their software can be quite dramatic. Actually, it really depends how much they really want to benefit from the SaaS model. To better explain this, we came up with a basic SaaS maturity model.

Let me give some of the key points. Technically speaking, you could decide to change nothing about your current architecture, and offer SaaS through some remote desktop technologies (Citrix and so on); I met a couple of ISVs doing this. It allows them to test the market without much re-engineering, but they quickly hit the limitation of this model. If an ISV really wants to reap the benefits of SaaS from a cost structure perspective, there are three areas where the architecture has to be altered. First, the architecture must allow multi-tenancy (that is, hosting several customers on a single instance of the application, hence maximizing the sharing of the resources); the analogy comes from a building "tenant." Imagine a big building (a skyscraper) with common infrastructure (common elevators, common hallway cleaning, and so on) and apartments in the building rented to many tenants. With this model, you can achieve much higher economy of scale than selling a house to each customer. This brings us to the second point: customization through configuration. Similar to the building analogy above, not all apartments are the same; one bedroom, two bedrooms, some have a balcony, and so on. Allowing customization to each of the "tenants" is important, but because the software is shared by the tenants, the customization cannot be done via custom code, and needs to be done via tenant-specific configuration. The need of a rich metadata environment and of a metadata service in the architecture is important. Finally, the third point is scale. When you sell your software "on premise," you need to scale to the size of the enterprise you sell to. When you host the software and deliver it as a service, you need to scale to of the sum of all the customers you will have. Scale practices similar to those used by large Internet sites (Hotmail, Amazon, Ebay, and so on) are often required.

These three architectural points (multi-tenancy, customization, and scale) are the core of the architecture guidance we are creating. We recognize that the other concerns mentioned earlier are essential but will be treated the same as with any other high assurance system.

Definitely a big challenge for those architects. So let's revise the whole picture: we have, nowadays, concepts like SOA, connecting silos, coarse-grained services, and so on. How, from the point of view of a traditional company, doe SaaS fit in the service-oriented architectural style?

GC: I see SOA and SaaS as different architecture styles relying on a same set of principles. In other words, I see them as "cousins." A colleague of mine, Fred Chong, uses a good analogy: he calls this the "healthy lifestyle." Whether you are a pro football player, a basketball player, you rely on healthy lifestyle principles: eat well, sleep at least 8 hours, exercise, and so on. But soccer and basketball players rely also on specific training. So, SaaS and SOA share the underlying principles of service orientation, face similar issues around federated identity, rely on similar technologies, and so on, but are optimized for slightly different use cases.

The way SOA is usually defined is more around Enterprise Application Integration (EAI) or business to business (B2B) patterns. Single Sign-On, Business Process Automation, Entity Aggregation, and so on are important architectural topic to master in SOA. These aspects are also part of the SaaS architecture, but SaaS is often optimized for multi-tenancy, shared resources, and automatic provisioning. Also, some specific shared services, such as metering, billing, and so on, are often more important in SaaS than in SOA, even though SOA cannot overlook them.

It seems that, although both architecture styles could face similar aspects, they do it with different intensity. Some days ago, I was telling a friend of mine (who is an architect) about SaaS. We were chatting about a commercial SaaS provider, and he asked me what happens in the case of someone who wants to end the contract with that provider. He asked me what happens with all the data loaded on provider's infrastructure. Who does own that data?

Now, I realize you probably can't answer that question. But how mature do you think this commercial model is in terms of data property and long-term availability beyond the duration of the service contract?

GC: The data is owned by who has the best lawyer! (I'm kidding, of course.) I think this raises a very important point. Not being a lawyer, I cannot comment in terms of what type of contract one has to put in place to guarantee data ownership, and so on, but what I have seen several times is the SaaS provider sending large zip files (for example, on DVD) with the data, so that it can be stored/backed up at the customer site. Data being hosted outside of the boundaries has also an implication on reporting, data warehousing, and so on. When hosted, access to the data is limited to the APIs offered by the SaaS ISVs; when "in house," the data can be accessed "out of band" if needed.

In summary, I would say that you own the data even if it is hosted outside of the firewall, but because it is hosted there, the hoster might have some rights of access to it. Think of how major commercial e-mail providers use data of your e-mail (hosted at their site) to provide you with advertisement. Is it a plus? Is it a privacy issue? I will let you judge.

Here in South Cone there are lots of software factories extracted from original IT areas of multinational companies, as a way of applying economy of scale

GC: I am not sure what you call software factories in this context. I assume they are some sort of software center of excellence building software for the entire group.

You are right, Gianpaolo. The term "software factory" is common in Latin America and Spain when you refer such kind of inner outsourcing. What I know of these companies is that they create and maintain software for their subsidiaries in Latin America, but still the infrastructure is owned by every subsidiary, and software is packaged and delivered in the classical way. In most of cases, the software tends to be a same core with local customizations.

I guess that SaaS model would fit well in these companies. So the question is: If these software factories would be interested on SaaS, is there any kind of guidance we could deliver to them, in order to be successful from the very beginning?

GC: This is exactly what I was describing above, where some large enterprises I talked to in the US are looking into offering Software as a Service to their subsidiaries, branch offices, and franchises. Because some of these locations could not function if the software delivered as a service was down and would result in big losses (imagine a point-of-sale solution for a retail store as a service managed by the store chain HQ), I have been discussing hybrid models, where the solution can work temporarily offline. By the way, the hybrid model and offline access to SaaS is another big topic. Assets that we have at Microsoft with Office as the front end, WinFX, SQL Service Broker, and BTS as the "glue," and SQL in the back, are an excellent platform for these types of scenarios.

On to implementationnow I know you really are an architect.

So, we are almost up with our time. Before we go I wanted to ask you about your Birds of a Feather session at the SaaS Summit in Napa Valley last month. What was your session about?

GC: Yes, Fred and I held a session at the SaaS summit, mainly around the architectural issues I described above: multi tenancy, scale, customization in a shared environment. It was interesting to see how little awareness there is around those issues, even for companies that have provided some sort of SaaS delivery of their solution. With the momentum that SaaS has, and hopefully with some of our help, this will change soon.

What do you believe they were actually worried about?

GC: Some attendees were business folks, so there were also some discussions around monetization (how do I make money with this?); we discussed the various models: subscription model (monthly fees as opposed to the perpetual license), as well as the ad-funded model. Another business question was the impact on sales people compensation. How should they compensate their sales guys, now that the big bucks sales are replaced by smaller monthly payment?

From a technical side, the main worry was around trust. Can I trust a small ISV to host my data? Is it secure there? What if the ISV disappears (goes bankrupt)? The other side of the coin was also discussed: how to gain trust as a small player in this industry. The consensus was that the hoster could be the trusted source. For example, if a small ISV was to be hosted by a big telco, then the trust level would be much higher.

Excellent. Gianpaolo, I truly thank you for your time today and wish you luck with your ongoing work in the SaaS space.

GC: My pleasure, Diego—it was fun! If any of your readers want to continue the discussion, the relevant blogs are: and My e-mail address is gianpc@ you know the company. :-)