National Academies Press: OpenBook
« Previous: Chapter 2 - Findings
Page 14
Suggested Citation:"Chapter 3 - Interpretation of 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 14
Page 15
Suggested Citation:"Chapter 3 - Interpretation of 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 15
Page 16
Suggested Citation:"Chapter 3 - Interpretation of 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 16
Page 17
Suggested Citation:"Chapter 3 - Interpretation of 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 17
Page 18
Suggested Citation:"Chapter 3 - Interpretation of 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 18
Page 19
Suggested Citation:"Chapter 3 - Interpretation of 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 19
Page 20
Suggested Citation:"Chapter 3 - Interpretation of 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 20

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.

14 CHAPTER 3 INTERPRETATION OF FINDINGS ASP AND THIN CLIENT VALUE PROPOSITION Across industry in general, the ASP business model has achieved early adopter acceptance as a legitimate option for obtaining outsourced computing services. Survey findings show that between 11% and 18.5% of respondents already subscribe to ASP services, and analyst predictions are for continued expansion of ASP use in the future. The major value proposition cited for the selection of an ASP is the return on investment that results from being able to achieve organizational business objectives with the help of outsourc- ing computing services rather than hosting those services internally or obtaining those services from a more traditional outsourcing vendor. This return on investment is distinct from pure cost reduc- tion. Few ASP customers have chosen to transfer applica- tions hosted internally to the ASP in order to reduce costs. ASPs generally claim that subscribing to their computing ser- vices rather than operating applications internally can lower an organization’s total cost of application ownership. This claim—although widely accepted as a fundamental tenet of the ASP computing model—has not yet been demonstrated in any conclusive way. Although ASP customers describe savings, Netto (34) points out that most businesses do not understand their costs of application software service opera- tion and delivery and rely upon educated guesswork to esti- mate their pre-ASP costs. Even if the businesses understand their internal cost structures, those structures are typically not broken down to the individual application level. Organiza- tions may know how much it costs to deliver overall desktop computing service to their employees, but may not know the cost of specific applications. Because the ASP model is based on subscribing to computing services one application at a time, accurate cost comparisons are generally not possible. Some observers question whether the full cost of sub- scribing to ASP application services is actually lower than the total cost of provisioning the same application service internally when full life-cycle costs are calculated. The ques- tion remains unanswered partly because the ASP computing model is too new to have allowed the collection of cost data over a full system life cycle. There is the additional problem that many organizations do not invest in tracking their inter- nal computer system operating costs. There is agreement, however, that subscribing to ASP services avoids the sub- stantial initial investment in hardware, software licenses, and customization services that normally accompany in-house application provisioning; subscribing also allows a more rapid implementation than is usually possible internally. These factors provide the opportunity for the business to benefit from the new service sooner than would otherwise be possible and to achieve an earlier payback. IDC (35) documented the results of a study in which ASP customers reported an average return on investment over 5 years of 404% to 280% for mission-critical applications and 636% for non-mission-critical applications. These results were achieved on an average initial investment in ASP services of $399,000 and on an average investment of $4.2 million over the life of the investment. The average pay- back period was 1.33 years. The ASP service–provisioning model gave the organiza- tions that participated in the IDC study the opportunity to add some significant new computing service that had an immedi- ate positive impact on their business results with the minimum up-front investment. The strengths of the ASP model are its ability to deliver a new computing service in a short span of time while requiring little, if any, infrastructure investment on the part of the prospective customer, thus allowing the cus- tomer to participate in the benefits of state-of-the-art appli- cations without a large initial investment. In spite of its benefits, the ASP industry is in a state of flux and many current ASPs may not survive. Sweeney (36) reported Gartner Group’s forecast that more than 60% of ASPs in business in mid-2000 would fail by the end of 2002. Hollerbach (37) asserts that this failure rate is symptomatic of new industries and that the failure of weaker competitors is beneficial in the long run. In the short term, this poses a serious problem for prospective ASP customers, who must expend time and energy assessing the financial health of their prospective service providers in addition to evaluating their service offerings. Thin client computing shares a technological base with ASPs—the server-centric application accessed remotely over a network from a client-side Internet browser or other minimal client-side application. From this point, the models of these two service-provisioning schemes diverge. The ASP model outsources application hosting, maintenance, operation, and support. Initial set-up and implementation of the application are the responsibility of the ASP. In the thin client model, all

