Cloud Computing – An Intro

What does this latest buzzword mean and how is the industry leveraging this technology for business benefit?

Multi-tenancy – Do I Need It?

How do you know is a multi-tenant architecture is always the right way to go?

SaaS: A Boon Or A Curse For ISVs?

Just as SaaS offers so many benefits to ISVs, it also brings along it’s own share of headaches. This article focuses on one such particular headache – integration.

Problems with multi-tenancy

Yes,the often touted multi-tenant architectures for SaaS comes with it’s own set of baggage and might not be the best solution for every SaaS ISV. Here’s why.

SaaS Ecosystem

Who are the players in a SaaS ecosystem and what are their specific concerns? This article talks about this in greater detail.

The 3 Horsemen for ISVs

For startup ISVs, these 3 emerging technologies can make all the difference.

SaaS Governance

The other day, I was talking to a company that posed an interesting question to me – they are a typical ISV developing on-premise software products, however, they have a need to develop and expose certain (hosted) services that need to by consumed by their end customer, which these customers can customize to a certain extent. So the question was - who is responsible for supporting these services if something does not work and how do we know what the underlying cause of failure was so that we can determine who is at fault and who should be fixing the problem?

It’s a very good question, because this ISV is entering a hybrid model – where their on-premise business model is now complemented by their hosted services model (not really SaaS because it might not be a multi-tenant single instance architecture). Before, they could create their product, package it, sell it and then let the customer worry about the operational aspect of it – if there was infrastructure downtime, it was the customer’s headache. But now, if the customers consume these hosted services which they can also customize and something goes wrong with the service, who now supports the problem? Was the problem due to the customizations that the customer did? If so, is it the customer’s problem? If not, then it should be the ISV’s problem. And how does one determine what caused the problem in the first place?

This is an issue many ISVs who are moving to SaaS struggle with. Every SaaS customer should have the ability to customize – customize the UI, customize workflows, customize the data model to extend it to suit their needs. Yet, every SaaS provider is faced with the challenge of providing uptime while at the same time allowing their customers to tweak the service. So how does the provider and consumer figure out who is using which service, when, under what conditions and what should be done in the event that something goes wrong?

That is where SaaS (and in general, SOA) governance comes into play. Governance is one of those overused words that is thrown around casually and it can mean different things to different people. Governance to a developer means something different than to an auditor. Governance, especially SOA/SaaS governance is about conformance and compliance. Are my developers writing code that complies with my Enterprise Architecture standards? Are my developers conforming to the standards and frameworks that should be used for developing certain products or projects within the enterprise? How are my product/project artifacts being advertised to other development teams? Who is reusing my artifacts during development, on which projects and how much time is it saving them? Who is consuming my service at runtime? Is the service doing what it advertises it does? All of these questions, and many more, fall under the realm of governance. Keep in mind that what I am talking about here is mostly SOA/SaaS governance, not IT Governance, which encompasses many other things like architecture, data and infrastructure governance, corporate governance (SOX, etc), disaster recovery and business continuity, etc.

So coming back to SaaS governance, how can it help this ISV to solve their problem? The answer is Service Level Agreements (SLAs). Most product companies do not have a lot of experience when it comes to crafting SLAs, simply because it has never been a concern for on-premise product companies. As I mentioned before, they are used to creating software, packaging it and selling it under a license and once the product is sold, it’s deployment and operations are now really the concern of the customer that just bought the product. However, SaaS brings with it it’s own set of challenges for companies, in particular ISVs who are now held responsible for the operations of the service that they are selling. So what exactly is an SLA and how does it help protect both the service provider and consumer?

In simple terms, an SLA is a a contract that exists between the SaaS provider and their customer that describes the level of service that the provider will provide and the customer should expect from that service. It details the availability, performance, operations and other areas of relevance to the service being provided and in many cases will even provide details around the penalty should these terms not be met. For the provider, it is a way to set realistic expectations for their customers. The for consumer, it is a way to hold the provider accountable should the provider violate the SLA agreement. The point of importance here is that the SLA should not be loathed by the provider or be seen as a way to hold the provider hostage by the consumer. It should be viewed as a way to open up the communication channels so that both parties can come to terms on what is acceptable and should be used as an objective way to measure usability, quality and accountability by both parties. But make no mistake, there is some level of negotiation that definitely happens as part of crafting an SLA. An SLA goes into great detail outlining the availability, reliability, performance, the types of support available along with the associated timings, penalties should these metrics not be met (usually in the form of credits), classification of problems and associated response times, etc.

