National Academies Press: OpenBook
« Previous: Chapter 1 - Introduction and Research Methodology
Page 4
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 4
Page 5
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 5
Page 6
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 6
Page 7
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 7
Page 8
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 8
Page 9
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 9
Page 10
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 10
Page 11
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 11
Page 12
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 12
Page 13
Suggested Citation:"Chapter 2 - Findings." National Academies of Sciences, Engineering, and Medicine. 2002. e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines. Washington, DC: The National Academies Press. doi: 10.17226/24724.
×
Page 13

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

4CHAPTER 2 FINDINGS ASP BACKGROUND ASP Business Model An ASP is an enterprise that provides network-based access to applications that it hosts, maintains, manages, upgrades, and operates in its own data center or in a partner’s data center. ASPs rent access to their applications for a monthly fee; this fee usually depends upon the number of users accessing the application, the specific application modules accessed, and associated service and support options selected by the cus- tomer. The ASPs’ products are its applications and associated support services. ASPs market the same applications to a broad range of customers with minimal levels of application cus- tomization and attempt to realize economies of scale by deliv- ering the same application service to many customers; cus- tomers hope to share these economies of scale in the form of a total cost of operation that is less than the cost of hosting the same application internally. There are a number of descriptions of the ASP business model in use, but there is no single formal definition of the model. ASPs self-identify so that any vendor who chooses to claim to be an ASP is classified as one regardless of the combination of services that vendor offers. As a result, it can be difficult to compare service offerings from different self-identified ASPs. Ashenhurst (1), Lavery (2), and Hayes (3) provide slightly varying descriptions of the ASP business model. There is, however, general agreement that the ASP business model contains four key elements: • Application hosting: Software applications run on a host computer operated by the ASP or by a business partner. • Network access: Applications are accessed across a network, either the Internet or a private WAN. • Thin client interface: Software applications offered are server-centric and concentrate their processing on servers hosted by the ASP. The applications are gener- ally accessed through an Internet browser or some other minimal client-side application running on the customer’s desktop computers. • Subscription access: Customers subscribe to software applications for an agreed-upon period of time rather than licensing the software directly and pay a monthly rental fee for that access. The first ASPs appeared in the late 1990s. The term “appli- cation service provider” was first applied to these vendors in 1998. The appearance of ASPs coincided with the emergence of what came to be known as the “Internet economy.” During this period, investors were willing to provide large amounts of investment capital to all manner of start-up enterprises with business plans loosely based on the Internet. The ready avail- ability of investment capital lowered barriers to entry into the industry and allowed many ASPs to establish themselves. These ASPs began to invest in the infrastructure required for their service offerings: data centers, networks, computing hardware, software licenses, and software development. Ini- tially, ASPs attracted few customers. Their business plans relied upon continued availability of venture capital funding until such time as they could expand their customer bases to generate positive cash flow. When investors lost confidence in the Internet economy in mid-2000, venture capital became unavailable and ASPs, along with other companies who were part of the Internet economy, were forced to rely largely upon revenue derived from their customers for survival. The ASPs found themselves burdened with debts incurred while building infrastructure and with a customer base that generated a revenue stream too small to sustain operations. As ASPs exhausted their cash reserves, they began to exit the market through cessation of operations, bankruptcy, merger, acquisition, or by entering different busi- nesses. The trade press contains numerous reports of ASPs exiting the market suddenly and leaving their customers to replace the ASP services with little or no notice. Bushaus (4), Songini (5 and 6), Mears (7 and 8), Hudson (9), Mitchell (10), and others document numerous cases of ASP failure. This shakeout in the ASP market was sufficiently severe to cause Gartner Group to predict that 60% of the ASPs in existence in mid-2000 would fail by the end of 2002, as reported by Sweeney (11). In spite of these problems, many customers who had sub- scribed to ASP services received the levels of service they desired and achieved the business objectives that had initially led them to the ASP model. Muse (12) reports the results of an International Data Corporation (IDC) survey in which adopters of the ASP business model achieved significant return on their investments in ASP services. In several cases, customers who experienced an ASP failure responded by finding another ASP and transferring their processing to the

