The relentless change brought to us by the consistent doubling of computing power that Moore’s Law describes continues and is now likely to change at least some SaaS applications in the near term.  What do I mean? Consider – we now have a very competitive mobile application market and thanks to Google Chrome and now Apple Safari, it has crossed to the desktop on browsers.

Meet the New Paradigm

The event that brought this to mind was the announcements of the release of Safari 5.o.  Leaving out the typical “improved performance” claims – two things were apparent – it is now a platform and it is designed for use in a cross-platform, mobile environment. On the platform side, Safari has joined Chrome in providing an extension system that allows developers to in effect, build secure and stable, rich clients into the browser. We’ve seen this for a while in the form of the “app stores” that are proliferating for mobile devices like smart phones and the “iPad” category (however you define it).  On the mobile, cross-platform aspect, the browser is now tuned for mobile users.  It is very noticeable if you try the new Reader function of Safari. It is quite usable on a desktop or laptop, but it really shines in the limited real estate of mobile devices. Multiple page articles merge seamlessly into one. Space wasting banners, sidebars and menus disappear. The browser becomes a credible, focused article reader for all devices.

What does this mean for SaaS? Take this evolving “browser as a platform” trend together with the announcement of iOS 4 (the artist formally known as the iPhone OS) and the growth of the Google Android and Chrome OS and you have a quickly changing landscape of operating systems tuned for a rich mobile environment and a browser-centric application implementation system. These advancements mean the expansion and adoption of HTML 5.0 is moving even faster than many of us thought. They will make the often tricky environment of JavaScript and Ajax less of an issue and the user experience of properly-tuned SaaS applications much more fluid and “desktop like.”  It means that locally-installed, OS dependent applications are becoming ever less relevant and cross-platform, network-delivered services are becoming increasingly rich and useful.

Frankly, as interesting as this news is, it also points out that SaaS is a very fluid environment. Keeping ahead of it is increasingly difficult. Knowing how to manage a SaaS product and chart a plan to navigate development is critical. Knowing what you need to support scalable SaaS operations and what you should embed in the application is critical. Understanding your user environment and what is expected in your market is critical. The list goes on and there has to be a way to understand the landscape and to make the choices easier. And the point of this article is – there is – it is SaaS University.

As a company, Scio has stayed involved with SaaS University because it answers the need our clients and the SaaS community has to have current knowledge about our industry and important issues. Because Softletter produces regional events quarterly, you can plan to attend when and where it makes sense and take advantage of the evolving content as you need to. The tracks and workshops are well attended, but generally sized so the sessions can be interactive and remain relevant. If you’ve been to the larger, vendor-led conferences – SaaS University offers content that is focused on providing valuable insight to SaaS entrepenuers.

The next SaaS University event is in Washington DC, July 20-22, 2010. There is a full two-day agenda of sessions in two tracks covering a wide range of subjects and a third day that offers a choice of four in-depth workshops. On that point in particular, I want to highlight our own workshop, Charting Your Course to SaaS.

Charting Your Course to SaaS – SaaS University, Washington DC, May 22

This is the third time we’ve offered this comprehensive workshop on SaaS and it continues to evolve as we respond to the needs of our participants. Following our joint workshop with Jim Geisman of Software Pricing Partners, we’ve continued to tighten the content and for SaaS University, will offer a more interactive format for this workshop, especially during the afternoon. The aim is to keep it small enough to allow everyone a chance to move the discussion toward the issues that interest them most.  It remains however, the only workshop that covers the business, operational and development issues that are critical to success in SaaS.

Companies that 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 strategies, metrics, 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.
• Developing a product roadmap and unsure of what can be accomplished and timeframes

Topics to be Covered:

• How is a SaaS Product and Business Different?
• Reference Framework for Creating Your Roadmap
• Making Strategic Development Choices
• Operating A SaaS Business by the Metrics
• 10 Ways to Fail at SaaS
• Applying Lessons Learned to Your Issues

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professor”

Mike Dunham, Vice President, Service Engineering for Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

The workshop costs $695, but you can get an Early Bird Price of $495 when you combine it with your SaaS University registration - total package price of $1290. As a way to bring together a great amount of information in a short period of time, the combined package is a great opportunity. As we get closer to the event, I’ll expand on the agenda, but this is a great time to start planning and get your team together to attend SaaS University in Washington, DC!  I hope to see you there…

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.

When you develop products in a repeatable, production fashion, you have to step back occasionally and take the long view so you can properly discuss the process with clients. We’ve been involved in that exercise recently and I thought it might be useful to share the what and why of our approach to software development for online products.

First, there is one basic idea that informs all of this:

We define “Big Bang” development as:

• A basically black box project where significant work is done up front to develop extensive requirements documents which detail the features and functionality in great depth for a software development project that typically lasts from 12 months to two years.
• The time expended on requirements development is expected to provide developers with a very specific vision of the product that can be put out for bid, will put a box around scope, cost and time, and will last through out the project.
• On release, the exhaustive feature list is expected to drive market adoption and leapfrog existing competitors.

This technique of specifying software product development has been used for years by companies that want to somehow reduce risk on a project they cannot do in house and often because of the technology and complexity, where they cannot provide granular oversight during the project.  But regardless of those worthy aims, these projects continue to fail because:

• Controlling scope over the life of a project becomes increasingly difficult as the project complexity and time span grows. Prediction accuracy degrades geometrically over time – yielding a project plan that can be relied on at a high level at best.
• Technology continues to respond to Moore’s Law.  The longer requirement development takes, the longer the project goes on, the less likely it is to meet the expectations of the market on delivery. User expectations, informed by other products they have tried, have moved on. In addition, the technology assumptions at the beginning of a project don’t always work out when development actually takes on the complexity of integrating them. So the choice of a tool, framework, or library may seem like it solves a lot of problems at first, but in practice may turn out to be a black hole into which resource time disappears.
• No matter how detailed requirements are – they are limited by two things: point of view (the classic story of the blind men and the elephant is the common point of reference) and actual feedback from end users of the resulting application.  No matter how carefully feedback from end users is brought together for requirements, it is only as good as their vision of the final product.  As we and others have said many times – if you asked people at the start of the 1900′s what they wanted for personal transportation – the requirements would only lead to better horses. In addition, it is rare for requirements to both anticipate user needs correctly and the complexity of delivering them in a particular way. The risk in requirements actually increases the more detailed they become – if they cannot respond to end user feedback early in the development process.

So – what is the alternative? Consider “Lean Product Development.” We have a general assumption of software product development we have formed over several projects and across several industries:

Lean Product Development (Click on the image to see it in detail)

The phases and their aims break down this way:

