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.

As I begin writing this series, I have to admit I am deeply disappointed with the portrayal of cloud computing by the pundits, analysts and technical media in general. “The Cloud” has quickly become a metaphor for anything that can be accessed on a network and for the network itself. The term is so broadly used it now can mean anything and at the same time – nothing.

Since as a word, a cloud carries the sense of a nebulous, vaguely defined mass – I guess it is apt. That description is certainly what it has become in most peoples’ minds. At the same time, every cloud provider is telling developers that they need to use their services and develop their applications for the cloud.  What does that mean? Why would I want to?

Let me begin by defining what I mean in the context of this article when I use the term Cloud. In essence, it is nothing more than virtualized infrastructure. The term includes all the resources necessary to communicate, access, process, and store data – but without having to manage and provision physical hardware. For a long time, ten years or more, virtualization technology has been an enterprise tool; used for managing infrastructure resources in environments that include hundreds of servers.

In enterprise data centers, virtualization is generally used to:

• Lower the implementation time and risk for server deployment.
• Aggregate services to improve total infrastructure utilization.
• Improve and standardize failover and server reliability.
• Improve and standardize server and infrastructure management.

In a pool of many servers, these benefits translate to lowered risk and a lower total cost of operation. Getting those benefits in a large pool of servers generally requires only moderate application configuration and no rewrites.

Let’s compare that to a minimal implementation for a SaaS Application – starting on bare metal (machines with no OS or configuration) so we can see how virtualization will impact operational costs:

As you can see from the diagram, when I say “minimal” – I don’t mean bare bones. This is a basic implementation on either owned, local servers or hosted servers that is redundant and will allow for failover and transparent (to the user) scalability.  A bare bones implementation could be just a web server/application server and a database server. But, in that case, every failure, upgrade, change, etc. will take the service offline.

This is an important distinction because SaaS is a cash flow business. Downtime equals lost opportunity. An opportunity lost in a SaaS business is lost forever. Not because you can’t eventually get the prospect back. You can. But in the meantime, you are still spending money to keep your operations running and available. In a SaaS business, operational costs for unused resources (staff, infrastructure, etc.) take away from margin. If taking a server offline means shutting off your service, you will lose opportunities for new business, reliability in the eyes of your clients, and the operating spend for your unused or under-utilized resources.

So, what does a basic redundant and scalable implementation for a SaaS application include?

• 3+ Web/Application servers in a cluster configuration.
• 2+ Database Servers in a replicating cluster to allow for failover.
• 2 Basic Log & Management Service Servers (could be one, but most implementations will use two).
• Firewall, Router, Load Balancer, Network Switch.
• OS, Web/Application Server, Database Server & Associated Licenses.
• Redundant Internet Access.
• Skilled Staff for implementation, maintenance, cluster and performance management.

Before we get to how we’re actually going to host this implementation, let’s also examine the time required. For implementation on bare commodity servers with experienced staff:

• Web/App Server (install OS, web server, application, apply updates, configuration, test, etc.) = 2 days
• Database Server (install OS, SQL database, apply updates, configuration, load database, test, etc.) = 3 Days +

Now most IT people will tell you it would take a little less time if you were setting up machines on a regular basis and you had some configured disk images ready. But we’re considering a small to moderate-size SaaS business, something beyond a beta phase startup, but certainly not a major service. Economies of scale are not available for server implementation in this size business.

While you’re considering the staff costs for an implementation – because you need experienced staff with an Internet-based skill set – you should also realize that these same implementation times will be true when you need to scale your deployment up during regular operation. Ok. We want to avoid as much of that cost as we can so we’ll use a managed server implementation like is available from most hosting companies. This is comparable to having hot standby servers with the OS, standard configuration, updates, and necessary web/app server or database server installations in place and ready. What times are we looking at then?

• Web/App Server (configure for application, install application, test, etc.) = 5 hours +
• Database Server (configure for application, upload database, test, etc.) = 1 day +

In both cases, the time and risk for implementing infrastructure means we will have to scale considerably ahead of need. As a consequence, most SaaS companies will not risk having less infrastructure deployed than is necessary to meet their peak usage requirements.  If service performance suffers, user satisfaction drops and churn rises. If the service cannot respond quickly to peak requirements, it is a lost opportunity and cash flow will suffer.

This implementation philosophy is known as Build-To-Peak.  What it means is most successful SaaS businesses will be over-provisioned more than half of their total operating time. And remember, in this scenario implementation is a manual operation. Someone skilled has to be available to do the work and be on standby to monitor the server and ensure it is working properly for some period of time after the server is stood up. This also means, we aren’t going to decommission infrastructure on a whim. We’re going to stay scaled to handle what we believe will be peak requirements until we’re very sure our need has dropped considerably and will stay that way for an extended period of time. Otherwise, we’re just throwing money down the drain.