new ASP rather than licensing the software applications them- selves and bringing the processing in-house. Benefits of ASP Usage The ASP industry claims a number of benefits result from subscribing to ASP services. These benefits include the following: • Application access: ASPs make access to sophisticated applications available to small- and medium-size orga- nizations—applications that those organizations could not afford to license and operate internally. ASPs also make a wide variety of applications available to organi- zations of all sizes. • Concentration on core competency: Use of an ASP allows the customer organization to focus the resources that would have been used to host an application in- house on activities related directly to the customer’s core business. • Cost control: Use of an ASP generates a predictable and controllable cost for the application service in the form of a predictable monthly subscription fee in place of the less-controlled and less-predictable costs of host- ing the same application internally. • Reduced need for information technology (IT) expertise: ASP applications reduce the need to recruit and retain information technology staff personnel knowledgeable in the application being hosted. • Reduced capital expenditures: Renting applications from an ASP reduces the need for large up-front invest- ments in computing hardware, software licenses, and integration services that frequently accompany the implementation of new applications. • Access to best computing practices: ASP services typically include such industry best practices as appli- cation and data backup–and–recovery services, access control and security, data redundancy, and disaster recovery. ASP offerings in these services are frequently more sophisticated than the services that ASP cus- tomers could provide for themselves. • Service delivery: The ASP provides help desk and application support, eliminating the need to provide that support internally. • System availability: ASPs can provide the availability levels for mission-critical applications that the cus- tomer’s own organization may not be able to support. • Rapid implementation: ASPs can generally deploy applications for customers in less elapsed time than the customers would require for implementing the same application. • Decreased implementation effort: ASP software gen- erally requires less implementation effort on the part of the customer organization than if the customer organi- zation hosted the application internally. 5 • Guaranteed service levels: Use of an ASP results in improved application service and customer service. ASP application service and customer-service delivery levels are governed by service-level agreements (SLAs), which guarantee the quality of service. Similar agreements with service-level guarantees are typically not available when applications are hosted internally. • Lower cost of ownership: The ASP computing model provides customer organizations with the opportunity to reduce overall costs of ownership of the rented appli- cations, thereby eliminating the need for the customer to invest in computing hardware and software or to incur the continuing costs of maintaining, upgrading, and sup- porting that hardware and software. • Return on investment: Subscribing to ASP services and leveraging the ASP’s capabilities to implement rapidly allow the customer to avoid high start-up costs and provide service at a continuing cost that does not exceed a customer’s internal cost of ownership. This allows customers the opportunity to achieve a positive return on investment in less time than if the same appli- cations were hosted internally. ASP Software Application Offerings The ASP industry offers subscription access to commercial software applications and to custom-developed applications implemented by the ASPs themselves. Table 1 lists examples of application categories offered by ASPs and specific com- mercial software applications offered in each category. The applications in Table 1 are of general interest across all industries and are typical offerings of what might be called “horizontal ASPs”—ASPs that offer applications of general interest and applicability to all industries. In addition to general commercial software applications as shown in Table 1, some ASPs offer applications with a specific verti- cal market focus. Examples of such applications include association membership management, financial risk man- agement, medical practice administration, and truck-routing and fuel management. A few ASPs offer applications that might be of specific interest to the transit industry. These applications include vehicle-fleet management, traveler information, fuel manage- ment, and passenger count reporting. Overall, the most popular applications according to the Information Technology Associ- ation of America (ITAA) are e-mail, e-Commerce, accounting and finance, office productivity, and human relations, in that order (13). Pring (14), in the results of a different survey con- ducted by Gartner Group, confirms that human-relations appli- cations are among the most popular ASP service offerings. ASP Services Offered In addition to software application access, ASPs also offer a wide range of services that are associated with hosting,