1. Sprint 0 – During this phase, requirements are verified, technology choices are made in detail (architecture, stack), user stories are built (we use Agile development techniques – user stories are roughly equivalent to use cases), and the user experience (more than just interface, how a user will use the product) approach is developed to set interaction standards.  The outcome of this phase is a set of technical specifications, personalities (roles to a degree), and prioritized user stories with effort estimates for each story.
2. Alpha Version – During this phase, the underlying framework is built and core functionality is developed for key end-users. The point of this phase is to verify the product vision with the key audience of the application – the end users who perform the most critical tasks and use the application most. This means the alpha version needs to be actually be tried by the core end-users.  This usually requires client partners – which in the case of a new vendor requires getting out into the market and bringing in some early adopters. The outcome is to lower risk. The cost at this point is low, compared to the whole project, so changes can still be absorbed without loss of large portions of developed code and sunk costs. Also, at this point, the approach of the development team in carrying out the vision of their client can be verified early – so that adjustments can be made and trust between the client and the development team can grow. This approach follows the sage advice articulated by Steve Blank - the point of early user validation is to get out your “dark room” and get in front your audience early so they can inform development before costly mistakes are made.
3. Beta Version – This phase produces the first cut of the market version of a product. It is important to understand that the scope of this version is intentionally limited to just what is necessary to deliver value to end users. In other words – deliver just what they will PAY FOR. This is a critical assessment that is informed by both the vision of the subject experts and the feedback from the Alpha Version. The problem is however, no matter how good the vision and feedback are, there will be additional feedback when the product hits the many different contexts of actual target end-users in the market. The release of the beta version also provides the “kick off” of internal operations for the provider – and in the case of most products – support, sales and marketing. The lessons learned from beta release then inform the next phase so that beta adopters are rewarded (and retained) and operations delivers the message and services needed to drive new customers and user adoption.  Because of the incremental nature of Agile release cycles, the actual point when sales are made during this phase varies a lot between products – but development doesn’t stop. What changes is that development is now more directly informed as new customers come on and participate in the beta. Some companies test pricing and marketing more aggressively at this point than others – but the general recommendation is to establish pricing early and test it against the perceived value from users. The outcome isn’t expected to be an adjustment to pricing directly but rather an adjustment of features or packaging to better align with perceived value.
4. Market Release – This phase marks the release of the full market product and the beginning of “normal” product enhancements to continue to grow functionality in alignment with user feedback. We sometimes add a phase for development up to market release itself that is separate from beta – but for general purposes – development has now slipped into an enhancement mode, rather than full out development unless there is a significant difference from what is planned for release to beta customers and the general market. The outcome of this phase is a product informed by target user feedback, tested business operations and a change of focus from getting the product “out the door” to getting customers and continuing to enhance features and functionality. It is not an end point – it is just the start of the natural evolution and “pull” of a “consumerized” online product.

The outcomes of this process are:

• Early release and feedback from the people who count – the users in the field.
• Early validation that both the vision and the requirements are resulting in a product that delivers value and will meet market expectations.
• Lower up front risk and lower time to profit. Waiting over a year to put a product in the market with real users is a recipe for disaster. Getting into the market, proving operational assumptions and kick starting cash flow as soon as practical is key to success.  A good reference on this Joel York’s SaaS Metrics Rule-of-Thumb #4: Company time to profit follows time to break even. You can’t prove your assumptions around operational costs and customer acquisition cost (CAC) until you get into the market. The sooner you get into the market, the more time you have to adjust to reality before your startup cash pile is burned up.
• Simple – a higher chance of success measured by what counts – adoption, cash flow from customers and retention of users.

A lot of our customers though face a little more difficult situation – they have an existing product in the field that started life as a traditional premise-based product and is now being pulled to adopt a more dynamic online model. That brings an additional set of issues:

• If the development cycle is long, existing clients may jump ship before the full online version is available.
• Support and maintenance of the existing product can overwhelm the key members of the product team that need to be available to shape the new product.  Finding a point when transition can begin in an orderly fashion, without cannibalizing existing sales is critical.
• The new direction provides an opportunity to develop new markets, adopt new pricing levels and transition to a pull-driven feature model (rather than the push of traditional product releases) but timing is key. For a complex product meeting the needs of the top of a vertical market this becomes a huge exercise and is frankly very difficult to break down into manageable pieces.

To deal with that we have a general model that takes the new product template above and turns it into a phased development of a suite of products. In the diagram below – you can think of each of the blue boxes as a modified run of the our typical product develop cycle:

Progressive development for a suite of online software products (Click on image for more detail)

The major steps in this are:

• Sprint 0 – A holistic project-level requirements, technical specifications and feature breakdown that sets the stage for the entire project – but doesn’t lock assumptions down. The point of this entire project is as before, get products out early, get feedback and cash flow as soon as practical. This also includes a more detailed look at the first product in the suite.
• Web Enhancements – This part of the first product release is optional but worth considering as a way to ensure existing customers stay onboard for the long run and can see the long vision early – so they will become key in feedback as the product progresses through the lifecycle. What form this product takes varies, but the idea is to enhance the existing product with features that suit the Internet environment particularly well and extend it in ways not possible before because of technology or restrictions inherent in the on-premise version.
• Broad Market Version – To allow early feedback and to get into the market as soon as possible, the first product  needs to be a focused subset of the expertise expressed in the legacy product that addressed the top of the market previously. Generally, this means providing a set of features that will provide value for the 2nd and perhaps 3rd tier of the market. Again, all the points of a typical product release as we first described need to happen in this release so the product is informed by actual end-users in the target market – which coincidentally is a new market for the vendor.
• Professional Version – Building on the same code base as the Broad Market Version, the professional version targets the features which will satisfy 80% of their installed base. This sets the stage for migration and broadens potential adoption by a group of customers who will pay significantly more for the value the product delivers. This also marks the point where legacy support and maintenance can begin to turn the corner and clearly move toward the new product.
• Enterprise Version – Again, on the same code base, enterprise functionality is added and now the entire “product suite” has reached levels of functionality never achieved in the legacy version. Users pick levels by feature packages within the suite – so if properly architected – there is a lot of variation in pricing and packaging possible to meet needs in different markets.

It should be said that the timeframes proposed here are generalizations and will vary, but – they are based on the assumption that development should focus on delivering features with value to end users. Everywhere else, the simple rule “less is more” should be followed with the leverage of services and frameworks where ever practical. The architecture needs to allow those services to be used as long as necessary, but to be replaced as growth provides the option to drive down the cost of service.  It should also be said that features and customization in this approach come from choices of what is made available to roles in market packages and configuration – not separate versions.

Now, I’ll admit this is a big vision and a lot to absorb in any context – either as a startup or a software company with legacy products in the market.  And – it is a big shift in how we have looked at software product development. It comes from our own experience of the issues we find repeatedly in the market. I can’t say it is an approach that every development group can provide successfully. It depends on making clear choices that will provide these outcomes and not waffling with half measures.

