Software is service: Why is it so hard for software engineers to fully internalize it?

The phrase "Software is service" became a very important keyword for Microsoft in late 90s. It was very obvious for Microsoft executives that the "shrink-wrapped" software business will be eventually taken over by "subscription" software business, where the user will pay monthly subscription fee instead of a fixed amount for a particular version of software.

First, Microsoft has tried to sell Microsoft Office in this business model (ASP model), but it soon became obvious that it does not work because the Office applications were not architected appropriately to support that model (they were traditional "big fat" client programs).

A new group was formed to create the next generation of productivity applications, which would allow Microsoft to sell those applications as subscription services. All applications were developed using web-technologies such as HTML, XML, Javascript, HTTP (using the technique called AJAX today), so that they will run as web-applications within Internet Explorer.

This group was eventually named Netdocs, and had nearly 400 engineers at its peak. This project was, however, eventually killed although Microsoft has never officially announced its defeat (as usual).

I was one of original members of Netdocs, and I know exactly why it failed now. Netdocs has failed not because of the internal politics (even though many people still believe it), but because of engineers (including myself) who do not understand what does it take to build a good service.

Building traditional large-scale software (such as Microsoft Office or Windows) requires a set of very smart people who understand both technologies and market needs. They spend a significant amount of time designing and architecting the product, which often takes over a year. Then, they grow the team big enough to implement various features and functions they came up with and spend a large amount of time (typically a year or two, but sometimes three to four years) writing code and testing it. They release beta version of product to public once or twice to get "customer's feedback". During this beta cycle, they receive a large amount of feedback. Even though these feedbacks include both bug reports and feature requests, they often just address bugs because they are "much higher priority". They eventually release the product to the market, have a big release party, and then take vacations.

Their job ends when they release the product. The most important part of this process is the very first part, where those smart people design and architect it.

Running services, such as restaurants, sports gyms, theme parks or web sites, however, require very different mindset. First of all, they don't try to design and build the whole service before opening the business to their customers. They involves real customers into their design process. Instead of trying to come up with a perfect menu of food before opening the restaurant, the owner opens the restaurant with a tentative menu and keeps improving it based on customer's feedback. A good theme park continuously evolves itself in order to make their customers come back again and again.

The most important part of building a good service starts at the day they open the service to the public. Therefore, it is much more important to have an internal process that reflects customers’ feedback quickly than having a set of good services at the day one.

Netdocs projects had great engineers who had built great products such as Office, Windows and Internet Explorer, but their mindset was all based on traditional shrink-wrapped software business. Instead of coming up with a small set of features and release it to customers quickly, they have tried to build something compelling enough to convince their customers to switch from Microsoft Office - a totally wrong approach to build a service, and a politically inappropriate approach to take within Microsoft.

If I am going to build a web-application business that targets those productivity applications today, I will not try to build something compelling enough to directly compete with Office applications. Instead, I will focus on a couple of key scenarios and build a web application that allow customers to do those specific tasks much more efficiently than using Microsoft Office products. I would release it to the public quickly in beta quality, and allocate significant resources to build an internal process that allows us to get customers feedback efficiently and quickly reflects them to the service.

There are a lot of things we can learn from the failure of Netdocs. I strongly believe that all software companies need to figure out the way to turn themselves into service companies. The web significantly reduced the cost of software distribution and also made it very easy to get customers feedback directly or indirectly. It is critical for all software companies to build a very good internal process that allow them to learn from customer feedback and reflect them into the product quickly.

Comments

[shun]

Great entry and an eye opener. Though this concept makes a lot of sense, it is hard to verbalize it like this and hard to execute when you are deep in it like myself.
I'll be thinking about this all weekend.

The failure comes from the process, not from the people. (well, sometimes...)

[Pete Stoppani]

The failure to implement applications as a service has little to do with the engineers. The direction to create a service rather than a standard application has to be clearly defined by product management. NetDocs is a great example of a project that lacked clear direction.