With so many people touting the advantages of cloud computing (me included), I thought it would be useful for my readers to also understand the dark side of cloud computing – issues to be aware of before consuming cloud based applications. Whereas I feel that cloud computing going to be disruptive for many business in terms of new business models, reduced costs and competitive advantage, there are genuine concerns with it today that also need to be openly addressed so that the consumer is aware of these issues and can make an informed decision as to whether or not cloud computing should be part of their strategy.

So without further ado, let us get in to some of these areas of concern:

• Outsourcing: This is an ironic problem. SaaS allows enterprise customers to save costs by outsourcing the cost of managing infrastructure and operations to the SaaS vendor. However, SaaS ISVs, especially smaller ones are really not equipped to, nor would they like to handle their own data centers and have the financial resources to employ people to manage that investment. So when cloud computing comes along and offers that ISV the ability to outsource that piece to the cloud vendor, many ISVs will jump at that idea. This outsourcing is going to happen at different levels and what that means for you as a consumer is that you don’t really know who is handling your precious corporate data because it might not be your ISV as you imagine.
• Data Security: The above point is a segue in to this issue. Your data is out there. Who has access to it? Who is viewing it? To make matters more challenging, many cloud vendors are not entirely transparent as to their infrastructure details, their server and storage configuration details, etc. So it is hard for you as a customer to really understand what goes on beneath the covers, resulting in (rightfully so), the consumer questioning the security of their data. So what is one to do about this? There are a few solution, one of which is to consider a hybrid deployment model, where you leverage the cloud for computation muscle and store the data in servers behind your firewall. Each approach has their pros and cons, which is a discussion on its own, so we will leave that for a later time. Another issue has to do with where your data is residing – whereas you can use SSL or PKI or SAML to encrypt your data using tokens or certificates as it passes through fibre optics, what really happens once the data reaches it’s destination. Is it still stored in encrypted form? If so, what encryption is being used? Who has access to the keys?
• Compliance: No need to harp on this – SOX, HIPAA and other such government regulations are enough to keep the CIO up at night. Add cloud vendors to the mix and your data possible residing in the cloud and that leads to many eyebrows being raised. The solution here is to work with the cloud vendor to understand their willingness to provide the necessary security and audit logs that you will need to comply with such regulations. Any vendor that does not provide this is obviously not suited for your needs if you are an enterprise level consumer. If you are provding software for the end user (like photo storage) then this is not an issue for the end user.
• Cross-country Data Migration: This has multiple implications. Since you do not know where your data is stored, this can impact performance of your application if your processing module is not close to your data that it is acting upon. What this also means is that now, since your data could be anywhere (literally), there are data privacy rights and acts that come in to play (for eg: if you data moves to Europe, are you complying with their data privacy laws?). So these issues need to be thought through. You need to be able to discuss these issues with your cloud vendor and ask if they are able to provide you the appropriate documentation that shows that cross-country privacy laws are being addressed and respected. Again, this also applies to the enterprise customers and not the person who is simply wanting to upload their family photos or use S3 as their personal MP3 storage because as far as I am concerned, I don’t really care if those photos are residing in Delaware or Damascus.
• Data Availability: What happens if the cloud goes down? How do you get access to your data? What if you do not have an Internet connection at the airport, but want to access your data somehow using the application? Whereas the latter is an architectural concern for providing data availability, the former has to do with SLAs. You need to understand what your vendor will commit to in the form of up time and availability and what is the consequence to the vendor if those SLAs are not met. At the end of the day, a water tight SLA still does not guarantee downtime, it simply acts as insurance.
• Data Recovery: This goes hand-in-hand with the above topic. If your data is not available or is completely wiped out due to a disaster, can they replicate that data for you? How soon? How much of it?
• RASP: Whereas a lot of what I have discussed above are things you should ask your vendor, there are other things that you need to do yourself to make sure your cloud strategy is bringing you the desired results. RASP stands for reliability, availability, scalability and performance. Whereas the first two might be somewhat the responsibility of the vendor from an infrastructure perspective, the reality is that you are really responsible for all four from an architecture perspective. RASP should not be left to the cloud vendor. You can depend on them to provide some level of automatic RASP, but at the end of the day, you need to give thought to architected RASP and bake that in to your application architecture in the event that your cloud vendor goes down. There are many architectural decisions that need to be considered when designing an application in the cloud and these decisions are just as important as the questions you ask your vendor. Again, this is a topic on its own and we will discuss architectural implications of cloud computing in another post, but it is worth touching upon here.