hosting, maintenance, support, and operation responsibilities remain inside the organization. The change that an organiza- tion makes in adopting thin client computing is that applica- tion processing moves from the desktop workstation to a cen- tral server, allowing desktop operations to proceed with a less capable or “thin” desktop software application. The value proposition in thin client computing comes in the shift of technical support costs from the desktop workstation to a central server. With less software on the workstation, less software support is required, which translates into less support cost. Less client-side hardware capability is needed, allowing additional value to be derived from older PCs that can be used to support client access to thin client applications. If thin client devices are used in place of PCs, client hardware reliability increases, providing savings in the form of reduced client hard- ware maintenance. Central server support does increase under thin client computing, and additional network infrastructure may be required. Lowber (38) finds that the implementation of thin client computing in an environment in which desktop workstations are unmanaged results in a 32% cost savings. The introduction of thin client computing into an environment in which desktop workstation management and support has been automated yields only a 1% cost savings. The current trend of designing applications to operate over the Internet or over an internal IP network is promoting thin client computing in the guise of web-centric or web-enabled computing. Web-centric software is designed to have its user interface presented as a web page that can be accessed using an Internet browser. Centralized application and database servers reside behind the web server to provide the actual application processing and associated data storage. This struc- ture is the thin client software architecture. TRANSIT INDUSTRY VALUE The transit industry can share the same benefits as other types of customers of ASP services. Unlike ASP customers in other industries, it is unlikely that the implementation of a new application will result in the kinds of return on invest- ment that IDC (39) reported as a result of implementing ASP services. The return-on-revenue results cited by IDC were achieved because of the ability to exploit new business oppor- tunities and to tap new sources of revenue generated by rapid ASP application implementation. Transit agency revenue sources are generally limited to subsidies, fare-box receipts, and advertising revenues, with little opportunity for system- driven increases in revenue. However, when a transit agency is confronted with the need to implement a new service to the public, when an existing application requires replacement, or when the agency would like to add some new computing ser- vice, the ASP computing model that allows application imple- mentation without capital investment and with minimal up- front cost may offer a better results on investment than do other alternatives and may be an attractive alternative when considered within the context of the agency’s overall budget. 15 There are very few ASPs that offer applications focused on the vertical transit industry, so there are limited opportu- nities for ASP usage for transit-specific applications. How- ever, there is a wide range of general business applications available. ITAA (40) showed that the most popular applica- tions for outsourcing to ASPs include e-mail, accounting and financial processing, office productivity software, and human relations management. These types of applications probably represent the best opportunity for transit agency use of ASP outsourcing. The case for automatic reductions in cost of ownership has not been proven as a result of the implementation of ASP- based applications. Outsourcing existing applications to an ASP on the theory that cost savings will accrue would be an ill-advised experiment. However, if a new computing service is required or if an existing application reaches the end of its operational life and must be replaced, then outsourcing the application to an ASP should be considered as one of the alternative means for provisioning that service. At that point, assuming that the agency is willing to consider outsourcing the application, it should select the provisioning alternative that will give it the greatest return on its investment and will provide the greatest benefit to the agency whether that agency is hosting the application internally or outsourcing it to an ASP or to another type of outsourcing vendor. ASP OUTSOURCING GUIDELINES The choices available for provisioning a new computing service are to host the application providing the service inter- nally, to provision the service with an application provisioned by a traditional outsourcing vendor, or to outsource the appli- cation to an ASP. No one approach is inherently superior to another, and no one approach will necessarily provide a greater return on investment to the organization than will the others. Organizational Readiness Prior to conducting an analysis of available ASP applica- tions and services, a transit agency should perform a self- assessment to determine whether the agency is ready to con- sider outsourcing computing applications to an ASP. The following guidelines are intended to assist in determining when it is appropriate to consider the option of outsourcing application services to an ASP: • Openness to ASP outsourcing: Is the organization open to the concept of outsourcing applications to ASPs? One of the barriers to ASP usage is internal resistance to the fundamental concept. If this resistance is too strong, other alternatives should be considered. • Level of technical expertise: If information technology is not considered a core competency within the organization