In summary, it is important to remember that an SLA is not a guarantee of service uptime. It is merely an insurance policy. However, it is an absolute must for both service provider and consumer to have an SLA in place so that both parties are protected in the event of an event. In my mind, an SLA is not just there to benefit consumers. Just as providers have a responsibility to their customers to provide their service in a highly reliable, available and scalable environment, consumers too have a responsibility to use the service responsibly, to not interject anomalies into the system by trying to do something that is not supported by the provider which should be clearly states in the SLA, etc. The SLA helps to open up communication between both provider and consumer and helps manage customer relations.

SaaS Pricing and Metering

I apologize for my long absence from this blog. A lot has been happening of late that has kept me quite busy. For one, I’ve been busy formulating solutions and service offerings for some emerging technologies such as SaaS and Enterprise 2.0 for my company. Plus, I’ve also been putting a business plan in place to start an animation and gaming practice within Patni and in order to get the ball rolling, there is lots of data that I need to put together to get the action plan together. On top of that, I just came back from a Vegas trip, where my company had a sales conference and anyone that’s been to Vegas knows that you need a few days to recuperate after a Vegas trip

Anyhow, I wanted to spend some time today discussing a topic that does not get as much attention as the usual areas of technology, architecture and multi-tenant data architectures that are more commonly associated with SaaS. That topic is about pricing and how to price a SaaS offering. SaaS brings many different challenges with it – architectural challenges, business model challenges, operational challenges and sales/marketing challenges. Of these, a lot is written about different SaaS business models, the technical challenges of designing a multi-tenant architecture and data models as well as the infrastructure and operational challenges of maintaining increased uptime. However, what are the pricing, metering and billing challenges that a company faces when they move to a SaaS model. That’s what this article is about.

The challenge with pricing has two dimensions to it. For one, ISVs need to figure out a pricing strategy that does not alienate their existing customers – ISVs need to figure out a way to prevent their existing customers just from all of a sudden just dropping their existing on-premise (OP) software packages in favor of the new on-demand (OD) version. At the same time, once pricing is established, ISVs need the infrastructure to property monitor usage (billing and metering).

Let’s look at the first dimension – pricing strategy. A key point to remember when making the switch to SaaS is that you no longer get a big fat paycheck when you sign up a customer. As I mentioned in my previous post on SaaS, there is a trickle effect with SaaS revenues – they start at lower levels than traditional OP software and come in over time due to the monthly pay cycles. With many ISVs pricing their monthly costs at less than $100, it is not easy to start seeing substantial revenue using a SaaS model early on. In addition, it is not easy to upsell or cross-sell your customers on additional value services all the time. Hence, there is no one pricing strategy that is a fit for all scenarios. ISVs need to figure out if they want to charge per user, or per account or per transaction. Gauging your customer’s price sensitivity becomes a hard thing to do given that a SaaS model means less reliance on channel partners. So what is an ISV to do?

That is where a company like Patni can help. As part of our complete solution offering in SaaS, we help you figure out a concrete roadmap on how to establish your pricing strategy by examining the business value of your software and how your customer will utilize and consume your product. Customer utilization patterns need to be studied and that factors into how the product will be priced. Another factor to consider is what the competition is doing and how much more value add is offered by your product in order to command a premium (or not). The bottom line is that ISVs need to factor in a multi-tiered pricing strategy to successfully implement a SaaS solution.

Once a pricing strategy has been formulated, the next piece of the puzzle is developing a metering and billing solution that can handle this new pricing mechanism and report results on usage. Whether you choose to build this in-house or customize an existing COTs product, Patni can bring their metering and billing expertise to the table to help you either build a complete customized solution from scratch or enhance and customize an existing product to meet your needs. At the end of the day, it is important to remember that a metering solution can be extremely complex depending on the ISV and their pricing strategy and needs to factor in a lot of data collection on usage and pricing on a per customer and contract basis. A good metering solution needs to collect relevant data around users, CPUs and hardware, transactions executed, workflows and business processes and a host of other metrics to be able to allow the level of flexibility and scalability that a proper SaaS solution billing framework needs. This is where a proper SOA implementation in your enterprise becomes very important. SOA allows us to effective monitor and manage some of these data points and pass this on to the metering engine in an effective and non-intrusive way, thereby allowing for increased integration between SOA and SaaS.