So as you can see, these are just some of the issues to be aware of with respect to cloud computing. At Patni, we work with our customers to provide cloud computing workshops where we cover these and many other topics to provide guidance and service offerings around cloud computing to both the ISV and enterprise customers.

With so much hype about cloud computing, the question that many architects are thinking about is how do I go about building a product or application in the cloud? How do I start? What do I do? What challenges need to be overcome? Well, whereas this post does not go into answering all these questions (at Patni, we provide a methodical approach for ISVs and enterprise customers to embrace cloud computing based on assessments and interviews), I will aim to talk about cloud based architectures and what it means to be leveraging the cloud in your architecture.

So what exactly is CBA? It is a software architecture that utilizes Web based on-demand services such that utilization of infrastructure and compute power can grow or shrink based on a myriad of factors such as server load, etc. CBA mean that you only pay for infrastructure and storage that you actually use rather than paying a flat monthly fee for a limited amount of resources.

The next question to ask is why CBA? What business problem are we solving here. As per my previous post, provisioning and configuring servers before deploying, testing and migrating your product or application to production has been, and continues to be a long and arduous task for IT departments. In addition, server maintenance, management and monitoring take up a lot of time, money and cost just to keep the lights running. Also, with many servers in a data center, enterprise customers are not making the most utilization of these servers (yes, virtualization does help here). In addition, most startups and consumers do not have access to vast pools of money to build and host their product on these expensive, clustered servers. That is where leveraging cloud vendors to build cloud based products can be game changing.

The next question is how? How does one utilize the power of the cloud on-demand, when needed to scale up or down, ensuring that they are not wasting money and people on idling servers and thereby reducing their overall cost of ownership? The answer is via APIs or Web based services. The complexity and reliability issues with invoking these services are hidden away (in the cloud) from the consumer of these services. All you care about is that when you invoke the service, that the service does what it needs to (provide you a new server, more memory, CPU, storage or whatever) and that when you are done, it does all the hard work of tearing things down and cleaning up after you…all for very reasonable rates – much cheaper than you managing and maintaining all this yourself. How powerful is that?

So in summary, one can see that there are many potential benefits of CBAs:

• Minimal upfront costs for infrastructure and manpower
• Faster time to market by focusing on your core competency
• Scalable, on-demand infrastructure as and when you needed it
• Pay-per-use costing structure
• Parallel processing across the cloud

These are just some of the generic advantages of CBAs. When you dig deeper and focus on ISVs and enterprise customers, there are many more. It should also be noted that there are many potential pitfalls as well. Designing and deploying in the cloud means thinking through a variety of issues around performance, data security, data partitioning, scalability, business models, and much much more.

At Patni, we work with both ISVs and enterprise customers to help them build products and applications in the cloud, while helping them understand these potential architectural, operational and technical issues. I will write much more on the topic of cloud computing and CBA in the coming weeks so stay tuned!

Enterprise customers that are building in-house applications are often faced with a lengthy process of procuring and provisioning infrastructure before their applications can be deployed, tested and made production ready. Even if infrastructure is available, it has to be prepped and assigned to the relevant department before any meaningful work can be done. Similarly, ISVs who are pursuing a Software-as-a-Service (SaaS) strategy to take advantage of the long tail, economies of scale, and reduced development and testing cycles are faced with a whole set of new challenges around managing and maintaining the associated infrastructure and SLAs. What this means is that enterprise companies and ISVs are spending a lot of time, money and energy on tasks which are not really their core competency – procuring, configuring and managing infrastructure. Imagine a world where they could focus on just building their product or application and tap in to a massive pool of infrastructure as and when needed, configured to their environment within seconds and readily available on-demand. That is the promise of cloud computing.