or if the specific competency required for the desired application is not present in the organization, then out- sourcing to an ASP may be a means of compensating for the lack of internal expertise. • Technical resource availability: If the organization has internal technical expertise but if that expertise is fully occupied with current duties and cannot support an additional application, then ASP outsourcing can be a means to augment overburdened internal resources. • Staff retention difficulties: If the organization has dif- ficulties attracting and retaining skilled information technology staff, outsourcing additional applications to an ASP may be an alternative. It may be inadvisable to add support for additional applications to an existing workload in the information technology department when it will prove difficult to maintain staffing levels. • Acceptance of standard applications: Use of an ASP is an option if the organization is willing to use the ASP application under consideration with minimal or no customization or modification. ASPs prefer to deliver unmodified access to standard applications to their customers. Some ASPs do perform application cus- tomization, but that typically raises the start-up costs and subscription fees and makes future upgrading of the application software more difficult and costly. • Minimal integration requirements: Integrating out- sourced applications to other applications hosted by the same or another outsourcing vendor or to applications hosted at the customer’s operating site increases the com- plexity of services requested by the ASP, decreases the flexibility of the implemented solution, and erodes the cost case for ASP usage. Extensive integration require- ments may be better satisfied internally. • Network connectivity: If the organization already pos- sesses a high-speed networking infrastructure and high- speed connection to the Internet, only minimal infra- structure upgrades will be required to implement ASP service. • Mission criticality: Outsourcing mission-critical appli- cations raises the issue of loss of control of key operat- ing capabilities to the outsourcing vendor. Considering only non-critical applications minimizes this concern. • Data security: Concerns over theft or loss of critical data entrusted to an ASP can be approached by limiting consideration of ASP outsourcing to those applications that do not require data to be stored by the ASP. Mission- critical applications can be excluded altogether from con- sideration for ASP outsourcing. • Rapid deployment: Rapid application is required, but internal resources are unavailable to implement the application. ASP resources can be used to implement and host the application. If required, the application can be brought in-house at a later date. • Lack of capital budget: Lack of capital investment funds may prevent the acquisition of the servers, soft- 16 ware licenses, and infrastructure upgrades that might be required to implement a new application. Implementa- tion of the application with an ASP should be possible for a much lower initial cost than would be incurred if the application were to be provisioned internally. ASP Selection Guidelines When an agency has determined that it is willing to seri- ously consider ASPs as computing service providers, it can then undertake an investigation of available ASP alterna- tives. As described previously, there are a number of risks associated with outsourcing applications to external providers. In the current ASP market, these risks are exacerbated by the very real risk of ASP financial failure and by the general lack of a proven history of service delivery in an industry that is only a few years old. Bolding (41), Gantz (42), Sartain (43) and Whalen (44) cite concerns to investigate when choosing an ASP. The following is a list of guidelines to assist in minimiz- ing the risk associated with selecting an ASP to host an out- sourced application: • Identify the business function requiring support. • Identify the application(s) desired to support the busi- ness function. • Determine whether the organization will accept alterna- tives to the desired application. • Determine whether the organization will accept a stan- dard version of an application or whether the organiza- tion will insist upon some level of customization. • Determine what types of end-user access to the applica- tion the organization will require. • Determine what results the organization expects from the application and in what form those results are required (online interaction and information displays; reports; interfaces to other systems hosted by the ASP, the orga- nization itself, or a third party). • Determine whether integration with other systems will be required. • Specify minimum application performance levels, in terms of the business processes to be supported. • Specify the specific performance metrics that must be met. • Establish data-storage requirements including initial data volumes and projected growth in data volumes. • Establish minimum organizational requirements for application recovery following a disaster.

