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.

“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

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

How many times have you seen software marketing pursuing “feature comparisons” – either as a method to breakdown version options or as a comparison against competitive brands?  Does “thousands” or “millions” of times sound more accurate? Can you navigate feature list comparisons?

If we were really honest. I’d bet most of us would admit when faced with feature lists we simply resort to numbers. Product  A has X number, the alternatives have X minus. But then, who makes up the list? And who says which implementation of a feature is “better” or even real? The marketer making the table is the one making the rules of course. If I make a feature comparison table, you can bet my product or service will have “more” checks in the boxes against the list I make.

So, what really counts?

I was reminded of this discussion (which we at Scio engage in as a matter of course when we start considering development of a new product for a client) by two recent blog posts by SaaS and product marketing gurus, Peter Cohen and George Colony.  Peter’s post, “Too many choices aren’t necessarily a good thing” points out that most customers, when faced with a lot of choices simply freeze and don’t buy. We see this all the time. Entrepreneurs entering the field of SaaS for the first time are often overwhelmed by the number of choices they are faced with. In response, they either drop the idea of developing a product “for now” or simply make a few gut level choices and charge on hoping for the best.  Most put the idea on hold.  Considering the risk, if they can’t parse the choices or get someone to help them, maybe it’s for the best.

George’s short post, “Apple Versus Nokia: The Primacy of Design” contrasts the returns on the Apple approach to product options to Nokia. Nokia has 86 models of cell phones available. Apple has two. Nokia sold 111 million phones in Q2 for a net profit of $286 million (3%). Apple sold 8.75 million cell phones for a net profit of $1.1 billion (21%).  Which business would you rather own? Better yet, which business would you rather run on a daily basis?

Of course, there are many sides to the question of buyer choice. Maybe buyers do want the “cool factor” as some say of Apple products. On the other hand, if Apple had an additional 84 models – would it actually sell more phones at the same margin? The answer is – most likely no. The cost of development and manufacturing alone dictates that in a market with limitations (not everyone wants a phone, needs a new phone or can afford one with service) that significantly more models will inevitably result in a higher margin and lower profit, even on higher sales.

There is also another factor, perhaps more interesting for the SaaS market. To a large extent, Apple is selling to end users. They have only one carrier, AT&T. There are a limited number of calling plans available for the iPhone. Buyers don’t have a lot of choices to make beyond, “Do I want an iPhone?” Nokia, on the other hand, is actually selling to carriers. Carriers differentiate on the combinations of brands, models  and plans they offer. For end users, this makes their choice even more complicated. You want phone X because of features Y and Z? That is only available under plan B with carrier C in your area. In the end, most users end up making the choice simple by asking “how much can I afford and still get decent service?”

Considering this paradigm in the context of a SaaS product – I would point out:

• SaaS is by and large a “business-to-business” (B2B) market where purchase is funded by a business client but endusers ultimately determine value and client retention.
• The more options a pricing plan has the less likely it is the client can make a logical choice for their users. Faced with a wide range of options, most will simply pick the highest or lowest price depending on their immediate budget and perceived value. That choice may or may not work well for their users, which one way or the other will play out in adoption.
• Feature lists do not equate to usage. Experienced SaaS vendors with feature monitoring and metrics can tell which features are in use by which roles, by size of client, by time of the day, month, year and a lot of other factors. Vendors of premise-based, licensed software rarely, or never, have access to that kind of data.

Understanding these key differences in marketing, pricing and determining features for a SaaS product are critical. Starting out, a SaaS product is much better off focusing on a narrow set of features (the 80% of value is driven by 20% of features – the Pareto principal) with customer development leading the way to a product that meets real needs.

The simple facts are:

• Having a strong understanding of the core value your service can deliver to its customer is not the same as knowing what endusers need to utilize it.
• Most often core value is supported by process and decisions within the client operation – incorporating and integrating them in the application is key to retention. If you don’t – eventually client workarounds become solutions or existing solutions become barriers to adoption.
• Monitoring, embedded user feedback and client interaction can (and should) be built into the “application suite” from a user point of view and part of the product management/feature development process pre- and post-release. Progressing from the core product to a form that quickly and continuously delivers value to endusers does not need to be an act of black magic in SaaS.  The tools and methods are available, accepted and expected by users and clients in today’s market.
• Building from the “visionary core value” to delivering a service driven by user and client “pull” puts the vendor in a very unique and competitive position. The client’s perceived value increases beyond cost and if they understand the product development process, becomes a key factor in retention.

But all this brings up one question -

What is “Core Value” for users and clients?

To answer this question, I suggest borrowing from the Theory of Constraints and ask, “What limitations will the service remove for clients or endusers?”

• Will it remove questions caused by the lack of quality data or understanding?
• Will it remove costs that prohibited action?
• Will it remove long processes, strict controls, rules, workarounds, or assumptions that limited users or client capability?
• And finally – What value will removal of the limitation unleash for clients?

Notice that cost and value are not the same. A simple accounting of costs does not account for lost opportunity or gained speed, quality or competitiveness.  It is also important to consider that in many cases, the client cannot see what they are currently doing as a limitation. It is simply what they do to achieve a goal. Gaining adoption requires creating the vision of what would be different in the end while still accomplishing the goal.

Figuring this equation out and developing the vision isn’t light work. But it does put a different light on marketing, the features required and the pricing of the service. It is equally important for new services and existing offerings. It is an on-going activity – it doesn’t end on day one of the new product release or after the latest “version” is in front of users.

So, it might seem that “Keep It Simple, Stupid” (KISS) applies, but in truth, there is nothing stupid about understanding and acting on core value in SaaS. Clearly understanding what a client sees and can realize as value is the key to developing, marketing, pricing, sales, adoption, retention and success in SaaS.

Our workshop with Software Pricing Partners following the SaaS Summit: All About the Cloud is now finalized! Seating is limited so please check the details below and sign up NOW:

SaaS Offerings: How to Develop, Price, Operate, and Succeed

• One Day SaaS Executive Workshop Covering Technical and Business Topics
• May 13, 2010 at the Donatello Hotel (near Union Square) San Francisco

Executives responsible for succeeding in the SaaS market need to make a series of critical choices in developing, packaging and selling their offerings. This one-day workshop provides the insights and tools needed to make the right choices.

Many of the challenges SaaS companies face can be met by balancing and integrating technical considerations with the business aspects of SaaS. Companies that can do this can bring their products to market rapidly and become cash-flow positive quickly.

This workshop is the first to integrate pricing and business models with development and deployment. The workshop will be held on May 13th, the day after the OpSource and SIIA event SaaS Summit: All About the Cloud at the Westin St Francis Hotel on Union Square in San Francisco. The workshop venue is conveniently located one half-block from the St Francis, at the Donatello Hotel on Post Street.

Which companies can benefit by attending this workshop:

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

Company challenges this workshop can help overcome:

• Building out a suite of products but are unsure of the pricing and operational models needed to grow.
• Developing a framework for sorting out technical and strategic choices required to move to the SaaS business model.
• Facing significant operational problems including efficiency while keeping churn under control in an existing SaaS product.
• Ensuring the pricing model, development framework and operational plan will work in complex, highly competitive markets.

Topics to be covered:

• What Makes the SaaS Model Different and Difficult?
• Making Development Choices Strategically
• How to Choose an Effective Pricing Metric
• Creating a Lean Product Development Roadmap
• Using Packaging and Licensing to Increase Success
• Finding the Right Price Levels and Discounts
• Operating a SaaS Business
• Auditing Your Plans with a SaaS Reference Framework