Cloud computing is a style of computing where massively scalable IT-related infrastructure and capabilities are provided to multiple external customers “as a service” using Internet technologies.  It is the latest buzzword in the IT industry and enterprise customers and ISVs are only now starting to dig deeper to understand and utilize this powerful concept for their business benefit.

However,  just as with any new buzzword, customers who wish to build, deploy and consume products and applications in the cloud are faced with a myriad of challenges. Right now, there is a lot of confusion around cloud computing with different terms like grid computing, SaaS and Platform as a Service (PaaS) being thrown around by the industry. Aside from this confusion, there are many business, technical, operational and marketing related decisions that an ISV or enterprise customer needs to make when developing or consuming a product in the cloud. I will be writing a series of articles on cloud computing based on the work that I do at Patni (develop a comprehensive set of service offerings around cloud computing that provide both the ISV and enterprise community guidance to help build and consume products using cloud computing technology).

At Patni, one of the things I am responsible for is structuring our service offering around SaaS and going to our customers to understand their SaaS related initiatives and discuss how SaaS can play an important role (or not) in their product or enterprise strategy going forward. As part of this initiative, I am often asked the question – “how do we architect for multi-tenancy and how do I know if that is the right approach for me?”. Some customers want to do multi-tenant architectures because they feel it is a buzzword that needs to become a part of their marketing collateral when they market their SaaS product to customers. Some feel that it is absolutely needed from an architectural perspective for their product to scale. Every customer has their own views and perspective on this and it is interesting to have these discussions with them and walk them though why it might or might not be critical to design a multi-tenant architecture each and every time.

First of all, ISVs needs to realize that their customers don’t care about multi-tenancy. Their customers probably have not even heard of that term, talk less of knowing what it actually means. All the customers care about is consuming the SaaS product and paying a subscription fee or having to view ads (whatever the monetization model might be). So, from a consumer perspective, multi-tenancy holds no water. They simply don’t care. But from a provider perspective, it might be very important. Not every SaaS implementation has to be multi-tenant. Yes, it is often highly desirable to pursue a multi-tenant architecture to achieve economies of scale. However, before embarking on designing such an architecture blindly, it is useful to analyze and understand the pros and cons of a multi-tenant vs. a single instance architecture.

At it’s core, building a out a full scale multi-tenant architecture means giving a great deal of thought on the overall database architecture, the resulting schema, the way the code has to be written to leverage the additional primary and foreign keys, thoughts around additional code for security now that data is shared, and much more. In essence, following a multi-tenant architecture means more complexity and costs up front. This is very similar to building a SOA based application. There is more work involved in baking in all the though around common services at development time. On the other hand, the costs of building out an isolated architecture.

On the flip side, a multi-tenant architcture, by its very nature is centered around economies of scale. This means that hosting and managing a multi-tenant architecture should result in cost savings when it comes to infrastructure, utilities and man power. This is the exact opposite of an isolated architecture, which typically needs dedicated databases, more servers, higher energy bills and more man power to handle all that complexity.

So it is important to realize that multi-tenant is more than a buzzword and as such, should not be blindly baked in to any product. It has real consequences (such as increased time to market for a product that needs to implement multi-tenancy upfront due to increased upfront complexity). Analysis needs to be done on the tenant population in terms of numbers of tenants, pricing strategy of the ISV for this new product, etc to determine if that increased upfront cost will be met based on how many tenants will subscribe or if the pricing is in line with the costs associated with the complexity. If the number of tenants might be small or the pricing cannot be set at a level where the breakeven might be achieved in a short timeframe, then there might not be a real incentive to go multi-tenant. Furthermore, there are other ways to achieve economies of scale by using virtualization and cloud computing, so those too need to be factored in when making such decisions.

Bottom line: yes, multi-tenancy is a very important concept for many ISVs, but it is a concept that needs to be thought out from many different angles before deciding on whether or not it should be an integral part of your product architecture.

Sometimes, monetizing does not necessarily mean cash in it’s purest form. The latest trend in social gaming is to leverage friends as cash. In other words, online games are allowing you to gain that special armor or get virtual cash or new clothes by inviting a friend to the game. Want the best race car available but don’t have the cash to buy it? Invite 20 friends and it’s yours!

