SOA & Response Time: A Generational Issue?

by Don Fowler
March 1, 2008

Traditional thinking has held that response times should be as fast as possible so users can maintain focus on the task at hand and not introduce errors into the current or next task. The longer the response time, the more errors might occur. Consider the merit of this perspective: 

• When you’re conducting online banking and hit the “pay” button and the system goes away for what seems an eternity, don’t you wonder if the transaction is hung up? Should you reboot? Will you pay that bill twice if you try to exit now?

• At work, you may be doing a task and, if the system response is slow, your mind may go to the vacation you’re about to take. When the system response finally arrives, you may have forgotten what you were doing. So you either enter something wrong or have to stop and review what you’ve done. 

When the system can’t provide an immediate response, the user should see some form of continuous feedback. This might be in the form of a percent-done indicator [Myers 1985]. As a rule, percent- done progress indicators should be used for operations taking more than about 10 seconds. Progress indicators have several pluses; they:

• Reassure the user that the system hasn’t crashed but is working on their task

• Indicate approximately how long the user can expect to wait, allowing the user to do other activities during long waits

• Provide something for the user to look at, making the wait somewhat less painful. 

Have you ever done a Windows update and gotten the progress bar that never moves? Having a progress bar that never progresses is worse than having no bar. You’re sure the update is broken. Should you abort, reboot, wait? 

Don’t put in a progress indicator unless it really works! Consider adding a conditional element for borderline response time assets that inspects the current average response time and interjects dynamic progress indications to the requesters when more than 10-second delays start occurring. The conditional element might report the agreed-upon Service Level Agreement (SLA) use counts against the actual use counts to show latency issues. In old terms from the ’70s and ’80s, we would call the latency issue the peak hour demand. If the configurations are provisioned for 1,000 instances of asset use, and the actual use is 2,000, insufficient resources exist to maintain the agreedto service level. Either additional provisioning or new SLAs are required. 

Response Time Paradigm Is Generational  

The following statement may cause a furor in the IT community, but it’s still true: The view of acceptable response is a generational issue. Some business applications of technology require real-time, sub-second responses. You probably wouldn’t like to be flying around the skies under control of a system using a Web Services SOAP implemented SOA! It would be too slow for a real-time requirement, by far.