Doing my research for this article, I can see that this subject was argued about a lot a couple of years ago. Recently however, the discussion seems to have disappeared. As marketing media will do, the term cloud has become a broad brush that can be applied to anything on the Internet. The result is a lot of completely different technologies have been painted a much-abused shade of cloud gray.

The best way I can think of to discuss this is in a series of questions and answers. This may sound like a sort of self-aggrandizing way to do an interview, but actually these are questions we have gotten in discussions with companies moving to the cloud.

Q: What is the difference between virtualization and cloud computing?

A: Virtualization is a technology that is available in several forms to allow technical resources (applications, network services, etc.) to be separated from the physical machines they run on and treated as an abstraction. A good example is a number of virtual servers running on one physical server. Each virtual server runs on its own virtual machine and can be managed by the tools provided by the type of virtualization being used.

Cloud computing on the other hand leverages virtualization technology to provide a model for access to a shared pool of configurable computing resources. One of the best and cleanest definitions I have found is the NIST draft definition.

Notice the five Essential Characteristics they have identified:

• On demand self-service, by the customer without the intervention of the provider.
• Broad network access. Notice that this goes beyond the Internet to include a wide range of client platforms.
• Resource pooling, that allows the provider’s computing resources to be shared in a multi-tenant model with resources assigned and reassigned on demand.
• Rapid elasticity allowing resources to be rapidly and elastically provisioned and scaled out and in either manually or in the best case, automatically either from set parameters or from application logic.
• Measured service that leverages metering capabilities to automatically control and optimize resource usage according to service parameters.

The three Service Models: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS)

The four Deployment Models: Private, community, public and hybrid.

So while virtualization provides a technical way to separate services from the infrastructure or system that supports them, cloud computing goes beyond that to provide a range of of models you can use to implement computing services economically and dynamically. As Garter has pointed out, there is a lot of confusion in the market aided by a lot of self-interest. SaaS providers need to be aware of this discussion and it’s implication for their businesses.

Q: Why is Cloud Computing important for SaaS providers to understand?

A: For a SaaS provider, business scalability is critical for success. If you can’t achieve scalability in a reasonable period of time and continue to sustain it over the long term, your odds of failure greatly increase.  While the technical side of scalability is only one aspect of the equation, for SaaS companies cloud computing represents an opportunity to achieve operational efficiency rapidly and at a much lower cost than was possible before it became widely available. To take advantage of this opportunity, SaaS companies need to leverage one or more of the three service models and insure they are using vendors who provide services that include the essential characteristics as mentioned in the NIST draft.  Many vendors say they provide “cloud computing,” but a careful review of their service model will often show that they are offering little more than access to a proprietary implementation of virtualization. The heavy lifting required to provide rapid elasticity or measured service is left to the customer and where it is available, cannot easily be passed through to clients. The effort required to build in the necessary service characteristics on someone else’s system is not trivial and requires a good understanding of the underlying virtualization technology. In the end, the investment becomes something of a barrier to entrance and once it is spent, a barrier to exit for the SaaS ISV.

There is no prefect cloud computing platform for SaaS providers, at least at this time. Most cloud computing providers at the IaaS and PaaS level are focused on the enterprise market and the simple movement of enterprise datacenter assets to their service. But there are systems that meet the classic definition better and provide a lot more opportunities for the SaaS provider to leverage them through to the client level. At this moment, Microsoft Azure and Amazon AWS meet the definition best, but the market is very competitive and there are ways to use other services in combination to achieve some of the same benefits available from these vendors.

Q: So, if I just put my existing application on one of the “best of breed” cloud computing providers, I will then have an efficient and scalable SaaS Cloud Computing implementation?

A: Unfortunately, if you are an ISV with an existing application it depends.

If you have a small application without a lot of features and complexity, you are using current methods for web services, you can adopt multi-tenancy and you use some tools for scaling out and in, it should work out just fine. There is no need to change, other to insure your business operations (pricing, billing, settlement, metering, etc.) are automated and will also scale properly, and you can manage maintenance tasks while keeping your reliability within your client expectations.

However if you have developed a large, complex, enterprise application, your cost and efficiency on a cloud computing model, IaaS or PaaS, will not be radically different than on hard metal with traditional clustering techniques. The problem is, your application is likely to be built for scaling up – rather than out. If it is a complex, monolithic architecture, you will scale simply by starting additional instances. The application will require large virtual machine instances, which are considerably more expensive than small instances. It will take longer to deploy new instances (scale out) or decommission instances (scale in) when they are not needed. Performance will be tied to the busiest functionality in the application, regardless of how many concurrent users you are carrying. So, a payroll function in an HR application will drive scaling of the entire application, even though the primary overhead is in computing the payroll itself, not in personnel assessments for instance. This impacts cost (for scaling and maintaining large instances) and operational efficiency.

In addition, complex enterprise applications tend to also have complex databases. On platforms like Azure, the functionality available is tuned to many small, federated databases rather than large monolithic databases. There are many things you simply cannot do on SQL Azure that you could in a standard installation. If you use other cloud computing platforms, you can cluster but clustering large databases requires considerable bandwidth for synchronization. In the end, a little modeling may show that is indeed easier to stay on traditional hosting if your database is large and complex.

In the case of large, complex and monolithic applications, the best bet is to realize that over time they will need to be re-imagined as a group of components that can run on smaller instances and scale independently based on their direct use. This doesn’t mean the entire application has to be redeveloped before a cloud IaaS or PaaS is used, but it does mean that there should be a plan for development of new functionality in a component style and gradual migration of functionality that can be segmented from the core application to separate components. Especially in the early days of deployment of a SaaS application, it is unlikely you will be overwhelmed by clients and you have time to gradually move toward a more efficient application configuration as you meet the demand of the new market your application will be facing. Take your success and plow it back into gradual operational improvement.

Q: We’re planning for an entirely new SaaS application. Do we have to design for the cloud immediately?

A: If you are using the current Lean approaches to product development, no – depending on the stage of product development you are in. In early stages, when you are still working to find an acceptable business model that produces value with visionary customers, use every tool at your disposal to keep development overhead low. Use tools that keep needed coding to a minimum, change turn arounds quick and investment costs low. Don’t become heavily invested in application code that you will probably have to throw away.

Once you have a proven product and market, then spend the time to break down the service functionality and develop a scalable, component architecture as is necessary for cloud-based SaaS. Use tools and methods that are proven for commercial grade, scalable development. Now your investment counts toward the ultimate goal – a scalable business built on a solid foundation.

A new SaaS application is a great opportunity to do things right and not spend a lot of money trying to change out your engines while you are hurdling down the runway.  Using component-based architecture gives you a lot more flexibility over time to tune and enhance individual parts of the application without risking everything. And – if you are in the enterprise market – you will find that most of your customers are virtualized anyway. Depending on how you use the tools available from the cloud PaaS or IaaS provider you select, you can still transfer the application cloud to your customer’s virtual environment where necessary.

Q: Isn’t using platforms and cloud infrastructure risky? Won’t it lock my business to the fortunes and lifecycle of the PaaS or IaaS vendor I pick?

A: Yes, but is that a bad thing?

If you chose well, you will have the advantage of a large number of tools that will lower the time and expense necessary to develop your product. In development today, programmers don’t code directly in assembly for the processor in a target server anymore. In fact, we’re less and less concerned with the base our application will run on, especially on the client side. This is because we leverage abstraction, frameworks, environments – platforms to make development faster, easier and the results usable in a wide range of contexts.  The leading cloud computing platforms are simply the next step in that continuing evolution of computing.

Of course, not every cloud service vendor is going to win in the long run, but we can pretty easily pick the ones that will last long enough to make it worth using their services. They have an established history and user base that is easy to assess. They are competing and innovating not at the distant edges of the technology – they are right at the core where the changes they make have a strong impact on business capability.

In this light, a lot of the “fear-mongering” we hear is nothing more than media hype. You have to evaluate and make choices, but that is a normal business process for selecting any vendor or partner. You can’t afford to go it alone these days.

Q: This is a lot to absorb. There are a lot of changes in the industry right now. Do you offer services to help companies navigate cloud computing as they develop applications and services?

A: Yes.

I guess you could call us a Cloud Computing Enabler. Scio is a partner of both Microsoft and Amazon. We have worked with companies from startups to leading Cloud SaaS providers in the field.  We offer services for business and technology assessment, application planning, development, tuning and maintenance. We are focused on continuing to develop tools and services for the cloud computing market.