An off-shoot of this trend is to allow friends and players to trade virtual items and keep a cut of all monies exchanged. Players win because they get new items they did not have before and don’t have to earn it. You win because you make money from the transaction. You also act as a go-between, making sure the transaction is conducted safely and securely, thereby allowing you to charge for it.

Today, I wanted to discuss an up and coming segment in the gaming arena that is starting to get some serious traction – the area of serious games. Serious Games is a term given to a category of games that provide a form of educational or training experience to the gamer, as compared to leisure games that provide more of a fun factor with little or no educational component to it.

With the boom in the gaming industry, coupled with educational institutions, government organizations and companies fighting for customer attention and dollars, it was only a matter of time before they put 2 and 2 together to fuse gaming with education/training to capture the attention of customers in new and innovative ways. In fact, with the popularity of virtual worlds like Second Life, virtual worlds are not becoming a popular channel to both host virtual environments and teach/train. This post will discuss my thoughts and findings of what is going on with serious games, what the challenges are and what are the future trends.

Serious games and virtual worlds offer great potential for people to learn about different topics by stepping in to a lively, fun, often 3D environment, where they can become a different person, get a visual and hands-on experience and engage in a highly creative form of learning using an extremely engaging user experience. The more fun the experience, the more likely the person is likely going to want to learn and more importantly, retain what they have learned.

The possible business applications of serious games and virtual worlds are almost limitless – from school based education material (teaching Math, Science, etc) to streaming lectures to remote collaboration to medical research, military training and much more. Think about students being able to conduct lab experiments in a virtual space or learning how to load, use and tear apart a military weapon online. Or how about walking through a virtual recruiting campus, meeting virtual recruiters and giving them your resume all without leaving your house.

An interesting example of this trend is the emergency training sessions led by Stanford University and being piloted using Forterra. Previously, every time an emergency training session needed to be conducted, Stanford was closed down to allow involvement of different organizations including medical and police forces. For the last two years training has been taking place in the virtual world and this has allowed distributed teams to role-play serious incidents using real people to play act victims and for the trainees to undertake lifelike training. This form of application has real potential for training with different organizations and allows Stanford to create many different mock up scenarios.

Leisure gaming (casual gaming), especially online gaming is growing at an alarming rate (and with it, new innovative business models to monetize online gaming), and serious games are getting a boost because of this trend in online casual gaming. The challenge is figuring out how best to use gaming to facilitate learning, while at the same time maintaining a high level of user engagement and entertainment. There are many different trends in this area which I will discuss in subsequent posts, but I will mention a few here – Alternate Reality Gaming (ARGs), Augmented Reality Gaming and Mobile Gaming are a few to begin with. In addition, virtual worlds and these trends are also impacting game play and game design. So there is lots happening in this space and lots for me to talk about in future posts.

Some of the other trends I see in this space is integrating social networking concepts, mashups, 3D Web and user generated content to create new and rich serious games. Studies show that if the game is flexible enough to either adapt to, or better, be created by the user community, users are better engaged and demonstrate increased learning. Serious games, like casual gaming, also has the potential to make use of rich media and integrate with various back end systems, making it very attractive to utilize such applications for a variety of different purposes. It is important to note that much of the flexibility to integrate will be provided by adopting a solid SOA approach.

In a future post, I will expand on the trends and usage patterns of serious games and give concrete examples of how corporations and institutions are adopting serious games and integrating them in to their overall business strategy. I will also discuss studies on serious games and if serious games are any more or less efficient and addictive than casual games.

In my previous post, I discussed social networks and started the thread on the different ways to earn revenue aside from the ubiquitous ad based model. In this post, I’ll continue the discussions and focus on another emerging way that social gaming companies are trying to monetize by leveraging prepaid cards. The debate is still on as to whether console gaming will some day go away as more and more gaming companies design online games thanks to ever increasing network bandwidth and cheaper hardware. There is a trend though for more and more games being developed and played over the Web, especially in the PC gaming segment. In certain parts of the world like Korea, where Internet connection speeds are very high, downloading games online and/or even playing games online are very popular.