operating, and maintaining software applications and pro- viding support to the customers who subscribe to those soft- ware applications. Some ASP services are included as part of the overall service subscription; other services may require a separate service subscription. Examples of services offered by ASPs are as follows: • Computing operations; • Software installation; • Software maintenance and upgrading; • Technical support; • Network management; • Performance monitoring, management, and reporting; • Access management; • Basic help desk and technical support; • Application availability; • Application performance monitoring; • Hardware installation; • Hardware maintenance and upgrading; • Capacity planning and management; • Backup and recovery; • Data and application redundancy and mirroring; • Disaster recovery; • Off-site data storage; • Application customization; • Integrating (interfacing) with other ASP-hosted appli- cations or customer in-house applications; 6 • Network and data security; • End-user training and education; and • Dedicated help desk and technical support. ASP Adoption Recent surveys conducted by industry analysts, the trade press, and trade associations have shown that ASPs have secured a foothold in the market and that while the current rates of ASP adoption are low, there is a future for this busi- ness model. Terdiman (15) predicts that during calendar year 2002, the ASP model will be accepted as a mainstream alter- native rather than as an untested or experimental option for outsourcing computing services. ITAA (16) published results of a customer-demand survey conducted in early 2000 in which 18.5% of the survey respondents were using ASP services and in which another 23.9% of respondents were planning to evaluate ASP ser- vices within the following calendar year. The survey also revealed that the survey respondents considered themselves to be well acquainted with the ASP business model and the customer value proposition offered by ASPs. Of the respon- dents, 35.7% considered themselves to be very familiar with the ASP concept; 40.5% considered themselves to be some- what familiar with the concept. Pring (17) documented the results of a survey conducted by Gartner Dataquest and published in August 2001 that TABLE 1 Examples of ASP commercial software application offerings Application Category ASP Commercial Software Offering* e-Commerce Broadvision BEA Weblogic Microsoft .NET Services Customer Relationship Management Siebel Professional Services Automation Microsoft Great Plains Peoplesoft Solomon Software e-Mail/Collaboration Microsoft Exchange 2000 Manufacturing and Distribution Microsoft Great Plains Peoplesoft Solomon Software Human Resources Management Oracle Peoplesoft SAP Business Intelligence Cognos e-Procurement Ariba CommerceOne Enterprise Resources Planning Lawson Peoplesoft SAP Personal Productivity Microsoft Office * Commercial software packages listed in Table 1 are examples of applications offered by active ASPs in each of the corresponding application categories. These are not the only applications available in the listed categories; this list does not imply any endorsement of these applications.

found that 19% of its respondents currently outsourced one application to an ASP; the survey found that another 18% of respondents outsourced more than one application to ASPs. Another 13% of respondents were actively evaluating ASPs at the time of the survey. Borthick (18) shows a case of slightly less-positive survey responses. This survey was the Business Communications Review of outsourcing trends. This survey found that only 11% of respondents currently outsourced data applications to ASPs; 7% outsourced voice applications. A significant neg- ative result of this survey was that a full 24% of responses said that they would not consider outsourcing either data or voice applications to an ASP. In the federal government mar- ket, ITAA (19) found that ASP usage among federal agen- cies lags that found in the more general surveys. This survey revealed that only 6.5% of the surveyed agencies currently outsourced applications to ASPs and that another 20% were evaluating the ASP option. These surveys show that the ASP business model has secured a place in the market for providing outsourced com- puting services both in the private sector and for the federal government and has achieved the status of an alternative source of services to be considered. Barriers to ASP Adoption Although there are benefits and advantages to adopting the ASP model for obtaining computing services and although surveys show that this computing model has been accepted, in general customers have been slow to adopt this computing model. Some of the reasons for this reluctance are listed below. • Customer confusion: There is no commonly accepted definition of “application service provider.” Vendors with different product and service offerings and differing busi- ness plans have all adopted the label. As a result, some potential customers become confused with the many options available in the ASP market and the difficulty in attempting to compare the varying service offerings. • Culture: The ASP business model represents a new way of doing business for many prospective ASP cus- tomers; many are not ready to experiment with what is viewed as an untried and untested mode of operation. • Fear of loss of control: Some organizations fear the loss of control that would accompany outsourcing mission- critical applications to ASPs. • Data security: Many organizations are concerned over the possible compromise or theft of critical enterprise data while the data is in the custody of an outside agent. • Fear of ASP failure: Concern about the potential of ASPs to cease service delivery because of bankruptcy, merger, acquisition, or decision to exit the service- provider market has caused some prospective cus- 7 tomers to defer considering ASP services or to bypass consideration of ASP services altogether. • Single-application outsourcing: The ASP model out- sources one application at a time. Many organizations seeking to outsource applications hope to outsource their entire portfolio of applications, not just selected individual applications. • Application performance: Concern regarding the inad- equate performance of applications accessed over the Internet or over a private network eliminates ASPs from consideration as viable alternatives. • Software availability: The inability to find ASPs offer- ing the specific application functionality or the specific commercial software applications desired is also a rea- son for reluctance. • Continued software availability: The fear that an ASP may discontinue a software application at some point in the future is another reason for slow adoption of the service. • Scalability: The concern that the ASP may be unable to scale an application to meet the service demand of all of its customers for that application also causes reluctance. • Applications already in-house: Organizations that already have operating applications hosted in-house or that are obtaining application services from another source may be reluctant to consider outsourcing those same applications to an ASP unless there is come com- pelling reason to replace the existing application service. • Service delivery: Concern that the ASP will be unable to meet the performance specifications and customer- service levels committed to in an SLA creates reluc- tance to adopt. • Lack of application customization: ASPs generally attempt to deliver generic applications to their customers with little or no customization of applications beyond corporate logos. Large organizations frequently insist upon extensive customization of packaged applications prior to use. The unavailability of this level of cus- tomization discourages some organizations from con- sidering ASPs. • Lack of application integration: Many applications interface data with other enterprise systems. There is a concern that ASPs do not have the capability or resources to interface data from one application hosted at their data centers to other enterprise applications, whether the other enterprise centers are hosted in the ASP’s data center, at the customer’s operating location, or at a third-party location. • Conversion cost: The anticipated cost to convert from an existing application hosted in-house to an ASP- hosted application is considered excessive. • Low market awareness: Potential customers are not sufficiently aware of the services offered by ASPs or the overall ASP value proposition to seriously investigate the ASP alternative.

