Many are promoting two core characteristics of SAAS today: the ability to provide a multi-tenant service model and the utilization of AJAX as a vehicle to provide better than basic browser capability to diverse browser products. I don't completely agree with these promotions.

Multi-Tenant Capability
This represents the ability of a single architectural system to instantiate many uniquely similar but personalized services to a diverse user base. It's important to understand that a single architectural system should be capable of providing multi-tenant capability without instantiating duplicate executable environments (operating systems, virtual machines, databases, communication networks, applications, etc...). This is where multi-tenant architecture becomes very difficult. You want to reduce the cost and complexity of multiple systems and applications through a consolidated environment while keeping the system easy to manage, adaptable to change, cohesive with existing and new systems and be transparently flexible as it delivers a consistent individually unique service to different users and groups.

This requires a flexible data model that allows for unique service instantiation inside a data management environment without significant integrity and performance issues and a loosely coupled transaction and presentation system that will allow for significant adaptability and flexibility yet not introduce a significant increase in network latency and system manageability challenges. This can make multi-tenancy challenging as the scale of operations massively increases. This has led me to some thoughts about infrastructure needs multi-tenant architectures:

Transparent
It should be very easy to understand by the user, the developer and the administrator.
At the rate of new services coming to market, architects cannot assume they have much control over the training needed to develop, administer and utilize a multi-tenant system. This becomes more real as mashing architecture techniques are utilized to assemble a unique service from an aggregated subset of other disparate services. Furthermore, the transparency should promote a seamless experience for the user as the solution utilizes multiple capabilities from these other services or resources. You could describe it as a seamless experience in using, managing and developing.

Consistent response rate

Each service should present a consistent experience for end users, administrators and developers. While application developers will promote that personalized instantiation of the service for the user community, the infrastructure architecture must design a consistent performing experience to scoped user types. This is especially important on multi-tenant systems providing rich capabilities across WAN connections. Small changes can lead to significant performance variation if not understood. This would require refactoring infrastructure designs to strip out overt complexity and brittleness in any way.

Predictable outcomes

While consistent performance is important, it is not enough. It is also critical for architects to design a system that will generate predictable outcomes for the user, administrator, developer and other systems which use it. Banking transactions are good example. Customers should be able to predict that transferring money into their checking account increases the amount of money in that checking account. If it doesn't, then there is a serious problem. Now, multiply the impact of poor predictability for a large multi-tenant environment. It would be a disaster. Execution integrity relies on many elements to be successful in a large multi-tenant environment. Furthermore, if these instantiated services must collaborate or communicate with each other, then the complexity can increase even more.

Extreme Availability Design

Services must maintain a heightened level of availability performance for users, administrators and developers as well as other systems. While explicit contracts promote varying degrees of performance based on negations, Multi-Tenant systems often will have extremely high expectations of availability performance. If there is just one system architecture in a multi-tenant solution, then the availability requirements would have to match the needs of the most stringent user base. Otherwise, you could functionally decompose the multi-tenant solution into availability units. Each unit would be architected to meet the availability requirements needs of similar users. While this divide and conquer approach is something I promote, it does have a price; complexity and potentially higher capital cost.

Secure by Design

Code, architectural frameworks, networks, storage, etc... must all promote significant levels of security in depth with extreme focus on its impact to the solution and the ecosystem it operates within. While often easy to say, it is incredibly challenging in large scale or highly complex designs. Small changes can often lead to massive impact. Security design is no exception. I remember watching an architect enforce a security decision to increase security in the organization on a large complex environment that immediately lead to a self inflicted denial of service attack. This is important to understand.

With a multi-tenant model, security is even more critical. A breach, corruption of execution capability or data into one unique user service could impact all users within a short amount of time. Multi-tenancy must be capable of user execution isolation at extreme levels of protection.

Supportable

Multi-tenant systems must be consistently and predictably supportable at a very fast MTTR (mean time to repair) metric without compromise. This includes operating system and application patching as well as operating system and application provisioning. Furthermore, it includes easily buildable, testable and deployable capability without significant training activities needed. It must keep disaster recovery expenses, backup and recovery systems as well as all operational costs to a minimum as small increases in complexity can lead to a large significant operational impact.