To capitalize on this huge audience, gaming companies can either keep the games free and show ads. But like I discussed before, ads are annoying, often time targeted at the wrong audience and it is hard to determine ROI. Microtransactions are popular, but by it’s very nature of asking people to part with their cash, mostly via credit card payments, means that a huge segment of the tween and teen population cannot actively participate. That is where prepaid cards are a huge benefit. Big name gaming companies have caught on to this idea and are fighting to get shelf space in major name retail stores where they can display their prepaid cards and entice the younger community.

But what does this mean for smaller companies who do not have the dollars to compete for shelf space? If they are selling a physical product (like a boxed PC game), they could include the prepaid cards with the box and charge extra. But if you are selling an online product, then yes, it does mean that probably the larger companies with more marketing and development dollars will win the retail battle and dominate that space.

Either way, online gaming is a huge business – during 2007, online games in North America generated revenue of $1.6 billion. The figure is projected to surge to $3.8 billion by 2012, according to the Yankee Group, a Boston-based research firm. This only goes to prove that the prepaid cards method of monetizing social networks and social gaming is here to stay. What are your thoughts? Is your company using prepaid cards in unique, innovative ways? Are there challenges that you are facing on this front? I would love to hear from other companies who are experimenting with this, or other methods of monetization (future articles to discuss many other ways of monetizing social gaming).

Aside from focusing on emerging technologies such as SaaS, Web 2.0/3.0, Cloud Computing, etc within Patni, I am also tasked with creating the appropriate conditions for Patni to enter the animation and gaming space. As part of those efforts, I regularly keep up with the latest happenings in social media and social gaming and how companies can monetize social networks.

Social networks are everywhere. Every day, new companies are springing up that have some sort of a business model centered around social networking – whether it be online or mobile. The challenge is that most of the established social networks, such as Facebook and MySpace are finding it really hard to actually make any real money from all these people that are members of their site. What started off as relying heavily on an advertising model is very quickly becoming a barrier for these social networking sites for many reasons, one of them being that majority of the customers on these sites are much more interested in viewing pictures and profiles rather than viewing ads. Also, often times, the wrong ads are being displayed to the wrong audience.

It is clear that new, alternative monetization strategies need to emerge if companies developing online social networks are to become profitable. This is the first part of a multi-part series where I will discuss the various monetization strategies that are being used by innovative businesses to generate revenue.

The first of these new mechanisms is virtual goods. What exactly are virtual goods? They are essentially items that you can buy in an online community of game in exchange for fake money or credits that you earn for participation in the online community or for playing the game. Yes, you are right. In essence, virtual goods are nothing but binary 1’s and 0’s stored in a database with your user name or user id as a foreign key. But people are spending real money to buy these fake items online. Lots of real money! How much?

• Habbo Hotel has over 75 million registered avatars in 29 countries and 90% of their $60 million+ yearly revenue comes from virtual goods.
• Tencent is one of the largest Internet portals in China with over 250 million active user accounts. They generated $100 million+ in Q1 of 2007 and over 65% of their revenue comes from virtual goods.

So the main question that comes to mind is – Why on earth would anyone spend REAL money to buy FAKE goods online? Quite a few reasons:

• Engaging At A Higher Level: Anyone can send a wink or a nudge to someone for free. But on an online dating site for example, spending real money to send a fake rose or some other virtual item to the one I am interested in shows that person that I am actually interested enough in that person to spend real money to send her something she will appreciate – a virtual rose. It shows that I am willing to set myself apart from many others to do something special. And at the end of the day, whether it be online community members or gamers, many of us want to feel a higher level of emotional connection and virtual goods allow us to achieve that.
• Showcasing My Popularity: For gamers, it’s a great thing to be able to showcase all the things I’ve been able to buy or win as a result of my superior game play. Being a better player than others means earning more credits or virtual cash, with which I can shower myself with more online bling, which might not be available to other players, thus resulting in me being the object of their envy.
• Creating Value: If I can spend $20 and get 20,000 credits, which in turn allows me to get additional features in an online community or a brand new sword in an online game, then that might entice me to spend another 10 hours playing that game, bringing me a certain amount of happiness that I might not be able to get if I spent half that money ($10) to go watch a movie. So in essence, the virtual sword is creating real value for me in terms of enjoyment and experience.