• Determine how many concurrent users the application must support. • Estimate the cost of provisioning that application inter- nally, including all costs for hardware, software licenses, development, application customization, operations, maintenance, technical support, help desk support, and training that may be associated with implementing the application. • Determine the schedule that must be met for application deployment. • Select ASPs that offer applications capable of support- ing the organization’s business functions and associated supporting services. • Screen the list of ASPs based on the established organi- zational requirements and ASP capability to satisfy those requirements. • Assess the stability of the ASP’s management team. • Examine the ASP’s financial statements to determine whether the ASP has the staying power required, look for a steady increase in revenue over time as a sign of health, and look for the capability to fund operations from cur- rent period revenues rather than from venture capital. • Examine the ASP’s business plan and determine whether the ASP has a sustainable business offering. • Determine whether the ASP has business partners and ensure that each partner is financially sound and that the primary ASP is accountable for the performance for all business partners. • Examine the quality and stability of the ASP’s technical infrastructure. • Determine how many data centers the ASP has, the location of each, and which facility will provide hosting services. • Inspect the ASP’s physical facilities. • Examine the ASP’s disaster recovery plan and compare that plan with disaster recovery needs. • Ensure that ASP facilities are not in disaster-prone locations. • Ensure that the ASP has high-bandwidth connections of at least 45 Mbps to a minimum of two Tier 1 Internet backbone carriers if delivering application access over the Internet and similar connectivity to at least two pri- vate network carriers if using a private network. 17 • Check computing platforms supported and determine whether the platforms used by the ASP are compatible with those supported internally—this ensures that if it becomes necessary to bring the application in-house, hardware compatibility and support are not issues. • Check the ASP’s ability to scale its computing and com- munications infrastructures. • Check the ASP’s policy on upgrades to commercial soft- ware applications and assess whether the ASP’s policy will match the customer’s expectations for the implemen- tation of upgrades to commercial software applications. • Check the ASP’s policy on computing hardware upgrades. • Investigate the ASP computing and communications redundancy capabilities. • Ensure that the ASP has alternative electrical power facilities, preferably power feeds from at least two dif- ferent electrical substations and a backup power system. • Examine the ASP’s security capabilities in detail, both physical security and information security. • Determine how many other customers the ASP has for the application services to be subscribed, what the fore- cast is for subscription growth for those services, and how the ASP plans to scale its infrastructure to handle the projected growth. • Determine what applications the ASP currently offers and what applications the ASP plans to add to its portfo- lio in the future; also determine whether the ASP plans to drop or replace applications in its current portfolio. • Determine whether the ASP has the capability to inte- grate hosted applications with other applications hosted at its facilities, with applications hosted at a customer’s facility, and with applications hosted at a third party’s facilities. • Inspect security arrangements for dedicated servers. • Check ASP procedures for controlling access to dedi- cated servers. • Check ASP procedures for controlling access to cus- tomer data. • Check ASP customer references, preferably customers with similar organizational characteristics and who sub- scribe to applications and services similar to those under consideration. • Check the ASP’s history for application service delivery.