So – what does this cost? Taking into consideration a managed server implementation with any of the major hosting companies (RackSpace, Peer 1, etc.) this implementation would have a cost of about $6,000 per month. That’s steep if you don’t have a lot of customers, but it isn’t  even close to all of your operating costs. Let’s assume a minimal staff load to just maintain the service while we hope our total number of clients rises high enough to give us a positive cash flow. What might we need?

In this scenario, I’ve considered that a lot of the staff will either be contractors (part-time) or an outsourcing firm. I haven’t included one-time license costs, office space and equipment, or any payment for the owner/manager. There is no application development cost because that is an investment, not part of operations. There is also no budget for on-going application development and very little or nothing for special promotions or marketing. At $26,900 a month, we are looking at a cost of $322,800/year for operations of a minimal SaaS business.

At this point, you have to step back and ask:

• How much are we charging for this service?
• How many clients will it take to reach positive cash flow and when are we going to get there?
• At what number of clients will our operating costs increase?

That last point is critical to consider. In SaaS, costs tend to increase in jumps.

Imagine: Your customer service and support person is getting too busy. You have to recruit another staff person, train them and get them up to full productivity before you need them or your service will suffer. In SaaS, costs come due ahead of income. That means, in a period of high growth, you are going to need a cash reserve or you will literally run out of cash trying to capture the new business.

You can see – even with a minimal implementation – the total cost of operations in a SaaS business could mean it will take a long time to reach a decent return on investment. If you haven’t modeled your business model properly you may never reach positive cash flow. In SaaS, business scalability is key and operational efficiency isn’t optional.

Now let’s get back to our basic discussion. What will “The Cloud” do to change this? For this size implementation, if we simply move it to virtualized servers on a standard grid-type “cloud” host it will actually cost more to operate per month.

That’s right: On a one-to-one basis, for a full month of usage, a virtualized server will cost more than a traditional, managed server. It will also require IT staff with a more advanced (expensive) skill set. It will do nothing significant to reduce total staff costs.

At this size, and with this kind of application architecture and implementation, the value of cloud hosting is marginal at best. In fact, most of the value mentioned in the bullets at the start of this article is going back to the hosting company that is managing hundreds or thousands of servers. At most, a SaaS company can only hope to shave a few hours off of server implementation and management by moving their application directly to a cloud hosting scenario.

So – why the heck would I say that SaaS companies could be saving 33-50% of their total operating costs by developing for cloud infrastructure?

How on earth can anyone recommend a cloud-based application for anything but the biggest companies?

You’re going to have to read the next segment of this series to find out.

And believe me – if you are planning a SaaS business it is an important lesson…

Over two years ago, we wrote a two part series about SaaS Metrics that has continued to spark interest in the subject. Since that article was written, Scio has consulted with well over 50 SaaS and Cloud companies through our SaaS Strategy Sessions, Workshops and most recently a program headed by FUMEC in Mexico.

This background has given us a broad view of the issues entrepreneurs should consider to plan and operate successful SaaS businesses. There are four common categories that these issues fall into:

• Business Model Scalability - Finding a scaleable, repeatable business model is key and very often lowest on the list of priorities.
• Operational Requirements – Most companies are laser focused on end user functionality. This isn’t bad in itself, but the fact is that SaaS businesses have to plan to manage operations with the least amount of cost and friction possible if they want to reach their full potential. Understanding the operational aspects of their business that can be built into the application and services is critical to avoid situations where business growth and cost control is constrained by operations that cannot scale efficiently.
• Managing to Metrics – The idea of metrics is widely accepted, but in practice, very few early stage SaaS companies have build the data feeds and internal procedures necessary to have the data for reporting and management. Without planning, it is very hard to back the data out of applications that are not set up to provide it.
• Product Planning – SaaS product planning is part business roadmap and part customer management in a carefully orchestrated system that produces what users need rather than simply complying with their wants. When it is done right, it yields a service that can continue to grow with the user community over the long run and produce a competitive edge that is very hard to overcome.

Recently, one of our partners, Rich Chapman of Softletter (SaaS University) asked us if we had developed a spreadsheet people could use to model SaaS metrics. With our client experiences in mind, we realized that we have talked a lot about using modeling to test business assumptions, but hadn’t provided any insight into how someone could build a simple modeling system and what data feeds and metrics dashboard might include.

To solve that problem, this article includes the Scio SaaS Metrics Workbook. This is an Excel Workbook with two spreadsheets. The first sheet has sample data included to highlight scenarios discussed in this article. The second sheet is blank with just the formulas so that you can use it without having to go through the process of cleaning out the sample data. So – if you want to “play along” as we discuss these metrics, you should go ahead and download the spreadsheet now.

A few caveats apply to this example spreadsheet:

• Every business model is its own special case. These metrics and the formulas they use are generally accepted and useful for modeling purposes. They are not however, a “one-size fits all” approach. For a deep dive into SaaS Metrics – I strongly suggest you look at Joel York’s excellent articles on the subject and Bessemer Ventures PDF that came out last Fall.
• A spreadsheet is not a complete approach to actually managing a SaaS business to metrics. Unless it is integrated with actual data feeds, a spreadsheet will require far too much manual data management and will eventually be discarded in the ordinary course of dealing with day-to-day issues. The best approach is to build the data feeds and display them a dashboard in the application. Unfortunately, for most implementations this means feeding some information into the report either from accounting processes or manual input. But, automating the reporting as much as possible is critical if you actually want to use metrics for managing your business. This means planning to provide the data as a part of application requirements. If you don’t, trying to get the data without the “hooks” built in will often prove impossible.
• This spreadsheet uses a 12 period window. The length of the periods don’t have to be months, although the Customer Acquisition Cost Ratio is generally managed on a quarterly basis. In a dashboard approach, a walking window could be very useful to see trends over time. The width of the window used is a decision you have to make to fit your business model. Of course, in the best case, a dashboard would use graphs of the key metrics with drill down reports just a “click-away” for more detail.
• Green, Bold entries should be feed directly from application data. This means your application needs to be built to capture and report on this data. If you don’t have these feeds at a minimum – it will be very hard to manage to metrics. Line 44 may bring some questions. Isn’t total revenue the same as renewal revenue? No, not in all business models. If you have transaction based revenue or utility-based features, your total revenue is different than your total renewal revenue.
• Blue, Bold entries need to be entered either directly or feed from accounting processes. This includes sales and marketing costs and operational costs. It is “fussy” to have to do this manually, but if you can develop a process and flow, it can be just be part of regular cost reporting within your organization.
• Clients are the entities that pay for the service. In a business-to-business SaaS application, this will generally be a company with multiple users. End-users are just that – individual application users who may or not also be clients depending on the business model.

So – with that in mind – let’s look at some SaaS Metrics….

Committed Monthly Recurring Revenue (CMRR) and Average Recurring Revenue (ARR)

Because the SaaS business model is predicated on a steady flow of recurring revenue, having a clear picture of your current standing is key. Using this figure, you can also derive the Average Recurring Revenue per Client which is helpful to understand if clients are generally adopting larger commitments or the average size is decreasing.

You will also see in this section, a set of formulas we use over and over. This is the Percent of Change from period to period and the Average Change. This is not a true trend line analysis, but it gives you an indication of where the metric is heading over time. This is important because in the day-to-day management of a business it is easy to miss the trends that are actually driving your business. In the example you can imagine a sales team crowing about their 28% growth in the 8th period and their 15% growth in the 12th period. But in the end, the average change of 6% tells a more important story of how recurring income is growing over time. Average change or trend analysis is a good way to smooth out the spot variations and help the team concentrate on the larger picture.

Retention Rate (RR) or Churn

When CMRR is growing, it can be easy to ignore the reality that many of the new clients don’t stay around long enough to pay off the cost of customer acquisition that comes from sales and marketing expenses. Startup companies often ignore this, hoping “we’ll make it up in volume.” The truth is that churn represents a steady cash leak that can eventually sink a new company. Most companies try to manage to 90% retention or better. In the spreadsheet example, you can see that the company is bouncing along the bottom with an average RR of 88.9%. Although income may seem good enough now, if the situation continues the cash burn could become a constraint on continuing product development. If there is underlying user dissatisfaction with the service, this will begin a spiral that the company may never recover from.

In Trial (IT), Time to Close (TC), and Close Rate (CR)

While not every SaaS business has a trial option, since most do, it is wise to have a way to track effectiveness of trials in bringing new clients onboard. Trials do work as a sales tool. The truth is that most SaaS buyers are already actively using Internet-based services and expect to be able to “try before they buy.” In some cases, the sales team may set up special trials for key customers, but generally these metrics do not track those special implementations. The point of looking the data coming from trials it not just to evaluate how many sales come out of them. You can find out a lot about how well the application fills the needs for specific verticals (if you have a way to collect data from prospects), if the application has as much of a “rapid uptake” as you suppose, how many testers typically participate in evaluations, how much data is generated (which can quickly become a push to sign a contract) and many other facts about the decision process. So – if you have a trial option in your business plans – set up data feeds that will help you adjust the application and the trial process to be more effective in closing sales.

Average Deal Size (ADS) or Average Revenue per Client (ARPC)

It is easy to confuse this metric with CMRR. Depending on the options available, deal size can vary depending on the period covered by each individual renewal and changes in the package purchased (number of seats, feature selections, prepaid transactions, etc.). This metric can help sales evaluate if clients are buying larger packages, changing feature sets, etc. Because the SaaS model is heavily biased toward recurring revenue, this figure generally does not include first time sales.