The net of it is that virtual goods are spreading from MMOG communities to online social networking applications and social gaming environments. If you are in to social gaming, I would be curious to hear your thoughts on virtual currencies and virtual goods and if you think that they are the next big thing in social media monetization.

SaaS is the latest buzzword in the ISV space. There are lots of articles on the benefits of SaaS for ISVs which I will not go in to in this post. However, as some of my previous articles have discussed, there are some real problems with SaaS as well, which sometimes makes me think that SaaS is not always a boon for ISVs. Not having a well thought out SaaS strategy can be a real problem for ISVs who take the plunge without due consideration. So what are some of the real challenges for ISVs that are thinking about SaaS?

• Multi-tenant Architecture: I discuss this in detail in my another blog post, so I will not elaborate on this, but suffice to say that for on-premise ISVs, this sort of architecture poses many challenges such as designing for scalability, availability, security, etc.
• Customization: Many ISVs are challenged with their customers constantly asking for customization at the UI level, at the workflow level and/or at the database level. What are the approaches to architecting such customization abilities? What the are pros and cons of such approaches? What are the alternatives?
• Operations: Managing and operating infrastructure was never a core competency for many ISVs but having to do this due to SaaS brings many challenges and possibly a few options/solutions.
• Security: Another common issue with SaaS that ISVs are faced with – safeguarding their customer’s data.
• Integration: This is the focus of this post. Integration becomes challenge because at the end of the day, the ISV’s customers need to use their product, integrate it in to their enterprise architecture and get at the data. Or, the ISV often times need to make their product flexible enough from an architectural standpoint to integrate with multiple legacy systems, ERPs, CRMs, etc. Every customer might have different legacy systems with different data formats. How does the ISV get insight into these systems which are behind firewalls while architecting their products? When it comes to integration, this is one of the fastest growing areas in 2008 for ISVs to deal with.

So, what options does an ISV have to deal with the integration headache?

• Let the customer deal with it. There are many ISVs out there that just do not have the technical know-how, the time, the money or the resources to take on this additional burden. They let their customers figure out how to handle the integration challenges. This is fine for many ISVs, but the reality is that more and more customers are getting tired of having to figure out the integration issues by themselves. The other thing is that if ISVs want to really start differentiating themselves from the competition, they need to figure out how to help their customers with this problem. Any ISV that sells packaged integration solutions along with their product (for an additional cost of course) would get the attention of their customers and race ahead of their competition (given that they have a comparable product to their competition).
• Engage professional services: Some ISVs might have the time, money and resources to recruit, train and deploy their on professional services arm to augment their product sales. This is a dual strategy for earning revenue for the ISV (think IBM, BEA, etc) – both via their products and their professional services. But the challenge for the ISV is again time, money and resources. Smaller ISVs just do not have that kind of money and resources to build out their own professional services team. And even if they do, they are often a small team that are probably accruing Platinum Elite status on Northwest Airlines flying around all the time and being stretched to the max, thereby keeping customers waiting for someone to be available once they get off a project.
• Partner with System Integrators: This is a very feasible solution to this problem. SIs are working on integration issues day in, day out with customers in different verticals and it makes sense that they have the expertise and know-how to either go from customer to customer and help them build out these integration bridges or maybe even work with the ISV to build out a custom integration solution for different legacy platforms.
• Build their own integration platform: This would be the ideal solution for ISVs. Take the time to build out our own integration solution/platform/adapters and sell these or give them away for free to your customers as a value add to stand out from your competition. This is just as, if not more intensive as the option above and you will not see many ISVs take this approach.
• Leverage Integration-as-a-Service vendors: This is another feasible approach to the problem. Partnering with such vendors allows the ISV to get different kinds of integration goodies on demand. As and when ISVs need to add integration for additional legacy applications, ISVs an leverage the integration services provides by such vendors to solve the integration challenge.

In essence, I think that just like infrastructure and operations is not a core competency of many ISVs and many such ISVs are looking to outsource that by using managed hosting or cloud computing and virtualization services, integration too is not a core competency of many ISVs and pursuing an integration partnership with an SI like Patni would make sense for many ISVs. Patni has a deep understanding of legacy integration challenges and we have solutions to integrate to many different legacy environments, which can be packaged and sold as a value added service to the consumer of the SaaS product.