Because of the value of this workshop, the importance of the SIIA/OpSource conference for SaaS providers and the convenience of the venue, this is an excellent opportunity to “put it all together.” The workshop content makes it well suited to a mixed group of business and technical members of your team because it joins the issues of both sides into a single view.

Per Person Pricing

Group Promo Codes

Three or more members of the same team:

• On or before May 3rd – 57KA5G
• After May 3rd – 7GNGBH

All attendees will receive copies of the workshop materials. The workshop fee also includes a “working lunch” and refreshments during the day.

Secure Registration with Acteva.

Hotel

The Donatello Hotel has a limited number of rooms available for workshop attendees at $139 during the period of May 9-14. This is an excellent opportunity to save with a very convenient location if you are also attending SaaS Summit/All About the Cloud Event.

• To receive this discounted rate, you must the contact the hotel directly at 415-441-7100 – and ask for In-House Sales and  the “SCIO Pricing” discount.

About the Speakers

Michael Dunham, VP of Service Engineering – Scio Consulting
Mike Dunham has more than 20 years of hands-on experience helping major corporations and government agencies succeed in an increasingly technical environment. As Scio’s principal consultant, Dunham provides clients insight into trends that affect business and technology planning so the processes Scio uses can bring clients’ ideas to life. As the VP of Service Engineering, Michael defines Scio’s service products and operational processes. A native of Sacramento, CA, he holds a bachelor’s degree in business administration from the University of California at Davis.

Jim Geisman, Principal and Founder – Software Pricing Partners
Jim is an acknowledged expert in software pricing and, since founding the firm in 1982, has helped several hundred companies develop effective pricing models and strategies. His consulting spans established and emerging software companies delivering B2B solution via desktop, enterprise-class and, more recently Software-as-a-Service / on demand software. Jim has been a board member or advisor to several early stage technology companies. He holds degrees in Electrical Engineering from Tufts University and an MBA from Harvard Business School.

A quick introduction on our podcast:

I’ve debated writing this article.  Do people expect me to write about Project Management? Well… developing software products does mean you need to plan a project. You need to know and control your risks. So – yeah. I guess it does fit.

My thoughts on this subject come from practical experience.  Companies who come to Scio with their projects often come with a multi-megabyte PDF, UML diagrams, and a list of specifications. “Give us a firm, fixed price for getting this project done by June 2nd at 2pm Eastern,” they say.

Their basic idea is:

• Software projects have a unenviable record of finishing over budget and way over the estimated completion date – we’ll set those so they can’t creep.
• Software outsourcing is risky so we’ll limit our risk by agreeing to a cost and timeframe we can live with and possibly tag onto some event.  “Shoot for the June trade show so we have a shiny new product to sell,” Marketing begs.
• We don’t have the resources to do the project in house, but we don’t trust any outsourcing group – so we’ll rope them in with a fixed fee and time and put all the risk on them.
• We know perfectly well what our product needs to be. If we don’t nail this down, we won’t get what we need for the price we can afford.

The result of this thinking generally speaking is:

Flaming Disaster!

Why? Their basic instinct wasn’t wrong. Software projects do fail to meet their targets with astonishing regularity. They were just trying to limit their exposure. What is happening?

There are five intrinsically linked factors in estimating software product development projects:

1. The Total Elapsed Time expected to produce the specified product.
2. The Effort required to produce the product.
3. The Cost the client expects to expend.
4. The Resources required for the project – their skills and availability.
5. The Specifications for the product; the features, functionality and user experience.

In general terms, what clients are trying to do is set a “target.” In project management, the general assumption is you can set any one of the five factors as a target for a project, but when you do, you need to let the other four float to where they need to go to reach the target. So if you set cost, you need to vary time, specifications, effort and/or resources to reach a mix that will achieve the project goals within the target cost.

Instead, clients set two or more factors in an attempt to “hold the line” on all the other factors. They spent a lot of time on those specifications. They need them all!