Average Revenue Per User (ARPU)

This metric is valuable in business models where a client buys multiple user IDs. Users typically require available support resources and in some instances may have access to features that burden utility-based resources like storage and data transfer. If you don’t track ARPU, you don’t have any way to determine if your revenue per user is beginning to making the pricing base unsustainable. Where multiple income streams are involved, it can be useful to track that income separately and use data to determine what kind of users are contributing the most to these revenue sources. Multiple income streams, beyond a simple subscription model, can be very valuable to a SaaS business if the subscriptions contribute enough to provide the base revenue necessary to sustain the business. Depending on variable income streams (rather than subscription income) to provide necessary operational income and profit however can be very difficult.

Cost of Service (CoS) or Cost to Maintain (CtM)

The cost of services and operations to maintain the application and client instances. This includes hosting charges, hardware and software renewals, support, staff operations, and outside services – everything it costs to operate. In a traditional hosting model, the costs tend to match the highest level of operational needs expected regardless of load variance over short periods. In a fully virtualized model, the costs can vary on a utility basis if the application is tuned to take advantage of elastic infrastructure capabilities. Regardless though, the operational costs are what they are – and that is what we are trying to model and view here. Here the running change is a key indicator again because it can offer insight into trends you might not see otherwise.

Average Customer Acquisition Cost (ACAC) or Average Cost to Acquire (AtC)

This is a “front-loaded” cost because you have to spend money on sales and marketing ahead of revenue. In web-based sales, it is hard to know the “lead-time” from the first moment a prospect comes in contact with the service through to sale closure. Only in the case of special marketing campaigns that include promotional codes can you actually begin to see how the sales cycle works. In the spreadsheet example, we’ve taken the simplistic approach of counting the previous period sales and marketing costs as the contributing factor for the sales in the following period. You could modify this to set a period that reflects your sales model better, but until you actually know the cycle, this is a good starting point and modeling assumption.

This metric also points out another factor: Most business-to-business sales models for SaaS include different subscription periods so you cannot simply assume that everyone is renewing every period. If the option is available, some may purchase on a monthly basis, some quarterly, some yearly, etc. In these cases, a separate report for the tracking the renewal period choices made by different market segments could be very valuable. These reports can answer questions like, “are larger enterprises actually buying the longer periods as we suppose?” “Is this market really acting like SMB’s and cautiously buying every month?” “Do clients tend to buy longer periods overtime?”

Customer Acquisition Cost Ratio (CAC)

This is a complicated metric and there are several ways you could look at it. The point is to aggregate costs and trends to help determine how long it will take to pay back the your sales and marketing costs on based on your current customer acquisition. The aim is to reach a ration better than 1. This means your costs are being paid off in less than one year by the revenue driven from clients. If the ratio dips to .5, it means it is taking two years. If the majority of your clients aren’t staying two years, you are losing money while acquiring clients. In a startup situation, when you are still carrying your initial development costs, this may be a perfectly acceptable situation – as long as you have enough cash on hand to carry your off the “runway.” So, in that way, you have to know your situation to know how to interpret what it is telling you. The example we have given is good for a “running company” but doesn’t reflect a startup.

Other metrics to consider…

Customer Lifetime Value (CLV) is an often cited metric but one that is hard to model in a spreadsheet like this. We’ve intentionally left it off, but that doesn’t mean you should leave it off your list of requirements. I suggest you look long and hard at the literature before you attempt to implement it though. You need to understand what you can determine in your data model and what is useful from a business reporting point of view before you set this metric for reporting.

There are lots of other metrics you might want to use. Largest Client % can be very important, particularly in situations when the total client load is not large. If a single client provides more than a third of the total revenue – it is time to start thinking about how to acquire a lot more clients to offset the risk that client presents if they “walk.”

If professional services are part of the revenue stream, it is important to be able to capture their contribution separately and to see if the balance between PS sales and application sales is sustainable. I’ve seen several models where the two sides of the business operate hand-in-hand, but seeing the contribution of each separately can help you understand how much of your resources you should be devoting to each.

This is our current modeling tool. We are using it now in our consulting practice and will continue to improve it based on feedback from clients and responses we get from users. It is daunting to look at – so I suggest first playing with some of the green and blue inputs to see what happens. If you are serious about managing your business to metrics, you will soon find yourself on the blank sheet running scenarios. And if you have questions or comments - please let us know!

“Scalability” is one of many cloud buzzwords that is fraught with confusion. Most of the time the term is used with a mixed meaning – covering both technical scalability provided by implementations of infrastructure virtualization and business model scalability. The problem is technical scalability by itself cannot impart scalability to a business model. But, on the other hand, technical scalability can be a crucial component of a successful and scalable cloud business model.

