Haut Tech

I’ve noticed there are broadly two camps when it comes to developing new services for the Internet: Those entrepreneurs that feel they must do everything themselves regardless of the hurdles they face and those that want to focus on their core expertise and leverage outside services where possible.

Of course, there are also those that sit on the fence and never make a clear decision either way, but since for the most part the fence-sitters haven’t and won’t develop a service anytime soon – they fall outside the scope of this discussion. And frankly – they are hard to address until they make a choice that works for them.

The DIY (Do-It-Yourself) mindset comes from a long tradition in software development. The idea of the lone visionary, working in a makeshift office in the garage late at night against all odds, is an iconic image for Silicon Valley entrepreneurs. The folks who took that route are the stuff of legends in the business – and rightfully so.

But today’s business is a lot different from the days when people like Bill Hewlett, Dave Packard, Steve Jobs and Bill Gates started. There are options, services and alternatives that can be strategically leveraged on the road to product release that didn’t exist just a few years ago. We’ve gone through many cycles of change and innovation that have both raised user expectations and created a number of issues that entrepreneurs are expected to understand and deal with at an early stage.

Since I focus on helping “as a Service” and cloud-based businesses – I also have to point out another interesting aspect of this strategic choice for entrepreneurs. If you are expecting to sell a service delivered on the Internet – are you taking your own medicine? Are you considering services you can leverage to help you deliver your service more efficiently, faster and with more options than you might otherwise be able to offer with a reasonable compromise between cost and effort? If you’re not – are you in a good position to advocate someone else should make a different decision when they look at your new service? It’s an interesting thought…

To add one more log to the fire – the first rule of Bessemer Venture Partners Top 10 Laws of Cloud Computing and SaaS is:

BESSEMER CLOUD COMPUTING LAW #1: Less is more!

Leverage the cloud everywhere you practically can, both for your internal systems as well as for your own product offering(s) and “just say no” to on-premises deployments! This will not only give you a direct understanding of the customer experience and best-of-breed strategies of Cloud Businesses, but it will free up your technical resources and balance sheet to focus on your core product and customers.

There is another side of the discussion too – There is a large segment of the SaaS market that is made up of service-based businesses that use custom applications to manage and extend their services to their clients. These companies often don’t see the applications they use as more than an aspect of their service. They do not see themselves as software developers but they do develop, integrate and leverage application-based services for their service offerings. In today’s environment, many of these companies are extending their services to the Internet in one way or another.

What are some of the options available as services to developers of “as a Service” products today?

• Infrastructure Virtualization – Whether you call them “cloud services” or Infrastructure as a Service (IaaS) or virtualization, there is a broad set of services available to eliminate the need to own, provision, maintain and scale the servers, CPU, memory, storage, networks, databases and operating systems required to offer a service on the internet. In the best case, these services are use-based and can scale up and down with demand. They can eliminate or lower the costs of buying and deploying infrastructure and the resources necessary to operate and maintain it. On the resource side, this may be a expensive skill set not present in the existing vendor team that could be less burdensome if many of the tasks are automated. That said, IaaS is an often abused term in my opinion. Just as everything on the Internet is being identified as a “cloud service” – infrastructure services come in many shapes and flavors and some deliver more promises than value. Knowing what is possible, what you are actually getting and what you need is key when you begin to engage with cloud providers.
• Operational Services – This is another broad class that covers what we often call the “plumbing” of an on-demand service. It includes areas like billing and settlement, pricing, client administration, reporting, integration, user community management, sales automation, product management, and content management. If developed from scratch, the combined effort to put these services into a product can easily reach 60% of the cost of a project. In fact, because of the cost and expertise required, these services often end up being very constrained or left to manual processes which greatly impede growth and reliability of the product.
• Platform Services – If IaaS is an often abused term, Platform as a Service (PaaS) is rarely ever described in terms that actually speak to their business value for as a Service companies. 90% of what is offered today as PaaS is either a development environment or a BPM (business process management or workflow) system. I don’t want to disparage the value of those two approaches to a software development effort – but - they need to be separated from the PaaS offerings that also address the operational needs of a service-based business as described above. A PaaS that addresses operational needs does several things for a new service – it lowers the effort and cost required for development and it lowers the time to market and risk associated with larger, more complex development efforts. In addition, most PaaS offerings include levels of infrastructure virtualization that lower the need to deploy and manage the servers and their associated hardware, software and networks.
• Resources – While outsourced development is a very obvious option for building the application (Scio is after all, a software development provider) , there are many types of resources available for specific tasks such as planning, marketing, sales, and support. It is critical that the selected service provider understands the issues that “as a service” businesses face, but when they do they can greatly reduce risk, false starts and strategic errors. In considering outsourced resources it is important to remember there will always be a “cheaper” resource somewhere. The provider you select needs to deliver value for cost and in SaaS and cloud-based businesses that comes from knowledge and practical field experience.

