SOA & Response Time: A Generational Issue?

by Don Fowler
March 1, 2008

Service-Oriented Architecture (SOA) and acceptable Web service response times have always seemed a dichotomy. SOA is clearly a major goal of Enterprise Information Technology (EIT), and satisfying users is what EIT is all about.  

SOA is focused on asset reuse, reducing costs and risks, and making the overall business more agile. The enterprise is balancing the costs and risks against the:

• Assets’ security

• Assets’ utility aspects to the user

• Richness of the assets’ function to the user

• Ability to make the business more agile by publishing the assets in a manner that can be categorized and reused. 

This article focuses on the utility aspects of assets and how response time affects the utility of an asset, depending on the age of the users. 

Response time is usually the measure of the time from the point the requester makes the service request until the time the service provider completes the first required information payload back to the requester. A payload might be the message content required for the first screen or the delivery of the messages required to trigger the next sequential operation at the requester. 

The basic advice regarding user perceived response times has been about the same for 40 years [Miller 1968; Doherty & Thadani 1982; Card et al. 1991; Jakob Nielsen 2006]:  

• 0.1 second or less is about the limit for having a user feel the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. This also is the response level that Doherty & Thadani dealt with in their 1989 paper, “The Economic Value of Rapid Response Time.” In this treatise, it was shown that when a computer and its users interact at a pace that ensures neither has to wait on the other, productivity soars, the cost of the work done on the computer tumbles, employees get more satisfaction from their work, and quality tends to improve.

• One second is about the limit for the user’s flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1 second, but the user does lose the feeling of operating directly on the data, especially if the response time is inconsistent. If a user always gets a 5-second response, he becomes used to it. When system response goes from 1 to 6 seconds, errors start to occur. Immediately, the user thinks something is wrong.

• Ten seconds is considered the limit for keeping the user’s attention focused on the system interaction. For longer delays, users will want to perform other tasks while waiting for the system to respond, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users then won’t know what to expect. (Current studies indicate 8 seconds may be the upper limit.)