But that said, we will honestly say there is no “one-size-fits-all” solution in cloud computing. Every project has its own goals and each client has their own constraints. Our job is to use our knowledge and experience in the field to find the best fit for the work in front of us and not the one solution we can squeeze everyone into.

The conversation continues:

If you are a member of LinkedIn and part of the Software + Services (SaaS) group, you can join the conversation.

This is the third article in this series. If you are just joining us and haven’t read the previous segments you can go to Part 1 or Part 2 and catch up with us there.

At this point, we have identified a problem with developing an operationally efficient SaaS application on traditional architecture.

• We can scale a SaaS application on managed infrastructure, but it is costly in terms of time and resources.
• We can use virtualization, to ease implementation and allow a degree of elasticity, but we’re hampered by the monolithic nature of the architecture. It requires us to scale the entire application or database to address even very localized component loading or high transaction loads in just one portion of the database. It also results in higher total overhead just because of the size of the application itself.

So, we know the best solution is to break the application down into separate parts and allow those parts to scale as they need to without loading other components. What do we need to do to make our solution as operationally efficient as possible?

Let’s make a few assumptions:

• We will use a cloud hosting provider that gives us access to a range of virtualized services through APIs and web services so we can automate scaling and decommission of services. The API will allow services to be monitored for performance and usage parameters; which will give us a way to manage the application scale programmatically.
• Our hosting provider provides utility-based pricing so we can see benefits from scaling up and down over limited periods.
• Load balancing, fail-over redundancy, and inter-application communication are all transparent.
• We will leverage virtual machine templates so implementation of services will be standard and transparent.
• We will be the account holder with the hosting provider, aggregating costs and billing our subscription and/or utility usage to our clients. This gives the client one bill, keeps us in charge of how we manage operations and accrues the benefits to us as our business scales successfully.

To be successful, there are some key points we must incorporate into our design:

• Application scale management for all components needs to be based in a dedicated instance with an administrative interface that will allow us to adjust performance and scaling rules over time. This is critical. The extra small instance we are using for a component might be just fine at the beginning, but we might find out over time we would be better off with a slightly different size. We don’t want to stop the application or change program code to make that happen.
• Scale management must include monitoring and scaling all the services in our design. It should not be based in just one aspect of instance performance (server memory for instance) that is expected to stand for all dimensions of usage.
• The design will allow for monitoring and metering throughout. Ideally, this should be based in the scale management component so it can aggregate usage patterns across the entire application cloud. We must be able to tell how usage is impacting our operations and use it as part of product management.
• The design needs to allow usage aggregation in ways that allow us to leverage use patterns and functionality.
• Where it is possible to identify direct client costs, our architecture should break out those services and use metering, monitoring and limits to keep them within the expected range for the service package. If a client is buying xGB of storage as part of their subscription we should be able to use metadata to determine average usage, low and peak usage, data transfer and transactions over a period.
• Automation for pricing, billing, settlement, client implementation, user access and role management, support and product management will all be part of the application or integrated from outside services. Operational costs include staff requirements so we want to do everything we can to lower the need for direct staff involvement in ordinary service functions.

For the purpose of this exercise, we’ll use Microsoft Windows Azure as our reference. Amazon AWS and similar services would also work, but differently, and it is easier to understand if we don’t to try to generalize our example too much.

With that in mind – what might we propose for the application we outlined in Part 2 of this series?

You will notice we’re calling this an application cloud. That term does not refer to a so-called private cloud. It is a grouping which allows the virtual servers and services to communicate transparently without having to set up a special network. Using a private cloud configuration is possible, but it raises the cost because we are no longer leveraging the commodity effect of the public cloud.

The component breakdown in our example is quite simple. There are a lot of other ways we could break the application up, but we’ll keep it simple enough that we can see the principal function and usage alignment.

• Web/Application Server – Available full time, scaling on small instance on performance – Provides user access and all direct user functionality. Also receives and stores data uploaded from client sites. Aggregated scaling across all clients and users.
• Scale Manager – Available full time, scaling on extra small instance in zones – Manages component scaling based on performance and usage characteristics. An admin interface allows access to reports, to change management rules and parameters. Aggregated scaling.
• Compute (headless) – Available on demand, scaling with small instance on jobs in queue and performance – Grabs compute jobs from dedicated queue, processes them and stores them as required. Handles many job types so it can be part of aggregated scaling.
• Reporting (headless) – Available on demand, scaling extra small instance on queue and performance – Grabs reporting jobs from dedicated queue, processes them and stores them as required. Handles multiple report job types and stores jobs directly in client simple record storage as well as making them available for users.
• Application Database – Available full time, a federated database for application data on small web instance – scales through federation in various dimensions.
• Client Database – Part of core database federation, but dedicated to each client – scales by moving history to simple record storage after each inventory cycle.
• Queues – dedicated queues for jobs performed by the Compute and Reporting components.

Six components with additional services? Yes, but because we used minimal footprints for each of the servers the minimum monthly operational cost is quite small.

You will notice that the base component set does not include the client database. That is because in this case, we can allocate the cost of each federated client database for inventory directly to the client. We also know that queues, access and storage will have a cost for each client. On Windows Azure, the database will cost $9.99/month and we will allocate $5/month of the client subscription to storage and communication overhead.

The direct cost allocation idea may seem strange at first. But, because we know that each client will require a small database for their inventory – we have leveraged cloud hosting to isolate the transaction load and storage required for each client from the application database. This raises both scalability and the total availability of the application at the level of the client inventory database which would otherwise be a weak spot. We have also limited the dedicated database size by using the inventory cycle to remove data from previous periods and store it in simple table format to reduce total costs. Federation keeps this scheme simple from an application point of view.

So how does this scale in comparison to typical architecture?

You will remember in our scenario, the client register system will send item adjustment directly to the application once a week. Assuming most of this happens on Sunday night, the web/application server will store the data and load the compute queue for the compute server. The compute server will run inventory adjustment jobs, store the results in each client’s inventory database and add a report job to the reporting server queue. The report server will grab the job, build the report and store it for store personnel to access Monday morning.

This activity will scale the application server, compute server and report server but they will each scale separately based on demand. So if the load on the report component is less over all, it will scale less. This kind of lumpy activity will aggregate because these components are shared across all client instances but separately. On Monday, when store personnel are pulling up reports for review, the application component will be busy, but compute and reporting will only have minor usage. Tuesday, users will adjust inventory as needed and send stock orders. On Wednesday, another batch of uploads will come through as store receiving checks in the ordered items. Compute will scale to adjust inventory again and the entire application cloud will scale down on minimal usage from Thursday through Sunday night.

The result is a usage pattern that requires high scaling less than a third of the week. The rest of the time the work is minimal. If some stores have a different use pattern, the system will scale to what it needs to handle those situations.

What is the cost of this type of architecture?

The monthly cost is quite a bit lower overall going from a low of $194 to a high of $1742. It scales directly in response to use patterns from the begining and the total client load based on the performance rules managed by the server manager. This means IT staff is not managing servers directly. They are pulling reports and adjusting performance rules in the scale manager as needed to adjust performance and scaling.  Positive cash flow is being achieved sooner which means more cash on hand over a given period.

The cost for the client database, storage and data transfer overhead is significant but because it is broken out, we can subtract it from the operational costs we are able to manage and can aggregate. Our cost per client is scaling well over the growth cycle.

There is another hidden advantage here.

The application cloud can scale over a very large range without redevelopment. If we want to enhance a component, we don’t have to rewrite the entire application. Each component is independent and can be handled separately. If we decide we have a need for more reports, we could add code to the reporting server and change the instance size without risking the entire application. In the front-end application server, we would only need to add the additional report types for users to select.

The number of servers that each component can scale to is uncapped to keep performance even from the user perspective. We can control the scaling of a component like reporting or compute by changing the parameters for queue performance at different times if we build that capability into our scale manager. So, we might allow more bursty scaling when we have a shorter window of time to complete all jobs. Schemes like this have negligible impact on a small number of servers – but may have very large impact at large client loads. This is one example of why you need reporting and performance administration on the scale manager from the beginning.

This is of course, just an example. But you can start to see, there are a lot of possibilities if we can develop to leverage elastic hosting to achieve operational efficiency. A lot more than we could ever achieve on a traditional architecture.

I hope you’ve enjoyed this series and it will spark some new ideas.

Here are a few resources you might want to review:

Cloudonomics.com – Joe Wienman’s excellent and detailed discussion on how cloud computing creates value. If you read nothing else, set aside some time to digest this nearly book length group of articles. You should also use his ComplexModels.com and see how scaling works in a cloud environment. Remember though, the benefits are strong if a large pool of servers are involved in an enterprise situation or if an application cloud approach is used in a SaaS implementation. They don’t apply as strongly for one application in a traditional architecture.

Cloud Computing = Elasticity * Availability – A great discussion of the value of cloud computing when you leverage it in a way that promotes operational efficiency in applications from a leader in the field of cloud database sharding – Herve Roggero.

Cloud Computing Economics: 40-80% Savings in the Cloud? – An article with links to several other resources from Ray Depena in the Cloud Computing Journal.

SQL Azure Federations: Building Scalable, Elastic and Multi-tenant Database Solutions – From Microsoft TechNet.

This is the second article in this series – If you haven’t read the first, you are going to want to go back and start here.

In our first article, we got into some of the operational issues SaaS companies face as they try to reach a positive, profitable cash flow. I asserted that with standard technical architectures, SaaS companies will have a serious problem trying to scale and operate profitably.

In this segment, we’re going to lay the groundwork for a solution. The term groundwork is carefully chosen, because to understand the solution, you will have to rethink everything you know about software development for the Internet and SaaS applications in particular. If you are a software developer then, the first question you should ask is, “Why should I care? We’re using proven architectures and building reliable, industry-standard applications. Why are business operations a concern for developers?”

The answer is simple.

The solution is in the hands of the application architect and developers.

For practical purposes, it is an impossible task for a business to specify the operational scaling characteristics of a SaaS application for a cloud implementation. The business can provide strong insight, if the development team can ask the right questions, especially in the areas of client usage, market characteristics, and business automation aspects including pricing, billing, client implementation, etc. But the most important thing developers can do is to specify a flexible architecture that can leverage aggregation in the right places and puts direct costs in the right pockets. If that is done correctly from the beginning – operational costs will be scalable and manageable. If it is not, application redevelopment is inevitable – assuming the business survives to a point where it can afford to redevelop.

But before we get there, what is wrong with traditional architecture and implementation?

In the simplest sense – a traditional architecture like we laid out in the first article can only scale in two areas. The application itself can be replicated and managed behind a load balancer to its optimum performance. The database can be scaled by using zones and database replication techniques. If the implementation is on traditional managed servers, deploying new servers has a cost in both the time and staff required. Decommissioning servers to capture lower costs for relatively short periods of lower user base activity (hours or a few days) isn’t cost effective in traditional managed hosting. It costs more to redeploy the servers than the offset is worth.

The application tier can and will aggregate usage, but precisely because of that, a point will come where performance begins to suffer. This leads to a performance cycle for scaling applications. Performance will be very good right after scaling the infrastructure one step. As we wait for the right time and cost/benefit point to make the next step, performance begins to suffer again. The size of the swings is a function of staff availability and cash to make the investment. Staff costs will always trump hardware costs, at least until scale reaches a point where implementation automation can begin to make a dent in costs. If we’re cash poor and are in a SaaS business, we’re caught in a difficult situation. Poor performance increases churn. Increased churn lowers income. Increasing scale costs money and requires skilled staff.

We have to scale, but we’re on a treadmill going nowhere.

In the early stages of growth, one-off server implementation can be managed. Later, clustering and server replication will begin to make more sense. But the application is still – one monolithic application. If the biggest load in the early part of the daily work cycle is reporting as an example, all other components of the application will both feel the impact of that usage and need to be scaled to have decent performance because they are sitting within the boundaries of the same server box. This accentuates the impact of the build-to-peak strategy. The peak usage of the busiest application component becomes the scale driver for the entire application. If that component happens to be extremely busy during some periods (such as paycheck compute at the end of pay period for a payroll app), the entire app will have to be scaled to meet that requirement – even though the payroll administration component (for instance) rarely has that kind of usage.

There is also another aspect of the monolithic application that we usually don’t consider. Even when it is sitting idle, an application designed for a monolithic implementation has higher memory and overhead requirements just because of its total code footprint. It takes up more resources because it is a big application. We could break it up into smaller components on multiple servers but in a managed hosting implementation that has one big limitation – the cost of operation for multiple servers. The staff and implementation time for each server in the application system multiplies quickly. Managing the network and server availability becomes very complex. It is literally unmanageable without some level of automation. Thus, until the advent of virtualization, there was just no reasonable alternative. As an industry, we locked ourselves into a monolithic box paradigm because of the standard hosting pattern and associated costs.

Ok – Let’s virtualize traditional architecture…

Virtualization does make server implementation easier and faster. But if we are locked into a monolithic application, how much can we actually save? We don’t have a lot of leeway. We can only scale the application and the database. The reason we’re doing that is to keep performance where it has to be to provide good service. And remember – in a monolithic application the most used component is going to drive scaling of the whole application. We going to have to use large instances so we’re going to have more implementation lag and we’re going to have to lead and follow usage more than we would like.

Again – a SaaS business needs to as scalable as possible and drive the cost of operations down as the client base increases to be successful and worth the investment.

In this scenario, we’re going to quickly reach a point where our potential business scalability is marginal at best. We just don’t have enough levers to pull. Scaling a monolithic architecture will reach a point where the cost per client is flat – it isn’t scaling anymore. We can raise the number of servers we’re using but when the number of clients we can handle per server in the application and database becomes regular we’re stuck. Plus, as we pointed out in our first article – larger virtual machines can actually cost more than hosted machines. Depending on the use pattern and scaling plan, the cost/benefit ratio may not work out and even if it does, the benefit is short-lived. You’re still locked into a couple of narrow dimensions for scaling. Traditional architecture plopped on top of a cloud hosting system doesn’t really serve the SaaS vendor as well as it should.

Ok. So what can we do differently?

We need to break out of the box. Maybe we could change things if we used elastic scaling but how? How can we maximize its impact on operational costs?

Let’s take a minute and explain our terminology. In a pure sense, scalability means we can scale up to capture growth at a reasonable cost because we’re not changing the basic system configuration. The traditional architecture we discussed in the first article is scalable. But it doesn’t scale down elegantly and it the number of dimensions it can scale in are quite limited. Elastic scalability means we can scale in two directions – up and down. When you put that capability into all the aspects of cloud hosting you start to have some really interesting opportunities. But you can only leverage them to a limited extent with traditional application architectures because it was designed to avoid using a lot of machines to do different jobs as much as possible. It wasn’t a practical direction to go on standard, managed hosting.

To understand what we could do differently, let’s put more flesh on the bones of our original scenario. Let’s assume we’re going to develop a retail management application to be sold as a service – SaaS. What is the basic functional outline of this application?

• Client market is individual stores of small to moderate size, in chains or not.
• Stock replenishment is weekly and may be adjusted by store personnel
• Inventory is taken twice yearly
• History is necessary for seasonal inventory management
• Stores have standard item management tools (item scanning at registers, for inventory and receiving)
• We think the market will take a price of $100/store/month.

We now have a basic functional breakdown and usage pattern. This is critical in breaking down an application to be operationally efficient. The assumed price is good to know to model our scaling pattern on – but it isn’t critical to know. We can drive backwards into cost into price, but that would assume we know very little about our target market. That is a risky proposition at best, so we will assume we know our market for this application. But what do we know?

• The number of items are limited by the size of the store, but we need to track items – so we’re going to need a database
• We have scheduled usages – on hand adjustment from the registers, order development, inventory receiving, and inventory
• Store personnel have to manage inputs at a high level at least
• There is a workflow because store personnel have review and adjust stock replenishment after weekly item sales adjust stock on hand and again, after inventory is verified.
• The weekly busy periods are going to be when data comes in from the registers and from store warehouse receiving for stock replenishment. That data will need to be applied to the items in the client database to update stock on hand and orders.
• Inventories will be updated twice a year which will set base stock on hand for the next period.
• The target inventory will change seasonally in all or most items. The change will be made by department or store managers.

What can we tell about our back-of-the-envelope scenario from the first article?

The servers will be busy managing inventory on Sunday night through the middle of the day on Monday as item updates come in from the registers for the week and reports are prepared and pulled by users. There will be moderate user input Monday afternoon until Tuesday morning as individual items in the order list are adjusted. Wednesday, input will come in from store receiving to update stock on hand. By Friday morning, all the stock will be on the shelves for the busy sales period. Not all stores will adhere to that schedule, but most will.