The false promise of AJAX
There are a lot of professionals who have been promoting the magic silver bullet promise of AJAX. While it demonstrates a powerful way to design browser based interfaces, that promise is flawed as a silver bullet for SAAS.

AJAX represents an empowering technique with specific technologies to increase the richness of a browser. However, at the end of the day, you're still left with a browser and all the limitations it contains.

Browsers are general purpose applications for interacting with a large diversity of websites and services. While it's wonderful that their capabilities to demonstrate a rich experience have significantly improved, at the end of the day, you're still left with a browser. A browser is capable of doing many things and nothing equally well and equally terrible. It is still a least common denominator interface that isn't designed to take advantage of unique hardware a browser might be operating on. Also, browsers can only talk with servers; they have no intelligence of their own. The experience is lost when the connection to the server is lost. Hence, the browser is only as good as the connection capability it experiences.

From Microsoft's perspective, architects must begin utilizing the unique capabilities of different advanced client devices to a service. There will be many imaginative and highly productive devices which will be introduced in the next ten years. Does designing to a common browser really take advantage of its capability? No, it doesn't it represents a least common denominator way to demonstrate basic usage of a service to these devices while stripping away the differentiation of the client platform purchased.

Some would argue that AJAX is a way to provide a better interface on browsers which might be on all of these devices. However, it really reduces an organizations and users return on investment in the unique devices they purchased. Why buy a better device if the services utilized for it will not take advantage of its new capability?

Furthermore, these new services must be capable to operating in connected and disconnected modes and demonstrate richer connection topology options than the common browser to web-server. Connected and disconnected modes don't just imply connection with the general network; it could also imply just a lack of communication capability with a central multi-tenant service. If the connection to the multi-tenant service is lost, shouldn't the user have at least some partial functionality that doesn't need centralized capability? Furthermore, the traditional browser to server model is dated. It's time to expand our minds around more flexible and adaptive communication models. Rich client experiences should be capable of keeping and using offline data and execution capability and communicate with other services as well as other peer SAAS clients without always being dependent on a centralized SAAS server.

This is where smart clients become important for the next generation of SAAS architectures. Smart clients take advantage of the unique characteristics of the client platform. Also, they can operate in connected and disconnected modes. Furthermore, they can communicate with any server or peer client the architect wants them to. P2P will enable SAAS capability while reducing server, network and storage pressures on an organization (yes, even with a managed P2P network traffic, it can reduce heavy traffic loads to datacenter environments). With smart clients, I believe SAAS architectures have the potential to deliver richer experiences where users become more in control of their data and execution services, reduce impact on data center system resources and reduces complexity of deployment and support environment. People became more interested in smart clients because of two main reasons: 1) it can provide a rich interface that can take advantage of the client platform's presentation capabilities without significant developer investment resources (example: Windows Presentation Foundation), and 2) in connected or disconnected modes, it can provide rich capability from limited to full experiences communicating to multiple systems or directly with other smart clients.

From a developed product example: the next generation groove client will work well. Groove is currently a great rich client that is deployable from the web browser that operates in connected and disconnected modes. And finally, it can communicate directly with other groove clients on demand. Groove 2007 will represent the intelligent rich client for Sharepoint services and portal.

The battle for the collaborative, disconnected SAAS client.

While many have been arguing what the future competitive space in IT will be look like with AJAX applications completing with other AJAX applications in SAAS frameworks, most all miss the real competitive battle that is coming.

The future battle will be between who delivers the best collaborative service experience between clients and centralized multi-tenant services. I call it the collaborative service platform. Diverse technology camps will compete for the collaborative service platform just as they compete for n-tier architecture solutions today). The collaborative service platform will need to provide extreme rich client interface experiences as well as an extreme capability to provision, patch, and support these rich interface experiences. Also, this collaborative service platform must have the flexibility to transcend the limitations of client server based communication when needed. Ultimately, these new services must empower humans to interact with each other on a richer level with transparency.

SAAS has been promoted by many as the next big revolution providing basic richer services through a browser in a multi-tenant capacity. While multi-tenancy and richer browser capabilities are valuable, I believe we have to start architecting multi-tenant solutions while incorporating the rich differentiation of new client platforms in disconnected and connected capabilities with the ability of ad-hoc collaborative communities forming around these services without centralized service friction. This means we must be willing to architect, develop and experience the internet beyond the browser and sometimes, beyond the server.