In this two part series, we will address the key technical capabilities required in a cloud service to achieve a scalable business model. I’m writing this article because we have found the confusion to be a common thread throughout many interviews and consulting sessions with software vendors bringing their products to the Internet as services. Almost without exception, vendors address end-user functionality clearly, but fail to address their own need to have a successful, repeatable and scalable business model.

A business model is said to be scalable when the incremental cost of acquiring, implementing, servicing and supporting a client drops as the number of clients increases. In a few business models, the service is repeatable but total costs remain relatively stable as the growth curve rises.  In these cases, incremental profit needs to flow from each new client regardless and attractive scalability will be hard to achieve. A fully-scalable business model is not constrained by resources such as skilled staff or materials. Full scalability is not achievable in all markets or business models. In all business models, the total incremental cost per client will eventually reach a point where it is zero or flat.

When the software industry was primarily selling licensed software – scalability was easy. ISVs would develop a software version once and sell it as many times as possible before investing in another version. Each incremental sale from a version lowered the total cost of goods for the ISV. ISV’s selling licensed software only noticed a constraint when the cost of support to each incremental client was more than the client’s share of the cost of goods generated by application development.

In a cloud service model, the challenge is to identify the services and features you must provide and then implement them so that the incremental cost of providing services for each client goes down as the number of clients grows. To accomplish this, the application has to be planned to support a scalable business model from the beginning. Otherwise the cost, risk and disruption from later changes will itself constrain scalability and cause costs to be higher rather until the investment is offset by profit.

The other challenge is that even a bad business model can look scalable during initial marketing ramp-up and growth.  Rapid growth can temporarily obscure the reality that the costs of implementation, support and operations required are not actually going down as the client base grows. Eventually though, as the growth curve begins to flatten and constraints appear, the pressure to maintain cash flow will make it apparent that the business model cannot be sustained long enough to reach an attractive profit.  In services where the amount of skilled staff required to implement each client is remains constant regardless of the number of client served, the cost and time required to acquire and maintain skilled staff will eventually become a brake on growth.

The length of the curve from the point where a business model begins operation to the point where it reaches a zero incremental cost per client, a flat level of cost per client, or a constrained-level of costs per client is the business model’s scalable range. As cloud service providers, the goal is plan the service so you are able to bring incremental costs per client to the far-end of the scalable range – to the point where the incremental costs per client are the most optimized.

The following points are aspects of the application and technical implementation that can provide leverage for business model scalability. They do not have to be achieved on day one of offering a new SaaS product or cloud service. However, to have a successful and scalable service from a business point of view, the application, its architecture and the infrastructure that supports it must be capable of achieving these points within a reasonable period of time without an application rewrite or major reconfiguration of the service.

Checklist for Business Scalability in the Cloud

1. Application architecture is component-based, uses web-services and the database is multi-tenant. In today’s development environment for cloud services, component-based architecture and web-services should be a given. These approaches provide much of the flexibility and continuous improvement we take for granted in online applications today. And without getting into a lot of religious battles about multi-tenancy – the point here is business model scalability. If you do not use the most scalable database architecture, you will always carry the risk and skills necessary to scale and manage alternative approaches.
2. Application maintenance and updates can be applied, or rolled back, to all client instances without business interruption and with minimal effort. In today’s market, cloud services are expected to have both continuous updates and operation. The procedures required to maintain application availability during updates need to be integrated into application development, straight-forward and repeatable.  Again, this has become an expectation across the industry. If your service has significant “down-time,” either planned or unplanned, your availability and reliability will be suspect from a client point of view.
3. Operational service functions (e.g., subscription management, billing, etc.) and reporting are part of the application but separated from client functionality so that they can be extended to additional applications over time, they can be tracked and managed. Operational functions generally scale in a linear fashion as the client base grows. If they are planned properly, they can be leveraged over multiple applications during the service lifecycle – driving down the operational cost. Not having operational functions integrated and automated as part of the application means manual processes will add to the cost of each client, payment cycle, billing change, etc. Manual operations will seriously constrain scalability and profit.. These functions facilitate client interactions with the service provider but they do not directly add to the value a client receives from the service. That doesn’t mean however they are unimportant. If these functions are not automated as part of the service they become a brake on growth as service operations struggles to keep ahead of growth while keeping costs to a minimum.
4. Application services can be purchased and embedded in the offerings of other services. Planning cloud services to allow other vendors to leverage application functionality creates additional channels at very low cost and greatly improves business model scalability. It is less important to know when or how it might happen that other vendors will want to leverage a service than it is to have the capability. When it does happen, it should require nothing more than a sales negotiation.
5. Outside services can be used to extend operational or client functionality as necessary. Application development is a part of the total cost of a cloud service. Just as it is important to allow other vendors to leverage service functionality in their offerings, it is equally important to have the option of leveraging other services so you can adapt their functions into the service without “redeveloping the wheel” unnecessarily. In early phases of the product lifecycle, software development will be the largest contribution to cost and will be carried as a burden over many clients before the business can reach positive cash flow. Leveraging outside services for selected functions (like pricing and billing for instance…) can lower the initial cost of development, significantly improve functionality for non-core needs and allow development effort to be focused on areas that have higher value for clients.
6. User interfaces can be extended to alternative platforms through web services and API calls to allow users to access to client functionality on emerging devices. The market for smart phones, tablets and mobile devices is exploding but it is also highly fragmented. Tying a service to a single end-user platform can constrain growth and put the application in a lockstep with the lifecycle and fortunes of the selected platform. Providing standard, documented methods to extend the service to end-user devices as they develop greatly increases the market and lowers the risk that extensive rewrites will be needed to adapt to new technology.
7. Client implementation is automated and immediate, on demand. Manual processes and delays required for operational functions like client implementations are costs and risks. Client implementations should not require anything more than authorization from the billing and settlement component of an application. This is a good example of the “consumerization” of software. The increasing use of online applications by consumers has created expectations for user-experience that now have moved to business software and services have to adapt to current client expectations.
8. Client instance configuration and integration is client-driven. One-off customizations and integrations should be strongly avoided in favor of embedded configuration choices and API calls that provide necessary data integration. Developing and maintaining split versions is simply too risky and expensive to be considered a sustainable business practice for SaaS and cloud services.  I’ve sat with many prospective vendors who say “our users demand customization” and they simply cannot imagine any other course. But the reality is the practice only works when clients are willing to deal with the costs of system integrators, delayed version updates, and the maintenance issues the practice brings in their own data center. When clients outsource to a service they expect you to bear the cost and risks. Standardizing a product to one version, including those configurations that take the place of 80% of the individual issues clients want to address, solves a great deal of problems for both the client and the service while it increases overall business scalability.