What do you think? Can you see your company going down this road? Can you see the benefits? Let me know…

]]> http://blog.sciodev.com/2010/02/24/lean-software-product-development-in-4-phases/feed/ 0 http://blog.sciodev.com/2010/01/05/6-points-for-successful-saas/ http://blog.sciodev.com/2010/01/05/6-points-for-successful-saas/#comments Tue, 05 Jan 2010 23:13:31 +0000 Michael Dunham http://blog.sciodev.com/?p=742

When I wrote the recent article “SaaS: 10 Trends for 2010” I used the phrase “Best Case SaaS.” I realized from feedback and some thinking afterward though that many people don’t share my vision of what it is.

What I was trying to say is there really is a path to success for SaaS products through the thicket of options out there.  But since we don’t all share an understanding of all the options – that becomes pretty nebulous.  We’ve written about the 10 Ways to Fail at SaaS – What about Success?

Whether you call it “best practices,” “optimum implementation,” or best case – to have a discussion of what it takes to field a successful product we need to have a common understanding of SaaS itself. One of the people who has been pretty clear about a vision has been Phil Wainewright – but there are several others who are advocating for various aspects. My concern is a lot of them tend to be involved in the technical side of SaaS and not a straight- forward business discussion.  Of course, it takes an understanding of technology to bring a SaaS product to market, but in truth, you can hire that expertise if you have a clear business strategy to back it up.

Before I list the six points I have outlined – let’s get our definition clear.  Software-as-a-Service (SaaS) is not as simple as, “A application delivered over the Internet on a subscription basis.” That definition is what most people think, but in truth it is far to limiting by itself. If you want to keep it simple, you could just say, “an online service” but that might be a little broad. To cover both sides of the fence, vendor and user, I’ve been using, “an application delivered across a network to a client in a pay for service model.” On reflection – even that definition has its faults.

The point of this little exercise in definitions is that we need to realize that what we once called “Business-to-Business (B2B or B-to-B)” or even the slightly more exotic sounding “B2B2C” would be called SaaS today.  Does that mean Priceline is a SaaS product? Well – Yes! The simple end-user travel services they offer are monetized on a transaction basis, but we should also understand that behind that stands an even more important service disposing of excess inventory for the hospitality and travel industry. Somewhere in the middle is an advertising platform that allows the “inventory customers” sell through Priceline directly. Does Priceline care which service you use? Not really, they make money from all sides of the transaction and with any service you select. It truly is a Long Tail offering in every way.  The same could be said of the Amazon platform only more so.

So – really we could just say SaaS is “an online service” or “service automation delivered in a pay for service model” and be accurate? When we do that we begin to realize there is a whole field of service companies that use applications to automate and deliver aspects of their services – but aren’t usually considered as “SaaS companies.”

With that in mind, let’s go forward and look at “Best Case, Successful SaaS.” The points build on each other – so follow along through them and it will make more sense.

6 Points for Successful SaaS

1. Expertise that can be sold to a reasonably large market segment in an online delivery model and can be scaled to meet the market potential over time.