• Check the ASP’s record for maintaining quality of ser- vice and meeting the provisions specified in SLAs. • Check the ASP’s record of responding to customer prob- lems and the ASP’s record for resolving those problems. • Determine what customer support services the ASP offers and how those services are delivered. • Assess the accessibility of the ASP’s support staff, deter- mine when support is available, and assess the ASP’s pro- visions for providing additional levels of support. • Check the ASP’s staffing levels for applications sup- port, system administration, security, and customer sup- port; determine whether the staff are ASP personnel or contractors, the level of staff expertise, and the rate of staff turnover. • Investigate all of the ASP’s partners—some ASPs known as “aggregators” function as general contractors and sub- contract hosting, software maintenance, development, operations, and security to various business partners; if this is the case, investigate each partner for organiza- tional stability and viability as though that partner were the primary ASP—a failure by any partner could jeopar- dize the ASP’s ability to continue to deliver service. • Investigate the ASP’s pricing structure and billing poli- cies; identify one-time costs for establishing service, data conversion, user training, software licensing, and infra- structure implementation; identify ongoing application subscription fees and any other fees that will be billed on an ongoing basis. • Examine the ASP’s standard SLA terms and conditions. • Determine the ASP’s willingness to negotiate customized SLA terms and conditions. The depth of investigation required will depend upon the crit- icality of the application to be outsourced. An extremely thor- ough investigation is required if the application is mission- critical. On the other hand, if the application is non-critical or perhaps even non-essential, a more cursory investigation may suffice. The depth required has to be decided on a case- by-case basis. Using the guidelines above, the agency should determine what criteria are important to it in selecting an ASP and develop a weighting factor for each criterion. The evaluating agency will have to select a scoring mechanism for use in rat- ing the ASPs. The ASPs under consideration can then be rated against each of the selected criteria, and an overall ranking of ASPs can be calculated. In addition to this rating exercise, the agency should conduct a full economic analysis of each alternative under consideration, whether they are 18 ASPs or other alternatives. Most ASPs offer an online eco- nomic evaluation tool. It is recommended that the agencies develop their own cost models to ensure proper consideration of all of the cost factors that will affect the decision. This will also ensure that any non-ASP solutions under consideration are treated appropriately. After evaluating criteria and per- forming economic analysis, the agency will be in a position to make a well-informed business decision to select a provider for its software applications. Managing the ASP Business Relationship The key elements in managing the business relationship with an ASP outsourcing vendor are due diligence in inves- tigating the ASP prior to subscribing to the ASP’s service and the negotiation of a comprehensive SLA. Due diligence in researching the ASP’s financial condition minimizes the risks of having the ASP’s business fail during the contracted service period. Due diligence in checking customer refer- ences and the ASP’s history of service delivery will mini- mize the risk that the ASP cannot fulfill its obligations under its SLAs. The primary tool available to the ASP customer for managing and controlling the business and service delivery relationship with an ASP is the SLA. All ASPs have standard SLAs that may be acceptable for non-critical applications that have little impact on the organi- zation’s operations. If, however, the application outsourced to the ASP is mission-critical or if critical or sensitive data must be entrusted to the ASP, then a standard ASP SLA may not address all of the issues that the customer organization may wish to address. ITAA (45) has published a set of ASP SLA guidelines that outline a basis for crafting and negotiating a specific SLA with an ASP. There are a number of critical issues that can be used to enhance the basic ITAA SLA out- line. These issues are the following: • Data ownership: The SLA should specifically state that any data entrusted by the customer to the ASP remains the property of the customer and that the customer retains all rights to that data and assigns no rights to the ASP. This is particularly important if the data are mission-critical or sensitive. The SLA should grant access to the data to the customer at any time and should detail the data-backup and data-storage procedures that the ASP will perform. The customer should negotiate the periodic delivery of copies of data backups either to the customer’s facility or to an agreed upon storage location where the customer has unimpeded access to the data. These backups should be in a standard, readable format. The agreement should also detail the regular storage of backups in an off-site storage facility where the cus- tomer has access to the data. • Escalation procedures: The SLA should detail the pro- cedures for raising problems to higher levels of priority when rapid solutions to customer problems are not forthcoming. This procedure should specify procedures