• Problem resolution: Concern that the vendor will be unresponsive to customer problems, especially if the cus- tomer is a small customer, creates reluctance to use ASPs. • Service interruption: Fear of loss of service from out- sourced mission-critical systems because of network outages also causes reluctance. ASP Customers The ASP model has been described as being intended for small- and medium-size organizations that do not have the resources or financing to host and operate state-of-the-art applications internally. These types of customers were the first targets for ASP services. However, Pring (20) points out that based on Gartner Group research, 40% of ASP business volume originates within Fortune 500 businesses. The ITAA 2000 customer-demand survey indicated that of its 1,526 responses, 20.3% were from organizations with more than 5,000 employees and 10.8% were from organizations with more than 25,000 employees (21). On the other hand, this survey also showed that 42% of responses were from orga- nizations with fewer than 100 employees, and 37.6% of responses were from organizations with between 100 and 500 employees. These results show that while a clear major- ity of customers are small organizations, there is a significant investment in the ASP computing model by organizations of all sizes. THIN CLIENT COMPUTING Thin Client Computing Model Thin client computing is an application system software architecture that concentrates application business function- ality and processing capability on a central server and limits the client-side portion of the application to user-interface dis- play. End users access the central application using client software loaded on desktop workstations and connect to the central server over a network. Thin client computing has become a standard application architecture because of the emergence of applications designed to run either over the Internet or over a private network using only a client-side Internet browser to access the application. Lowber (22) cites a trend toward the use of an Internet browser such as Microsoft Internet Explorer or Netscape Navigator as the standard client-side software application for accessing net- worked systems. The desktop workstation used with the thin client applica- tions can be either a standard personal computer (PC), or it can be a thin client device. The concentration of processing and data storage on the server reduces the processing burden on the client-side device and allows the use of a less-powerful computing device than would otherwise be required. This device needs to run only the client-side, user interface–display 8 software, which may be an Internet browser for web-enabled applications or a minimal user interface–display application. Thin client devices are specialized computers that include a central processor, monitor, keyboard, mouse, and memory, but do not include local storage in the form of floppy or hard disks and do not include CD or DCD disk drives. These devices are used to run client interface software hosted on a server or interface software burned into read-only memory. Lowber (23) reports that the most popular method for implementing thin client computing is through the use of Microsoft Windows Terminal Services in conjunction with Citrix Metaframe. This implementation allows Windows- based applications that normally run on a PC to be run from a server and accessed from thin client workstations. Thin client computing is best suited for hosting applica- tions that are transaction-oriented. Lowber (24) recommends against installing thin client computers as a general across-the- board replacement for PC-based applications and is in favor of installing thin client applications to support work that is struc- tured or repetitive but not for work that is creatively driven. Lowber (25) identifies applications supporting call centers, customer-service functions, medical-records processing, pack- age tracking, insurance-claims filing, and airline-reservation processing as being well suited for the thin client computing model. Applications similar to these—along with occasional use of Microsoft Office applications, e-mail, and Internet browsers—are also well suited for thin client computing. However, applications supporting users who are classified as power users or those who use applications in support of creatively driven work activities are generally not good can- didates for thin client application support. Heavy usage of Microsoft Office applications, computation-intensive and data-intensive processing, graphics, and multimedia applica- tions are all poor candidates for replacement with thin client applications. User populations that require the capability to work in a mobile environment or the ability to work while disconnected from the network are also inappropriate candi- dates for thin client processing support. In spite of these restrictions, Lowber (26) finds that thin client computing can support 85% of most users’ needs. The desktop workstation used with thin client applications can be a thin client device, or it can be a PC configured with an Internet browser. The essential components of a thin client device are a display monitor, a central processing unit, mem- ory, and a keyboard. These devices are designed to have as few moving parts as possible and frequently have no hard disks or floppy disks. These devices may have an Internet browser burned into read-only memory, or it may run the browser from a server. An alternative device in a thin client configuration is a PC configured with an Internet browser. Lowber (27) reports that 85% of thin client desktop devices are PCs. Because these computers only need to run a browser to access the server-based central thin client application, they can be older machines that lack the system resources to run other desktop applications.