From Wednesday afternoon through Sunday night, the level of activity on the servers is going to be very low. At nights, except for Sunday, there will be very little or no activity. A few reports will be pulled. A few stocking levels will be adjusted. A few stores will have a different shipping and receiving schedule. When the servers are busy, they will be very busy. When they are slow, they will be very slow. They will need the IT person standing by on busy days to take care of any issues, but on slow days and at nights nothing more than an emergency will need response.

So – if you were going to put this application on Microsoft Azure or Amazon Web Services (as only two of the many elastic hosting options that are available) – how would you do it? What could you do differently than just scale a application server and a database server? Think about that and we’ll go into one simple solution in the next installment.

That’s it now – go on – think about it.

This is the third article in a series with excerpts from this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap.  If you are just joining us – you can return to the first article in the series and find out more about the workshop background and other articles in the series.

Cloud Product Roadmap – Technical Architecture

Excerpt: Reviewing the Roadmap Template for Technical Architecture

In this installment, we going to look briefly at what needs to be in your Technical Architecture plan rather than review a part of the presentation from the workshop.    We provide MS Word templates for each element of the Cloud Product Roadmap, which can be modified and brought together to document your plan.

So just for the sake of understanding the outline – let’s review the major points of a Technical Architecture plan as for SaaS and Cloud products we see it:

• Technical Architecture Design Model
• Technical Architecture Design Process
• Architecture Design Elements
  • High-Level Architecture Requirements
  • Application Architecture Design
  • Tenancy Approach
  • Scalability Approach
  • Metering Approach
  • Security Authorization & Authentication Approach
  • Audits & Compliance Approach
  • Provisioning & Implementation Approach
• Gap Analysis & Third-Party Solutions
• Cost Estimation & Optimization

It is important to note at this point that this is not the complete technical plan. The roadmap also needs to include Development and Maintenance Processes, Operations and the Support Approach. You will also notice something it doesn’t include: Long, detailed descriptions of end-user functionality. This is because we recommend companies with SaaS and Cloud products use Agile development processes. Using an Agile approach means that the application is planned up front at a high-level using “user stories” that describe the main points of functionality needed by users. These descriptions will be broken down in more detail during the development process, but within the context of the evolving application. This allows the product manager to consider what the application needs to do, but spend less time on about how the functionality is implemented. Today developers leverage a wide range of tools and frameworks to deliver rich functionality more quickly and with better quality than in previous years. But each set of tools has its own implementation pattern. A product manager that spends too much time specifying HOW things need to be done, rather than focusing the outcomes, is likely to be wasting time on specifications that don’t leverage the frameworks properly or creating work-arounds with increased risk and development effort.

Another aspect of this plan are the elements included specifically for Cloud and SaaS applications. Tenancy, Scalability, Metering, Provisioning and Implementation are all architectural issues that concern online applications. In our experience, it is common for product management to focus on end-user functionality and leave the specifications for operational purposes until a later time. In many cases, this means the development team either ends up “back-porting” critical functionality into the application or tacking it on the side somehow. This usually means that important opportunities to do it right the first time are lost and in many cases issues like metering never have the flexibility they need. The point of our templates is to help our clients to consider these and other critical elements at the right time in the planning process – before choices are made and effort is expended that is hard to back away from.

The Design Process

If you have an existing product or assets in the form of technical assets (libraries, web services, algorithms, etc.) you can migrate, the first thought is of course leverage them to build the new Cloud or SaaS product. Using them provides a level of comfort and could lower the total cost of development. However, depending on what the assets are and what technologies are involved, they may also become a constraint that will prevent you from optimizing costs, performance, processes and the user interface. ISVs with existing products quite often consider ways to leverage their existing assets – even going so far as to just host instances of their application for clients ASP style to get something in the market quickly. Their basic thought is that the value of SaaS or Cloud all based in the delivery model. Typically startups design their applications from the ground up because they rarely have technical assets to consider.

Existing assets that are not already setup for the Cloud can also suffer from a lack of operational features to automate customer on-boarding and implementation, feature packaging and pricing, and usage metrics. Conversely, building from the ground up doesn’t mean you have to build everything. Using the Cloud model, you can leverage best of breed components to fill the operational gaps and allow you to focus on developing your core value.

You can also leverage specific SaaS and Cloud platforms that provide a many of the operational elements of Cloud products and usually enforce a level of code consistency. These can greatly lower the effort required and can offer capabilities that you can use immediately but would rarely put in your first product version. The build or buy decision in this case is usually a product of business priorities for budget, effort and the time required to bring a product to release.

So, in essence, the design process is a series of choices and compromises that finally arrive at the approach for the final product. The choices can be difficult but are usually made easier by making a series of strategic business and product decisions before you begin to consider the technical architecture. Making decisions on the technical architecture before key business and product decisions are made can lead to wasted development effort and increased risk that the development process will take longer than planned.

Special Attributes of Cloud Products

Current Cloud products, particularly those that take advantage of services like Windows Azure, can scale compute, storage, and delivery in direct response to needs in a specific dimension. That means if the application needs more storage, but doesn’t need more compute power, storage capability can be scaled up (or down) by itself. Conversely, if the application needs to process a great deal of data, it can add compute until it reaches a satisfactory performance for the job at hand. This ability to scale elements of the application separately provides opportunities to approach design problems in new ways. Where before we scaled simply by adding more servers, which included all elements whether we needed them or not, we can now scale just what we need to meet demand. This changes the design process to include considerations for issues like:

• What processes can be handled by a compute role, possibly from a queue, and processed in the background to reduce front end pressure?
• What degree of scalability will be required by each process?
• How will the application scale up and down? What will be monitored and how will it trigger change?
• What types of data will the application use and what resource can be used to store it?
• Are there content distribution needs that could take significant bandwidth?
• Does our scaling model fit within our pricing, packaging and overhead model? Are there better ways to accomplish same end with a lower overhead? What are the trade-offs?

Each cloud platform has its own capabilities and design patterns so there is a learning curve in deciding which applies to a specific product and project. But once basic decision is made for the platform, the next level is to consider how to design the application so that it can scale and leverage the platform transparently and make the best use of its strengths. It is best not to duck the decision and just go for a simple virtual machine approach because, with the exception of a few special cases, most of the value leveraging a cloud platform will be lost in the process.

If working with the interplay of decisions between your product strategy, technical architecture and business model is something you are struggling with – you should consider joining us for our workshop!  It will help you parse your priorities and bring together a roadmap for product development that meets your needs.

<Read the previous article in the series – Next article>

This series will be covering more in the days leading up to the event. But reading these excerpts will not give you all the material and is no substitute for attending and joining in the discussion.

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register by April 1st for our Denver Workshop and take advantage of our Early Bird Pricing

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Registrations By April 1st, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $100 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave100 when registering for SaaS University.

Go to SaaS University Denver Registration Page

Installment 2: Our 2011 Workshop Series

This is the second article in a series with excerpts from this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap. If you are just joining us – you can return to the first article in the series and find out more about the workshop background and other articles in the series.

Cloud Product Roadmap – Product Strategy

Excerpt: Lean Product Development and the Customer Development Process

The Product Strategy section of our Workshop covers the Lean Product Development approach and how it leverages the Customer Development Process. One of the opening slides mentions this quote, “Product strategy is like a roadmap, and like a roadmap it’s only useful when you know where you are and where you want to go.” (McGrath 2001)

This is the core idea behind our Product Strategy presentation and our Cloud Product Roadmap – helping companies considering SaaS and Cloud products to find where they want and need to go.

Lean Product Development rests on a basic premise: The product features that customers will value are unknowns. In the case of a software, regardless of how it is delivered, that means the features and services the application will offer are simply a hypothesis until they have been actually evaluated by users in their own context and use. By using Agile development and practices and evaluation by key customers, product management seeks a minimum feature set that will provide the greatest value while reaching the widest customer coverage. The Agile development approach provides a system of relatively short development cycles or iterations that produce features that users can evaluate immediately.

The Customer Development Process provides the basis for customer involvement, particularly during early product development. The founding team seeks clients who can understand the product vision. These clients will become early adopters and customer development partners during application development. The Agile development iterations are used to test the feature hypotheses with the customer development partners to validate that the features developed provide real value and will drive sales. The point is to find a product that reliably produces value for enough customers to sustain a business model that can be scaled.