But in fact, setting more than one factor as fixed creates an almost impossible tension among the remaining factors that almost assures the project will fail to meet its goals. There are no levers left to control the project! It starts out with the best of intentions, but with two or more factors fixed, any change in circumstances during the project creates an imbalance that cannot be corrected with the remaining factors.

Why does this happen?  Stepping away from our example of setting time and cost as the fixed factors – think about each of the factors individually and the impact they have on the project:

Time

The elapsed project time from start to finish is always different than the total effort applied. Time is measured by a calendar start to finish. Conversely, effort is the sum of all the time expended on a project by the assigned resources.  Total time is never equal to the total effort unless only one resource is assigned, full time.

Software development projects rarely finish on time. Unplanned specification changes, unexpected risks, and resource changes always build up over time and eventually result in a project that is both over budget and beyond the allocated time.

Time to completion can only be estimated and controlled well over short periods. As the time period considered in an estimate increases, the accuracy begins to degrade because of variations in expected effort, the depth and complexity of the specifications involved, the skills and availability of the resources required and the limitations an assumed total cost puts on the project.

It should also be understood that time to project completion is rarely scoped as a direct result of the estimating the effort required.  More often, “artificial completion dates” evolve from a point in a product marketing plan, the current product position, and/or customer demands.  When this happens, there is usually some consideration of project scope, but is rarely enough to address the situation that arises from not first doing a straight-forward evaluation of the effort required to complete the specified product.

Effort

The accurate estimation of effort is key to successful software project costing and setting a realistic expected time to completion. In practice however, the amount of effort required to actually produce each bit of application functionality always varies from estimates. The more detailed and contingency bound the estimate becomes, the more likely it is to be wrong. Because of this, past experience and general effort assumptions are used across a project estimation, in the belief that in the final outcome everything will average out. Of course the reverse is also true; averages can never address the all risks in an individual project. So, while averages are a practical approach to project estimation, they cannot yield a project quote that can be fixed to a specific figure without risk.

In this situation, risk buffers for variations in specifications and resources are recommended for effort estimation, especially in Agile development methodologies where development iterations are “timeboxed.”  Timeboxing iterations means variations in effort will generally cause functionality to be pushed ahead to the next iteration and a “snowball effect” can be produced where the amount of effort required for each iteration increases incrementally beyond estimates over time. If buffers were used, more projects would reach their estimates, but in the drive to reach a more competitive price, they are rarely employed when using assumed effort to arrive at fixed cost.  This results in a very narrow margin for error in effort estimation.

In addition, the amount of time required to reach project completion is not directly related to the number of resources available concurrently. Determining effort depends on an experienced assessment of an efficient team size for the project and the methodologies used.  Increasing the number of resources and concurrent tasks beyond a certain point increases coordination and communication overhead exponentially.  Increased team size tends to increase errors, oversight, and testing cycles without a cost effective increase in total output.

Estimates of effort required tend to be assessed from a straightforward analysis of specifications.  During projects, the actual effort required frequently increases beyond estimates because of “fixes” required to bridge the gap between specifications and the product as realized in development.  In addition, the elapsed time required for QA by the client team is often under-estimated and can result in either idling development or moving ahead with incorrect assumptions and subsequent rework.

Cost

Software development projects almost never finish under their expected cost from the point of view of clients. A few finish at the client’s target cost, but generally only at the expense of other project factors. As a result when projects do cost what was originally expected, the product is often a failure from an end-user point of view.

For clients, target project cost is generally a function of:

• Expected product price and the desired return on investment that could be produced by an estimated number of paying customers in a reasonable period of time.  In other words, a string of dependencies that may have little basis in the final analysis.
• Available funds and cash flow limitations.
• Experience with “similar projects” – However, only rarely do estimates based this way actually work out to be similar in the effort required.

Target cost is never or only rarely based on:

• The steps and effort actually required scope and develop a product that is a successful market fit.
• Small, incremental steps that can be estimated with a reasonable chance of success.