Thin Client Benefits Thin client computing offers several benefits to those organizations that choose to implement it. Lowber (28) iden- tifies the following benefits: • Reduced costs: Thin client computing reduces the amount of support required to install, maintain, sup- port, and upgrade software residing on desktop com- puters. If thin client computing devices are adopted, the use of these devices reduces the cost of desktop hardware support and repair in addition to reducing software support costs. • Reduced staffing: The reduction in desktop software and optionally hardware support requires fewer staff to provide that support and allows those staff hours pre- viously dedicated to desktop support—especially help desk and desktop support—to be reallocated to other duties. • Accelerated application deployment: Thin client appli- cations typically require only server-side installation, especially if they are designed for access with an Internet browser. This allows new applications to be installed without having to perform an installation on desktop workstations once the thin client infrastructure is in place. • Ease of remote access: Thin client applications acces- sible from an Internet browser promote remote access. • Increased client reliability: The use of a thin client hardware device provides a client hardware device that is more reliable than is the typical PC because of the absence of disk drives and other moving parts. • Reduced support: Thin client usage reduces or elimi- nates client-side hardware and software support. • Desktop standardization: The use of the thin client architecture provides control over the software that can be run on client workstations. Thin Client Limitations The thin client computing model does have several limita- tions that offset its benefits. The following is a list of issues that should be considered prior to deciding to implement thin client computing: • Increased server cost: Added server capacity will nor- mally be required for installing and operating the server- centric thin client application systems. If new servers are required, this may require a capital expenditure. • Increased server support costs: The concentration of processing capability and application software on the server increases the amount of effort required to sup- port the server environment and, therefore, server sup- port cost. • Increased software license costs: License costs for the software that enables the server-based thin client com- 9 puting and the license costs for the thin client applica- tions increase server software license costs. • Required expertise: Thin client computing requires skilled technical personnel who can install, configure, maintain, and operate the server-side thin client soft- ware applications and who can provide the ongoing sup- port for those applications and the servers in which those applications reside. • Scalability: The central servers must be able to accom- modate the processing load generated by the desktop users accessing the thin client applications residing on them. Servers must be sized to accommodate peak pro- cessing loads and must have an available upgrade path in the event of future increases in processing loads. • Network infrastructure upgrades: Thin client com- puting increases network usage by introducing server- to-desktop data transfers that did not exist under a client- server architecture. The increase in data transfer may require an increase in network bandwidth to deliver opti- mum performance to desktop users. This bandwidth increase may require network upgrades as part of the cost of system implementation. • Server and network dependence: Thin client applica- tions can only be used if the servers hosting those appli- cations are running and if the client workstations are connected to the network. • Inability to work offline: The thin client architecture requires continuous access to the server-based applica- tion from the desktop device in order to use the applica- tion. Server or network failures will result in end-user downtime. End users will be unable to work offline in a purely thin client environment. • Application performance: Delivery of application access over a network makes application performance dependent not only upon the central server’s perfor- mance, but also upon network performance. • End-user reaction: One of the major drawbacks to thin client computing is the reaction of PC users to thin client devices. Users accustomed to working with full- functioned PCs with resident software may consider the introduction of thin client systems as a reduction in their stature in the organization. Lowber (29) claims that 85% of end-user computing needs can be met with a thin client device and system. However, thin client devices are not appropriate for users who are classified as power users or for those who need to work offline. • Staffing: The inability to attract and retain the trained technical staff required to implement, maintain, and oper- ate server-based applications and the servers in which those applications reside is also an issue to consider. Thin Client Adoption Thin client adoption is driven by different dynamics than is the adoption of the ASP outsourcing model. Thin client