Based on Customer Validation, the process continues into creating market demand and scaling sales to reach positive cash flow. The product development doesn’t end however, it continues throughout the lifecycle of the application as the customer pool grows, continually feeding discovery and learning. At the same time, the company itself manages a process of transition from being a product development organization to an operational machine that can continue to execute and serve customers as sales scale.

The key starting point for this process of product and company building is finding the Minimum Viable Product (MVP). This is a product version with the minimum features needed to solve the core problem of the target market. In most cases, it is a lot less product than is necessary for a market release. This is an important difference from the traditional product development process where the aim is to bring together as robust and complete a feature set as possible that will fend off possible competitors and produce an apparently over-whelming feature advantage. This is possible because traditional product development processes depend on the assumption that the market is known and the needs of users are fully understood. It works well when the product line has a solid history of success and the product management team has been participating in the market for some time.

Internet-based applications and services, however, have the possibility of reaching new markets and customer segments that were out of reach in the locally-installed, licensed model – even for ISVs in the market with products. While a SaaS or Cloud product developed with traditional product development methodology could capture its existing customers, it could easily miss newly available market segments with unexplored problems.

To address this gap, Lean Product Development and the MVP approach are aimed at testing the value hypothesis and allowing the visionary early adopters to “fill in the gaps” when it is validated that the MVP is solving a real problem. If the MVP isn’t solving the core problem, the cost of re-evaluating and approaching the opportunity from a different direction is small and early adopters can aid in defining the issues contextually. In this approach, the risk of wasted effort and time are minimized, and the opportunity for clarity in solving the real problem is greatly improved. Once the MVP is proven, the vision can continue to be achieved in small increments without the waste of producing a laundry list of features that in the end no one will pay enough for to realize a profit.

The advantages of Lean Product Development:

• Reduces the risk in bringing a new product to market
• Reduces investment prior to positive cash flow
• Accelerates time to market with a viable product
• Aligns product features with proven customer needs
• Provides a rapid, dynamic feedback loop from the customer that drives product design, product packaging, price structure, and competitive positioning

The competitive positioning issue is one that is worth a few extra words. The Customer Development Process engages customers and creates a shared sense of product destiny. In turn this increases customer satisfaction, loyalty and retention. These are critical to success for online services like SaaS and Cloud Products. It produces a product that fits a client base tightly and is a barrier to competition. It has been shown that products with a Replace Strategy need to be perceived to be nine times better than the product they replace to gain market traction. The longer a customer is retained in a Lean Product Development model, the greater the barrier the competition will have to overcome.

<Read the previous article in the series – Third Article in the Series>

This is just one of many critical subjects we cover in our workshop.

This series will be covering more in the days leading up to the event. But reading these excerpts will not give you all the material and is no substitute for attending and joining in the discussion.

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register By April 1st for our Denver Workshop and take advantage of our Early Bird Pricing

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Registrations by April 1st, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $100 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave100 when registering for SaaS University.

Go to SaaS University Denver Registration Page

There have been some mentions in the press recently of the “platform strategy” of some of the leading technology companies. Generally it is a key part of planning a technology business strategy, but we’ve found the point is often lost when considering new SaaS and Cloud-based products.

First – what is a platform strategy? This question can be somewhat complex to answer because it is a term that is used in business, product development and technology. It can be a set of standards, a brand, and a group of common components used by several products. For our purposes, the last point is the most important for technical products, but all the uses of the term are important to leverage for any business. When you build a SaaS or Cloud product, there are operational requirements that you will find are common to all services of this class. This includes new account provisioning, user and account management, billing, settlement, maintenance – and all the other operational aspects of the service. In the best case, in addition to addressing this common functionality, a platform strategy can allow each additional product to leverage the client and partner community in a way that makes the entire suite and surrounding ecosystem of products more valuable.

But, it could also be said that a platform strategy is “wishful thinking” for a new entrant into the market. Without significant adoption of the first product, a platform strategy is a capability without a need. Consider the iPhone. Would the iPhone App Store matter if the iPhone itself was not a runaway best seller? The popularity of the core product drives a community of developers to wade through a somewhat opaque approval system to reach a very crowded field of applications with the hope of “hitting it big.” Can that kind of success really be replicated outside of a “hot consumer market?” Is it worth the effort to even worry about?

The reason this has been a subject of interest for us at Scio is that we work with many new entrants to the SaaS and Cloud Services market. Part of our consulting offering is to help them develop a product roadmap so they can develop a product in logical phases. What we want them to avoid is spending the effort to develop a risky “full product release” with a long list of complex functionality that has no proven market. A roadmap helps them to focus on bringing the product to market and reaching a positive cash flow quickly.  It can also result in a higher level of thinking when it comes to considering the necessary feature development. As an example – It is easy to consider a price and package management system as a “one-off component” for a product during early development. A product manager will say, “Which features really deliver value? Just develop some price levels for the service.  Is that complex?” It isn’t until sometime down the road, when marketing wants to add discounts, promotions, special market pricing, that it begins to put a drag on other priorities. If the pricing management system doesn’t allow for these concepts, each has to be coded into the application before they can be applied. If you take the logic further, what if you add more products or different mixes of capabilities to the service? How will your simple approach cope? Will it become a constraint on product development and marketing?

But, developing a pricing system that can handle a multitude of scenarios is certainly a lot of effort and “beyond scope” in early product development efforts. This is where the roadmap begins to play a role. You know you need a pricing system from the first day – but you have no idea of final requirements and how much effort you can afford to use to build it. Knowing that, you could chose to leverage a service that has broad market acceptance instead of building your own in the middle of developing critical end user functionality.  The service will have  enough options to cover a wide range of scenarios out of the box and will be billed on a pay for use (utility) model. If you have developed with that strategy in mind, you can always make the choice to develop a more specific component later, when you have a better idea of your product requirements.

The same is true from a “platform strategy” point of view. If you have developed with the idea that your client community has value beyond your first product, there are choices you could make that would make it easier to allow client data to apply across the platform at a later time. If you see an opportunity at some point in time to “open up” your user community to partners, it makes sense to architect in a way that you can control the asset, but also make it easier for others to use.

While it seems these ideas should just be “good sense” and standard practice to avoid costly restructuring later – it is actually difficult to convince most ISVs to think beyond the current product, towards a longer vision and roadmap that would align architecture and development with a business strategy.  If an ISV could adopt this longer view of capabilities, it would increase their options tremendously, but still, few consider their options.  Maybe this is because it is a part of the “continuing evolution” of SaaS and Cloud Services. Traditional products designed for a on-premise installation didn’t need to leverage a common operational framework and asking most client IT teams to set up a complex system is inherently risky.  Multi-tenant architectures lend themselves to this sort of thinking. Freestanding, independent applications installed individually do not.

So – this is our suggestion: If you are considering a SaaS or Cloud Service product, don’t skip considering a product platform strategy even if you don’t know if you will ever have the opportunity to use it. It will change the choices you make, standardize your architecture and improve your options no matter what happens in the future. It’s that simple.  In all honesty, we highly recommend SaaSGrid from Apprenda because of our experience with the product and because it provides both an immediate payback in reduced development time for common operational functions and a route to multiple products and suites on the same platform.

If you would like to hear more about developing your product roadmap – please consider joining me at SaaS University in Denver, Colorado April 26-28, 2011. I will be giving a presentation on “Lean Product Development for the Cloud” and a four hour workshop titled, “How to Eat an Elephant.” We will have information in the next few weeks including discounts (!) so watch for our next blog entry…

See you there!

Over the years since the SaaS acronym was identified, there has been a preconceived notion that hundreds, if not thousands, of SaaS applications would be spawned by independent software vendors (ISVs) from their packaged, on-premise products. It just seemed natural.  Why wouldn’t vendors want to jump on the bandwagon heading into the cloud?

The truth is though, there are still thousands of business-to-business (B2B) applications that have not transitioned and many vendors who have no plans to move their products to SaaS. I found this recent quote relating to hosting for ISVs interesting:

There are thousands of ISVs that have not deployed their application or offered their application as a service.  In fact, only now are ISVs and their customers moving in greater numbers to deploy in a hosting provider’s data center.  The majority of applications in use today are still installed on-premise.

Even more interesting, there are at least hundreds that either made the transition and then withdrew their products or never really embraced the business model, choosing instead to “test the waters” with hosted, single-customer implementations of the same software they sell to their on-premise customers. With all the marketing hype about users adopting SaaS and success in the market for cloud-based services, it is fair to ask:

What’s Going On?