So in summary, pricing is just as important a piece as the rest of the SaaS components and ISVs need to think through a pricing and metering/billing strategy to effective deploy and realize revenue from their SaaS based applications.

Multi-facets of the Multi-Tenant Architecture

There has been a lot of talk around Software-as-a-Service (SaaS). Many ISVs are exploring SaaS to achieve increased revenues and expand their customer base. With the advent of increased bandwith, customer demand, competitive pressures and increasing need for innovation, many ISVs are looking at alternative delivery models for their packaged software products (know as on-premise software models). 2008 is touted as the year that SaaS will take off. Whether that is true remains to be seen, but I thought I’d write an article on SaaS and the real underlying thought process that an ISV needs to go through when considering a SaaS strategy for their legacy product(s).

Multi-tenancy is a word that you’ll hear often in this space. What does it mean? Think about how a normal software application is designed to be consumed/used. It is expected to be installed within the domain of one company, where multiple users will use it to create/store/retrieve data, etc. Now what if you want to create this product once and have it used via the web by any company with any number of users? The design needs to change to accommodate this usage style. All of a sudden, you need to consider if you will have a single instance of your product with multiple back end databases (one per company) or individual instances of your product tied to individual databases. A multi-tenant architecture in the SaaS world basically means one instance of your product serving multiple companies and multiple users within each company. There is a difference between users and tenants SaaS which is important to understand – think of a tenant as a company or a team – basically a collection of users. A user on the other hand is an individual person or system that is interacting with the product. Multi-tenant is not a new concept by any means. It is just that as SaaS gains popularity, it has become a buzz word thanks to marketing hype. However, the implications of designing a multi-tenant architecture from the ground up vs. augmenting a legacy architecture to make it multi-tenant are real and can be quite complicated. Also worth noting that your SaaS solution does not have to be a multi-tenant solution. You can keep it single tenant, but there are associated costs and headaches with it that you need to be aware of.

The intent of this article is not to provide a detailed introduction to what SaaS is. There are lots of articles on that online. My real interest in SaaS lies in carving out a detailed strategy to implement complex SaaS solutions, something which is lacking in the industry today. There are not a lot of articles that detail the different areas that an ISV needs to think about before jumping into implementing a full blown SaaS solution. This article will aim to address this. However, one article cannot do justice to the complexities involved in designing a SaaS solution, but it’s a start I guess. So what are the core areas in my mind that an ISV needs to focus on when building out their SaaS strategy? There are four areas that need attention:

• Business implications – Is my current business model conducive to SaaS? Have I conducted a market opportunity assessment? What financial models can I pursue for my new SaaS products? What about organizational and cultural issues and how will these impact my team and product development? What is my go-to-market strategy?
• Technical implications – How do I achieve my multi-tenant architecture? Via software or hardware? Using Virtualization? How will my product scale to this new model? What architectural considerations need to be explored? How will SaaS impact my product lifecycle? What will my database design look like and how will it impact my data model? How will I handle subscriptions? What about security and how will I isolate my data in the database to keep customer data secure? Which encryption methods to use? What will my SaaS infrastructure look like?
• Operational implications – Once I offer my software as a service, I now have to take on the burden of ensuring that the systems are up, otherwise no one will really want to use my software anymore. So as a service provider, the risk now shifts to the vendor from the customer of ensuring high availability and uptime. Along with this comes the onus of ensuring operational excellence.
• Sales and Marketing implications – For companies (especially ISV) that are thinking of implementing a SaaS strategy, this is a vital piece of the puzzle. The reason being that the SaaS model changes the way an ISV will do business. The ISV will move from becoming a product company to a service company down the SaaS path. Coupled with the fact that SaaS opens up new customer channels and revenue models, the ISV needs to factor in how to capitalize on that and have a marketing plan handy to make the SaaS model work for them. A SaaS model causes a “revenue trickle factor” – what I mean is that the ISV no longer gets a fat paycheck everytime a customer now buys their product but realizes the revenue over a course of time (depending on which SaaS model they adopt), so this needs to be factored in to the sales and marketing plan to ensure that they make up for the trickle factor by signing up more customers to justify the cost of the infrastructure and management.

