Last week I had the great opportunity to present at and participate in a panel discussion at FISPA’s Atlanta 2014 conference.  The panel and presentations were focused on the lessons that the presenters and panelists had learned from providing hosted solutions and services to their customers.  This topic suited DataYard very well, as we have been providing hosted services since 1995.  The presentation time was brief, less than five minutes, to allow for questions from the moderator and crowd.  Given the small presentation window, I thought I would elaborate further on some of the points I briefly touched on.

Lesson #1

When I was preparing for this presentation and the corresponding panel discussion, a quote crept into my mind,

“The man who promises everything is sure to fulfill nothing, and everyone who promises too much is in danger of using evil means in order to carry out his promises, and is already on the road to perdition.” – Carl Jung

This quote, albeit a bit theatric, catches your attention and makes you start thinking about the first lesson, Focus…

Hosted services, like e-mail, web hosting, etc., are primarily software driven services.  The installation and configuration of them is something many IT professionals can do quite easily and here is where the danger lies.  After, or even during, the initial deployment of a service it is easy to lose focus on the core service it is intended to provide.  Unlike a physical product, features and core functionality can easily be changed with modifications to software configuration.  This can easily lead to a mutation of a hosted service that was originally intended to provide one thing but now does something very different.

A hosted service must be flexible enough to accommodate new customer needs, but must still provide it’s core functionality.  When considering modifications to a hosted service, it is imperative to consider how it adjusts the core functionality of the service.  Does the adjustment add value to the service or take the service in a different direction?  If it takes the service in a different direction, should a new service be created to provide this functionality?  Is there enough demand for this as a new service?

These are difficult questions to answer, but retaining the “Focus” of the service while answering these questions will help guide it in the proper direction. Don’t lose site of the core focus of the hosted service, when dealing with add-ons and service tweaks.

Lesson #2

Building a hosted service can be both an easy and daunting task all at once.  What type of infrastructure should be deployed for this service? Use an open-source project or a white-box solution?  How much more support will this generate?  How will growth be handled? How big should the infrastructure be? 

I have had that conversation many times and there is a two part rule that I have found works best. It does not answer all of the questions but provides a guideline to help build an excellent hosted service.  The first is Build for Quality.  When I bring this up as a guideline for building new hosted services, there are generally two response, “That sounds expensive” and “Doesn’t everyone do that”. 

The answer to the first objection is not really; quality doesn’t always mean drastically increased costs.  Consider the fact that quality will be perceived by the end user of the service.  Good quality of a hosted service may mean providing accurate details and instructions on how to use the service.  Good quality might also mean getting the exact same service every time a customer requests it.  There is the potential for increased expenses if you need to invest in new infrastructure or software, but this isn’t the only way to build for quality.

The second response, the belief that everyone builds hosted services for quality is misguided.  Due to the ease of deployment for hosted services many providers play the “Me Too!” game.  If someone else is providing a hosted service they feel the necessity to “stay competitive” by quickly rolling out the same service.  This can lead to a lower quality service or one the provider may not be equipped to support.  We all know quality products once we use them and quite frequently when they aren’t quality products we like to let everyone else know about it.

Building for quality has several advantages.  First, it allows you to be competitive on the service and not just on the price.  If the service provided is of a higher caliber you can use that to differentiate yourself from the crowd.  Second, a hosted service built for quality will hopefully have a lower support cost.  A hosted service with good documentation, that is always delivered in the same manner and is generally reliable should mean less customer requests.  This can help reduce and potentially make-up the costs you had to invest to build for quality.

The second half to this lesson is Plan for Quantity.

When building a hosted service the initial build scale should be small, but the infrastructure and service should be designed with growth in mind.  It is easy to think that a new hosted service will be the next big thing, but the cost to build infrastructure to support it at scale is probably not practical. However, if the infrastructure is designed with the intention to grow it, when it does become a big hit you can expand it easily.  Then, hopefully costs are less of an issue as revenue is being generated by the service.

Wrap Up

These are only a sub-set of lessons that I have learned from providing hosted services, but they provide some foundational guidelines I have found for success.  Of course your approach to hosted services may be very different from mine and if so I would rather enjoy hearing your lessons learned.