First, let me say, I am not one of those who has a strict definition of “Real SaaS.” Can SaaS architecture be anything other than multi-tenant? In my world, yes. Multi-tenancy has great value for both the vendor and the user community it supports, but that doesn’t make products that are not architected that way automatically less sustainable. Should all SaaS be configurable instead of customized to fit individual needs? I’d say it is preferable but that doesn’t mean there aren’t many other supportable ways to allow customization in a SaaS application. Shouldn’t all SaaS products embrace the social and community product management model we see emerging? I’d say it would be foolish not to consider it, but that doesn’t mean there aren’t many places where it doesn’t fit. But perhaps most controversially, I’ll stick my neck out and say not all SaaS is directly subscription-based nor should it be.

My possibly heretical point of view comes from a simple observation of what we have seen coming to our door. There are many companies today, extending their business models to include online applications. Their customers may pay for access to those applications in addition to their regular service fees, but in many if not most cases, they do not. These applications provide automated access to repetitive services, quick access to online expertise, and process-based systems based on the business services the vendor provides. Are these implementations any less of a Software as a Service application than those of a vendor whose only service is the application itself? Are these services not SaaS because they are bundled into a group of direct services? In fact, because these businesses have fully embraced a service-based business model, is it actually more natural for a them to be successful at SaaS than an ISV?

So, if you haven’t caught on yet, what kind of companies am I writing about? It could be almost any service in any industry. Legal, travel, medical, financial – you name it. Naturally, most will follow the mold of the majority of SaaS companies today and are B2B, but that doesn’t mean that their end users don’t regard themselves as ordinary consumers. Imagine a  medical group, that is contracted by an employer, provides online access to medical advice, scheduling, and preventive care through an Internet-based application. It is paid for by the employer as a part of benefits and used by the employer’s staff and their families. What is the difference between that and the same service provided direct to consumers for a subscription fee by the medical group?  In essence, the difference is the sign up, the payer and perhaps the method of billing. The service itself is just as critical. If the employer-subscribed members aren’t satisfied, they will tell their bosses or HR department. But of course, the same medical group also provides direct medical services and if they offer the subscription-based service through an application to the general public, it can become an “on-ramp” for new clients.

Service In Their Genes?

But that brings up another thought. Do ISVs have the “service-based DNA” necessary for success in SaaS?  Do they clearly see not just the advantage of hosting an application for their clients but also of extending the services that would raise an application beyond a commodity that could be easily replaced by another vendor? Honestly, that is a difficult question. Whether they like it or not, most ISVs are locked in a cyclic-product development mode by their business model. Transitioning to an incremental cash flow with continuous product enhancements is very difficult. Every part of their business is set up to support a fundamentally different direction. We’ve found repeatedly, even when the desire is there, it is very hard for an ISV to change boats in the middle of the stream.

That doesn’t mean that ISVs can’t or won’t transition to SaaS, but I’d say at this point, if they haven’t – the likelihood is increasingly small. On the other hand, if we stop focusing on ISVs and startups as the primary drivers of new SaaS products, we will quickly see there are even more opportunities on the horizon that don’t fit the media-led definition of SaaS. The simple fact is, most companies don’t have to be told what defines the expertise and services they sell. What they need help understanding are the tools and services they can leverage if they want use an internet-based application as a part of their product mix that will lower their development effort and related costs.  They need to know about platforms, cloud-based infrastructure, and development for cloud stacks like those offered by Google, Azure or Amazon.  They need to understand current application user experience patterns and the methods behind SaaS products that are easy to use and adopt. Of course, there is one more thing – they are likely to want other services with the technical expertise to develop and deploy Internet-based applications to fill in the blanks while they continue to focus on their core business.

Do we need another acronym to describe these companies or their online applications? After all -  they are much harder to identify than ISVs. There are many more service companies in the market that could decide to extend their business online but they don’t fit an easily identifiable profile. Should we call them “Service-Based Applications” or something? As tempting as it might be – NO. It is easier to open the definitions of SaaS and cloud-based services to include their business models than it is to come up with an alternative or to just be straight-forward and call them Internet-based applications.

The Bottom Line

The point is we in the industry have to stop being so self-centered. Software developers are not the only ones who can fund, plan and implement a service online. ISVs don’t have a natural or the only path to becoming online service providers. Subscription-based, self-configured, multi-tenant applications are not automatically successful services. Online services are enabled by technology, but generally are not successful as business models if they are based solely on technology. We have to open the doors and let some air in. When we do, we will see there is a lot more opportunity out there than we ever imagined.

So next time you find yourself talking down to ISVs that “don’t get it” – stop and consider. Is it me? Am I cutting out a much larger opportunity for SaaS just because I haven’t included the most likely success stories?

I can think of many reasons to be at SaaS University in Washington, DC, July 20-22, beyond my session and Scio´s workshop. But I want to be clear: The sessions at SaaS University are always changing, always relevant to developing SaaS products and successful SaaS businesses. It is the only venue available with a focus on helping SaaS vendors navigate a complex business model.

This time I have the honor to be presenting a session on the second day titled: Increase Your Bottom Line Value with Multi-Tenancy.  Here is the session summary from the University agenda:

There is a lot of debate about multi-tenancy.  Most of us understand its value from a technical point of view, but what can actually translate to our bottom line?  How does it change what we are able to do to increase operational efficiency and customer retention?

Multi-tenancy is not a magic bullet, despite what you may have heard. Implementing your SaaS application with a multi-tenant architecture offers great returns, BUT ONLY if you understand how to leverage it along with metrics, operational automation, your ecosystem, and the network effect of your customer base – effectively.

This session will answer questions concerning the value of:

• Different architectures for implementing multi-tenancy and maintaining flexibility.
• Reliability, scalability, maintenance, and product evolution to your clients.
• Multi-tenancy in operations across your product organization.
• Implementing metrics in a multi-tenant application.
• Your customer and user network, delivery network and ecosystem under multi-tenancy.
• Methods of implementing multi-tenancy without breaking the bank or slowing product release

This session is strategic for C Level executives and product managers planning, implementing, or enhancing a SaaS offering. Participants will come away with a clear understanding of how they can leverage multi-tenancy at every level of their service and increase their bottom line potential.

This session is replacing a similarly titled session by planned Lincoln Murphy because of a scheduling conflict he has encountered. I want to thank him for his recommendation that I take his slot. I must say, although I want to keep the same broad focus for this session, my approach to this subject is different than Lincoln´s. My background with multi-tenancy comes from planning SaaS products with Scio´s customers and many years of working with companies on Internet-based business models.

In itself, multi-tenant architecture is not new.  The same could be said of the SaaS business model. What is still new is the broad market attention to on-demand services and the opportunities that virtualized infrastructure gives to business. The knowledge of how to leverage architecture and technical choices to impact product features, customer value and operational effectiveness is what is lacking in my experience. This is what I will lead discussions on in my session at SaaS University.

In addition, if you aren´t aware of it, SaaS University has a third day of full day workshops that provide a ¨deep dive¨on specific subjects. Our own session is Charting Your Course to SaaS, which will help it´s participants navigate all the choices they face in developing a SaaS product while they develop a road map that can get them to market and positive cash flow sooner.  I can also personally recommend Jim Geisman´s Right Pricing Your SaaS System: Beyond the Basics – Advanced Workshop. Jim and I had the opportunity recently to give a workshop together and I greatly enjoyed the experience, and I know our audience did also. Ideally, product teams should consider sending representatives to both workshops because they are complimentary points of view that are very important to understand.

So, with that background, here is the overview of our one day session at SaaS University for July 22, 2010:

Charting Your Course to SaaS – SaaS University, Washington DC, May 22

This is the third time we’ve offered this comprehensive workshop on SaaS and it continues to evolve as we respond to the needs of our participants. Following our joint workshop with Jim Geisman of Software Pricing Partners, we’ve continued to tighten the content and for SaaS University, will offer a more interactive format for this workshop, especially during the afternoon. The aim is to keep it small enough to allow everyone a chance to move the discussion toward the issues that interest them most.  It remains however, the only workshop that covers the business, operational and development issues that are critical to success in SaaS.

Companies that can benefit by attending this workshop:

• A new venture or as an ISV with on-premise products considering developing a SaaS offering
• A service company with significant vertical expertise than could be delivered and monetized in a SaaS model.
• An existing SaaS provider who made choices opportunistically that now constrain growth and cash flow.
• A SaaS entrepreneur with limited funding that needs to achieve positive cash flow early with products that evolve with the market.