technology has been available for a number of years and appears to be well on its way to universal acceptance. Low- ber (30) forecasts that by 2005, 75% of enterprises will adopt thin client computing for at least some applications. Of these applications, 80% are forecast to be Windows Terminal Ser- vices installations implemented for specifically targeted applications used in specialized, task-oriented environments. Only 2% of enterprises are expected to convert completely to thin client architecture. The adoption of thin client computing is driven by cost-of- ownership considerations and the emergence of software designed for operation over a network. Thin client reduces the amount of software to be installed, maintained, and sup- ported on desktop workstations and provides a means to reduce the cost of that desktop support. Network software architecture has emerged in response to a demand for soft- ware that can run on a central server and that can be accessed across a network using an Internet browser. Network com- puting has become the preferred software architecture for many enterprises with an Internet browser as the client-side software for accessing central applications. Any organization with the technical resources and exper- tise to install and operate central servers, server-based appli- cations, and a network that allows desktop workstations to access the central applications can consider installing thin client applications internally. Large- and medium-size orga- nizations are those most likely to have the required infra- structure and expertise to implement, maintain, support, and operate thin client systems. Technically astute smaller orga- nizations may also consider thin client computing as an alter- native as well. Lowber (31) asserts that the best fit for thin client applications and thin client desktop devices is in areas in which the users perform structured, repetitive tasks such as data entry that are not creatively driven. From a Gartner Group survey published in April 2001, Lowber (32) reported that organizations that had previously had an unmanaged desktop computing environment achieved a 32% reduction in cost of ownership as a result of thin client implementation. An unmanaged environment is one in which central management and administration services have not been implemented and service and support for desktop work- stations requires that a technician physically visit the work- station. In contrast, organizations that had already imple- mented centralized desktop administration achieved only a 1% reduction in the overall cost of ownership. Lowber (33) identified savings resulting from a switch to thin client computing in both direct and indirect costs. Direct costs include those such as software maintenance and distri- bution, hardware maintenance and operation, staffing, and administration. Indirect costs include the costs of end-user self support, casual colleague support, casual and formal training, and file and data management. When moving to a thin client environment from a loosely managed PC environ- ment, indirect costs decreased by 90% on average; direct costs fell by 26%. When moving from a well-managed PC envi- 10 ronment, indirect costs fell by 32% and direct costs fell by 13%. However, cost reductions as a result of thin client imple- mentations are not guaranteed and must be examined on a case-by-case basis. Many of those organizations reporting the greatest cost savings from implementing thin client applica- tions were those that had not implemented industry best prac- tices in managing desktop workstations and applications. Barriers to Thin Client Adoption In spite of the cost and management advantages associ- ated with thin client computing, there are negative consid- erations that must be considered when contemplating thin client implementation. These include the following: • Lack of information technology expertise: The lack of sufficient expertise in the internal information tech- nology organization to implement, maintain, and oper- ate thin client applications and the servers required to host them is a consideration. • Capital expenditures: The cost of the capital expendi- tures required to license the thin client application sys- tems and the cost of acquiring the servers required to run those applications should be considered. • Cost of infrastructure upgrades: The cost of upgrading the internal network to provide the bandwidth required for the operation of thin client applications is an element to consider. • Application suitability: Not all applications and envi- ronments are well suited to the thin client computing model. Environments in which users employ applica- tions that require the performance of structured and repet- itive tasks are well suited to thin client computing. Those environments in which end users are engaged in creative activities and that require extensive data transfers from client to server are less well suited. • Inability to work offline: If users must be able to con- tinue working in the event of a network or server out- age, thin client is inappropriate. • Application portfolio: Generally, it is not possible to implement an organization’s entire application portfolio using thin client technology. This results in a mixed environment that includes both thin and fat client appli- cations that frequently must be accessed from the same client device. • Existing investments in hardware and software: The presence of applications that have not yet reached the end of their operational lifetime presents a barrier to the adop- tion of thin client computing. Unless the implementa- tion of thin client systems to replace the existing sys- tems is accompanied by a substantial economic benefit, the presence of existing systems will generally delay the consideration of thin client adoption until a replacement for the existing systems is required.