In subsequent posts, I will get into the details SaaS, especially around the area of giving guidance around how to implement a SaaS strategy, what to look out for, best practices, SaaS economics, the main technical challenges of SaaS and much more. Stay tuned!

IT Focus for 2008

I thought I’d start off the new year with a post on my thoughts for where the IT focus will be for 2008. There are articles that discuss IT trends for 2008 such as Web 2.0, green IT, etc. However, I do not think that these areas are going to be a focus for most corporations in 2008. They will definitely be a focus for some, but for the majority of companies, I think that these topics are going to be on their radar and they might start experimenting with it, but nothing more than that.

So having said that, here are the topics that I think will be high on the agenda of most CIOs:

• Integration: Yes, it’s still an issue given aging systems, legacy applications, emerging platforms, M&A activity, need for integrating external partners and need for business agility. With all the talk around SOA and integration, it’s easy to forget how many companies yet have not adopted SOA and are still struggling with integrating their heterogeneous systems. Whether it is via adopting SOA or homegrown means, integration will continue to be a focus for 2008 for most CIOs.
• Cost Containment: Ask most CIOs what is one of their top 3 initiatives and most will reply cost containment. The need to manage the cost of IT is high on their agenda and should continue to be so this year as well. The trick is to figure out how to use technology to achieve this business goal. SOA for business agility? Virtualization for hardware and software consolidation? SaaS for increased business channels? Open Source to reduce licensing costs? Better customer service using BI? Reduce energy costs? Manage vendor better via standardization? Pursue an outsourcing strategy? All of these will keep the CIO up at night.
• Process Automation: Current processes are manual, cumbersome and error prone at many companies. The need to automate these and hence cut costs, save time and improve customer service (both internal and external customers) will continue to drive focus in business process automation. In an effort to align business and IT, CIOs not only need to figure out how to automate their processes, but also how to translate the process automation from concept (business folks explaining what needs to be done) to the implementation (how IT folks will get it done).
• Business Intelligence/Data Mining: In order to improve customer service, you need to know your customer. What better way to do so than to pursue a BI/DM strategy to clean up your data, structure it for on-demad reporting and surface that via a myriad of fancy dashboards? BI/DM will continue to be popular this year.
• Virtualization: I think that CIOs realize the full value of virtualization already. It is a matter of putting it into practice. A lot of companies already have a virtualization strategy and those that do not will start looking into it this year. Data center virtualization, OS virtualization, application and JVM virtualization, along with sophisticated monitoring and management tools (the most important piece of a virtualization solution) will continue to grow.
• SaaS: Software as a Service will build on the SOA foundation to provide increase revenue channels for many companies. Despite its complexities (getting used to a different business model, proper infrastructure, licensing models, security, etc), many companies should pursue SaaS this year.
• Open Source: Statistics say that one in three small and medium sized business are adopting open source as their platform of choice. With the obvious cost savings, increased developer pool, more control over patches and deployment and faster time to market as a result of increased ramp up in infrastructure (think open source ESB, portal, CRM, etc), many companies will need an open source strategy to become more innovative in 2008.
• M-Commerce: Especially in banking and retail, I expect this to be a major focus this year, given the immense popularity of cell phones, increased band width and customer openness to doing business on the web. Security will still be a concern, but I expect a lot of focus on building out mobile software and infrastructure this year. Add to this the popularity of Mobile 2.0 and Web 2.0 mashups, along with an insatiable appetite of the Gen Y population to get things done while on the move and you can see why reaching customers via mobile phones will be a top focus area for many companies.
• Security: With the focus around SOA, SaaS, M-Commerce, increased integration between lines of business, exposing data as a service and other key initiatives, security should remain a focus as it is deeply ingrained in each of these areas for the initiatives to be successful.

What!?? No Web 2.0?? No social networks?? Don’t get me wrong. Web 2.0, green IT, etc are all cool and trendy, and they definitely will appeal to a section of companies out there. Web 2.0 will definitely find applicability in the BI space, as well as in areas of marketing, consumer based applications, building brands and areas where people buy products because they trust their friends and social networks, but I do not think that these are going to be the main agenda items for most CIOs who are focused on the enterprise. Web 2.0 is a trend as are social networks and I think that in the coming years, they will become a focus for many, but for now, I feel that they will remain a trend in 2008.

If you feel differently, or feel that I’ve missed out on some key topics, then I’d love to hear your opinions.