Company challenges this workshop can help overcome:

• Building out a suite of products but are unsure of the strategies, metrics, and operational models needed to grow.
• Developing a framework for sorting out technical and strategic choices required to move to the SaaS business model.
• Facing significant operational problems including efficiency while keeping churn under control in an existing SaaS product.
• Developing a product roadmap and unsure of what can be accomplished and timeframes

Topics to be Covered:

• How is a SaaS Product and Business Different?
• Reference Framework for Creating Your Roadmap
• Making Strategic Development Choices
• Operating A SaaS Business by the Metrics
• 10 Ways to Fail at SaaS
• Applying Lessons Learned to Your Issues

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professor”

Mike Dunham, Vice President, Service Engineering for Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

The workshop costs $695, but you can get an Early Bird Price of $495 when you combine it with your SaaS University registration - total package price of $1290. As a way to bring together a great amount of information in a short period of time, the combined package is a great opportunity. As we get closer to the event, I’ll expand on the agenda, but this is a great time to start planning and get your team together to attend SaaS University in Washington, DC!  I hope to see you there…

Last week our team, like lots of other members of the SaaS community, attended the OpSource/SIIA SaaS Summit 2010 – titled, “All About the Cloud.”  We had a busy and meeting-filled week, as I’m sure many did.

Because SIIA and OpSource gave this conference jointly – it was somewhat different than the OpSource led conferences we have attended in the past. Instead of being an industry conference tilted towards a single vendor’s customer base and prospects, it was much broader, bringing in a wide array of SaaS vendors and industry providers.  Since OpSource has been an industry leader for some time, I wouldn’t attribute the change entirely to the influence of SIIA. More likely it was the combination of the two constituencies along with a bit of a push from the uptick in the economy. Whatever it was, it was one of the biggest groups I’ve seen for SaaS/Cloud conferences in a few years.

It was perhaps most surprising to see the “maturity” of the industry in our guests. Most of the vendors were not from start-ups or ISVs moving to SaaS – instead they were established SaaS vendors – regardless of the lifecycle stage of their product offerings.  This shifted the conversations we had at our booth from “what does it take to build a SaaS product?” to “how do I scale my architecture?” or “how can I extend my offering to bring new services to my customers?”

This is a good thing to see, but I wish the presentations had been more geared to the audience and less to information about vendor’s products, but it could be said equally that no one knew for sure how the attendance would balance out long enough in advance to plan for it. I think that will even out next year, now that there is some history in the combined event.

Jim Geisman and I gave a workshop following the summit that was quite successful as we “filled the house” with as many guests as we could comfortably engage with. It was a wide-ranging group with representatives from some of the largest software vendors in the market to some new entrants from Latin America.  If there was a common theme among them it was the need to understand the options and structure of product development and pricing for SaaS. The folks from DreamSimplicy were good enough to feature a video of our workshop on their website.

There is certainly a void when it comes to clear information that isn’t filtered by a supplier’s agenda. We all do it – but there are also some who push their value above everything else. And, unfortunately, there are several instant pundits in the industry who really have less background than opinions.  From that point of view, I am proud to be associated with someone like Jim Geisman for this workshop because his background shows in the depth he can bring to the subject of pricing.  To say you can’t “afford to get your pricing wrong” may be a bit of an overstatement – companies change their pricing and survive – but it can certainly be as much of a market killer as developing a product that misses the mark.

In no particular order then – some notes and learnings from the Summit:

• Pick your strategy, play through, check your metrics, adjust and play again. I saw several companies who were trying multiple strategies for product, pricing, marketing, etc – simultaneously.  The result is – every attempt is a one-off with no way to measure one against the other logically or if the strategy might or might work if tried more than once.  The people trying to execute on all these ideas are playing a difficult game. Which idea really has legs? Which one do we really want to go with? And by the way – what do their customers think of this apparent lack of single purpose?  It’s difficult to navigate no matter where you stand.
• Look for your weak spots, eliminate them or optimize as well as possible. I heard many stories of early decisions that will eventually put a SaaS company in a no win situation.  Your infrastructure maintenance costs are eating into your cash flow at an ever increasing rate as you grow. Or – perhaps you want to change your pricing or offer a discount and it seems like the only way to do it is take payments manually and adjust the books, unless you want to redevelop your pricing and billing system…. It is easy to say you might have seen these things coming, but that’s Monday morning quarterback speak.  It sounds too simple, but there is help in the Theory of Constraints: First, optimize the situation as well as possible, looking for ways to manage the issue at best you can. Don’t stop there, leverage the stop gap only as long as needed to develop a true solution to the problem.  If you’re losing opportunities or burning cash in SaaS, you’re killing yourself, slowly but certainly.
• If you have an opportunity to speak to your peers and prospects, give them value. This sounds a little simplistic, but it’s worth a thought.  We need to take every opportunity we can to expose our products to new customers, especially in this tight economy, but you can’t spend the time you’ve been given with a blatant sales pitch.  The audience paid to sit in front of you.  What can you give them for their attention? Knowledge. What do you know? What have you seen? What experience do you have you can share? If that is the sum total of your talk, it will be remembered. If it is embedded in your new product announcement, it is more likely people will hear it.  To many of the presentations at conferences today are symptoms of our economy.  Our audience is looking for positive news and knowledge, just like we are.
• SaaS is a business model – not a technology. I still see far to many attempts to sell SaaS as a technology and the same is true when we switch to using “cloud” as a substitute term.  There are technical advances that are becoming available because of the growing SaaS/Cloud market, but they are just enhancements of what otherwise is a service-led, cash flow based, business model.  Companies in the field need to be successful at reaching an adequate size market with a positive cash flow and technology can only assist in achieving that goal.  Understanding the business of online services and planning to scale effectively is critical to success.

I hope to get more chances this year to get out and be in the field and at conferences to hear and share more ideas and experience.  It is a great opportunity to learn more about what is happening “inside” the business of SaaS.

It is that time of year again – when analysts and writers of all stripes put their bets on coming trends for the new year. There’s some interesting stuff in them – check the links. But, since our predictions last year were right on the money – I expect nothing less this year.

Of course, I do have to say if you didn’t read our prediction last year, it was about what would appear on the blog in 2009. Hardly something to crow about since I knew then what I know now – this is our field and it will continue to be our focus. But… this year, while not particularly emboldened by such shallow success – I am going to stick my neck out – a little.  Over the past year, despite a dismal international economy, we did begin to see some trends that carry enough weight that we at Scio will be refocusing our services in the new year.  Nothing too dramatic really, but moving more towards the emerging best practices in the industry.

So – that said – here’s our:

Top 10 Trends for SaaS and Cloud Services in 2010

1. SaaS will continue to grow in acceptance and prevalence in the marketplace but – the term itself will fade in favor of “Cloud (insert your term).” There is no end of analysts predicting the continued growth in 2010 of SaaS as a business model for software vendors and a positive direction for software users. That part of the prediction is about as safe as predicting rain will come to Seattle sometime next year. But – we’re not going to call it SaaS much anymore?  Is all that marketing ink going to disappear? No. But the truth is we get tired of hearing the same old tune everyday and it starts to become little more than background hummmm.  Everything “Cloud” is ascending and marketing loves it because it is by definition a nebulous, foggy term that can be floated for nearly any purpose. I could just as easily say the same thing about the time worn acronym Service Oriented Architecture (SOA). At the heart of all well-designed services is a SOA strategy – but we don’t really talk about it explicitly. Marketing has hit that nail for over 10 years and still very few know what we’re talking about.  The same is true of SaaS. Discuss the term and we get tied up in preconceived arguments about security, lock-in, lifetime costs, and multi-tenancy without discussing the business case for vendors and users. Next year we’ll be shedding those arguments and just selling mature services without acronyms. And to add one more log to the fire that will lower the prominence of the term “Software as a Service” – vendors of virtualized infrastructure have already hit commodity pricing thanks to Microsoft’s Azure and Amazon’s offering – the only place for them to go is to add application suites to their “cloud.”