Specifications

Specifications are almost always assumed to be a known and set factor in fixed cost projects. They are used as the basis for effort estimation and effort estimation ultimately determines quoted cost. Clients generally have a basic expectation that their specifications do not need to be varied from substantially to produce the desired product at the specified cost.  Clients often expend great amounts of time producing specifications for bid to assure they will be complete and assumed to be fixed. But in fact, not assuming specifications will need to be varied as over the course of a project to meet fixed cost results in a continuous tension between the effort required, the scope remaining and the time remaining on the project clock.

Most fixed cost projects have intentionally limited options to change scope.  Instead, limiting scope change by not providing workable options increases the risk the project will not reach desired goals when actual product is assessed by end-users.

Software development requirements can never be complete enough or communicated well enough to insure understanding and success.  Errors in interpretation, over-broad and over-complex specifications result in many “fixes” that are not related to actual code errors by the development team.  These fixes are actually elaborations or “clarifications” of project specifications, but in most projects they are assumed to be “bug fixes” in the process of development, testing and QA. In practice this means the actual functionality works as specified but the implementation is not as desired by the client. Fixes of this type generally add to effort and resource allocations without the assumption they should impact specifications, time or cost.

Software development project requirements are by their nature improved by discovery on the part of both the development team and the client team during analysis and development.

In the course of normal work, discovery exposes:

• More depth than expected (scope creep).
• Different aims and approaches from client and end-user feedback or unexpected insight from seeing the product as it develops.
• Technical limitations or alternative approaches that change requirements, the effort and time required.

In most software development projects, there are no assumptions or procedures to handle specification discovery and subsequent changes. This results in many variations from project estimates and is a significant factor in project overruns.

Resources

Resource management is a function of having the right skills available when needed for a specific task in a project. With limited resources and funds, this is a difficult task for software development companies.

Both internally and externally, software development companies have an ongoing need to balance new projects against support, maintenance and enhancement of existing applications. Companies need to decide the level of investment they will put into new technology. Using time from existing work to move to new technology skills is a difficult and expensive proposition. Recruiting for internal resources is a long, expensive process that often fails to yield dependable, trained resources in the long run.

These factors are the leading reasons clients consider outsourcing. But they are also a factor in outsourced projects themselves because at some level, the client team becomes involved directly with the outsourced team and the results of team resource management. The management of new software development projects is difficult by itself. Because of the time and risks involved in recruiting resources with appropriate skills and knowledge, client project/product managers often don’t have a good understanding of the technology and limitations in the project they are managing.

In this situation, outsourcing software development often leads to a confrontational relationship where the client team feels they have lost control and don’t understand the choices the outsourced development team has made or what effort is being applied to produce deliverables.  They don’t understand that the estimation for time to completion was figured against assumed effort but the accuracy of that assumption varies according to specification clarity, resource skills and availability.

In Summary

Variations in the five factors during a software development project leads to:

• Defensive reactions to clarifications and changes between the client and development team.
• Situations where the actual effort in the given time varied depending on specification accuracy and resource skills and availability leads to confrontations.  When time to completion is figured for fixed cost, it is generally figured against assumed effort. Without assumptions for what controls are available to deal with variation, the confrontation continues to simmer throughout the life of the project.
• Lost opportunities for a partnership-like relationship of shared risk and reward.

The solution could be as simple as not setting more than one factor as fixed, but in practice that is hard to do for many projects. What is really needed is a consultive framework for communication and decision making that is informed by real time reporting during the project and collaborative resolution of issues to reach the client’s goals. It’s easy to say, but it takes understanding, planning and agreement to accomplish.