for both the customer and the ASP and should specify clear timeframes for moving to each level of escalation. • Performance metrics: The SLA should include spe- cific, quantified metrics to be used in measuring service delivery. Specific metrics should be included for each application or support service that the customer consid- ers critical to business operations. These metrics may include application response time; network response time; application service delivery in business terms (e.g., able to invoice customers from 9:00 A.M. to 5:00 P.M., Monday through Friday); elapsed time to respond to customer trouble calls; elapsed time to resolve cus- tomer problems; and transaction throughput. • Application availability: The hours of application ser- vice availability should be listed specifically. This spec- ification should account for any downtime planned by the ASP for system maintenance activities. Availability should be specified only for those hours when access is actually needed. • Performance monitoring: The customer should include provisions in the SLA requiring the ASP to account for the quality of service delivery. This is a necessary mea- sure for ensuring service delivery for mission-critical systems. Both Bolding (46) and Betts (47) recommend requiring the ASP to provide monthly reporting on ser- vice delivery against the metrics specified in the SLA. They also suggest negotiating the right to use third-party monitoring services to independently monitor ASP ser- vice delivery or to use third-party software at the cus- tomer’s site to monitor performance. • Rights to software: The customer should negotiate the rights to any software custom developed by the ASP or any software developed for the customer by the ASP in the event of ASP failure. Should the ASP go out of busi- ness, the customer may need this software to be able to re-host the application provided by the ASP either inter- nally, with another ASP, or with other outsourcer. The customer should negotiate a code escrow agreement for any developed code and the rights to purchase any asso- ciated licenses. • Performance penalties: Liquid penalties should be negotiated in the event the ASP fails to fulfill service delivery obligations stated in the SLA. These penalties should impact ASP revenue either in the form of sub- scription fee rebates or in reduced future payments. Betts (48) recommends penalties in the range of 5% to 15% of the monthly subscription fee. • Termination conditions: All business relationships ter- minate at some time. At termination time, issues deal- ing with data and software ownership, transition to a new service provisioning environment, and general ser- vice termination must be resolved. It is recommended that these issues be identified and addressed during the negotiation of the initial SLA so that when termination occurs, both the ASP and the customer know exactly what each owes the other and what obligations each has 19 during the close-out phase of the business relationship. These conditions should apply both to the normal ter- mination of subscription services and to termination for non-performance, non-delivery of service, or other vio- lation of the SLA. • Termination for cause: The customer should include provisions in the SLA that describe the conditions under which the customer may unilaterally terminate the busi- ness relationship with the ASP. THIN CLIENT GUIDELINES Unlike the decision to use an ASP, the decision to use thin client applications does not include a decision to outsource application hosting to an external provider; therefore, the investigation required when choosing an external ASP is unnecessary. The decision to use thin client technologies can be based entirely upon internal organizational capabilities and the organization’s internal business and economic objec- tives. The following are guidelines when considering the use of thin client applications: • Server infrastructure: Thin client applications are server-centric and concentrate application processing and data storage on central servers. Either the required servers must already be in place, or a budget must be available to upgrade existing servers to host the antici- pated thin client applications or to acquire new servers for that purpose. • Thin client software costs: Funding must be available to cover the cost of the software licenses for the thin client applications, for any client-side software required for accessing the thin client applications, and for any operating system–level software necessary to enable thin client computing. • Staff expertise: A shift to thin client computing shifts support requirements from desktop workstations to cen- tral servers. The organization must either already have staff skilled in server and central application support or have good prospects for attracting and retaining the staff necessary to support thin client applications. • Network infrastructure: Either the organization must have in place a network with sufficient capacity to sup- port accessing thin client applications hosted on cen- tralized servers, or it must incur the cost of installing new network infrastructure or upgrading existing infra- structure to provide the needed network capacity. • Offline usage: Thin client applications can only be accessed if the network is accessible and if the central servers hosting the thin client applications are running. Thin client applications are not suitable for supporting workers who need to access applications while not con- nected to the network or when either central servers or hosted applications are not available. • Workstation usage: Thin client applications are most appropriate in supporting applications used during struc-

tured, repetitive, transaction-oriented tasks and are not for tasks requiring creative activity. Thin client applica- tions are also not good candidates to support computation- intensive processing or data-intensive processing. • Management environment: Organizations that have implemented industry best practices for desktop work- station management will have a reduced opportunity for realizing cost savings from converting applications to a thin client architecture because they have already achieved most of the benefits and savings from work- station standardization and central management. • Cost analysis: Consideration of converting to thin client applications should be supported by a cost analysis that compares the costs of hardware, software licenses, main- tenance, operation, technical support for servers and 20 desktop workstations, help desk support and staff train- ing, server acquisition and upgrade, thin client device acquisition and upgrading, and network capacity instal- lation or upgrading. • Thin client device usage: Thin client devices are suit- able desktop devices for supporting structured, repeti- tive tasks and for use as PC replacements in hostile envi- ronments such as high-traffic areas, retail operations, shop floors, and factory environments. • Web-enabled applications: Web-enabled applications are inherently thin client applications. Plans to introduce the use of web-enabled applications are, in effect, plans to introduce thin client applications that use an Internet browser as the client-side software.

Next: Chapter 4 - Recommendations »
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!