3
The Social Security Administration’s Information Technology—Present and Future

As the Social Security Administration’s (SSA’s) workload increases, technological change continues and brings with it a corresponding increase in the online service expectations of at least some segments of its clientele. Unlike earlier retirees, the baby boom generation is more computer-literate and Internet-savvy and is likely to retain these traits after reaching retirement age.1 Thus, it should be expected that the SSA’s various beneficiaries and other user communities will continue to be adept at keeping pace with these technological changes. Broader and more systematic attention to technical and social trends will be warranted. Further, to achieve a forward-looking electronic services strategy in any organization requires an understanding of the organization’s current technological capacities coupled with an understanding of trends in important and relevant information technology (IT) and user expectations. This chapter provides a high-level assessment and set of impressions regarding the SSA’s current IT infrastructure, its database technology and conversion strategy in particular, external technological trends, a brief overview of user expectations and projected demographics, and how they all can affect prospects for effective electronic services, now and in the future.

1

See the discussion of Pew Internet and American Life Project survey data later in this chapter.



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment 3 The Social Security Administration’s Information Technology—Present and Future As the Social Security Administration’s (SSA’s) workload increases, technological change continues and brings with it a corresponding increase in the online service expectations of at least some segments of its clientele. Unlike earlier retirees, the baby boom generation is more computer-literate and Internet-savvy and is likely to retain these traits after reaching retirement age.1 Thus, it should be expected that the SSA’s various beneficiaries and other user communities will continue to be adept at keeping pace with these technological changes. Broader and more systematic attention to technical and social trends will be warranted. Further, to achieve a forward-looking electronic services strategy in any organization requires an understanding of the organization’s current technological capacities coupled with an understanding of trends in important and relevant information technology (IT) and user expectations. This chapter provides a high-level assessment and set of impressions regarding the SSA’s current IT infrastructure, its database technology and conversion strategy in particular, external technological trends, a brief overview of user expectations and projected demographics, and how they all can affect prospects for effective electronic services, now and in the future. 1 See the discussion of Pew Internet and American Life Project survey data later in this chapter.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment INFORMATION TECHNOLOGY INFRASTRUCTURE The IT infrastructure of an organization encompasses hardware, software, databases, applications (including Web services) along with security processes and, for the purposes of this report, software-development policies and practices. This section briefly describes the committee’s assessment of various of these parts of the SSA’s IT infrastructure. It focuses particularly, however, on the underlying databases and database architecture, as these are especially key components of any effective electronic services strategy and application suite (see Box 3.1 for more on the centrality of databases to electronic services provision).2 Hardware Infrastructure The SSA organizes its hardware and IT infrastructure3 in three tiers: local/departmental, remote operations control centers (ROCCs), and headquarters. There are numerous local offices; six ROCCs located in Pennsylvania, New York, Illinois, Missouri, California, and Alabama; and one headquarters facility, the National Computer Center (NCC), located in Baltimore, Maryland. The hardware in the local offices consists primarily of personal computers (PCs) running the Microsoft Windows operating system, plus a local file server, all connected using standard local area network (LAN) technology. Desktop machines are upgraded regularly on a 3- or 4-year cycle. In addition to access to the local servers, local PCs also have access to the servers at the ROCCs through virtual private network (VPN) connections. The ROCCs run standard Unix servers from a mix of vendors and again are connected using standard LAN technology. The bulk of the SSA programmatic applications run at the NCC. The NCC hardware configuration is typical of a large financial services organization. It consists of a variety of hardware configurations, including midsized servers running both Windows and Unix with their own storage volumes, six IBM Parallel Sysplex mainframe systems, and a large data-storage farm implemented using storage area network (SAN) technology from EMC Corporation. Most of the programmatic data sets reside on the 2 Note that this overview is of necessity brief and based on comparatively small amounts of data and input. A comprehensive assessment of such a large organization’s IT infrastructure was outside the scope of this committee’s activities; the committee tried to focus particularly on the capabilities and functionalities related to electronic services provision. 3 Factual details about the SSA’s IT infrastructure in this section are from Social Security Administration, Information Resources Management Strategic Plan (2005), especially pp. 85-224 (hereafter cited as Social Security Administration, Information Resources Management Strategic Plan (2005)), available at http://www.socialsecurity.gov/irm/IRM_2005.pdf, accessed June 20, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment BOX 3.1 Modern Database Technology Is Critical to the SSA The rapid growth in the development of large-scale electronic services has been strongly supported by rapidly growing understanding of the anatomy of such services and by advances in supporting the development and deployment of their component parts. The data-management component is the most critical component—online services 24 hours a day, 7 days a week (24/7) are as dependent on the data-management component as an automobile is on its engine. Virtually any information technology (IT) application, whether it is in the public or the private sector, is about data. In the case of the Social Security Administration (SSA), the central data comprise the information that the SSA has about its core constituents—essentially every person and business in the country. That is at the very core of the agency’s mission—it keeps track of everyone: who they are, who their families are, where they live, what they have earned each year, what they or their employers on their behalf have paid to the SSA. This is all data. It is what drives everything that the SSA does. All of the SSA processes and services are centered on those data—they read the data, they record changes to it, they note what is happening to it, and so on. The data are the model that the SSA has of everyone—they are its computerized model of the world that the SSA exists to manage. Electronic services must rely pivotally on appropriate database services. Requested services may simply require access to up-to-the-minute information, in which case this must be available from an archival data store that is capable of receiving and processing updated information in real time. The privacy of this information, however, must be carefully guarded, and its security from loss or tampering must also be ensured. These demanding requirements must be supported by the archival data-storage component. The services requested may also entail modification of archival information (for example, adding in the latest Social Security employer deposit, or logging the payment of a monthly benefit). Here too, the data-storage component is relied on for assuring the provision of the appropri- EMC storage arrays so that they are available from any of the mainframes. All of the machines are interconnected using standard LAN technology, which is protected from outside access by a firewall. The SSA’s continued dependence on Customer Information Control System (CICS), Virtual Storage Access Method (VSAM), and the crucial Master Data Access Method (MADAM) software currently restricts the SSA to IBM mainframes for the bulk of its programmatic data. As discussed below, migrating these data to a relational database system would offer the SSA an opportunity to consider hardware alternatives with more performance at a much lower cost. For example, since the mid-1980s, the software company Teradata has provided the retail and banking sectors with scalable database technology based on the use of scalable servers constructed from commodity hardware components. In 2004, Wal-Mart had

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment ate capabilities. Thus, the data-storage component must be capable of immediate updating as well. The challenges entailed in developing such data stores clearly are considerable: they must be incorruptible, persistent in perpetuity, even in the face of attempts to corrupt them, and must also support being able to be updated in real time. Considerable research and commercial development, however, have led to the availability of such databases. Support for 24/7 access to electronic services requires that all components be capable of providing appropriate support. Thus, clearly, the services promised by an inviting user interface can only be provided if an appropriately powerful database is a component of the application. Today, though, the SSA is using a decades-old database system. The Master Data Access Method (MADAM) is based on a 40-year-old proprietary record-based file/index system that ran on IBM 360s and still runs on their modern mainframe hardware. The fact that the SSA’s equivalent of the “corporate jewels” are stored using decades-old technology is alarming and needs to change. As Chapter 3 in this report points out, modern database technology can readily manage the amount of data that the SSA has. Moreover, the number of IT professionals having the background and skills to maintain the current MADAM database and surrounding applications is very small, and dwindling. Few people today know how to deal with mainframes and the kind of software that MADAM is based on. In the relatively near future, there may be none. By contrast, Structured Query Language (SQL) developers are ubiquitous. The SSA needs to move forward quickly in this area so that it can develop new services and processes using the many skilled developers and system administrators and performance tuners available in the modern job market. Otherwise it will continue to operate in the “old days” of multi-hour batch updates and backups, fragile software that few know how to tune or manage, and so on. The SSA will not be able to provide effective 24/7 services that way, nor will it be able to add new data to support new services easily. Modernizing the underlying databases that support the SSA’s activities is critical to the agency’s effectiveness in the realm of electronic services. almost 500 terabytes (TB) of operational data stored on its 1,000 processor Teradata configuration.4 Other scalable database alternatives include IBM’s relational database system product DB2/PE (Parallel Edition), Oracle 10g, and products from vendors such as Netezza and Datallegro. The adoption of scalable database technology and clusters of commodity processors to handle even the very largest database tasks is expected to accelerate as databases of all forms and types continue to grow. Exploration of the use 4 Constance L. Hays, “What Wal-Mart Knows About Customers’ Habits,” New York Times Business Section, Nov. 14, 2004, available at http://www.nytimes.com/2004/11/14/business/yourmoney/14wal.html, accessed June 14, 2007; and Charles Babcock, “Data, Data Everywhere,” Information Week, Jan. 9, 2006, available at http://www.informationweek.com/story/showArticle.jhtml?articleID=175801775, accessed June 20, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment of this sort of technology as part of a migration plan from MADAM to relational database technology would likely be fruitful. Redundancy and backups are of course essential to data integrity and availability—and ultimately to business continuity. One means for meeting this need is through the use of data replication to provide the capability to switch over automatically to spare components that provide for continuity of operations. In general, the reason that such replication is important is that, although backup tapes are kept off-site in a secure location to prevent significant data loss, without replication a major disaster at the primary site could leave the SSA unable to access its master database until a replacement facility was up and running. In this study, the committee was unable to obtain information from the SSA regarding data replication and failover plans for handling disaster recovery owing to security sensitivities. Therefore, rather than evaluating the agency’s current or planned capabilities in this regard, the committee notes that various approaches to addressing this challenge are possible and are supported by modern database systems and architectures. However, in the committee’s view, realizing a modern data-replication and disaster recovery strategy could be significantly hindered by the SSA’s use of decades-old database technology for storing the majority of its programmatic data (see the discussion of MADAM in the following sections). The antiquated MADAM database system and technology are difficult to replicate using current technology (see below), and the custom modifications that would be needed to do so would be very costly and would require scarce expertise. Software Infrastructure Each of the three SSA organizational tiers runs slightly different software.5 At the local/departmental level, both the desktop PCs and the servers run Windows NT and the usual suite of Microsoft productivity tools. Microsoft Access is run on the desktop PCs, and the local/departmental servers run Structured Query Language (SQL) Server. As is typical for large organizations, the desktops are used for running a broad spectrum of applications, including administrative applications (for example, payroll and travel); management information applications (for example, report generation); and programmatic applications (for example, data entry). Although the applications are currently a mix of client-server 5 Factual details about the SSA’s IT infrastructure in this subsection are drawn from Social Security Administration, Information Resources Management Strategic Plan (2005), especially pp. 85-224; available at http://www.socialsecurity.gov/irm/IRM_2005.pdf, accessed June 20, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment and Web-based applications, the SSA is in the process of replacing most or all of the client-server applications with Web-based versions. Both types of applications are used to communicate with servers located at all three tiers: local, ROCCs, and NCC. The servers at the ROCCs are a combination of Unix and Windows NT servers. Both Oracle and SQL Server database systems are used at this tier. The NCC hosts servers running Windows NT, Unix, and IBM’s z/OS operating system. SQL Server is run on the Windows servers, Oracle runs on the Unix servers, and a combination of DB2, Computer Associates Integrated Database Management System (CA-IDMS), MADAM, and VSAM run on the IBM Parallel Sysplex servers. The databases housed on the servers at the NCC can be roughly divided into three categories: programmatic, administrative, and management information (MI). The programmatic databases are organized into separate operational data stores; they include Title II (administering disability, old age, and survivor benefits); Title XVI (administering Supplemental Security Income [SSI]); Disability (determination, control, and tracking); Earnings (recording of annual wage reporting by employers and benefit reports); and Enumeration (allocation and verification of Social Security numbers [SSNs]). The administrative database is a separate operational data store that includes information on SSA employees, facilities, and finances. Each of these operational data stores feeds abstracted and aggregated information into a data warehouse that is used to support management decision-making processes based on both current and historical data. The schemas for each of these databases are consolidated in a metadata database. See Figure 3.1 for a graphical depiction of the SSA’s Management Information Database Architecture. The MI data warehouse is hosted using Oracle running on the Unix servers. The administrative databases and associated applications are currently in the process of being migrated to a combination of DB2 running on one of the SSA mainframes and Oracle running on a Unix server. With the exception of the Disability database, which is housed on DB2 on a mainframe, the primary programmatic databases including Title II, Title XVI, Earnings, and Enumeration are stored on a SAN and manipulated using a combination of CA-IDMS, MADAM, and IBM’s VSAM. While the names DB2 and Oracle will likely be familiar to the casual reader, it is highly unlikely that CA-IDMS, MADAM, and VSAM will be. CA-IDMS is an implementation of the Conference on Data Systems Languages (CODASYL) data model. The company that actually built IDMS (Cullinet) went out of business in 1989, at which time Computer Associates acquired the rights to Cullinet’s system and its customers. The CODASYL data model was popular in the early to mid-1970s, but by approximately 1980 most experts in the data-management field had

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment FIGURE 3.1 The Social Security Administration’s Management Information Database Architecture. NOTE: SSI, Supplemental Security Income; PEBES, Personal Earnings and Benefit Estimate Statement; SSN, Social Security number; ADMIN/MI, administrative and management information; RDBMS, relational database management system; IWS/LAN, intelligent workstation/local area network. SOURCE: Social Security Administration, “SSA Data Architecture,” Version 1.0, Dec. 9, 2002, p. 22. (Courtesy of the Social Security Administration.) concluded that the relational data model was superior.6 In addition, CODASYL database systems are almost exclusively accessed by applica- 6 For a timeline history of databases, see International Federation for Information Processing Working Group 9.7, “A Brief History of Database Systems,” in History of Computing, last modified Dec. 5, 2004, available at http://www.comphist.org/computing_history/new_page_9.htm, accessed June 20, 2007. For discussion of the foundations of database systems, see Raghu Ramakrishnan and Johannes Gehrke, Database Management Systems, New York: McGraw-Hill Higher Education, 2002, especially Ch. 3 (hereafter cited as R. Ramakrishnan and J. Gehrke, Database Management Systems). A mid-1970s comparison of the CODASYL and relational approaches is presented in Ann S. Michaels, Benjamin Mittman, and C. Robert Carlson, “A Comparison of the Relational and CODASYL Approaches to Data-Base Management,” ACM Computing Surveys 8(1):125-151, March 1976.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment tions written in Common Business-Oriented Language (COBOL), which, as the oldest business-oriented programming language in the history of computing, is now generally considered to be obsolete, understood by only an increasingly small fraction of the practitioner community. One drawback is that applications written in COBOL/CODASYL are more cumbersome to maintain compared with those implemented using modern technology. An application written in COBOL against a CODASYL database management system (DBMS) such as CA-IDMS is typically 10 to 100 times longer (in lines of application code) than an equivalent application written in C++ or Java against a relational database system. The main reason for this difference is that the database requests against a relational database system are written in SQL, the declarative data manipulation language that is the mainstay of relational databases and modern IT organizations. Simply put, SQL allows applications developers to request data by saying “what” they want, not “how” they want the system to obtain the data. The underlying relational DBMS optimizes the application’s request based on how the data are physically organized and indexed and what the current data statistics look like. This provides orders-of-magnitude code reduction and productivity gains relative to CODASYL database applications. CODASYL applications are extremely difficult to write, debug, and maintain in comparison with today’s mainstream data-centric application-development technologies. The SSA’s dependence on CODASYL and COBOL for MADAM represents a severe handicap because of these difficulties in developing, refining, and maintaining the demanding applications needed to meet the current requirements of SSA’s diverse constituencies. Another drawback is that COBOL itself will eventually become a “dead language.” It is rare today for new applications to be written in COBOL, and the dwindling number of existing COBOL/CODASYL applications is being steadily replaced by versions written in contemporary languages such as C, C++, or Java, or scripting languages such as PHP or Perl, using SQL (or SQL-based programming tools) for database access. This is due to the much more productive database programming capabilities and associated benefits that these combinations of technologies offer. In fact, COBOL and CODASYL are no longer taught in college and university computer science departments, and the number of programmers who are conversant with COBOL and CODASYL programming has become quite small and is shrinking rapidly. Thus, in addition to the SSA’s being dependent on a set of low-productivity technologies, it is likely to become increasingly difficult for the agency to recruit and retain the pool of IT developers needed to meet its current and future IT needs. In summary, these issues represent major challenges for the SSA going forward. Specifically, because such outdated technology is used for the

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment SSA’s master database, it raises barriers in terms of the feasibility of linking it to new Internet applications. In addition, it causes applications to be unavailable for 24/7 access, because this technology requires downtime for updates in batch windows (see below). Some software for MADAM is written in assembly language and so closely coupled to the operating system (OS) that any changes in the OS require testing of the database. Finally, the cost and increasing scarcity of relevant custom programming expertise is making the maintenance of this technology increasing difficult and problematic. The SSA is not unaware of these issues, which have also been raised in earlier reports and studies (some are cited below). Indeed, the SSA reported to the committee that it was exploring converting to a newer technology, but the committee nevertheless has concerns about the conversion process, as discussed below. MADAM and the MADAM Conversion Process The SSA’s Master Data Access Method, MADAM, is a database system that was developed in-house by SSA staff in the early 1980s when the SSA converted from tape to disk storage for its data sets. In 1986, the congressional Office of Technology Assessment (OTA) issued a report entitled The Social Security Administration and Information Technology. As part of that report, OTA expressed concerns about the use of MADAM instead of a commercial database system: The most controversial accomplishment of the data integration effort is perhaps the Master Data Access Method, or MADAM, the file management system that SSA developed when it converted from tape to disk storage. Many experts thought that SSA should have sought or adopted off-the-shelf software for this purpose which would be maintained by vendors, rather than developing its own which it must maintain (that is, improve, modify, and update). MADAM may well be incompatible with future mainframe operating systems, database management systems, and fourth generation languages. The SSA incurs future risks of incompatibility and long-term maintenance costs. In the short term, there are also risks and costs. MADAM is apparently a very complicated and poorly documented system, so that only a small group of people are sufficiently knowledgeable to operate it, yet it is the basis of the SSA’s data management. This constitutes a particular vulnerability to smooth operations if there is any short-term emergency, sudden work force reduction, or drastic reorganization.7 7 U.S. Congress, Office of Technology Assessment, The Social Security Administration and Information Technology, OTA-CIT-311, Washington, D.C.: U.S. Government Printing Office, 1986, p. 43 (NTIS Order PB87-136834), also available at http://www.ssa.gov/history/pdf/ota86.pdf, accessed June 20, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment Despite those concerns, the committee notes that MADAM is still functioning, 20 years later. However, the vulnerability factors, including workforce issues that OTA noted, still pertain. MADAM is layered on top of IBM’s Virtual Storage Access Method product (VSAM is IBM’s indexed file management package, based on the use of B-trees to support searching8), which allows it to run in a Parallel Sysplex environment. It appears, however, that updates to the central MADAM database are done primarily (if not exclusively) in a batch mode. New data (for example, batches of earnings reports) are first inserted into CA-IDMS and then batch loaded into MADAM during a nightly batch window (based on information that the committee received from the SSA, this window is 1:00 a.m. to 5:00 a.m. during the week and longer on the weekends). The large batch window is required to update the MADAM database daily; this scheduled downtime makes 24/7 operation of online services impossible without the implementation of some sort of complex caching and merging mechanism that could allow online services to overlap the batch window. The continued use of the CA-IDMS/MADAM combination of technologies represents a significant barrier to the SSA goal of providing improved and expanded electronic services to users. One issue is that Java Platform, Enterprise Edition (J2EE) application servers, such as the IBM WebSphere product that the SSA is using to deliver new Internet applications, typically communicate with databases using Java and SQL, not through COBOL and CODASYL record-level operations. Connecting WebSphere applications to CA-IDMS and MADAM will involve custom adaptors that are difficult to program against from within a J2EE environment and that cannot reap the usual benefits of the productivity tools and technologies available to “normal” J2EE developers. It is also worth noting that, aside from the software issues, the continued use of CA-IDMS and MADAM serve to lock the SSA into a particular expensive hardware and software combination. Both pieces of software only run on high-end IBM mainframes, making it impossible for the SSA to take advantage of potentially lower cost alternatives such as scalable Unix clusters or parallel database systems such as IBM DB2/PE, Oracle 10g, or NCR Teradata, among others. One justification sometimes offered for the continued use of MADAM is its size. The argument is that the SSA databases are so large that they can only be handled by custom software. Although this argument may have been valid 20 years ago, the SSA databases are no longer uniquely 8 B-trees are useful for exact match and range retrievals, such as looking up someone’s Social Security account using the SSN as the key for the B-tree. See R. Ramakrishnan and J. Gehrke, Database Management Systems, Ch. 9.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment large by modern enterprise standards. As of 2005, the SSA’s programmatic databases had a total size of about 30 TB9 (a terabyte is 1 trillion bytes). Proprietary concerns make it difficult to obtain published data on commercial enterprise database sizes and workloads in order to identify those that rival the SSA’s database in terms of size and number of transactions. However, published data indicate that commercial systems handle very large relational databases, and relational databases with very large workloads. By way of comparative example, the customer database for Verizon, a major U.S. telecommunications company, consists of 50 billion records and 47 TB, and this database does not include data concerning the company’s wireless customers.10 Verizon’s database is currently housed on a cluster of Windows Servers running Microsoft SQL Server—using commercial off-the-shelf relational database technology. Moreover, the annual Winter survey11 lists a number of commercial relational database instances in the 20 TB to 100 TB range, and these databases are all managed by standard relational database products, each typically housed on Unix or Windows clusters. In terms of system load, SSA’s workload approaches 50 million CICS transactions a day.12 The 2005 Winter survey indicates that standard relational database systems in use at telecommunications companies and banks typically handle well over 1 million transactions per hour, with one system in the report having a peak workload of 28 million transactions per hour. This system handles this transaction load using DB2 running on Unix. It is the committee’s opinion that the capabilities of commercial relational database products in 2007 have now overcome any technical rationale that might justify the SSA’s continued reliance on decades-old, custom data-management technology. Selecting a MADAM Conversion Strategy The SSA has taken some steps to explore MADAM alternatives. A 2002 report describing the SSA’s data architecture plans states that “efforts will be made to determine what portions of the [MADAM] data could be 9 See Social Security Administration, Information Resources Management Strategic Plan (2005), p. 168, available at http://www.socialsecurity.gov/irm/IRM_2005.pdf, accessed June 20, 2007. The SSA has a total of 110 terabytes of mainframe data stores, and the SSA’s client-server data stores maintain 80 terabytes (ibid., p. 5). 10 Personal communication from Michael Brodie, Distinguished Architect, Verizon Communications, to David J. DeWitt and Michael Carey, e-mail, Feb. 20, 2006. 11 This survey is available from Winter Corporation, Waltham, Mass., http://www.wintercorp.com. 12 The SSA reported that, in 2004, its mainframe and client-server databases had supported some 42 million individual data transactions a day. Social Security Administration, Information Resources Management Strategic Plan (2005), p. 5.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment BOX 3.2 The SSN as Identifier and Authenticator Social Security numbers (SSNs) are nine-digit numbers whose first three digits are related to the geographic location where the SSN was issued. The SSN concept was originally created in 1935-1936 to keep track of workers’ earnings. After Executive Order 9397, issued in 1943, required federal agencies to use the SSN to identify persons in any new federal systems-of-records systems, its use as an identifier in these systems grew, but slowly, for nearly 20 years. Then, in 1961, the Civil Service Commission began using the SSN to identify federal employees; the Internal Revenue Service began using it as the official taxpayer identification number the next year. As computers came into more widespread use, the use of the SSN as an identifier by federal, state, and local governments and private-sector organizations grew very rapidly. No legislation prohibited broad use of the SSN. Indeed, in 1970, congressional concerns about welfare fraud and unauthorized workers led to amendments to the Social Security Act authorizing the Social Security Administration (SSA) to assign SSNs to legally admitted noncitizens entering the United States and to people applying for or receiving federal benefits. Subsequent legislation continued to expand the use of the SSN—for example, as a condition of eligibility for federal assistance or loan programs; for use by states as part of their own tax processing, public assistance, driver’s license, or motor vehicle registration functions; for use in child support enforcement; and for military Selective Service (draft) purposes. According to the SSA, there are now 27 authorized uses of the SSN as the identifier for record-keeping or matching criteria.1 Although numerous laws authorize and/or require the use of the SSN as an identifier, no federal law regulates its overall use. Some federal laws restrict the use of SSNs in certain programs to specific uses and prohibit unauthorized disclosure, but there is no federal law regulating or restricting the use of SSNs by the private sector.2 Their use as a de facto near-universal identifier has proven to be problematic—resulting in easier paths to identity theft and credit fraud.    1The information in this history is from Social Security Administration, Report to Congress on Options for Enhancing the Social Security Card (undated), available at http://www.ssa.gov/history/reports/ssnreport.html, accessed June 20, 2007.    2See U.S. General Accounting Office, Social Security: Government and Commercial Use of the Social Security Number Is Widespread, GAO-HEHS-99-28, Washington, D.C., February 1999. the current direct deposit to another account or financial institution; and change the password.36 36 Information obtained from the SSA’s Web site at https://s3abaca.ssa.gov/pro/passregi/passserv.shtml, accessed June 23, 2006. In June 2007, the SSA’s updated Web site has new information indicating that a current beneficiary or a person who has recently applied for benefits can request a password. See https://s044a90.ssa.gov/apps6z/ACU_LDPG/landingpage,

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment When possible, most institutions are now moving away from use of the SSN (for example, as student identification [IDs], subscriber IDs, customer IDs, and so on). Given the widespread use of the SSN and its increasing exposure to potential misuse (for example, from lost or compromised government and corporate data containing millions of individuals’ SSNs and other identifying information), knowledge of an SSN should not be the only information required for an individual to authenticate himself or herself to the SSA or any other institution. Indeed, as the SSN contains only 9 digits (making for a maximum of 1 billion different SSNs), and the number of issued SSNs exceeds 400 million,3 there is at least a 40 percent probability that a randomly generated 9-digit number will be someone’s SSN. Thus, the security risk from relying solely on the SSN for authentication is large and growing. In comparison, American Express card account numbers are 14 digits long, Visa/MasterCard account numbers are 16 digits long, and both have a 3- or 4-digit security code marked on the card to prevent fraud.4 Additional information related to an account (for example, the billing zip code, a personal identification number, or details about a recent transaction) is often required when interacting with a financial institution in a way that could compromise an account. The security of the SSN, given its ubiquity and comparative simplicity, is a challenge. Addressing this challenge involves not just the SSA but also the multiplicity of federal, state, local, and private-sector entities that use the Social Security number to identify individuals or accounts.    3By 2006, more than 420 million SSNs had been issued. See http://www.ssa.gov/history/hfaq.html, accessed June 20, 2007. The structure of the numbers includes a geographical area number (the first three digits) and a group number (the next two digits), then four consecutive digits from 0001 to 9999. Because group numbers are not issued sequentially for a given area, at a given point in time some nine-digit numbers are not possible as valid SSNs. The SSA publishes SSN number ranges issued to date. See http://ssa.gov/history/ssn/geocard.html, accessed June 20, 2007.    4The security code is not embossed on the card; therefore, it does not show up on the credit card slip. This prevents someone from obtaining the code from a receipt. Note that a user’s password is not sufficient to view his or her earnings history online. Indeed, only current beneficiaries can get passwords. accessed June 20, 2007. In 2007, as in 2006, the password request functions are not available 24/7, and the SSA’s Web site indicates that the waiting period for receiving a temporary PRC by mail can be up to 15 days. See https://s044a90.ssa.gov/apps6z/ACU_LDPG/landingpage, accessed June 20, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment A beneficiary’s password is, however, sufficient to change the bank account to which direct deposits are made. The committee conjectures that the former may be considered not merely a security risk but also a more emotionally laden privacy risk, even as security breaches regarding the earnings history are less likely to have real financial consequences than would security breaches regarding bank accounts and direct deposits. It is unclear whether this policy is a carefully considered choice, resulting from a rigorous cost-benefit analysis, or an unintended consequence of various privacy and security policies influenced by oversight probes. Security and Privacy in a Dynamic Environment In addition to continuing changes in hardware, software, and the ways in which people will choose to access services, large organizations such as the SSA will also have to address how their security, privacy, and authentication policies may need to change over time. Over the next decades, the SSA will face many challenges—both internal and external—in maintaining privacy and security. The external challenges will arise from entities that wish to obtain information or access for which they are not authorized. The internal challenges will come from entities that are authorized to have access or information but the authorized entities abuse or misuse it, or even just make a mistake. The set of policies that define security, privacy, and authentication for the SSA are controlled not only by the agency itself but also by external factors such as statutes and regulations (see Appendix D regarding some of the relevant statutes). The agency is constrained to choose mechanisms to enforce these policies in a way that complies with the goals and constraints under which it functions. In particular, the SSA’s entire e-government approach must view security, privacy, and authentication policies in the context of the agency as a whole, with electronic services as part of an overall service-delivery strategy (see Chapter 4). Numerous approaches to information system security (in this case encompassing privacy and authentication, as well) have been developed by the information security community.37 On the basis of briefings and conversations with SSA technical staff, the committee considers that staff to be well informed in these areas and mindful of the challenges and principles involved. The SSA consists of several components, each of which manages different sets of systems. Each part of the agency has performed security 37 See, for example, at http://cstb.org/topic_security/ a listing of numerous reports from the Computer Science and Telecommunications Board on cybersecurity and computer security.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment analyses. According to information given to the committee, the SSA has clearly weighed the risks very heavily. One caution, however, is that such an emphasis may lead to an unnecessary use of mechanisms that impair one or more security services. This can occur because security can be thought of as consisting of three types of services: confidentiality services, integrity services, and availability services. For example, the availability of information is critical for timely transactions and handling of cases. But availability carries with it the risk that the information may be disclosed to unauthorized parties. Hence, limiting availability reduces risks to confidentiality, but it increases risks to availability. The security policy must strike the correct balance between these qualities, and that balance should be determined by risk analysis and cost-benefit analysis. The factors involved in determining approaches to security and policy include not only the SSA’s internal rules, but also the laws and regulations imposed externally by Congress and by other federal agencies (such as the Office of Management and Budget [OMB]) and court rulings. Further, agreements with state agencies impose additional constraints. Thus, technical concerns are not paramount but are simply one factor to be considered along with these other factors. Clearly, none of the above is meant to suggest that the SSA should not pay appropriate attention to security risks. Both internal controls and measures to address external threats (fraud, hackers, and so on) must be considered. To be most effective, security must be built into a system from the start. Treating it as an add-on or applying Band-Aid-type measures is costly in terms of resources and risk. Although the SSA may not have taken a security-from-the-start approach in all of its previous electronic services projects,38 this report is aimed at encouraging the agency to adopt that posture as it seeks to expand the scope of its electronic services. Admittedly the agency cannot address these challenges alone—as with other government agencies, congressional and/or executive branch (through OMB, for example), involvement could help provide a framework and broader support for SSA actions to offset the threat of potential negative reactions. 38 See SSA, Assistant Inspector General for Audit, “Evaluation of the Accelerated eDIB System—Third Assessment (A-14-03-13047), December 20, 2002, available at http://www.ssa.gov/oig/ADOBEPDF?A-14-03-13047.pdf, accessed June 29, 2006. The SSA’s Office of the Inspector General (OIG) found that the August 2000 eDIB Program Management Plan “neither addressed security nor evaluated the risks involved in eDib program development. OIG concerns were partially addressed in the November 14, 2001, eDIb Program Management Plan…. However the [2001] plan did not address the risks associated with security, fraud, hackers, and complexity of the system. Instead, the Risk Management Plan addressed development risks, which could be incurred during systems development, such as cost, schedule, integration/technical and mission. While system development risks should be considered, it is as important to address risks that relate to internal controls and security.”

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment BOX 3.3 General Security Principles In a dynamic and changing environment, the policy and technology questions relating to security and privacy must be revisited on a continuing basis. The following are several useful principles for any large organization developing security policies: Simplicity. The more complex a policy or system is, the more that can go wrong. Worse, complexity of interfaces leads to errors, because humans develop mental models of how systems work and base their actions on these models. If a system is too complex, the mental models either fail to capture the system behavior or take too long to develop. In either case, errors occur. It is critical to understand that this pattern applies not only to “outsiders” using interfaces to access systems but also to developers of systems, who have mental models of how the components work; to analysts, who have mental models of what to look for and how to look for weaknesses; and to policy makers, who have mental models of what policies allow. As Einstein reputedly said, “Everything should be made as simple as possible, but no simpler.” Least privilege. A person should have access to only the minimum amount and type of information needed to do his or her job. For example, someone analyzing an individual’s usage-pattern data should not have access to that individual’s financial data. Similarly, a statistician analyzing current funds in order to forecast future funds should have access to financial information but not to customers’ names and addresses. Breadth. By their nature, security policies and mechanisms need to be centrally managed, with each component of the organization managing security having a limited amount of autonomy consistent with the central policy. This approach prevents the balkanization of security but allows individual components to take local factors into account. Comprehensiveness. The principle of psychological acceptability1 states that security mechanisms should be as unobtrusive as possible. One application of this principle is to require users to enter data only once. Then, if the data are needed multiple times (for example, for authentication across several systems), the session data should be retained so that the user need not reenter the data (for example, having a single sign-on for authentication). This principle functions with the principle of breadth, above, because local components must use security information gathered from other local components. This is possible only when a central authority controls the interpretation of the data. However, local components can decide how to use the data, provided the use is consistent with overall policy. Holistic approach. An organization may interact with many private-sector organizations (including financial institutions); with federal, state, and local agencies; and with private citizens. Issues of security, privacy, and authentication affect and are affected by all these relationships. Thus, the organization must consider not only its own systems and policies but also those outside its control with which it must interact, and the people and agencies that use its systems.    1J. Saltzer and M. Schroeder, “The Protection of Information in Computer Systems,” Proceedings of the IEEE 63(9):1278-1308, September 1975.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment This section has focused briefly on three aspects of what is commonly called security: namely, security, privacy, and authentication. Each is different, and presents different challenges. All are intertwined; none can be considered without regard to the other two, and decisions made for one affect the decisions that will have to be made for the other two. A brief summary of general security principles is provided in Box 3.3. Several themes that the SSA should continue to keep in mind when contemplating security, privacy, and authentication policies going forward are these: the larger societal, organizational, and technological contexts of which it will be a part; balancing risks with benefits and avoiding an overemphasis on risk, especially with regard to electronic services (in today’s environment, lack of electronic service adoption is itself a serious risk for an agency facing serious workload and staffing challenges); and the need to be open to the evaluation and adoption of proven industry technologies and tools. USER INTERFACE Some of the current barriers to electronic service adoption are external to sponsoring organizations such as the SSA and/or they directly involve users. These include user concerns over privacy and security (discussed previously), the perceived convenience or inconvenience of electronic services, users’ lack of knowledge about available services, the complexity and cost of providing electronic services, and lack of access to Internet-connected devices.39 Privacy concerns may have a significant impact on overall user interfaces and access, because information protection measures being considered at state and federal levels may require users to provide identifying information such as personal identification numbers (PINs) and passwords. For example, encrypted data may require the cus- 39 Michael Adler and Paul Henman, with Jackie Gulland and Sharon Gaby, Computerisation and E-Government in Social Security: A Comparative International Study, Washington, D.C.: IBM Center for the Business of Government, July 2005; Council for Excellence in Government, Hart-Teeter on behalf of the Council for Excellence in Government, The New E-Government Equation: Ease, Engagement, Privacy and Protection, Washington, D.C.: Council for Excellence in Government, April 2003, available from http://www.excelgov.org/usermedia/images/uploads/PDFs/egovpoll2003.pdf, accessed June 19, 2007; Internal Revenue Service, Findings from the 2002 Wave of e-file Taxpayer Attitudinal Tracking Research, 2002, available at http://www.irs.gov/taxpros/display/0,,i1%3D5%26genericId%3D10121,00.html, accessed May 23, 2002; Nielsen/NetRatings, More Than One Third of All Online Users Log on to Government Sites, New York: Nielsen/Net Ratings Press Release, March 17, 2003, available at http://www.nielsen-netratings.com/press.jsp?section=ne_press_releases&nav=1#2003, accessed June 19, 2007; D.M. West, “E-Government and the Transformation of Service Delivery and Citizen Attitudes,” Public Administration Review 64(1):15-27, 2004; and Elena Larsen and Lee Rainie, The Rise of the E-Citizen: How People Use Government Agencies’ Web Sites, Washington, D.C.: Pew Internet and American Life Project, April 3, 2002, available at http://www.pewinternet.org/reports/toc.asp?Report=57, accessed June 19, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment tomer to provide identifying information not only over the Web but also in phone calls, so as to authorize the person at the call center to access the caller’s data. This requirement can pose challenges to some customers who may have difficulty remembering such information. Other barriers are internal to sponsoring organizations and arise from institutional and cultural factors: lack of staff, an out-of-date technical infrastructure, competing priorities for resources, lack of institutional readiness, and lack of leadership.40 Fifteen years ago, the major Internet applications were e-mail, file transfer (ftp), and remote log-in (telnet). Nearly all home users accessed online services through dial-up connections. There were no electronic commerce sites. The emergence and burgeoning of the Web has clearly had a dramatic impact on all aspects of our lives, and there is every reason to believe that its impact will only increase. The majority of individuals now in their retirement years are not Web users, and usage currently decreases markedly for those over 70. However, by the time the baby boom generation has finished retiring, in 15 to 20 years, one can reasonably expect Web use by retirees to be much higher. The youngest baby boomers are now in their early 40s and have far different exposure and comfort levels with computers and electronic transactions than did average people in their 40s in the early 1980s. The oldest baby boomers have turned 60, and the majority of them are using the Internet (see below). There always will be some individuals (of all ages) who will not use electronic services despite efforts to make these services accessible and easy to use. However, other people or institutions may be assisting users with these electronic services; thus, the SSA’s electronic services are not just for use by individual clients, but also by the states, other government agencies, and employers, among others. In predicting the demand for electronic information and services, it is important to understand the characteristics of Internet users—who will be online and how old will they be—as well as how online demographics will be changing. Key questions include these: Is it true that older people do not use the Internet? What are the projections, especially among baby boomers, for older people using the Internet? Who will use it and what 40 S.H. Holden, D.F. Norris, and P.D. Fletcher, “Electronic Government at the Local Level: Progress to Date and Future Issues,” Public Performance and Management Review 26(4):325-344, 2003; J.L. King, V. Gurbaxani, K.L. Kraemer, F.W. McFarlan, K.S. Raman, and C.S. Yap, “Institutional Factors in Information Technology Innovation,” Information Systems Research 5(2):139-169, 1994; M.J. Moon, “The Evolution of E-Government Among Municipalities: Rhetoric or Reality?” Public Administration Review 62(4):424-433, 2002; and D.F. Norris and M.J. Moon, “Advancing E-Government at the Grassroots: Tortoise or Hare?” Public Administration Review 65(1):64-75, 2005.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment will they use it to do? Are the users getting help with electronic services, and what are the motivations of those providing the help? In a partial answer to such questions, the Pew Internet and American Life Project41 reports the following statistics from 2004 survey data: As of February 2004, 22 percent of Americans 65 and over (about 8 million people) use the Internet, compared with 15 percent in 2000 and 2 percent in 1996. The trend is clear. Those who have learned how to use the Internet are expecting to use it in the future. Surprisingly, 77 percent of those with Internet experience have 4 or more years of experience. In the population already 65 and older, Internet use decreases steadily with age: in 2001, about 22 percent of Americans age 65 to 69 used the Internet, compared with about 15 percent of those age 70 to 74, about 8 percent of those age 75 to 80, and about 4 percent of those age 81 to 90.42 In that population of Americans 65 and over (see the preceding bullet item), the number of female users equaled the number of male users. Compared with the general population, not surprisingly, these are people with higher incomes and more education. Many more of this set of users access the Internet at home over dial-up, rather than high-speed connections, compared with the general population who go online at home. Only 11 percent of African-Americans 65 and older use the Internet, although 21 percent of English-speaking Hispanics 65 and over use the Internet, the same as for Caucasians in that age range. Of those 65 and older who use the Internet, 94 percent use e-mail and well over half look for health or medical information. By the end of 2003, 60 percent of seniors who used the Internet had visited government Web sites, compared with 40 percent in 2000. Most of these users are online daily. Of more interest are the expectations and talents of the older baby boomers, at the time of the survey 50 to 58 years old; the Pew report calls this population the “Silver Tsunami.” In 2004, Pew found that 62 percent of those 50 to 58 years old used the Internet, compared to 46 percent of those in the 59 to 68 year age range. Only 17 percent of those age 69 and older use the Internet. The older boomers are very much like the younger, Generation X, “eager users.” They embrace e-mail, use instant messaging, 41 Susannah Fox, Older Americans and the Internet, Pew Internet and American Life Project, Pew Research Center, Washington, D.C., March 25, 2004 (hereafter cited as Susannah Fox, Older Americans and the Internet), available at http://www.pewinternet.org/pdfs/PIP_Seniors_Online_2004.pdf, accessed July 11, 2007. 42 Susannah Fox, Wired Seniors, Pew Internet and American Life Project, Pew Research Center, Washington, D.C., Sept. 9, 2001, available at http://www.pewinternet.org/pdfs/PIP_Wired_Seniors_Report.pdf, accessed July 11, 2007.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment and often get their news online. “As Internet users in their 50s get older and retire, they are unlikely to give up their wired ways and therefore will transform the wired senior stereotype.”43 However, one in four Americans never uses the Internet and is not in a household with Internet access. People over 65 currently make up a large portion of this group. This last group is sometimes referred to as the “Truly Disconnected,” and its number has not changed over the past 10 years. These are the people who need agents to help them get the information they need. Even though this group may be a relatively small proportion of the general population, it represents a large number of people in absolute terms. There are barriers to these people getting the information that they need. For instance, a number of older people think that they do not need to access the Internet, since many services, such as Social Security, are available through multiple delivery channels. This is an opportunity for education and outreach. In addition, many older people do not own a computer, nor know how to use one. This number will decrease in time, but right now there is clearly a need for third parties or intermediaries to work with the people in this group to get them the information they need. This could be done through organizations similar to commercial tax preparers that help tax filers, through public servants such as reference librarians at public libraries, or through not-for-profit organizations that provide a variety of services to SSA beneficiaries. Just as the financial services institutions discussed in Chapter 2 do not remove all access channels other than electronic services, so the SSA will need to retain and support more traditional approaches to service provision. Even if older people access Web sites on the Internet, many are difficult to use.44 The Nielsen/Norman Group, a usability consulting firm, has declared that Web sites are twice as hard for older people in general as for younger people to use. In particular, older people have difficulty with small type sizes, low contrast, short links (the target size to be pointed at is small), and rolling pull-down menus. Furthermore, because of short-term memory challenges, if the site does not change the color of the links traversed, older people may have difficulty navigating.45 43 Susannah Fox, Older Americans and the Internet, p. iii. 44 See Amanda Lenhart, John Horrigan, Lee Rainie, Katherine Allen, Angie Boyce, Mary Madden, and Erin O’Grady, The Ever-Shifting Internet Population: A New Look at Internet Access and the Digital Divide, Washington, D.C.: The Pew Internet and American Life Project, April 16, 2003. 45 U-Group: Improving the Usability of Federal Communication Technologies, Newsletter, Washington, D.C.: U.S. General Services Administration, September 2004.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment One set of current usability standards for older people recommends the following: Less text (so that it is easier to remember), Plain language, 12 point sans serif font, Strong color contrast, Buttons that can be used to enlarge the type size, increase the text contrast, or read the text out loud, and Consistent page layout (so that people can learn where to look for various things).46 Not surprisingly, efforts to make a site more usable for seniors also increase the usability for all age groups.47 The SSA will also need to keep in mind the requirements of individuals with disabilities or significant physical or cognitive impairments. Although the same principles and approaches may prove useful, ability-specific methodologies may be needed to ensure that the SSA site is as easy to use as possible for people of varying abilities. More generally, what are considered optimal Web site designs and standards will change over time. Remaining aware of best practices and conducting ongoing use testing to evaluate proposed sites and designs are necessary efforts for any institution maintaining an online presence. ACCESS TECHNOLOGIES A variety of technology options—cable, digital subscriber line (DSL), fiber-to-the-premises, metropolitan area wireless networks—are enabling increased broadband penetration. Increasingly functional access using handheld devices is available through 3G cellular networks. Although personal computers (whose prices, both absolute and performance-adjusted, have steadily dropped) appear likely to remain the major way that users access the Internet, the SSA, and indeed all government agencies, should expect that other technologies such as mobile phones, Internet-connected televisions, game boxes, and other “thin clients” will provide means for those who are not technologically savvy to use networked information and services. Consequently, the SSA should not continue to expect that most of its customers will be using Internet Explorer (or a similar browser) running on a desktop or laptop PC. To be effective and to meet the likely future needs of its users, the SSA should be prepared to eventually support a wide variety of browsers running on a wide variety of devices ranging 46 Ibid. 47 Janice R. Nall, Usability Solutions Group, U.S. General Services Administration.