COMPARISON OF ASP AND THIN CLIENT The fundamental difference between the ASP service delivery model and thin client computing is that in the ASP case, application hosting and operation is outsourced to an external vendor, the ASP. Under the ASP model, the ASP vendor takes responsibility for all hardware and software issues, system implementation, operation, hardware and soft- ware maintenance and upgrades, performance monitoring, and user support. Under the thin client model in which sys- tems are hosted internally within an organization, the orga- nization itself assumes all of the responsibilities that would have been outsourced under the ASP model. Both the ASP and thin client models rely upon network access to the hosted systems. For the ASP model, the network may be either the Internet or some other private IP-based net- work. In the thin client model, the network is usually a pri- vate corporate network. ASP RISKS AND RISK MITIGATION This section and the next discuss the major risks associ- ated with outsourcing applications to ASPs and the risks in using thin client computing, respectively, and discuss tech- niques for mitigating each risk. The major risks associated with outsourcing applications to ASPs are as follows: • ASP failure or bankruptcy: A full investigation of the ASP financial position is required to assess whether the customer will be at risk of sudden loss of service caused by ASP failure. For publicly held ASPs, check Securi- ties and Exchange Commission filings. For all ASPs, ask for a full customer list and assess whether the ASP has a positive cash flow; assess whether the ASP is prof- itable. Determine whether the ASP relies upon venture capital or whether its business generates operating rev- enue. For privately held ASPs, ask for financial state- ments directly from the ASP; check trade publications and the Internet for news items mentioning the ASP. Pay particular attention to any items mentioning layoffs, restructuring, or problems raising capital. If the ASP has business partners, perform similar checks on each of the partners. • Loss of access to ASP applications: Ensure that the applications that the ASP operates are compatible with the customer’s internal computing infrastructure so that the customer can load and operate those applications if required. If the ASP has developed its own applications, negotiate the rights to license that software should the ASP exit the business. Alternatively, negotiate a code escrow agreement to ensure access to application source code in the event of ASP failure. • Interruption of service: To avoid interruption of service problems, ask the ASP for a list of reference accounts that 11 subscribe to applications and services similar to those under consideration. Check these references thoroughly. Ask for copies of the SLAs that apply to each of these references. Interview each reference account and inquire specifically about continuity of service—the ASPs track record in meeting the service levels specified in the SLA. Inquire about ASP handling of situations in which the SLA has not been met. When negotiating an SLA with the ASP, insert specific performance metrics that the ASP must meet. Also, insert provisions for performance reporting to the customer. Include provisions in the SLA for the use of a third-party performance-monitoring ser- vice to track delivery service levels or provisions for the customer to operate monitoring software at the customer site and tie penalty clauses in the SLA to the results of this monitoring. Ensure that all of the ASP’s business partners are covered by the terms and conditions in the SLA so that the ASP is accountable for failures by any one of its partners. • Loss or compromise of sensitive or mission-critical data: If data security is of paramount importance, the prospective customer may decide not to outsource the systems that process that data. If the decision is made to proceed with outsourcing, include in the SLA provisions for the periodic delivery of backup copies of critical data to the customer in a format the customer can inter- pret and process. Insert provisions into the SLA requir- ing storage of copies of data backups at off-site storage locations where the customer can access them. • Loss of control of applications: To avoid the loss of the expertise required to maintain and operate mission- critical systems, do not outsource those systems to an ASP—rather, keep them in-house. • Vendor lock-in: To avoid becoming trapped in a con- tract with a vendor who does not or cannot fulfill the terms of an agreement, include the terms and conditions in the SLA under which the customer may unilaterally terminate the contract with the vendor. Specifically state the vendor’s obligations under such a termination for returning data, providing access to software application licenses or source code, and any other services that may be required during the course of termination. In addi- tion, the customer should develop a contingency plan for transferring its application to another ASP, into its own organization, or to another type of service provider. • End-of-engagement problems: All business relation- ships eventually come to an end. Plan this separation initially and include specific provisions in the SLA that address these end-of-relationship processes. • Quality-of-service risks when accessing applications over the Internet: ASPs have no control over the per- formance of the Internet. To minimize this risk, deal only with ASPs that employ private networks as well as the Internet and in which either the ASP or one of the ASP’s partners will be accountable for network performance.