2. Real business value in SaaS will continue to improve, be better understood and measured more explicitly. There is a growing understanding of the difference between an ASP implementation of a standard premise-based application and a service that designed for the delivery medium that is embodied in SaaS. It is much more than technology or an offset of costs for infrastructure and resources.  That said, the metrics on both the vendor side and end-user side of the SaaS equation need more clarity and uniform acceptance. As a buyer of a SaaS offering, I shouldn’t care if it has been adopted by hundreds or millions of users.  What matters is who is using it successfully and what is their context? If I am going to base a critical part of my business on a SaaS offering, I need to understand if the lifetime value of customers is substantially greater than the cost of customer acquisition. I need to have confidence that the adoption of the service is higher than abandonment. I need to know the service will have enough value to continue. Having that confidence is a product of a conversation between the SaaS vendor and their customers/end-users.  It takes some real thinking on the part of the vendor to engage in that level of collaboration – but we will continue to see the most successful services providing a model of this behavior and inspire others to do likewise.

3. Service ecosystems will rise. Best case SaaS should be designed to meet the market embodied in the Long Tail. As we and others have said many times, the economics of SaaS and efficiencies of modern development cannot really be leveraged without a good-sized market. You can often reach sufficient market size by targeting your service to the second and third tier markets in a vertical but the time required to reach positive cash flow in SaaS can still cause many problems. Whether a specific service can be sold to a wider market or not then – it is wise to consider an ecosystem approach and I believe many will in the coming year. Salesforce and Google both exploit their ecosystems to bring a broad range of services together on their platforms and as was mentioned in our first point, cloud infrastructure vendors are heading in the same direction. In verticals, I can imagine a focused service teaming up with a general operations package for instance – especially one that could be pre-configured and integrated to the vertical application providing a “suite” for users. This can give users the benefits of single sign-on, data sharing, perhaps a lower total cost (assuming the vendors recognize the value in packaging joint services) and a “desktop” for most tasks they do everyday.  In fact, in the long run, I don’t expect to see many “stand alone” services – it just doesn’t make sense for the users or the vendors. We will see a lot more applications “joining forces” strategically or being acquired in the next year by integrating, combining user data pools or through “Mash-Ups.”

4. New services will focus less on “doing it all from day one” and more on their roadmap. In the “brave new era” of SaaS, one of the big impediments of developing a service was all the decisions you had to make and all the business operational aspects you had to have a handle on to arrive at requirements and start development. Many entrepreneurs felt they were being asked to either start with the equivalent of the original Wright Flyer or with a development burden so large they could never reach a positive cash flow with a reasonable investment.  Now however, there is a wide array of mature, tested services that can be easily integrated into a service product to provide standard approaches to operations, integration, sales, and many other business and technical requirements. With an extensible architecture, there is a great value in picking “best of breed” services to do the “dirty work” while focusing custom development work efficiently  on the real value proposition for a service. The time to market and up front investment decrease dramatically and the risk of running out of cash on a reasonable investment is contained. As none other than one of the leading investment groups has proclaimed, “Less is more!” And rather than worry about “lock in” – thoughtful entrepreneurs will realize at the point in the road where the cost of the integrated services begins to be a part of overhead that is worth investing some development time in – current development practices can allow extensions to the application without an expensive rewrite.

5. Integration requirements will drive standards for service-based communication and interaction. If cloud “ecosystems” are going to rise, if online services are really going to dominate the market for innovative products in the near term, standards for integration and service-to-service interaction need to be recognized and grow dramatically. Despite the continuing whines of a few holdouts – no serious vendor of online services should be considering parallel deployments – both on site and across the Internet. Developing a product that can address both markets eventually becomes “SoSaaS” – a product so hobbled by its split identity it cannot truly leverage the value of either delivery model. Instead, with an extensible Service-Oriented Architecture (SOA), open APIs and standard integration tools, online services will offer ways to leverage local data, applications, and other online services in ways that are in the end much cheaper and more reliable than traditional custom integration services.  This doesn’t mean SaaS vendors won’t offer on-site applications – but in many cases those applications will be hubs for addressing local integration needs and compliance issues.

6. End-user clients and platforms will continue to evolve and increase in their importance and differentiation. We’ve all recognized for a while that standard PCs and “browsers” have many deficiencies in addressing the needs of a growing market for on-demand services. Over the past year, we’ve seen the release of ever more capable “netbooks,” smart phones, and rumors abound that Apple will introduce a market changing tablet in the coming year. Regardless of what Apple does or doesn’t do – it is plain that an increasingly mature field of online services  means that fewer users will require the same platform they have used for decades. The coming products will certainly be more mobile, more connected, and less tethered to common operating systems.With the rise of applications like Google Chrome, the Chrome OS, Android, frameworks like Flex, and the increasing number of “app stores” for the various smartphone OS platforms, it doesn’t appear likely that the growth will slow down any time in the near future.  As is already happening – 2010 will be a year of increasing market fragmentation as each camp heads in its own direction. I don’t expect consolidation and standardization to begin for at least another two years. For online services this means more opportunities to reach specific markets, but it also requires a level of user experience (UX) and user interface (UI) expertise that few developers have had to address so far. In the short run, the best path is going to be a roadmap of planned deployments to different platforms, starting with the one that is most “ubiquitous” in the vendor’s target market. In the long run, we can expect to see more development environments address the most prevalent options – but there is going to have to be more consolidation for that to be truly effective.

7. Customer collaboration will become a more integrated and critical part of product management and business operations. Just like “SaaS” and “Cloud,” “Social Media” has been so over-hyped in the last year that it has become nearly useless. Some see any mention of the subject as a red flag. “A time-wasting, spam-heavy, productivity killer,” they say. Others have found social media to be a strong implementation of “opt-in” marketing (count me among them). Regardless of which side you are on, I think we can all agree that online services require end-user and customer collaboration to be successful. We’re seeing product management, marketing, support – all aspects of SaaS product operations move toward closer collaboration with their user base and I expect it to continue in the new year and to become accepted as “standard practice” among winners in the field.  To that end, integration of collaboration tools and services into the applications themselves as part of the operations side will grow a great deal in the coming year.

8. Agile will continue to grow in acceptance and will become the dominant approach for both development and business operations “in the cloud.” To understand this prediction, don’t confuse yourself with the “Agile vs Waterfall” software development debate that never seems to go away. Please also drop the religious approach to the Agile Manifesto that some have adopted. Think instead of the implications of a more dynamic, competitive, integrated, and collaborative delivery platform and try to imagine doing business as usual. I don’t believe you can. The philosophy of Agile, rather than the methodology specifically, is a fit for online services that is hard to ignore. Tie that to a product development team that is using Agile methodologies and delivering a nice, steady drip of product improvements to your customers and you really don’t have any choice.  You either align with success or get run over. This means too, however, that ISVs with existing product lines have to think about how they will handle change. Organizational change is never easy and many have decided to basically put the new product into a separate product group. It isn’t the best strategy for the long run, but it may be the only way some vendors can manage the change.

9. There will be a growing awareness of the requirements and responsibilities implied by “mature services.” Let’s be honest – most companies market ahead of capability.  Whether it is to “test the waters” or jump start sales, it leads to a lot of hype and fuzzy specifications that customers see through quite easily.  The fact is though that as online services become more accepted and critcal to their customers, they will have to be more reliable, secure and scaleable.  Some of this falls on the vendor to insure their operations and platform are truly “enterprise-class” but there are a growing number of options that allow vendors to adopt best-of-breed environments and platforms on a “pay as you go ” utility model and avoid the high cost of upfront investment. Taking advantage of them means more consideration of Service Level Agreements (SLAs) and open service histories, but these are emerging and they will continue to be key in contract negotiations in the coming year. We still see people new to the field looking for an infrastructure provider before they start development on a product, but with more standardization and more recognition of the needs of mature services – I believe we will see more understanding that you can and probably will both migrate among providers and have more than one at a time during the lifecycle of a online service.

10. SaaS vendors will stop trying to sell split versions. Ok, this is me, beating a dead horse. But really – if even half of the predictions in this list come true (and I don’t think it is even remotely a stretch to imagine it) – you can’t offer products that will both install locally and as an online service off of one code base and not cut off most of the value your SaaS version could deliver. That doesn’t mean you won’t continue selling to your installed base if you have one – but it does mean you can’t sell the same product you’ve sold to your installed base as an online service. It also means you will probably have to put the online service on its own path to success – not tied to your existing customer base. In time, if your online service is as successful as it should be – you will probably be able to drop or sell off the on premise version – but that is a consideration for the roadmap. So, let’s all hope for the best outcome and stop trying to reinvent the past.

Ok – that’s it.  What do you think? What’s on your list? What did I miss? I went way over my usual allotment for space with this one – but it seemed to need it and I didn’t want to split it up so late in the year.

Here’s to Success for Everyone in the NEW YEAR from the Scio Team!