We’re constantly working on this paradigm everyday – it’s challenging and rewarding. What’s your experience? How do you hold the line? What controls do you have realistically? Have you recognized the five factors in your project estimation process formally? I’d love to hear your thoughts…

]]> http://blog.sciodev.com/2010/04/06/the-5-variables-of-project-estimation/feed/ 5 http://blog.sciodev.com/2010/03/23/saas-irrational-fear-of-platforms/ http://blog.sciodev.com/2010/03/23/saas-irrational-fear-of-platforms/#comments Tue, 23 Mar 2010 20:24:16 +0000 Michael Dunham http://blog.sciodev.com/?p=833

I find much of what I read in the media about the “issues” involved in developing SaaS products as silly – and sometimes just plain misinformed. Is it just me or are there just too many analysts with nothing else to write about? Hint: Pick up the phone and talk to some people who are actually developing a SaaS product…

SaaS itself is a victim of this type of FUD (Fear, Uncertainty and Doubt). There seems to be a rise again of articles about “continuity assurance” and “source code escrow.” I’m not going to link to any of them – all of them seem to assume that there needs to be some draconian legal answer to the problem of data portability. Let’s be honest people – No Technical “Solution” is Forever <PERIOD>. If you’re not taking steps to manage your risk for control of your data and processes from day one you’re in trouble no legal agreement or high-priced lawyer can fix.  And yes, a smart SaaS vendor will build portability into their product because they understand the business value it gives – but nothing can force customers to use it and plan properly.

Likewise, I think people who are researching the business and technical issues for developing SaaS products are finding more FUD than substance. Yes, SaaS business operational issues are different, particularly for vendors of traditional “premise-based,” single-tenant applications. Yes, the technical requirements of the Internet-based and “cloud” environments are different.  In fact, it would be a good idea to seek help on these issues so you can concentrate on delivering a service with business value.  But honestly, I would and have recommend that for anyone developing a software product today. Think lean. Don’t waste money and time developing what you don’t have to – use services and frameworks you can leverage. Spend on developing a product customers will pull into the market. Learn customer-driven product management.

But doing that means leaning on tools, frameworks and yes – platforms so you can focus on your product. Enter the Boogie Man. Analysts produce lists of lists of keywords that capture a perceived issue: “vendor lock-in,” “Opex Vs. Capex,” “proprietary lock-in,” etc. And as anyone who has followed the industry knows – there have been failures.  But on the other side of the coin – the number of failures has been quite limited considering the wealth of tools and services available.  That isn’t a lot of solace to companies that bet on Coghead – but I have to say they should have seen the writing on the wall a long time before the doors closed. The total lack of data/code portability tied to a vendor that was clearly struggling to get traction and funding (read: no business model – the smell of burning cash) should have caught prospects’ attention.

The real truth is that software development has been depending on tools, frameworks, application servers, services, and platforms since the days when we left assembly code behind. You can’t avoid them.  If we were constrained to coding directly for each processor and environment, technical progress would be dismal indeed. Java, C#, HTML, .NET, Apache web server, XML, PHP, Ruby, Python – all of these simple examples are at some level an abstraction of layers below them. But like Microsoft’s Visual Basic – they are all tools that have a lifecycle and will eventually be superseded or folded into the next generation product. Technology moves on. Nothing is forever.

Of course, this doesn’t mean application developers shouldn’t consider where their tools are in their lifecycle and viability of the community of users around them. It doesn’t mean that the business side should ignore the risks of the choices the technical team has made.  It doesn’t mean we don’t need to have an idea of what we would do if the worst comes and we need to change our assumptions. How long would it take? What would the most likely alternatives be? What is the real risk of doing nothing because you’ve become a “deer in headlights” with all the choices you have to make – instead of just making decisions, allowing for risks and moving forward to a positive cash flow from a product with a growing, paid user base?

Because we don’t believe “doing nothing” is an option that will lead to success, at Scio we’ve made a conscious choice among the tools available to us. We’ve picked a group that we believe deliver business value to our customers.   We have invested our time and resources in this “platform” to develop our delivery expertise and are continuing to do so.  I say that not to highlight ourselves – it is what service companies do. They leverage tools to deliver their services better, repeatably and more competitively.