So, let’s say you’re one of the entrepreneurs that are either considering or actively leveraging services as a part of your product strategy. What do you need to understand to be successful at picking or using services?

1. Pick for Value, Not Cost – Value can be measured many ways but the key in services is not the cost, it is value delivered. In most cases this should be realized in lowered or offset development effort, risk, complexity, time to market, or increased expertise (or all of the above). Depending on the type of service, the offset could be in the form of on-going overhead – as it would be if you use a billing service for instance. In the best case, all overhead for service-based businesses should be tied to use. This means the overhead cost per period can be divided by the number clients or users so it can be understood and budgeted as an operational cost. In this scenario, the cost should also fall if the basis (users or amount of bandwidth or whatever the metric is) also goes down. A service cost that only rises in stair steps can quickly become a serious liability if there is a lot of subscription churn or usage variability in your product.
2. Build for Flexibility - Just as the features you offer in your product today will invariably need to change over time, so too will your service strategy. When you have reached a point in your growth curve that it makes sense to recapture the overhead devoted to a service, you may decide to build that function into your application directly. If you have built on a flexible architecture, this should be a choice that is available to you whenever you decide the time is right. This same line of thought addresses changes in service providers. Just as you might decide to change your bank to capture a better interest rate or more services, you should also be able to change your service provider if competition puts a better choice in front of you or your existing provider goes under. This is a risk in every aspect of business and part of the trade-offs you have to consider. Not planning for risks is wrong but expecting you have eliminated all risks by taking on the responsibility yourself is equally shortsighted. Properly balanced service usage and risk planning is a serious competitive advantage in the long run.
3. Pick Your Battles - Understanding service value means really knowing what your business needs. You will not have every use case for pricing in place the day you roll out your service. Building a pricing engine at that point means you may have to completely redesign your system while doing manual workarounds when it is realized you need a different pricing strategy. In this case, a feature-rich service could provide a window into many approaches you hadn’t considered. On the other hand, if your service requires a great deal of analytics, a library of analytic routines may be of value to lower development overhead, but if you do not completely understand how the library works and the results are obtained, it could be providing unreliable results. Just as in selecting features, you need to understand what your service needs to be effective and pick your battles carefully. Don’t build what you don’t have to but don’t accept black boxes that you don’t understand. Do proof of concept runs and don’t accept marketing at face value. What works for another provider may be entirely different in your context.
4. Focus on Delivering Your Expertise and Satisfying Your Customers – Really this is just part of picking your battles, but it is a core strategy just the same. The point of an effective services strategy is that it must free your team to focus on the value you provide to your customers . If managing a service is more work than doing it yourself, there is something wrong. Effective services clear out operational hurdles, provide market-led options, and grow with you. This also means understanding your core expertise and not extending yourself into areas where you don’t need to go to be successful. Service-based business is quite different than providing licensed software. Leverage service providers who have the field expertise you need while you continue to define and deliver the value your customers are paying for. Would you want your airline pilot to also be the maintenance team that keeps a modern passenger jet operational? It might sound good on the surface, but in reality, there is enough in each field that it just isn’t practical or safe. Focus on what you need to do to keep your customers and let qualified resources keep the engines running.

I would be remiss if I didn’t also say that we help our clients pick services everyday. There is no one size fits all and every choice has a trade-off. We spend a fair amount of time dissecting services and trying to understand the technical and business cases for their use. I can’t recommend a set of services that will work in every situation – but I hope these “pointers” will give you an idea of what is involved in the choices you have.

What have you found? What situations have you faced? Join the conversation and let me know.

Addendum -

I’m going to the Cloud Futures conference in San Jose, December 7-8, 2009. If you’re going to be there let me know on Twitter or by leaving me a comment here. I’d love to get a chance to meet with some of the community there and heaven knows, none of us have gotten out to many conferences in the last couple of years.

Follow Me on Twitter