I'm developing a methodology for determining the optimal time at which to begin the implementation of a web-service application. Specifically, I'm trying to understand how the continued evolution and maturation of the underlying technologies and standards affects timing decisions.

As an historical analogy, consider the adoption history of FAX machines. In the early days of FAX, the machines were very expensive and the value (for most companies) of having one was low. But at some point in time the costs dropped dramatically as the value increased. Soon thereafter, the value exceeded the cost by such a great margin, that the risk of not investing (RONI) in a FAX machine was substantial.

Some distributed companies found that it made sense for them to buy those early expensive FAX machines, not to communicate with their partners (who didn't have FAX machines yet), but just to communicate with their own branch offices. These companies were the early adopters, and for them the value/cost crossover point came early.

At the other end of the spectrum, many retail businesses couldn't justify the purchase of a FAX machine until they became quite inexpensive and their customers (consumers) had FAX machines at home.

As with FAX machines, the value of most web services typically increases over time. This is due to the network effect: The value of the network is equal to the square of the number of nodes connect to it. External web services in particular follow this model. They're of little value when no one else has the technology to use them, but a tipping point occurs after which adoption increases rapidly. At some point, in fact, the cost of not having an implementation of the web service becomes substantial.

Below is an illustration of the value of a web service over time.

Cost is the other criterion. It's always less expensive to develop an application as the technologies on which it's based mature. As the following diagram illustrates, it's less expensive to develop an application once third-party tools become available. Likewise, it's more expensive to hire contractors and consultants in the early stage of a new technology (before it's a common skill set) than to later hire employees that have learned the required technology either at a previous job or perhaps in school.

I've identified a number of easy-to-recognize events that can be used to evaluate where on the decreasing-cost curve a technology is currently positioned. The figure below shows the order in which these indicators occur and the position each occupies on a curve of implementation cost that decreases over time.

Given that both value and cost vary over time, we can superimpose them as illustrated below for an arbitrary web service.

Assuming the curves are also aligned along the "$" axis (abstractly representing both cost and value), the point in time at which the curves intersect is the optimum time for this organization to deploy this web service. In the example above, we see the deployment cost and value for a moderately progressive (perhaps early-majority) organization.

But it will take time to develop the web service, so we need to determine the point at which we must begin development. This process is illustrated below. We move backwards from the desired launch date by the amount of time it will take to develop the service (lead time). This gives us the start time at which development must begin in order to deploy on schedule. Note that the development cost (Y axis) is determined by the point at which the start time intersects the cost curve.

From the above it appears that in order to deploy the desired web service somewhat prior to widespread use of such services, the organization must begin development immediately upon the publication of the standards that address the underlying technologies. For instance, if the web service is a B2B (outside-the-firewall) business process, development should begin as soon as all of the required protocols and standards have been finalized.

Note also, that the development team should be prepared for problems with product interoperability, and that the company should not expect to hire employess who have previously been exposed to the recently standardized technologies required to build the web service.

Using an analysis such as shown above, it should be possible to avoid starting a web-service implementation project too late. But it's also possible to avoid starting too early. That's critical for minimizing IT waste and maximizing ROI.

Consider what would happen if the company in the above example were to begin development as soon as the first developer tools became available. The results would be as illustrated below.

The above illustrates the problems with starting development too soon. Because the start date intersects the cost curve at an earlier/more-expensive point, the company will spend substantially more than is required, and development process will suffer from a lack of documentation, slippery standards and a shortage of experienced staff or contractors. The "waste" gap indicates the increase in development costs due to starting too early.

It's not a matter of "later is always better," for clearly, once value exceeds costs, you'll experience a loss from investing too late. The key is to optimize the timing and start neither too early nor too late.

A methodology I propose begins with the following steps:

• Map the cost-indicator curve to actual dates for the web service you're planning.
• Determine at what stage it's appropriate for your organization to deploy web services (innovator, early adopter, early majority, late majority), and attempt to draw a value curve that intersects the cost curve.
• Working backwards from that intersection (the optimal deployment date), create a plan and schedule to develop the required services.

More to follow, of course. Comments and criticisms are encouraged.

Doug Kaye, 14 April 2002
doug@rds.com, www.rds.com
This report available at http://www.rds.com/essays/20020414-when.html

For my latest analysis of this and other web-services issues, subscribe to the IT Strategy Letter. It's published weekly, and email subscriptions are free.

IT Strategy Letter back issues.