Do I need to say it? SaaS is a service business. Don’t succumb to the irrational fear of tools you can leverage to better deliver your expertise and value to your customers. Learn to evalute and manage risk. You cannot be successful if you are totally risk averse.

If you’d like to know more about how to navigate the operational and technical choices in developing SaaS products – let me make a suggestion: Jim Geisman, of Software Pricing Partners and I will be giving workshops on SaaS following the OpSource/SIIA SaaS Summit 2010 – “All About The Cloud,”  May 10-12 in San Francisco.  We’re very serious about making this an opportunity that people can take advantage of – so we’re “crowd-sourcing” the workshop configuration before we open registration. We need feedback from people who are either planning to be in the area for SaaS Summit or are just in the region and interested in attending (you don’t have to attend SaaS Summit to attend our workshops – but we encourage it).

Would you give us some feedback on the workshop configuration that would be most useful to you with this survey?  We would really appreciate your help on this.  And watch for more about the workshop starting next month.

I’ve seen a lot of different “roadmaps” for SaaS products lately. Some of them are good guides for specific questions. Some are simply misleading or poorly focused. But only a few of us are talking about the two guiding thoughts behind a realistic roadmap that are critical to success:

1. Developing a product that customers want, will pay for and will advocate
2. Finding and scaling an economically viable business model without wasted time or money

These two points form the basis for a slowly building consensus among founders of successful (and some failed) SaaS companies and those of us who have been involved in multiple projects over time. If you haven’t come across them, you will if you need to go for funding of any kind or show a business model these days. These folks are in the business of making money from the SaaS business model and developing companies with a worth that is many times their investment.

People who are unfamiliar with the Lean concept often think that it means developing a product that is at best, minimal and at worst, a product that is too basic and that no one will actually want. We’re used to the idea that it can easily require a two-year development cycle to get a fully-featured product to market. So, when someone says, “We can develop a SaaS product in six months or less!” there is a tendency to dismiss them as novice product managers or marketers.

If this has been your thought, I don’t blame you.  You should question what is behind that type of claim. If it is just the size of the development team that can be brought to bear on the project, I would remind you of the old joke in production engineering:

“While we know that it is true a woman can produce a baby in nine months, this does not mean it is also true nine women can produce a baby in one month.”

For our own part, we’ve developed our concept of lean product development based on careful analysis of what we could provide to our customers to help them be successful. Rather than repeat the entire mantra – let me call out some leading references you should be familiar with for evaluating your roadmap:

• Bessemer Cloud Computing Law #1 – Less is More! Leverage the cloud. Don’t spend money to build features that don’t provide direct value to the end user.  Go into the market and “rent” services. Services allow you to concentrate your resources (time, talent and money) on your core value. They will in fact be richer and more cost effective than anything you can afford to develop.
• Steve Blank – Perfection by Subtraction – Having a clear, tight vision helps to keep development scope down, but it isn’t the key to the “minimum viable product” often mentioned in discussions about product development.  The key is to get a product in front of customers who can understand the vision and who can become evangelists for it because – They have a problem your vision will solve. They understand they have the problem. They have been actively looking for a solution. They have put together some parts of a solution themselves. They have or can get a budget for something that solves the problem.  These customers can validate the vision and will actively pull it into the shape that fits their context. With them behind you – you can develop a beta product that is much closer to what the market needs.  This is also part of Bessemer’s Law #5 – Build Employee Software – which talks about the “consumerization of software” that SaaS has enabled.
• David Skok – Why Startups Fail – The business model is just as important as the feature set in the end. We’ve all heard of great products that never sold enough to return their investment before failing. Learning if you have a market fit, if you can actually scale your operations profitably, if the cost of acquiring a customer (CAC) is less than the average lifetime value (LTV), and if you are going to have enough cash when it comes time to hit the marketing accelerator pedal – these are differences between success and crash and burn. They come down to having a roadmap that gets you into the market early, allows you to test your business model and your product before you have burned all your cash.
• Eric Reis – The Promise of the Lean Startup – Leverage the Agile methodology and philosophy to develop progressively based on customer pull rather than a miracle of market anticipation. We’d all like to be Apple, but we’re not – and getting there is a lot harder and more expensive than we need to expend ourselves on.  The SaaS multi-tenant model allows incremental releases and fixes, usage monitoring, and real feedback-driven products that customers pay for. Eric has a very good presentation with the difference between two companies he was with – that brought him into Lean thinking.
• And finally – Evangelous Simoudis – Criteria for Determining a Company’s SaaSyness – This brings all the previous ideas together with having a successful business model and product BEFORE you go for funding. This puts funding when it will do the most good – when you can use the extra acceleration to get the proven product in the market and when in the classic hockey stick market model, it will be easier to get cash with attractive terms.

