What is the difference between Simple ASP and True SaaS?

What is an ASP?

asp-200pxWhat an ASP does for you can vary widely:

  • They can simply providing hosting services
  • They can build and host an application on your behalf
  • They can build, host and manage an application on your behalf (what management includes can also widely vary)

It is really important to check what you are getting when you purchase ASP services. If not, you will have to perform many services yourself. At a minimum, this will be costly. In the worst case, this may leave you in an impossible-to-manage situation (especially if you are not at IT company).

What is a SaaS provider?

Of course, SaaS means “software a service,” What does this really mean? It means the provider enables you to acquire, setup and manage your software as a something you simply pay for like a utility. As a result, you do not have to allocate any more resources to manage your software than you do for other high-feature utilities, such as conference services or your benefits program. This is incredibly useful (especially if you are not a technology company) as it lets you focus on your core business (instead of managing software)

So what is the difference between SaaS and ASP?

SaaS and ASP are not mutually exclusive from each other. SaaS-based solutions are those that fall into the upper-range of the continuum of ASP-based services:


Service Continuum: From Hosting Only to Full Software-as-a-Service

Everything is included in a true SaaS model:

  • Building (or Configuring) and installing your application
  • Hosting it in a secure, high-availability environment
  • Proactively managing it in terms of monitoring, performance tuning, conducting preventative maintenance and adding or removing capacity as needed
  • Performing updates as they become available (anyone who has ever managed an upgrade of their enterprise application or infrastructure can appreciate how valuable this is)

How do I know if I am getting SaaS or ASP?

Here is a basic “truth table” that will let you roughly gauge what you will get from your provider and what you will need to perform (on contract on your own)

A. Do I need a hosting provider?

Will the Provider host the purchased software for you? If not, you are dealing with an on-premises solution. See my last post for the costs associated with this type of solution. It may seem obvious to ask this, but I encounter situations every few months in which an associate of mine has been told by a vendor they are getting an ASP or “ASP-like” solutions — they only need to hire the hosting provider recommended by the vendor (at extra charge, of course)

B. Do I need an implementation vendor?