Is this all? Not by a long shot. We’ve got 12 more points in in the second half of this article. Business scalability is a core competitive edge in SaaS and Cloud Services – so please – join us for Part 2.

This is the fourth 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.

Excerpt: How to Eat an Elephant Workshop by Scio Consulting

Planning and developing a Cloud product can be a daunting prospect, especially if using cloud-based infrastructure and services requires a departure from your “comfort zone” in more traditional installed and server-based products. One of the biggest concerns is developing the architecture for the project. For an implementation on something like Amazon Web Services how do you decide on the break-down of the application between the various services Amazon provides? Can you model the utilization scenarios and understand your costs in different situations?

Before you begin that consideration – let’s first make it clear that straightforward server virtualization is not the key feature of Cloud technology. Where Cloud implementations really shine in their value is in the ability to provide highly elastic capacity for specific application elements. This means the architecture can to break out client service elements that are based on utilizing elastic storage, moving large amounts of content, or have bursty characteristics.  Simple server virtualization schemes are limited reaching these scenarios economically because they are based on replicating a the server footprint rather than extending individual application  components.

On the other side of the coin, the “client side” of the application is not the only thing we’re concerned about. We also need to consider an operational side of the application that will support our product strategy and business model.  Hobbling operations by relying on manual processes to onboard customers and handle operations is not a sustainable way of dealing with the “back office details” of the service.  Generally, the operational side of an application will scale in a linear fashion. These components will scale in relation to the number of clients rather the usage patterns of application features by clients. That means utilizing different scaling strategies for various parts of the application. It also means cost modeling needs to be split between dynamic services that are consumed directly by client use and the more linear use patterns of components that are required to operate the service.

To understand the issues, let’s go back to one of the basic problems of a SaaS or Cloud product. There are several elements of these applications that are critical to operations but take considerable effort to plan, develop and implement:

• Multi-Tenancy – For most SaaS and Cloud Services, multi-tenancy is the core approach to application management, generating new instances, and structuring client data. Multi-tenancy is implemented in the database of the application itself.
• Application Management and Availability – Regardless of whether they are designed for the Cloud or not, modern applications are not monolithic. As we have discussed, they are actually a group of components that may have different use patterns and performance characteristics. Managing performance and scaling for the entire application is a basic requirement, but in a component model, you may need to manage performance and response at the component level to leverage the opportunities that true Cloud architecture offers.
• Product Management – Configuration, metering and billing are necessary to manage service packages that can be offered to clients. It is likely your packages will change over time, so your management system needs to be flexible and accept a wide range of scenarios. If you plan to leverage reporting to determine feature acceptance and value, you also need to be able to monitor feature-level usage over time.
• Usage Metering & Billing – If your service has usage-based billing, no matter how it works, you need some way to translate usage into billing. What seems simple can be come complicated quickly when you are faced with various combinations of partial months, changing user counts, differential pricing by user role, promotions, and other unexpected complications. Being able to respond to a changing elastic deployment. It requires much more effort to maintain reliability over changes to the core and operational sides of the application. In the best case, the basic architecture of the application platform supports the kind of load-balancing and instance version control that makes this possible.
• Subscription Management – A subscription is the package of services that a client has subscribed to and pays for in regular periods.  Although they are utility-based, very few Cloud Services can adopt a totally unpackaged, spot use model.  Granular spot use models are hard for the client to plan for because they can represent a risky “uncapped expense.”  And – unless they are based in regular use by a very large client base, they can result in a cash flow that is impossible to plan on. Because of this, regardless of how the service works, most SaaS and Cloud Services will have subscription-based packages and require on-going subscription management and the ability for clients to change subscriptions based on the current feature pricing schema.
• Access Control – Users must be able to access the features related to their role within their company subscription and if the service includes a suite of applications – their access needs to reflect their participation in the suite.
• Customer On-Boarding and Provisioning – When a customer signs up and is accepted, the application should be able to use the information provided at signup to provision a client instance and provide the necessary credentials, roles and access needed to the customer without any manual intervention or coding.
• Service Management and Configuration – When web services are used to provide the different components of an application, each service needs to be managed, versions need to be tracked and dependancies need to be respected. Without a management tool, this work needs to be done manually and can greatly complicate the job of managing new component rollouts.
• Contextual Logging – All servers and applications provide some level of logging – but if there is no mechanism to tie log information to users, clients and features, it can require a lot of effort to track down issues. Some sort of contextual information attached to logs speeds support efforts and improves overall customer support and reliability.

Taken together, these features require considerable planning and development effort to implement. They are not part of the core product value a SaaS or Cloud Service delivers, but they make the difference between a business model that operates and scales successfully and one that becomes burdened by too much overhead to scale repeatedly and successfully across enough customers to reach profitability. As you can see, these components will technically scale in relation to the number of clients the service has, not the features in use by clients and users.

SaaSGrid is one of a relatively small number of middleware servers or platforms that vendors can build on to provide these operational features and it will run either directly on servers or as virtualized servers on a service like Amazon Webservices. In either a virtualized or “bare metal” installation, a tool like SaaSGrid can lower the effort required to develop and implement a SaaS or Cloud product by as much as 60%.

So, when we get down to it – fully leveraging the capabilities of the Cloud for an application means understanding component-based architecture, the expected scaling characteristics and use patterns of each component, and finally the “orchestration” or web services messaging that allows all the components to act transparently across many clients as one application. On the business side, all of these elements have to be packaged and modeled to develop client offerings that have prices aligned to value and use. And – building a SaaS or Cloud product means planning for both client and operational functionality.

<Read the previous article in the series<

Do you need to know more about developing SaaS and Cloud Services to develop your application and business model? You should consider joining us at:

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 NOW for our Denver Workshop and take advantage of our Apprenda-SaaSGrid Special Price
  

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 (Early Bird Registrations On April 15, 2011)

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

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

Go to SaaS University Denver Registration Page

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

Introduction to Our 2011 Workshop Series

This is the first article in a series I will be writing over the next several weeks with excerpts of 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.

Background

First, some background on our workshop. The concept behind the workshops comes from our consulting experience at Scio. We provide Nearshore Product Development for SaaS and Cloud products from our Development Center in Morelia, Mexico. Our clients come from a wide range of industries and cover the range from single entrepreneur startups to multi-national corporations. We focus primarily on the Americas because that is where we can leverage our collaborative Nearshore model best, but we also provide services for companies in Europe and Australia where our background with SaaS applications is particularly important to the projects. Our services center around software development for SaaS and Cloud applications, but in the course of developing apps for our clients we also realize it is critical we contribute what we can to their success.

Over the years we have been providing our services we have found that clients repeatedly hitting the same “bumps” in the road to releasing a service. Some of the issues are business and some are technical. In response, we began to develop consulting services that could help our clients avoid those problems and have a clearer picture of the way forward. These services are strong and well-received, but basically focused on the needs of a single client prior to development by our team. They don’t scale in a way that we could easily provide them in a more generic setting to multiple companies. So – to fill that gap – we developed a more formal approach to what we began to call the Cloud Product Roadmap.

The idea of a Product Roadmap is not new and we’re certainly not the only ones to use the idea. Our particular focus however brings a concentration on the factors that are critical to success in the field of SaaS and Cloud Services. Broadly, our roadmap leverages the concepts of Agile Software Development, Lean Product Development, Customer-Driven Product Management, and the collaborative environment they require at all levels of the project. From our experience and a growing number of practitioners in the field, this is the secret sauce behind a growing number of successful SaaS and Cloud products. The elements of this roadmap are increasingly seen as the standard for product development and management in the field.

The workshop itself is an intensive, interactive discussion of the critical issues and decisions that need to be made to launch, manage and maintain a successful SaaS or Cloud application. It covers both the business and technical aspects involved as well as the iterative cycle of decisions that have to be navigated to arrive at a complete roadmap. The events are intentionally small to provide more opportunities for discussion and adjustment to the needs of the attendees.