But – that means having a roadmap that allows you to make these things happen with a reasonable investment. It means signing up customers and getting cashflow before you reach what you might otherwise think was a full-featured product. It means a company with a product in a licensed model will have to think a little differently than a startup to retain their existing customers, but the larger picture should remain stable.

So, coming back to the premise of this article – a realistic roadmap for SaaS should allow you to -

• Validate your vision with early adopter/evangelist customers as soon as you can show them your the core of your product’s business value.
• Test your marketing, sales and operations during a beta that is still less than a full-market version, but allows you to show your vision to the broader market and get further feedback.
• Leverage services and products that allow you to focus on developing the core value and keep your choices in line with business outcomes – lower initial cost and faster time to market.
• Keep your investment to a reasonable level, particularly in advance of breakeven, and allow high power funding to come when it can do the most good – when you have a proven product and customers.
• Allow early cashflow by having a product driven by paid customer demand.
• Be Agile and flexible in both your product development and your business model.

At Scio – we have used these points to come up with a general roadmap that we customize for each customer’s situation.

Our choice of methodologies, tools and technologies is similarly aligned to ensure we can execute successfully at each stage. Every outsourcing company will decide where they need to focus but for us this means:

• Using the .NET framework as our core techology base. This allows us to apply common skills across a variety of devices and applications and to tap into a much larger commercial resource pool for staffing. It also keeps costs low because we can focus on building best practices and development patterns while leveraging a large pool of libraries that are available for .Net.
• Building on a SaaS application server – SaaSGrid – that lowers the total cost of development and provides the common SaaS monitoring and operational needs. Sticking to one “best of breed” application server that we understand the internals of lowers risk and “discovery” associated with learning new development patterns and allows us to focus on the problem of delivering business value to end users.
• Leveraging Agile and Lean methodologies internally to allow us to deliver useable software early with feedback from customers and operate with high efficiency.
• Use a Nearshore model to put us in closer contact with our customer base and to better enable the promise of collaborative software development embodied in Agile.
• A production model that can apply consistent approaches and learning across engagements rather than approaching each project as a “one-time shot.”
• And finally – a business model that not coincidentally has a lot in parallel with the concepts we expect our customers to embrace.

That is just the choices we’ve made.  Making these choices is a lot like we ask our customers to do when picking a feature set. We purposely left “opportunistic” approaches off the table that would mean we had to spread ourselves a lot thinner to support them at the same level as our core. It also means we can concentrate on improving our core value set without compromising the services we deliver.  We concentrate on our core – developing successful SaaS products repeatably, economically, and quickly – and let our customers do the same for their clients.

So what is your roadmap? Does it align with the ideas we and others have offered in recent articles on developing Internet-based products? It’s all about using the delivery technology that underlies SaaS products to your best advantage in the end.  Whether you develop your product in house or with a product developer like Scio – I strongly suggest you consider your roadmap and the driving vision behind it. It can save you a great deal and lower your risk greatly.  Worth considering…