Yesterday I set the stage for the 5Cs of Saas: collaboration, community, connectedness, completeness, and changeability. Today I'm going to focus on collaboration in SaaS. As I mentioned yesterday our team found, through customer interviews and research, that a motivating factor - one of the primary factors - for SaaS purchases is to allow seamless collaboration between parties in arbitrary (but well-defined) roles.
Well, what exactly does this mean? From our perspective it means that an actor using the software has full, role-specific privileges and experiences directly within the software. That is, there's no concept of a "portal" or any other external "connector" to the software. It also means that the provisioning of that experience is seamless to the actor doing the provisioning.
An example here might help explain this. Let's say we have a customer support representative using a customer service application. This person receives a phone call or other trigger causing them to describe a customer to the application. Now, in a typical application, this means that there's a user, the customer service representative, and a customer. These two concepts are typically quite distinct in their semantics. The user has access to the application and, by definition, can use it. The customer is a data point somewhere in the application represented by a row in a database, but has been granted no additional rights.
In a collaborative world this model breaks down. There's a distinct difference in the caste model: in some way the user is a higher caste entity than the customer. The user can create new data items and fully interact in business processes. The customer is disconnected from the application and may be able to "interact" via some external connector (for example receipt of an email message or a message exchange).
What we found was that our customers want us to remove this divide. They want to see the customer as a first-class, privileged actor in the application. But, and this is important, they do not want the customer to be a user in the application in a way that either uses a license or requires a specific provisioning step. As you might see we have a bit of a dilemma here. Most business software written to date enforces this divide. We can't use the existing models.
What can we do about this? Well, we could fake it and create an additional layer on top of the business application which provides some level of interaction for the customer. But, this means that any customization that takes place in the core application must be duplicated in this additional layer. It's not only that, but any business logic or business process which is enacted in the core application must be augmented so that it explicitly takes this additional layer into account; and this business logic must typically be duplicated, often in a different way, in the additional layer. This doesn't sound like a good thing.
What customers want is a single application, with defined identities, playing well-understood roles to collaborate around a given business process. Additional layers only mean additional work. That is, customers want to treat their partners as if they are first class citizens in the business process.
I've been thinking about this software-as-a-service thing for many, many years now (prior to joining MSFT I wrote one of the first internet chat applications with my buddy Scott, and later on I worked on the leading internet-delivered skills assessment system). Clearly there are different camps and that's a good thing. It means we understand that there are different classes of needs and desires.
The recent push toward social networking (hmm…) has its roots in the individual or casual group. That is, social applications are about connecting people and groups based less on their work affiliations and more on those intangibles: likes, wants, and desire to belong. This aspect of the new internet has bled nicely into other application spaces, like the one that I work in.
My work for the last few years has been around creating great experiences in line of business applications. These applications are usually known more by their acronyms: CRM, ERP, ERM, HRM, etc. It's also interesting to note that these applications traditionally are not productivity applications such as Office, but are more about helping to automate certain business operations.
It's this concept of user though that made me start thinking hard about how social networking applications are changing the face of LOB applications. For the last year my team has been doing research into SaaS LOB applications to understand why customers would consider purchasing them instead of traditional on-premise software. There are a few easily guessable and recognizable patterns in the purchase decision such as security, cost-cutting, and availability. These were aspects that we assumed customers were looking for and we weren't overly surprised to find them.
What was surprising, at least to a number of people on the team (I'm not saying I knew this, but I suspected it) was that customers were beginning to purchase SaaS because they expected to collaborate seamlessly with their trusted partners. This was the basis for the work that my previous team was doing last summer and fall. What's interesting about it is that it goes against the core design of (nearly) every LOB application ever built.
I think of SaaS in terms of some additional intangibles: collaboration, community, connectedness, completeness, and changeability (the 5 Cs for now). For me it's not about multi-tenant architectures, or feature sets, or any of the other things that we as architects typically worry about. It's about how to create great experiences for businesses. I'll talk more about the 5 Cs over the next week or so and try to explain how this new web is having an impact on the status quo.