So – what do we talk about in our workshop? Here is an except from two slides in our Business Model presentation:

Cloud Product Roadmap – Business Model

Excerpt: The Democratization of Entrepreneurship

A successful business model in SaaS and Cloud Products evolves from a series of iterations between the concepts for the product and the business that supports it while deriving income from the value it provides clients. The process has been best conceptualized in the writings of Steve Blank and Eric Ries and identified as the “Lean Startup.”

The key point is that the ideas behind business model development and the process of developing a successful software product have changed in the last few years. Experience and technology have come together in a way that makes it much easier for individual entrepreneurs to enter the field.

Consider the traditional barriers that confronted entrepreneurs:

• Long, technically-driven development cycles – A lot of the basic functionality required didn’t exist. There where no models or platforms to build on. Development required research and highly-skilled, technically creative development teams. Development cycles were long, feature lists were exhaustive, and the risks were high. Imagine a development cycle of more than a year for a platform that has a regular renewal cycle of three years. Add to that an implementation environment that varies from client to client because they are all isolated. There is a lot of risk to absorb in taking on a project like that and most individual entrepreneurs don’t have that kind of resources.
• The high cost of the first customer – In this environment, the first customer implementation carries tremendous cost and risk. If there is a failure in the implementation or the product fails to meet expectations, it becomes very difficult to recover. Is the product wrong or the customer a unique case? It is hard to know. If you go forward assuming this case is unique, you continue to carry the risk that you have spent a lot of money going down the wrong road. If you assume this is a clear indication that your product is at fault, you could increase your total cost and risk even more by spending the effort to fix the perceived problems. This is exactly the risk that high license fees had to address. The entrepreneur fronting the development of a complex product is taking a lot of risk in an installed environment.
• Limited financing options – The high capital needs and limited options available for a pool of thousands of new businesses created a focus on funding rather than the product itself. This was the era of the one-page business model and the endless cycles of meetings with venture firms in Silicon Valley.
• Expertise in entrepreneurship and product development concentrated in a few places – The skills and resources needed to form a successful team concentrated in parallel with the financial firms that could handle the risk and investment. Outside of Silicon Valley and a few other areas, it was very hard to find resources.
• High failure rate – Entrepreneurism is a process of failure. If you are averse to risk and failure, your upside is badly constrained. With the high investment required, only a few could stand the risk of a new project.
• Slow adoption of new technology – By its nature, the success of a software product depends on the adoption of the basic unit of implementation – the computer or platform that runs the software. If the initial cost is high, skilled resources are limited, and the knowledge of the value that can be derived is low – adoption is limited to the few brave souls with the vision and resources to take the plunge. When communication itself was slower and less driven by the individual, it was very hard to build acceptance of new technology.

What has changed?

• Compression of the product development cycle – Instead of trying to cover every possible aspect of a founder’s vision, current product development processes focus on the minimum number of features required to deliver value. Using Agile development techniques, a functional application can be evaluated much sooner and put in front of customers at a much earlier point. Add this to the ubiquitous delivery medium of the Internet and you have the capability to reach a wide range of prospective customers in a very short period of time. This allows you to leverage customer much sooner in the development cycle and correct your course while your risk is still manageable.
• Lower funding requirements – Over time the number of tools and services that lower the effort required to build and implement a product, especially in current cloud configurations, has increased geometrically. This lowers the time-to-market and investment needed, which creates an environment where investment can be forestalled until a ramp up is justified by market acceptance, positive cash flow and real customers.
• Funding tuned to encourage and manage the search for a sustainable and scalable business model – Smaller steps in the development cycle, success-based funding, with a focus on waiting for key investment until a repeatable and sustainable business model is found. In fact, in many business to business models, venture funding is not needed at all. Positive cash flow and traditional business instruments can carry the load.
• Entrepreneurship recognized as a management science - The overarching process and philosophy is well understood. A successful business model is not luck. It is achieved with a roadmap approach that can be repeated over and over.
• The consumer Internet paves the way – The acceptance of the Internet by consumers and the change in their perceptions of technology is becoming part of business DNA.

The Second Installment in this Series is now Available >

So – Are you considering or developing a SaaS or Cloud Product? Are you operating a Service that isn’t reaching it’s potential? Do you want to know more about how you can leverage the success others are having in the field?

• How are you going about the process of business model and product development? Is it serving you?
• What do you know about current techniques and experience in the field? Can you evaluate which ideas could work for you?
• Do you have a product roadmap?  Do you know how to put one together and use it?
• Do you know how to navigate your product to a successful launch while minimizing your cost and risk?
• Do you know what it takes to operate and maintain your service while continuing to respond to your customers needs?

…This workshop answers these questions and many more. It leverages our field experience across many projects and many situations

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