Let’s play a little word association:

What comes to your mind when I say 2008 NBA Eastern Conference Champions? Did you think of the Boston Celtics?

How about SaaS? Did you say multi-tenant architecture? I don’t blame you.

See, the words multi-tenant have been used so much in discussions around ways of creating a SaaS architecture that SaaS an multi-tenant are almost joined at the hip. But he truth is that not every SaaS solution needs to be multi-tenant. Not every architecture needs to be rewritten to be single instance, multi-tenant. Why? Because multi-tenant comes with it’s own set of challenges and without properly understanding that these challenges are and what alternatives might be better, ISVs might lose time and money just blindly re-architecting their products to conform to a multi-tenant architecture.

For those of you that are not familiar with multi-tenancy, please visit this post that I have made on that topic. From a perspective of lower costs in terms of infrastructure and maintenance, yes, it is very desirable to move to a multi-tenant architecture. However, doing so raises a slew of problems:

• Potential cost of re-architecture – Let’s face it, no IT service provider, Patni included, has a magic recipe to automatically make your on-premise product in to an on-demand product. So an ISV that is thinking about SaaS has 2 options – either re-build the entire architecture from the ground up or weave in multi-tenancy in to the existing product. Either way, it is going to be costly. And what about new features while the product is being transitioned from on-demand to multi-tenant?
• Security – One of the most often touted concerns from a customer perspective – is my data going to be secure? Often times, a lot of extra design and development needs to happen around the product and database to keep sensitive data safe since the data all resides in the same database in different schemas.
• Hosting – Even if an ISV is not hosting their own product, hosting for multi-tenant architectures needs a lot of prep work and that is why not all hosting providers can be a good fit for multi-tenant products. The database configurations, the shared infrastructure and other related issues can make it complicated sometimes to find the right hosting company.
• Increased operational and infrastructure costs and people skills – Although not a problem strictly associated with multi-tenancy but more so with SaaS itself, the problem is still worth mentioning. It is not easy to scale up suddenly to managing your own data center, servers, and the hiring of people associated with the SaaS infrastructure.
• Availability – Since you now have a single instance of the product servicing 100s or 1000s of customers, anything that the customer does either accidentally or maliciously could mean downtime for your application (things like an infinite loop, or a security breach or memory leak).
• Limited Customization – Whereas there are ways to provide customization at the data level, workflow level and UI level, the truth is that these options are limited when you pursue a multi-tenant approach. This becomes more of a problem when an ISV has an established customer base who have highly customized their on-premise product and telling them now that the new SaaS product will provide limited amounts of customization or worse still, break if you try to customize it beyond a certain point will just not fly with these customers.
• Rigid service levels – SaaS delivers the promise of one customer, but this is a boon and a curse to ISVs at the same time. Larger customers will often not be happy with the one size fits all service levels that most ISVs provide to all their customers and the main reason behind this SLA approach is because the ISVs want to keep customization to a minimum to better control rogue behavior and also because their product now is a single instance serving multiple customers over the Web. Many customers might not be happy with this scenario.
• Forced upgrades – SaaS makes it really easy for ISVs to do upgrades. They go from multiple service pack type of upgrades that need to cater to multiple environments to doing infrequent, small upgrades to their product. But this now means that customers are often times not give much of a choice as to which version they want to be on.

So as you can see, a multi-tenant architecture brings along with it it’s own set of challenges and one needs to think though these issues before deciding if multi-tenancy is the best way to go. When to implement a true multi-tenant architecture depends on various factors. The thing to keep in mind is that multi-tenancy is not the only way to go about architecting a SaaS solution. There are other alternatives to this approach, one of them being virtualization in conjunction with some level of multi-tenancy. Whereas a strict multi-tenant solution might be suitable for SMBs, larger enterprises with more acute needs and desires might not be too happy with a strict multi-tenant solution. This is where using a virtualization product from VMWare to provide for virtualized storage and hardware might be a good compromise.