• Failure to meet specified service levels: Check the ASP’s prior service-delivery performance with existing ASP customers. Investigate how the ASP delivers service and how the ASP handles customer problems and increases the priority given to problems remaining unre- solved after fixed periods of time. Determine exactly what service levels are required and specifically insert those levels and the metrics to be used to evaluate the levels into the SLA. Include application availability, application response time, any other technical performance criteria, and escalation procedures for problem resolution. • Costs: Investigate the ASPs business model and cost structure thoroughly. Investigate any one-time initial set- up and conversion charges, assess monthly subscription fees, and examine the basis for those fees. Investigate how fees change in response to increases and decreases in the number of users and to increases and decreases in transaction volumes. THIN CLIENT RISKS AND RISK MITIGATION Unlike the case with ASPs in which many of the potential risks are in dealing with an outsourcing vendor, all the risks in thin client usage are internal to the organization itself: • Inability to attract and retain the technical staff re- quired to implement, maintain, and operate the thin client systems; • Resistance by traditional PC users; • Unavailability of budgets for infrastructure improve- ments, servers, and software licenses; and • Availability of operations and maintenance budgets. 12 ASP AND THIN CLIENT USAGE IN THE TRANSIT INDUSTRY The following section provides a summary of the survey conducted as part the e-Transit research project (TCRP Proj- ect J-09, Task 1). A more-detailed summary is provided in Appendix B. The goal of the survey was twofold: first, to determine the extent to which transit agencies are aware of and understand the concepts of ASP outsourcing and thin client computing; and second, to assess the degree to which transit agencies currently use ASP outsourcing and thin client com- puting and the effects that use has had on business operations. The survey was conducted through a combination of tele- phone interviews and e-mail solicitations. A total of 64 tran- sit agencies were contacted; of these, 10 responded—a 15% response rate. Table 2 provides a summary of the survey responses. Of the survey responses, 70% of respondents indi- cated that they were familiar with the ASP business model and ASPs in general while 30% were not. Currently, 30% of the respondents use ASPs. Of those respondents who do not currently use ASPs, 29% had considered using ASPs but elected not to do so, and 71% had not given any considera- tion to using them. The survey showed that 50% of the respondents were familiar with thin client computing and that 20% currently use thin client systems. Of those respon- dents not currently using thin client applications, none had previously considered their use. The agency interviews provided a few additional insights. The transit agency institutional setting has a direct impact on agency consideration and awareness of ASP services and thin client systems. Some transit agencies are units of local government and obtain their computing services from some TABLE 2 Survey response AS P Are you fam ilia r w ith AS P ? 7 70% 3 30% D o you currently, o r have you previo usly, used an AS P ? 3 30% 7 70% If N O , have you considered us ing an AS P ? 2 29% 5 71% Th in C lient Are you fam ilia r w ith "Th in C lient"? 5 50% 5 50% D o you currently, o r have you previo usly, used a "Thin C lient"? 2 20% 8 80% If N O , have you considered us ing a "Thin C lient"? 0 0% 8 100% Y es N o Y es N o SOURCE: TCRP Project J-09, Task 1.

other local government agency. In these cases, the transit agency, either by choice or by statute, has effectively out- sourced its applications to the computing service–providing agency and is not directly responsible for providing its own application system services. If the providing agency happens to provide access to the outsourced applications over a net- work, then that agency functions in a manner similar to an ASP in providing computing services to the transit agency. If the applications provided to the transit agency are server- based and if the transit agency employees access those appli- cations through a network computer, thin client computing device, an Internet browser, or other minimal client-side soft- ware application, then the service-providing agency is prob- ably employing thin client applications. Although lowering costs is a benefit claimed by both the ASP and the thin client computing models, reducing exist- ing operating costs is not a major objective when agencies consider ASP outsourcing or thin client applications. The 13 major considerations are obtaining a new application service with the shortest possible lead-time and in the most eco- nomically advantageous manner possible. Major decision factors include the time required to implement the solution; the initial investment required; ongoing operating costs; and the rapid achievement of business objectives, which deliver a return on investment. A further consideration is that by out- sourcing applications to an ASP, the customer agency is able to concentrate more of its internal staff resources on its pri- mary mission—public transportation—rather than on what is viewed as a peripheral service—software application support. Those agencies currently using ASP services currently subscribe to financial and accounting applications and trav- eler information services. There appear to be very few ASP applications available that are aimed directly at the transit industry. The applications available are limited to vehicle- fleet management and maintenance, traveler information, and safety-incident reporting.

Next: Chapter 3 - Interpretation of Findings »
e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines Get This Book
×
 e-Transit: Electronic Business Strategies for Public Transportation, Volume 2, Application Service Provider Implementation Guidelines
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Report 84: e-Transit: Electronic Business Strategies for Public Transportation, Volume 2: Application Service Provider Implementation Guidelines, presents the results of an investigation into the use of application service providers and thin client computing technologies by transit agencies.

READ FREE ONLINE

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!