This is of course the “reason for being” for SaaS.  Online services are sold on a “pay as you go model.” No matter how you look at it, if you don’t have a target market large enough to give you a positive return on investment in a reasonable period of time, you aren’t going to be successful in a SaaS business model. In a vertical, this means offering a service that is attractive to at least second and third tier markets. It could also mean “tagging along” with more general offerings that give your service more weight in an “ecosystem” model. Regardless, you cannot ignore the simple economics of online services. You cannot afford to run out of cash before you reach a positive cash flow. That means development has to be planned and controlled to yield just enough of a service to sell successfully as soon as possible. It means that you must have a understanding of SaaS Metrics and the critical Customer Lifetime Value Ratio (CLV). It means you need to have a “proof of market” investigation as a part of product planning and (for heaven’s sake!) development. It means you have to understand (and monetize) the value your end-users perceive. It means your online service must be planned to evolve after release (see point #2).

Now the second part of our first point is what brings up the application model of SaaS. To scale a service economically, it has to be automated. When you get right down to it – SaaS is service automation! We’ve been doing that for years – the most significant difference is that now the Internet offers a delivery vehicle that is pervasive and universally accepted. So – if you’re really going to deliver a service online, plan to automate your own business operations from day one or you won’t scale with enough efficiency to reach positive cash flow in time. You might be able to onboard your first 100 customers manually – but if your market plan says you need to take on 1,000 customers with 20 seats each in your first year – your operational costs will quickly eat your cash reserves – IF you are able to handle the work that involves. (See point #5).

2. A strategic roadmap that allows the product to be brought to market early in the design cycle and to adapt to user and market feedback.

Taking the first point to heart means really understanding you can’t do everything and you shouldn’t if you want to be successful. You need to have a plan, a roadmap. You need to provide a valuable service from day one the market will pay for, but you also need to have a strategic plan for where your service is going over time.  Within that plan, you need to be flexible (see point #3) and responsive to user feedback (see point #4) and market forces.

Bringing the product to market early also means not taking on development of features that don’t support the direct value to end-users. As mentioned in point #1 – you need to automate your service – but do you really need to build all your operational automation (see point #5) to bring a product to market? No. There are many operational services you can leverage to lower your development complexity (risk), time to market and total development cost.  The general rule of thumb is you will save as much as 60% of your development effort and about 40% of your total costs before launch. The services you use become part of your overhead and need to be part of your metrics. Can you develop them into your service at a later date when the cost is justified by growth? If you take point #3 into account – yes.

3. An extensible, service-oriented technical architecture that will support the expected growth and change over the long term, economically.

Before anyone calls me on it – the last word in this point covers a lot of sins that have been visited on the SaaS business model. Let’s be straight-forward. We’re interested in SaaS because we want to MAKE MONEY. If we want to do that we have to be able to operate, deliver and maintain our application economically and reliably over the long run. That means we need a multi-tenant database structure. I don’t know any other way to say it. You cannot scale on individual instances for each customer or maintain them over time and make money.

It doesn’t mean however we have one big spinning top that runs everything forever.  As your service grows, you will use several strategies to extend your application over multiple instances, and to balance your service among several applications perhaps. Do you have the idea that Amazon is one big application? Of course not. Your service might present one “interface” for users – but that doesn’t mean it is just one application. Architecturally, that is just the “presentation layer.” We have to have an understanding of the technical strategies that allow online services to scale, embed other services, extend our services outside the application, and change our service without extensive rewrites over time while continuing to make a profit.

With that understanding, we can plan our roadmap to help us decide the battles we need to take on and when. Do we need to buy infrastructure if we can rent it? Not if the market price, availability and reliability meets our needs. Do we need to build a pricing and settlement system to monetize our service? Not if there is one available at a price that can be incrementally applied as we scale and with the level of maturity we need.  Can we eliminate some maintenance concerns with virtualization? Yes – when it makes business sense – if we have a properly architected application that is built for the online environment.

What about “lock in?” they ask. There are two things to consider: #1 – Can you afford to spend thousands of extra dollars over some extended period of time before you put your service in the water, take on customers and begin making money?  For most of us the answer is no.  #2 – If your application is properly architected and you have developed a roadmap with proper risk avoidance, the services and platforms you use are tools you use to reach your maket sooner and with less up-front investment. Do you want to buy that store on the mall or rent it? If you rent – can buy or build when you have a proven market? In most cases – yes.

All this implies you or your team has technical background in online services. But if you are a entrepreneur or service company without a strong technical team – can you still survive in the SaaS world? Yes. There are companies with services that will fill that void – (shameless plug for the people who bring you this blog) Hello….

4. Customer and user collaboration tools embedded in the service and the business operations that surround it.

If you absorbed the last three points – you should have gotten one thing clearly: Release 1.0 day is not the end of the development cycle for online services. Because of Google, SalesForce, Amazon, and service portals like FedEx operates, we all expect, even require, online services to evolve. It should be no surprise that online services need to evolve dynamically to meet customer needs and stay ahead of the market. The question is how?

Just like nearly everything else in online services, the answer comes with some level of automation. Inside the application, monitoring must be embedded to help evaluate feature use in a user context. We need to know if user admins are able to use the tools they have effectively. We need to know what percent of their day our line of business users spend in the application and how often they use it to complete “high value tasks.” With that information as a baseline, we can evaluate the impact of new features, improved help, better support strategies. Without it – we’re clueless and we might as well be selling licensed software to silos behind firewalls.

To leverage our delivery platform even more we need to embed direct user engagement with blogs, forums and community tools like UserVoice and Get Satisfaction.  These are services you subscribe to (point #3) not build. These are not the endpoint for user engagement however, they are just the tools. As tools, they are used by product management, support, sales and marketing to help guide service development, to retain customers, up sell and grow best practice communities.  What you should be beginning to realize is this really means a successful online service needs to rethink the timeworn model of “key stakeholder engagement” and get directly to the end user. To do that the business organization behind the service needs to be aligned to leverage the tools and integrate what they yield into decisions. (Enter points #5 & 6).

5. Integrated business operations for the service itself embedded in the same delivery model used to deliver to end-users.

Once again – SaaS products are classic service automation. If you are going to sell a service – if you are going to build an application to deliver your services – shouldn’t you also automate the pricing, settlement, onboarding, user management and all the other operational aspects of your business directly in the application itself?

This is a point that seems to have eluded many service companies and ISVs with licensed products. You cannot scale to reach profit in online services with manual or loosely connected internal business processes. SaaS is all about making a profit from volume.  But, as point #2 cautions, you cannot build all the operational aspects of your service directly into the application without placing considerable risk on your costs, application complexity and time to market. If you have planned your product with the architecture discussed in point #3, you can leverage available services that will provide these critical aspects of business operations for you and embed them in the product platform itself. This gives you the best of both worlds – fully integrated business operations using the data and infrastructure you already have online and a cost that is applied incrementally based on use.

6. Agile business philosophy embodied in every aspect of product development, operations and services.

You nearly have it – successful SaaS is all about service automation and dynamic business. It delivers what we need, when we need it, at a cost that is measured by use on every side of the platform. That means you and your customer alike are benefiting from the investment in the application and involved in its continued success intimately.

To handle the continued development and change involved in SaaS, most technical teams use Agile methodologies. To feed development and manage the product roadmap then, we also need to consider an organizational alignment with agile philosophy. When we really consider the organizational impact of being an online service, we start to understand there is really no option. To be successful at SaaS, we need to be an agile business top to botttom.

This is a lot to absorb. It is a different way of doing business. I don’t want to underplay the significance of any one of these six points. We at Scio made a strategic decision last month – we’re alining our services to deliver best case SaaS to our product customers and nothing else.  To help people put this into their own context, we’re giving a workshop on January 28th in Dallas as part of SaaS University. I strongly encourage you to join us if you have any interest in developing an online service in the coming year.

So – what is your take? Did this list suprise you? I hope not – but I’d love to hear your point of view.

At Scio, we use Innovation Games with our clients in several contexts, from new product definition to ongoing product management. For a new product design, the games help us work with our client team to uncover customer requirements that are still loosely defined, as well as to help our development team understand the key selling points of a product. For ongoing product management, the games help us work with client product managers to come up with new ideas, develop and prioritize their product roadmap and identify issues hampering their success.

Innovation Games are a series of serious games developed by Enthiosys, an Agile Product Management consultancy based in the Silicon Valley. Enthiosys developed these games to drive innovation by facilitating communication between clients, users and the development team in a structured but fun approach. By using a “game” approach, the activities remove personal agendas and psychological barriers that frequently exist when trying to reach alignment between stakeholders. Luke Hohmann, CEO of Enthiosys, has written a book about the games and methods behind them – Innovation Games: Creating Breakthrough Products Through Collaborative Play.

We recently started a project with a new client from the UK to develop a SaaS application for them using SaaSGrid (SaaSGrid is a SaaS Application Server developed by Apprenda). As part of the project kick-off and Product Design phase, three members of the client team spent a week at our Development Center in Mexico including the their product owner, the project manager and a development manager.

The visit was part of Sprint 0 (product definition and design), which is the first phase of our Agile Development process. The visit had five key objectives:

• Finalize the high-level product requirements.
• Define the technical architecture.
• Define the UI approach and look & feel
• Finalize the project execution plan.
• Get the development team underway with the certainty that they had an accurate understanding of the project goals, the product key features and the overall vision and expectations of our client.

During this visit we used Innovation Games to reach some of the objectives we had in mind. We used four games:

1. Product Box – day 1, morning
2. Start your Day – day 1, afternoon
3. 20/20 Vision – day 3, afternoon
4. Remember the Future – day 4, morning

Our client provided their application requirements as part of their development partner selection process and those were used to estimate project scope and provide our price quote. It was understood at the beginning that the requirements were not 100% complete and some ideas about new requirements or the approach to implementing some elements had changed since the  document was written.

We began our games with Product Box. Our aim was to quickly surface the key features (and key selling points) of the product. After reviewing what came out of that game, we discussed in more detail the full set of application requirements, the company goals, and the overall project expectations.  We then followed with a session of Start Your Day. In preparation for this game, we had printed daily, weekly and yearly calendars on full poster-size paper. We played the game for all Personas, and with this activity we wanted to identify patterns of use for each persona.

On the third day, after we worked on defining user stories in greater detail and across all modules, we played 20/20 Vision. We printed all the features (each feature contained one or more user stories) on letter-size paper, and with masking tape, we started to place them on the wall. The client team went through an iterative process of placing features on the wall and moving them up and down, where the features at the top were deemed to provide more value to end users, and the ones at the bottom less value. This exercise helped us prioritize the product backlog. This prioritization, together with technical dependencies, is used to define the sequence of application development for the user stories.

On the final day of the visit, we worked with the client team in the Remember the Future game. The scenario we set for the game was: “The date is exactly three months after the launch of the product, what will the ideal situation look like?”. This brought up expectations about the number of paying customer they would have, the quality and performance of the application, etc. Then we asked, “what will each of our teams have done to make that happen?”. We worked backwards to bring out all the activities and milestones in marketing, development, testing, etc. that will be needed to get to that ideal situation.

Using Innovation Games was very productive for this project.

• Product Box it helped us see that some of the requirements that we thought were secondary were actually part of the key selling points of the product.
• In Start your Day we realized that some users will concentrate their usage of the system to specific hours of the day, where they will need to process data in batch modes. This suggested that we needed to design a UI optimized for sequential data capture for those users. Additionally, we discovered that we will have peaks in some batch processes, such as invoicing, at certain times during the month, as well as some reporting that needs to be generated once a year for tax return purposes.
• 20/20 Vision was useful to prioritize features using end-user value, rather than how cool a feature would be or how attached a member of the client team was to a piece of functionality.
• Remember the Future helped us see the dependencies between the work that each of us (Scio and Client) has to do to make the project successful, as well as establish a timeline that we will need to adhere to.

When as part of the agenda for the visit, we mentioned that we were going to use “Innovation Games,” our client was of course, curious about the idea. It is easy to imagine a “game” but not necessarily the business value behind it. We explained that the games are strong facilitation techniques that would be fun and productive, so they engaged with enthusiasm and played along happily. The results were great, and at the end of the week we all agreed that we accomplished a lot.

Although it is possible to obtain similar results using other facilitation approaches, using Innovation Games is a more engaging and fun approach to exposing all the different aspects of a product that surface during the games, which would otherwise be missed or discovered too late.

So let’s keep on playing – Serious games that is.

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.

The question I pose in the title of this article is the theme of the podcast we did this month for Haut Tech Conversations. It turned out to be quite a conversation and you can download it and listen to it in its entirety here. Our panel and guest brought up so many excellent points that I’m going to take the time to summarize and extend them in this “post interview” so they are not lost.

Giving credit where it is due: Our guest was Steve Plunkett, CTO of Servitizer. He has studied the concept of delivering services over the Internet and has a depth of understanding and experience few in the field can claim. I recommend his blog as a continuing series of insightful articles on the business of delivering services in an on-demand world.

Giving more depth and points of view, our panel was stellar. Luis Aburto, CEO of Scio Consulting provided a clear summary of the intersection of technology and business concerns that make up service offerings in this field. Mikael Blaisdell of MBaisdell & Associates brought up a range of issues that are rarely if ever considered in planning and developing a service. Lincoln Murphy of Sixteen Ventures broadened the business side of the discussion many times over.

The conversation exceeded my expectations and I encourage you to listen when you can. But I felt that the key points can be easily lost because an hour seems like a long time when you just think about it – when listening to the conversation there is a lot of information coming all at once. So – this series is an attempt to summarize and extend the wealth of insight and ideas we covered.

First – let me cover the title of this article with a few words. The subject of this article is service offerings on the Internet – broadly. This means not just Software as a Service (SaaS) or Platforms (PaaS) or Infrastructure (IaaS) – it includes all the various types of service products available now on a subscription or fee for use basis. This is often referred to as “X”aaS – whatever you might want to put in front of the words “as a Service” and includes the various cloud services and application services extensions for things like billing, metering, integration, etc.

The Gartner Group has recently said we’re at the peak of the hype cycle for these offerings. I agree and I also believe that many services today are “immature” at best as pointed out by a independent study mentioned in a recent article by Dave Rosenberg. That leads to the “trough of disillusionment” as Gartner calls it – when early adopters find the services are not yet where their marketing said they should be and they “push back” against the vendors to deliver at a level consistent with critical business needs.

It is the realization that much of the promise in the XaaS market is still to often just that – a vague promise – that I think united all our guests. The “Service” in many service offerings on the Internet is still poorly defined and poorly delivered, even by major players. And I think i can speak for everyone when I say we are not just standing on the sidelines booing when we say that – we’re all all personally and professionally committed to helping our clients and the industry get to the level of maturity that is necessary for long-term success.

Steve Plunkett kicked off the conversation with some background on “servitization” in industry and an example that struck me – Rolls Royce Aviation provides jet engines for much of the commercial aircraft fleet in service today. But they don’t do it by “selling” the engines – they provide them as a service-based on the number of miles flown, along with all the maintenance and support necessary to operate them, to their customers. When you take an example of a service like that you immediately see that there is more to it than just putting engines on planes – this is the entire operational assurance that goes with the operation of an aircraft and the critical service it is providing its customers. As Steve pointed out – our industry is still very naive when it comes to providing this level of direct services to customers. In the past, it was enough to provide a CD and an install script. It was someone else’s responsibility to properly size, secure, and provide access to the server where it was installed. Service was limited to second or third-level calls to the help desk. But as Phil Wainewright of ZDNet recently pointed out – this isn’t because a service-based approach is new to the industry. If nothing else, it could be said that licensed software started in earnest because of US anti-trust actions against IBM.

The core issue for the industry and SaaS vendors is there is a great lack of understanding when it comes to approaching the business of becoming a service provider, especially for companies that started out as straight-forward “product providers” – meaning those who provide software and a license but don’t provide any of the delivery and operational mechanisms that allow people or other systems to use the application. In fact, it could be said that it is much easier to be a XaaS startup than to transition from being a traditional ISV to SaaS. Going back to the quote from Gartner, if we don’t address this problem, it will greatly impede – if not sink – XaaS as an alternative in the market.

This leads to another point Steve made quite strongly. We are talking about the industry as a whole when we say this. There are a lot of vested interests, that as always in the face of disruptive change (like the current debate on healthcare), will advocate for the least amount of change if not avoid it altogether – the “do nothing option.” These objections come in a lot of forms:

• Product managers will say you can’t control a product development cycle driven by direct customer involvement – as customers expect on the Internet.
• Your Value-Added Reseller (VAR) will tell you there is no way you can sell direct in your market – and maybe they are right – but did you ask if they were ready to become Value-Added-Service Providers? What value will they add to a service-led offering to assure their place in the chain?
• Your IT department will tell you they are not ready to provide the level of service and reliability customers expect for critical line of business applications. But – have they identified the requirements so they can figure out what it takes and who can?
• Your sales group will say they cannot transition from large up front license sales to incremental subscriptions.
• Your marketing group will tell you they cannot imagine how they will operate without the “big bang” of a new feature list for their next trade show.
• Your outsourcing group will tell you they can help you get to where you need to go but they can’t offer a model of interaction and reliability that reflects a more service-led approach.

These same issues are echoed across the industry by naysayers who say security and reliability problems are too great, integration or customization is beyond SaaS, and the business model is too hard to make a profit with. The issue is getting them all to acknowledge that providing a service instead of a packaged application is yes, inherently different from the current “norm” but in many ways just part of the larger business push toward “servitization.” On balance, I think our answer is, “Get over it.” This is a business opportunity and you will either find ways to take advantage of it or get left by the wayside.

In the early days of the industry companies like IBM and HP provided much, if not all the IT services needed by major enterprises. The aforementioned anti-trust action along with the rise of commodity desktop computers and servers provided an alternative that allowed a lower point of entry brought a great deal of disruption that companies like Microsoft took full advantage of as they moved into a place of dominance. Just like today, there were many changes and many players who felt a sense of entitlement in their roles who were ultimately displaced when they couldn’t make the transition.

A big part the change is the place and role of the service provider (the former software vendor). Now end-users look to the service directly when they have questions about how the application is “supposed to function” and internal IT resources (rightfully) expect their direct support role to be measurably diminished. This is the service that is being paid for after all. Gone are the days when the IT service desk made the decision to push the call “up” to the second or third level support with the vendor. Now the IT department expects the calls to come from the vendor and then only when they cannot resolve a local communication or desktop configuration issue. In fact, increasingly the role of the IT department is to set the standards and expectations that fit the business case for a line of business service and then hold the vendor accountable.

Lincoln Murphy pointed out that within servitized products, it is the service that keeps commoditization at bay. A successful vendor becomes more directly involved and responsible to the end-user both as the service provider and the subject matter expert in the field they represent. As Lincoln pointed out – we can go to our personal computer and start “Word 2003″ and it will work just fine – just as it did in 2003. But if Word was online, we would expect it to seamlessly evolve and be something more that it was six years ago – just as iGoogle is a clear line of evolution from the iconic single search box we all came to love when it first began. In the same way, “Infrastructure as a Service” needs to be more than a commoditized server. If it is not – it isn’t going to displace local servers.

And to extend the concept – a service on the Internet has a “responsibility” to carry the model to include the level of communication the delivery medium allows. Is a platform or infrastructure service benefitting you enough if you can’t leverage the ecosystem or community that revolves around it? What is left “off the table” when the community around a line of business application cannot leverage a forum or even list server to communicate best practices, voice concerns and answer questions? These things certainly exist for premise-based products, but they aren’t baked into the business model and certainly not part of the application itself. The question should be – why aren’t they in a XaaS offering?

Moving yet deeper, Lincoln pointed out that XaaS offerings must leverage their ability to monitor their customer interactions with their product to ensure features are of value and meeting customer expectations. Security concerns aside, generalized usage metadata allows service providers a level of understanding of user interaction. Rather than shying away from monitoring customers, it is a responsibility to users to ensure the service will continue to deliver value and to the brand to ensure it stays ahead of competitive offerings.

This means an XaaS offering has to be much more than a new technology. In fact, I would have to say marketing any XaaS product as a technology alone is an error. Of course, the delivery system itself is technical. The expertise and services that are on top of the delivery are enabled by technology, but if they do not stand on their own, they cannot go beyond simply surviving and move to thriving. An excellent product without the technical underpinnings that provide reliability and scalability will fail to reach its potential. In the same way, the mediocre product with excellent technology will be replaced by competitors in no time, especially when that product is delivered on the Internet. There is simply no real barrier to prevent it.

With that we have set the stage to get deeper into the conversation with Mikael Blaisedell taking us into another aspect of the question – what does “as a Service” really mean? But, this article has reached as much length as I think readers can handle so you will have to join us in Part 2 of our series or – download and listen to the podcast. And – feel free to extend the conversation in your own way – here in comments or on your own blog. We’ll be listening…

We’ve given a couple of webinars recently with our partners Apprenda (archived copy here) and OpSource focused on the key issues ISVs need to consider when developing a SaaS product. One of the areas we covered that received a lot of interest was “Platform as a Service” – PaaS and what it can bring to a SaaS product development project.

Let me start out by saying that in the fog of high tech marketing hype – a great number of products are described as “platforms” for SaaS development. I’m not going to try to parse which specific products are or are not “really” platforms – it is too easy to get tied up in semantics and still not reach useful conclusions. In this article, I’m going to break down some of the services that are often called platforms and put them in a SaaS context.

First – let’s define what functions you must perform – somehow – to effectively provide a software application as a service across the Internet:

• Pricing – A pricing engine or methodology must provide accurate, consistent pricing. In order to be really useful the engine or service should be flexible and allow for changes in the pricing system to accommodate new services or promotions.
• Billing & Payment Processing – Because SaaS is generally based on a recurring payment for services, a system or engine needs to be provided to bill clients and process payments. If there are elements of the service that are usage or transaction based, a part of the application needs to be dedicated to measuring and recording those factors.
• Tenant & Subscription Management - Each client account and the services they subscribe to along with their account status needs to be managed and linked to billing and payment processing.
• Service Provisioning – As each new tenant is added to the service, their “instance” needs to be provisioned. How this is accomplished varies a great deal and depends on the “maturity” of the service offering.
• Usage & Performance Monitoring – This is a very broad category of functionality that spans everything from monitoring individual user activities to the infrastructure that underpins the service. It should also include the accumulation of the raw data that will allow metrics to be derived for operations management.
• Subscriber Management & Self-Service – Each tenant should have ways of modifying their subscription, adding users, changing user roles and monitoring their current usage.

We sometimes refer to these functions as “SaaS Plumbing” because they are operationally necessary regardless of the business rules and expertise that defines your specific product. Of course, the best case is for all of this to be handled within the application “stack” in more or less of an automated fashion. In addition, a true multitenant architecture addresses these issues in the context of a single application instance. To develop a SaaS application that includes these functions in a multenant architecture typically takes from 20 to 50% of the whole development effort. If you do not want to incur this overhead in your application, you have two choices – do some or all of the work manually or use some type of service that provides the functionality for you.

With this background, the basis for the various services and platforms that are available to SaaS developers begins to fall into various levels of functionality and value. To help separate the “wheat from the chaff” a little further – let’s consider what the true, multitenant SaaS “stack” looks like:

The layers of the stack include:

• Infrastructure - Network, Servers, Storage, Load Balancing, etc.
• Technology Stack – OS (Windows, Linux, etc), Database, Application Environment (.NET, Ruby, PHP, etc) and associated services.
• SaaS Functionality – The “SaaS Plumbing” and services outlined above.
• Application Logic – The core business rules and functionality of the service to tenants.

With this common understanding of the SaaS stack, we can start to break down platforms and services for SaaS according to the layer(s) of the stack they address.

Most “platforms” are common to all application development. These address infrastructure and technology stack layers in one way or another. A common example would be something like Rackspace Managed Hosting. A platform in this category can include anything from a single dedicated server to a virtualized cluster, along with the OS, environment, database, reporting and monitoring that application installations typically require. Depending on the services the provider offers and you select, these platforms can greatly reduce the overhead in infrastructure and server deployment. They can improve reliability and provide development environments that lower development effort and improve application reliability. But - they do not specifically address the functionality that is required to operate a SaaS application.

This is where we start to run into problems…

The marketing for most products described as “PaaS” for SaaS today includes some combination of the infrastructure and technology levels of the stack and quite often impacts the way the application logic is expressed. They rarely address multitenant architecture or any of the SaaS functionality that impacts the operational needs of your service. Depending on how they are configured, they can often represent a certain amount of risk through “lock-in” to their service. A recent example of this is the Coghead system which provided the infrastructure and deployment services but in the process provided a development environment that was unique to itself and hard to break away from when the service began to close. These factors don’t lessen the advantages of these platforms, but they do shed some light on their utility for SaaS development specifically. They can be invaluable in the SaaS stack but it is critical to assess up front how they will impact service costs, risk and what they leave on the table that still needs to be developed.

At this time, finding a more complete stack is still a bit of a challenge. Apprenda’s SaaSGrid, Force.Com and Zoho Creator are some of the platforms that in one way or another directly address SaaS. Each has its own pluses and minuses in terms of the functionality they provide and the impact they have on application development. Beyond those, you can use services that address SaaS functionality on top of one of the more general application platforms. This brings on another level of risk – you are now piling together the general platform and perhaps services from several other sources – but this is not uncommon in eCommerce or business-to-business applications so you’re not really breaking new ground if you have experience developing applications for the Internet. Each service addresses a specific range of functionality and again – you need to go back to the list of SaaS functionality to see what you are getting in return for the cost and risk. A good place to start is the SaaS Showplace.

In addition, there are hosting providers – like OpSource – that provide a mix of services for SaaS applications as a part of or on top of their infrastructure. This type of offering lowers the risk because they are centrally controlled and generally provided across the data center instead of across the Internet.

In truth however, there is no PaaS that will addresses all the needs of a specific SaaS operation but – we do find repeatedly that using services and platforms allows the product team to focus on the value features of an application, reduces the time-to-market and costs of development. Assessing what is needed and what is of most value is necessary in the front end of every project and quite often the hardest thing to explain to clients until they get into the “plumbing” themselves. Making the decisions necessary takes planning and consideration, but re-architecting a service after it is on the market is – as anyone who has tried it can tell you – not something you “want” to do without serious pain to prod you.

There has been a lot said about the “maturity levels” of SaaS – so much in fact that the concept is becoming meaningless. Are we looking at it from the customer’s point of view? The ISVs business side? or their development side? or are we thinking like a supplier to the ISV? A hosting, platform or component provider to SaaS ISVs? Without some context – the whole discussion is an exercise in “analyst-speak” to put it kindly.

If the discussion is to have any value – it needs to help in some way to clarify the choices that an ISV or start-up entrepreneur has to provide their application as a service. So, let’s put some context in place. Consider an ISV who wants to offer a SaaS product needs to develop and launch, react to a very fluid and competitive market, continue to please customers, and make money. Cross out of this discussion all those who are not forced to make at least some money on day one or even by day 365 X 3. That removes Google and a number of the industry poster children that are propped by VC funding while they “explore profitability.”

So what are the options?

Level 0 – If the ISV has a premise-based product in the market – or just wants to get a product out the door no matter how quick and dirty the process might be – they can opt to simply put up an instance for a customer to access on a server somewhere. Let’s not quibble over whether that takes one server for every customer or if one server can handle three customers – because in the end it is truly an “it depends” kind of situation. How much CPU and memory does the application take? How many users and how much storage does each customer use? Are they roughly the same or different every time? How much of the time are they connected to the application and how many transactions do they run an hour?

This approach is often used to capture a few customers who really want an on demand product NOW, to get a product out into a new market, or just to test how well it might sell. But – it doesn’t scale. Every customer needs a new instance of the server (or every so many need one). Each instance depends on the reliability of that individual server, its maintenance, usage, age, etc. The only way an instance can be ready immediately for a customer when they buy is to have provisioned servers available all the time. By all rights, pricing for this type of an offering should be more than a simple licensed version because the ISV has taken on all the cost and risk of the infrastructure and services required to host the application. If a customer tries it for a while and then doesn’t renew – the ISV now has excess hardware inventory until it is cleaned out and “rented” again. New versions require that each individual server and instance be upgraded. Server maintenance and patching becomes an expensive and risky undertaking so it is often delayed. As many have said – this should just be considered as “application outsourcing” because every instance is unique.

Level 1 - This is really the old “ASP” model. A hosting provider takes on the job of sizing and provisioning servers on demand for the ISVs customers. To some degree the process or the instance is automated and virtualized, but the server and application instance is still individual for each customer. The advantage of this model is the ISV has outsourced the burden of handling servers and provisioning to someone more skilled and prepared. The hosting provider may also contract to provide first level support but most often that is still the job of the ISV support staff. This still has the disadvantages inherent in the one instance per client of the Level 0 implementation and none of the advantages of a true multi-tenant application. Some hosting providers offer additional tenant management tools for this kind of implementation. Some models say that adding significant automation to the implementation process should be broken out as an additional approach – I really think it is splitting hairs.

Level 2 - When this level broken out things can get confusing. Basically this is where ISVs start towards multi-tenancy but haven’t fully embraced it. Some providers at this level offer a common web front end with a discrete database instance for each customer. Some have a centralized database but haven’t integrated subscription management or full multi-tenancy into the application. Hosting may not be based on virtual “cloud” technology so scaling is not clean and is still manual or automated to the server level. The integration of the SaaS business operations is often minimal at this level and if subscription churn or uptake increases significantly it can become a burden. Quite often at this level there is no difference between a regular licensed version of the application and the “SaaS” version other than delivery and pricing.

Level 3 – At this point most everyone agrees that the SaaS offering is a single application on a database that is truly multi-tenant. One upgrade cycle upgrades all customers at once. The sequence from trial to customer including provisioning, implementation, payment, and subscription management is fully integrated. Customer user management is in place and handled by customer administrators. The underpinnings may be based on anything from local infrastructure with clustering to a fully virtualized cloud provider. Some ISVs at this level build their offerings in a way that allows them to provide a local installation for those customers that insist – although that seems to be dropping away in most verticals. At this level there is little room for compromise – there is specific code or accommodation to allow one multi-tenant application, subscriptions, customer/user management and full scalability. This doesn’t imply that all SaaS applications at this level are on fully virtualized infrastructure but they have reached a point where scaling is more rational.

When we get beyond level 3 the idea of maturity begins to get hazy. Some analysts say that the amount of application generalization should be the factor to consider. Does it allow customers to customize their instance without a code revision? Does it allow vertical versions or channel offerings to exist without a separate code base? Does it allow customers to adopt a suite of products on the same platform – in effect growing their subscription horizontally? I truly believe those are market (non-technical) decisions EVERY SaaS vendor should consider during product development. These are the marketing goals that push the product model to embrace The Long Tail and raise the opportunities for profit and success.

So from my own point of view – If we’re going to talk about levels of maturity beyond level 3, they should tell us something about what SaaS ISVs need to do to reach optimal operations with a time to market and cost that allows the earliest possible payoff. They need a path to provide a flexible, reliable and scaleable base from the beginning. ISVs embarking on a SaaS project need to have a chance of winning without a three year development cycle and a large, custom code base.

I would argue that at an early point in product development – components, platforms and standards need to be considered. If simple subscription management is a solved problem – why put the money, time and risk into the project to develop it again? If components ease and standardize the development of the interface or remove the need to develop a common set of routines – will it limit the product too much to use them? If a platform reduces the development to specific business logic – is it worth considering? Is your team’s interest in a new language going to provide you with an edge or does it limit the application’s ability to adapt to broad market changes in the future?

Because of the growth of web applications, there has been at least an equal growth in tools and platforms that speed and standardize the their development. Some are general in nature and some are SaaS specific. Some are backed by large companies and user bases and some are small and niche-oriented. As the recent shutdown at Coghead points out however – they are not without risk. Like when you consider a hosting provider, the risks and rewards of each offering needs to be understood and evaluated. Here are some questions SaaS ISVs should ask to ensure they are getting what they need from platforms and components:

• Does it offer SaaS specific functionality? If provisioning, billing, user monitoring, subscription management, user roles and administration are not part of what you are considering it is a web or general development tool. That doesn’t mean it shouldn’t be considered – but it does shine a light on value.
• How open and standard is it? If your developers have to learn a new language to use it or if it isolates you to the environment it lives on – is it worth the trade-off? Google Gears is a valuable environment if your application is going to use other parts of the Google or Zoho application systems. Apex is useful if your application gains value from the Salesforce community and platform. Outside of those communities – how much value are you really getting versus the cost and risk?
• What is the experience of the “community” using it? The size of the developer community is really of less importance than what their experience may tell you. Coghead had a large community, but too many were not paying subscribers. Why?
• What is the “lock-in?” There is always a lock-in, whether it is tool-centric development and training or a platform that will only operate in the hosted environment the vendor provides. How much of a risk it presents is what should be evalutated. What does the vendor offer to lower the risk? What do you need to do to migrate if the tool vendor no longer supports you? Being in the SaaS business is a risk by itself so being risk adverse to the extent you can’t consider tools and platforms to lower costs, streamline development and get a better product to market is a strategy that can sink you. Knowing your risks and planning to deal with them up front is the key.
• Will it scale with your business? If you have to buy 500 seats before you can sell one subscription – how valuable is this burden? Will it scale back if you volume changes during the year? Is the cost flat (per user), per application, or transaction? Can you build it into your operational cost?

Depending on the platform or tool there may be more things to cover – but these are the most common issues we deal with as we work with our clients. I already see more that will come in the near term as “cloud computing” becomes more accepted, but for now – looking at your options clearly and selecting the most flexible approach you can manage is the best route. You don’t have to get there all in one step – but you should have a roadmap in mind so you don’t waste time and money with dead end development.

We don’t often “push” our own services here, we see our mission on Haut Tec to be a part of the conversation around Cloud Computing and software technologies in general. But, I’m excited to say – today’s announcement is one of the exceptions:

As a part of their continued efforts to bring value to their customers, Scio Consulting and Apprenda have announced a strategic partnership to offer enablement services for software companies looking to bring their products to the on-demand business model rapidly and efficiently by using Apprenda’s SaaSGrid™, a Software-as-a-Service (SaaS) delivery platform.

SaaSGrid drastically slashes time to market for independent software vendors (ISVs) by automatically weaving a SaaS architecture and business functionality into their non-SaaS web applications, while providing significant long-term value via web-based application management capabilities.

“Essentially, we’ve done for on-demand software development what the operating system did for desktop software development. We’ve created a cloud operating system for SaaS, which provides a new layer of abstraction that takes the burden of creating SaaS-specific technology, architecture and business components off of ISVs shoulders,” said Apprenda’s CEO, Sinclair Schuller.

ISVs that choose SaaSGrid as a foundation shave off massive amounts of development time and capital requirements that would have previously been allocated to SaaS delivery intricacies. This allows ISVs to bring their solutions to market faster than ever before, utilizing SaaSGrid’s out-of-the-box functionality.

SaaSGrid's zero effort multi-tenancy isolates your customers by handling data partitioning, request routing, and authorization security as part of the package.

“It is a pleasure to partner with Scio, a company that shares our enthusiasm and vision of an on-demand future,” said Sinclair Schuller. “Software companies that want to create new SaaS offerings often need assistance with their business and product strategies, with developing their SaaS applications, or with modifying the code of an existing on-premise application to move it to SaaS. Our relationship with Scio enables us to help customers more easily obtain such services and make a smooth transition to SaaS with SaaSGrid.”

SaaSGrid has been evaluated by Scio Consulting and found to be an excellent tool for reducing costs and time to market for their ISV customers.

“Scio has been developing custom SaaS applications for years utilizing .NET and open source technologies . Using Agile practices and our Nearshore Development Center in Morelia, Mexico, we are typically able to deliver new SaaS applications in 4-9 months. Now with SaaSGrid, we will be able to build SaaS applications for our clients faster and more economically than ever before,” states Luis Aburto, CEO of Scio Consulting.

Rather than requiring the use of a proprietary technology stack, SaaSGrid applications are built using the industry-hardened Microsoft .NET stack and the SaaSGrid SDK. The SDK hooks into Microsoft’s Visual Studio, and provides an integrated development environment that allows a software company to write business code, user interfaces, and databases locally by using popular .NET languages like C#.

Update:

If you would like to hear an in depth discussion of SaaSGrid – Listen to the podcast Paul Miller of Nodalities did with Apprenda CEO Sinclair Schuller.

Useful? Copy, paste and Tweet it!

Scio Consulting Partners with Apprenda for Rapid SaaS Product Enablement http://bit.ly/huw5