If the answer to any of the questions is “No” (actually if the answer is anything but a clear, unequivocal “Yes”), you will need to hire an Implementation Vendor. In many cases, the vendor will be certified by the application provider (to ensure a minimum level of consistency and quality). In all cases, this will require extra money (usually on a time-and-materials basis, usually under the nomenclature of “Professional Services”:

  • Will you capture all of my configuration needs from my business and technology stakeholders?
  • Will you configure and integrate the software to implement these?
  • Will you test these configurations and certify their correctness?
  • Will you project manage this whole process for me?

C. Do I need a systems administrator or systems admin services?

If the answer to any of the questions is “No,” you will need to acquire systems administration resources. Again, these can be additional services provided by a “partner” of the ASP vendor. They are often lumped into: Professional Services, Setup Services, or Systems Integration

  • Will you analyze my proposed transaction volume and determine my hardware needs?
  • Will you configure these servers (application and database) with the correct operating system, applications, and patches?
  • Will you install the software for me?
  • Will you verify correct operation of the software?

D. Do I need support services?

If the answer to any of the questions is “No,” you will need to acquire systems administration resources. Again, these can be additional services provided by a “partner” of the ASP vendor. They are often lumped into: Maintenance Services or Level 2 Support

  • Will you monitor the software’s operation to address problems that emerge pro-actively?
  • Will you monitor load to determine when you need to change the hardware footprint (up or down)?
  • Will you add or remove capacity in response to load changes?
  • Will you provide upgrades (on your own) as they become available (without requiring time and attention from me)?

E. Do I need help desk services?

If the answer to any of the questions is “No,” you will need to aquire a Help Desk or Customer Support service. Again, these can be additional services provided by a “partner” of the ASP vendor. They are often lumped into: Customer Support, Training, Level 1 Support or Help Desk services

  • Will you train my primary users?
  • Will you setup a help desk that they can contact to report issues, problems or questions?
  • If so, when will be open and how many ways can I contact them?
  • Will you provide a knowledge base to help my users based on my configuration?

Why SaaS is different?

When you have a full SaaS solution, you get “Yes” answers to all of the above. This makes it much easier to focus on your business (instead of building, setting up and (perpetually) managing an lower-tier ASP solution.

What it takes to successfully implement COTS enterprise apps

That dreaded failure number and its root cause

As soon as you start planning for an enterprise program you will almost immediately begin to hear some variation of the following quote:

“You know, X% of [enterprise vendor name’s] implementations fail or are canceled before they ever make it to production.” (Where X% is usually around 50% or 60%.)

I will leave communication of the exact number to groups like Gartner. Nevertheless, many enterprise programs fail. Nearly all exceed their recommended budget and time allowances, even for their scoped-down first phases (I will get into scope control in a whole other series of posts). The single most important reason for this I have seen is the following:

Program sponsors (and their program teams) forget to include much of the work required to implement a successful off the shelf product

As a result, they need to come back to Capital Review Teams or their CFO to ask for extra money to complete their programs. In good times, they get this money (but reduce or eliminate their IRR), in bad times they can see their programs severely cut back, delayed or killed outright. Most companies are not in good times right now.

Buying off the shelf and integrating does not eliminate as many costs as you might think

My last post outlined everything you have to do to built applications in-house. Buying off the shelf and integrating eliminates many of these (in lieu of licensing and integration costs). However, it leaves many tasks that are often underestimated in the traditional “build vs. buy” analysis. It is easiest to highlight these by directly comparing the tasks for each:

Activities by project discipline area (i.e., not a Waterfall plan)

Key: Struck-out = Eliminated by purchasing and integrating an enterprise application. Red = added to successfully integrate the enterprise application. Italics = Clarifying note

  • Scoping (About half the time vs. building it yourself)
    • Negotiating contracts for acquisition
    • Negotiating contracts and Statements of Work for integration
    • Defining Concept of Operations or Vision Document outlining how the application will work at a high-level
    • Negotiating scope and phasing of capabilities over time
    • Estimating cost and time for this
  • Requirements Management (About one third of the time vs. building it yourself)
    • Capturing Use Cases, translating these into technical feature configuration and integration requirements
    • Determining non-functional requirements – performance, reliability, scalability, availability
    • Negotiating sign-off and prioritization by phase
  • Design (About one quarter of the time vs. building it yourself)
    • Designing an top-level architecture
    • Designing the logical data model. Specifying the configurable meta data for the application.
    • Designing the object model.
    • Designing the software architecture (what is internal vs. external, what is the software vs. the database, etc.)
    • Designing interfaces with external systems
    • Designing the User Interface – a huge one from determining style conventions, wireframes, mockups, usability analysis, Section 508 compliance and lots more. Specifying configuration settings for the User Interface (much easier than designing “frem scratch”)
    • Specifying the business and workflow rules to configure in the system
    • Designing the systems architecture – how you will handle maintenance, scaling on-the-fly, backup and recovery, disaster recovery, elimination of SPOFs (Single Points of Failure) – this task is so large that I built a whole portion of my career doing this for utility-class systems (always-on systems with reliabilities exceeding 99.999% and scales exceeding 10,000 transactions per second)
  • Infrastructure Management (Often LONGER than building it yourself as your infrastructure team will have to learn how the application is architected)
    • Capacity planning – how much hardware to you need, where should it be, when do you need it
    • Hardware acquisition – Selecting and ordering your hardware
    • Systems Integration – Installing the operating systems, patches, and base middleware. Integrating hardware into your network (configuring IP settings, adding to your routers and switches, much more)
    • Setting up your monitoring and production support teams and systems
    • Doing this for EVERY environment – development, integration, certification and production (your environments will multiple post-launch as you will have systems under development AND in production)
  • Construction (About one-third of the time vs. building it yourself)
    • Setting up the code repository
    • Setting up your continuous build process
    • Defining your interfaces and configuration management files. Defining exactly how existing systems will integrate with the new system
    • Building your databases
    • Building your database scripts and stored procedures
    • Building software modules
    • Building hooks for monitoring and business intelligence
    • Defining and executing your unit test cases around configured metadata, business rules and work-flows
    • Integrating and verifying the integration of your software modules with your databases and external interfaces the application with the rest of your environment.
  • Certification
    • Tracing your configuration requirements (functional and non-functional) to Test Cases
    • Building Configuring your Test Harnesses
    • Conducting verification testing, sending configuration builds back for repair, integration and certification/regression testing
    • Optional – usually done for highly-integrated mission-critical applications only: Conducting load and performance testing, including analyzing and repairing performance and scale bottlenecks
  • Training & Support
    • Developing training documentation and curriculum (for end users)
    • Setting up your Help Desk – including your knowledge base of how-to resolve expected questions
    • Setting up a Center of Excellence to manage the application after implementation (you will need to build or rent as your internal staff will not have the expertise to do this)
    • Training end users
  • Project Management
    • Developing the plan (tasks, durations, assignments, critical path, etc.) to do all this
    • Managing and resolving all those issues that come up with something this complicated
    • Estailishing governance for decision-making and issue resolution – requiring lots of time from your executives
  • General Management
    • Getting approval for the money to do this – Capital and Expense (often requiring you to in front of your Board of Capital Review Committee)
    • Managing the RFI, RFP and contact negotiation process for your Integration Vendor
    • Getting (or reallocating) the staff to do all of this – usually this is now external staff such as Integration Vendors (pro: you do not divert as many of your staff, con: they are more expensive than internals)
    • Managing the staff for requirements, design, development, integraiton, testing and installation (acquiring resources, approving vacation, backfilling departures, etc.)
    • Managing the capital and expense expenditures, including all the invoices for purchases and services and weekly or monthly reporting to your Finance organization
    • Handing all those items like staff departures (people quitting, not performing, getting sick, etc.) – This is reduced as you have “outsourced” a good fraction of it to your implementation vendor

This is still a lot of work — and a lot of time you could instead focus on the core of your business. Some will be done by internal staff. Much will require you to hire an external integrator (as your internal staff will not have the expertise to do this). The good news is that this frees up more internal staff than building it yourself. The bad news is that external implementation staff often cost 1.5x to 2.5x as much as your internal staff (making schedule overruns very costly). The cost of these overruns increases exponentially based on your degree of under estimate – this is known as Parkinson’s Law. Using a SaaS model avoids many of these costs.

5 points where tech balances between life and work