OCR for page 54
Social Security Administration Electronic Service Provision: A Strategic Assessment from digital televisions to cellular phones. This is not to say that the SSA will need to be at the forefront in developing these services. Other private-sector industries will undoubtedly lead the way. The agency will need to be mindful of these and related technologies and how they are being deployed and used, and it will need to be prepared to take advantage of them for its own beneficiaries and users when appropriate. Deep broadband penetration will provide the opportunity for the SSA’s users to interact with the agency using technologies such as text chat or Voice over Internet Protocol (VoIP). For example, when filling out a form, a user might click a help link connecting the user to a live help desk using VoIP or chat (as some online retailers do today). Alternatively, a “stuck” user might click on a context-aware help link that would bring up a segment of video demonstrating how to continue filling out a troublesome part of the online application.48 SUMMARY Like virtually all other organizations inside or outside the government, the SSA must carefully and regularly examine information technology trends. The agency simply could not perform its functions without the use of technology, and its current reliance on technology will inevitably grow as its workload grows and its access to support resources inevitably fails to keep pace. Thus, it is incumbent on the SSA to keep close track of changes and advances in technology. In some areas, notably security and privacy, the SSA seems to be doing a good job of tracking technology and incorporating current best practices into its processes. In other areas, notably databases, the SSA is not on par with technological advances. Ensuring that the SSA is able to keep pace with technology is not only a technological issue but is also an organizational issue. There are other organizational issues that have a direct bearing on the SSA’s ability to roll out needed electronic services in coming years. These are addressed in Chapter 4. 48 There are also technologies known as Rich Internet Applications, such as Flash, Asynchronous Java Script and XML (AJAX), and others that allow Web developers to develop richer client-side applications by migrating pieces of an application from the server to the client browser. See, for example, Jesse James Garrett, “AJAX: A New Approach to Web Applications,” Feb. 18, 2005, available at http://www.adaptivepath.com/publications/essays/archives/000385.php, accessed June 20, 2007. The most familiar example of AJAX technology is probably Google maps (http://maps.google.com), which provides the user the ability to “scroll” the map by dragging it with the mouse. This scrolling occurs locally, with the AJAX application asynchronously requesting additional map segments and/or satellite imagery from the Google server. In addition to providing a richer user experience, applications written using AJAX technology reduce the load on the server. On the other hand, such approaches can conflict with the desire to let the user employ “thin clients” to access services.