National Academies Press: OpenBook

Planning the 2010 Census: Second Interim Report (2003)

Chapter: 2. Real Reengineering: Technical Infrastructure and Business Process

« Previous: 1. Introduction
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 23
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 24
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 25
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 26
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 27
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 28
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 29
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 30
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 31
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 32
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 33
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 34
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 35
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 36
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 37
Suggested Citation:"2. Real Reengineering: Technical Infrastructure and Business Process." National Research Council. 2003. Planning the 2010 Census: Second Interim Report. Washington, DC: The National Academies Press. doi: 10.17226/10776.
×
Page 38

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.

2 Real Reengineering: Technical Infrastructure and Business Process ONDUCTING A DECENNIAL CENSUS of the United States Cpresents massive logistical challenges on many levels. It has been said that the fielding of the 2000 census complete with over 860,000 short-term employees serving as enumerators- constitutec! the "largest peacetime civilian mobilization" in American history (U.S. Department of Commerce, Office of Inspector General, 2000:3~. Impressive as well is the extent of computing anc! information networks that underlie the census systems to track personnel hires anct fires, monitor caseload, capture anct synthesize data, generate maps, and so on which must function not only at Census Bureau headquarters but also at regional offices, data collection centers, anct over 500 temporary local census offices. Specifically, the 2000 census relied on 10 major systems (U.S. Cen- sus Bureau, 2000~: · Geographic Support System (GSS): facility for deriving extracts from MAF/TIGER as necessary anct printing enumerator maps; 23

24 PLANNING THE 2010 CENSUS · Pre-Appointment Management System/A?~tomatedt Decennial Ad[- ministrative Management System (PAMS/ADAMS): support for the hiring, processing, and payment of temporary employees, as well as administrative data archiving; · Operations Control System (OCS 20009: caseloac! management system to clefine anct track enumerator assignments, as well as to monitor duplicate anc! missing aciciresses; · Data Cap tore System (DCS 2000J: check-in anct scanning of com- pletec! questionnaires; · Telephone Questionnaire Assistance/Coverage Edit Follow- Up (TQA/CEFUJ: support for respondents requiring assistance or aciclitional forms, as well as follow-up data collection from respondents by phone; · Internet Data Collection/Internet Questionnaire Assistance (ID C/ IQAJ: support anct management of limitect-scale Internet re- sponse to short-form questionnaires; · Accuracy and Coverage Evaluation (ACE): support for follow-up survey to assess possible unclercount ancl, possibly, adjust census counts accorclingly; . ManagementInformation System (MIS2000J: senior management planning anc! information tracking, including schedule anc! bucI- get; · Headquarters (HQ) Processing: analysis and processing of final clata, including production of reapportionment and redistricting population counts, as well as other data products; anc! · Data Access and Dissemination System (DADS): system for clis- semination of census data to the public, most notably through the American FactFincler Internet sited ht~p://factfinder.census.gov f6/1/03] .

REAL REENGINEERING 25 In the encI, this network of information systems supported achieve- ment of the clesirec! results. "Operationally, most agree that this decennial census was a success participation was higher than antic- ipatec! ... anc! operations concluclec! on time," notes one assessment. However, the assessment continues, the means by which it was achiever! including the patchwork of information systems lee! to other clescriptions: "costly, complex, and high risk" (U.S. Department of Commerce, Office of Inspector General, 2002:iii).2 The Census Bureau's generic label for its current plan for the 2010 census is that it is a "reengineering plan" (Waite, 20021. One interpre- tation of the term "reengineering" is that it means a markoct departure from past practice that the plan for 2010 is not intenclect to follow the 2000 census script merely with minor embellishment. The boldness of the Census Bureau's proposals for MAF/TIGER modernization anct the American Community Survey suggests that the bureau is not taking "reengineering" lightly, anct that is commendable. A more meaningful interpretation of reengineering suggests a se- rious systemic analysis anct evaluation of the entire decennial census process, with a particular eye towarc! effectively implementing changes, enhancing efficiency, anct establishing organization-wicle coordination on major initiatives. It is on this score that the panel critiquccl the bu- reau's initial presentation of its 2010 census strategy, noting that the bureau's plans lackoct an overarching framework. Though not as well publicized as the Census Bureau's major pro- posect initiatives for the 2010 census, a pilot project within the Census Bureau has macle great strides towarc! creating a base for true reengi- neering in the best sense of the term. This pilot project is a move to- warc! establishing an enterprise architecture for the 2010 census, first by 2An example of the "high risk" nature of system operations: In late 1999, the Com- merce Department's Office of Inspector General reviewed one of the constituent in- formation systems of the 2000 census the PAMS/ADAMS system to track personnel hiring and payroll. Based on interactions with the Census Bureau, the report concluded that the Census Bureau "did not follow a well-managed software development system" in creating PAMS/ADAMS, but the bureau was confident that the system would be able to support decennial census operations given "extensive operational use" of the system since the 1998 dress rehearsal. By January 2000, further review led the bureau to conclude that the PAMS/ADAMS might not be fully capable to support decennial needs and undertook "extensive software modifications" less than 3 months before Census Day (U.S. Department of Commerce, Office of Inspector General, 2000:i-ii).

26 PLANNING THE 2010 CENSUS mapping all the activities anc! information clepenclencies associated with the 2000 census en c! then by using that resulting structure as a moclel to test alternatives for 2010. In this chapter, we examine this effort in more detail. TOWARD A "BUSINESS PROCESS" OF THE DECENNIAL CENSUS Past experience with reengineering and upgrading information tech- nology operations within corporations and government agencies sug- gests that the most pruclent anc! productive approach is to proceed in well-thought-out stages or steps. · Define a "logical architecture" or "business process" model. A first step is to articulate the set of activities anc! functions currently performed by the organization anc! the informational clepenclen- cies among them. This moclel of activities anct functions is called a logical architecture. It may also be called a business process moclel because it clefines the ways in which operations are carried out to accomplish the intenclec! objectives of an organization. In the census context, the current business process would be the in- formation flows anc! tasks associated with the 2000 census. We will explain the nature of logical architecture or business process models in greater detail in the following section. . Reengineer the logical architecture. The completed logical archi- tecture may be viewoc! as an "as-was" model; again, in this case. the as-was moclel would describe the activities of the 2000 census. Using the as-was moclel as a base, the next step is to produce one or more "to-be" models. That is, new assumptions anct objectives are identified and the as-was logical architecture model is adjusted as necessary to finct the optimal way to structure functions uncler the new clemancis. Different to-be models can then be compared against each other in order to reach a final architecture moclel. · Construct the physical technical infrastructure using the reengi- neered logical architecture as a guide. The finished logical ar- chitecture/business process moclel is then usec! as template anc! specification for a new physical technical infrastructure the

REAL REENGINEERING 27 actual network of hardware anc! software systems assembled to carry out the organization's work. Any other approach such as failing to map business functions in terms of overall objectives or rushing to make decisions on technical infras- tructure too early serves only to allow the organization to make more mistakes, albeit (probably) faster than before. The Census Bureau has begun the task of reengineering the clecen- nial census infrastructure in this manner because it fits into the objec- tive of early planning anc! testing envisioned as part of its broac! strat- egy for the 2010 census anct because it brings the Census Bureau anct the Department of Commerce into fuller compliance with the Infor- mation Technology Management Reform Act of 1996 (also known as the Clinger-Cohen Act).3 This act forcer! federal agencies to reexamine their information technology (IT) structures, requiring greater atten- tion to how IT furthers the agency goals anc! attention to modeling current anc! moclernizec! IT structures as a business process. The Chief Information Officers (CIO) Council, created by executive orcler, sub- sequently clevelopec! the Federal Enterprise Architecture Framework (FEAF), a set of minimum stanclarcts for description of IT programs anc! modernizations. . Baseline: Logical Architecture of the 2000 Census The Census Bureau contracted with the Centech Group, an IT company based in Arlington, Virginia, to develop its baseline for in- frastructure reengineering: namely, a business process moclel of the operational flows underlying the 2000 census. Lockheec! Martin was subsequently brought in as a subcontractor. The result of this first stage of work is a map of the logical architecture of the 2000 census, anct it is summarized in a report (Centech Group, Inc., 2002a). A more cletailec! companion volume examines each logical segment of the moclel in greater detail (Centech Group, Inc., 2002b). 3The Information Technology Management Reform Act of 1996 is part of Public Law 104-106. Among other provisions, the act also encourages the use of commercial off-the-shelf (COTS) products relative to software systems built within government agencies.

28 Logical Architecture: What It Is and What It Is Not PLANNING THE 2010 CENSUS The logical architecture models clevelopect by the Census Bureau uncler this contract adhere to the Integration Definition for Function Modeling (IDEFO) language, a method that has been acloptect as a federal standard for representing organizational functions and flows.4 IDEFO models use simple graphical structures to organize information. Functions (activities) of an enterprise are renclerec! as boxes; arrows connect the boxes, representing information constraints. For large enterprise moclels, a high-level diagram is typically produced as a guide or roac! map for the analyst; smaller pieces are then inclexec! based on this high-level map, available in full detail on separate pages. A logical architecture moclel is a blueprint of the workflow of a particular enterprise. It describes the nature of information that must be passect from point to point at various phases of the operation anct, in doing so, highlights information interfaces points of connection both within the system anct with external entities. A logical architecture model thus clefines the baseline capability that must be present when a physical technical infrastructure is constructed. A logical architecture model may also convey a rough sense of where, geographically or organizationally, groups of activities should be clustered. To better unclerstanct what a logical architecture moclel of the clecen- nial census is, it is also important to remember what it is not. The main purpose of an IDEFO-basect logical architecture moclel is to emphasize process anc! function. To that encI, a logical architecture moclel effec- tively ctisregarcts two variables that are of some natural concern. First, it cloes not attempt to assign completion times to any function or process. Hence, the moclel describes forward information flow through a busi- ness process but is not meant in any way as a timeline or schedule of the process. Incliviclual segments of the model may be completely distinct in terms of their actual execution time, or they may just as likely overlap extensively. In aciclition, IDEFO models clo not consider existing orga- nizational boundaries; logical segments are partitioned strictly basect on function en cl purpose, without respect to internal work divisions that may already exist within an enterprise. Specifically, IDEFO was released as a standard in 1993 in Federal Information Pro- cessing Standards (FIPS) Publication 183.

REAL REENGINEERING 29 Finally, since the concepts may be confusecl, it is important to em- phasize that a logical architecture is not equivalent to a physical com- puting or technical architecture. Properly executed, a logical architec- ture cloes not clefine the specific computing platform to be usec! or the specific database structure that may be employoct, anct it certainly cloes not presume to dictate the specific variables or records to be savec! in particular databases. However, the logical architecture can provide a template for the physical trappings; the cliagrammecl flows and con- straints of the moclel give shape to anct provide baseline specifications for the types of activity that physical systems must be able to perform. Moreover, a logical architecture documents work but should be invari- ant to specific operational decisions whether certain data are input at one computer or at twenty or, in the context of the census, whether operations take place in 500 local census offices or 600. Follow-up Work After clefining operational flows, the Census Bureau's next step was to select a computer-assistect architecture modeling package. Ulti- mately, the bureau chose to use System Architect, a package clevelopec! by Popkin Software, Inc., as an initial base for its modeling efforts. Beginning in February 2002, the diagrams and logical flows captured in the logical architecture moclel of the 2000 census were renclerect in System Architect, to support a pilot reengineering exercise. Reengineering Exercise Between August anct October 2002, Census Bureau staff performed a logical architecture reengineering exercise, again contracting with the Centech Group, which issucct the final results in a report (Centech Group, Inc., 2002c). To keep the exercise manageable, given the Census Bureau's new- ness to the process, reengineering activities were narrowoct in scope to focus on the data collection through data processing steps of the census process. Cancticlate areas for retooling were proposed anct consiclerect for inclusion in the exercise. Ultimately, the exercise concentrated on adapting the as-was moclel of the 2000 census to reflect three areas of change:

30 PLANNING THE 2010 CENSUS · Localized control offollow-?~p procedures: assignments for non- response follow-up would be made clynamically, based on regu- lar upclates of response status for all housing units cluring census conduct anc! on the progress of incliviclual enumerators. · Centralizing data capture andformattingfor all response modes: en- sure that data proviclec! to headquarters is in uniform format re- garclless of response type (mail, telephone, Internet). · Redistribution of "undeliverable as addressed" questionnaires: adapt sorting anct screening processes to streamline handling of ques- tionnaires returnee! by the U.S. Postal Service, for easier iclentifi- cation of vacant housing units. Architecturally, adapting the as-was 2000 census moclel to reflect these operations incluclec! many changes in follow-up information process- ing as well as the acictition of data centers5 to perform processing anct formatting tasks. As part of the exercise, Census Bureau staff clevelopect a list of six- teen architectural principles to guicle the logical architecture as the three selected changes were incorporated into a to-be design. As the con- tractor report notes, individual architectural principles may, by clesign, oppose each other "optimization for one principle may cause non- compliance with another principle." The hope is to finct alternative ar- chitectural flows that best balance the opposing clemancis of the entire set of principles (Centech Group, Inc., 2002c). For instance, two of the architectural principles are: "consider the neects of the respondent" anct "facilitate counting everyone once, only once, en c! in the right place." These principles can be weigher! against each other by the degree to which they contribute to overall goals. They can also be usect to evaluate competing "to-be" logical architecture models. For instance, a higher number of response mocles available to respondents uncler one plan might be consiclerect evidence in its favor with respect to the "consicler the needs of the responclent" principle. In the reengineering exercise, Census Bureau staff iclentifiect 5Here, "data center" refers to a designated point to handle sorting and reformat- ting tasks. Use of the term should not be confused with the Census Bureau's current state data centers, which are part of the bureau's existing apparatus for data and analysis outreach to users.

REAL REENGINEERING 31 a number of such measures (quantitative and qualitative), which serve as evaluation criteria to compare the baseline as-was model (the 2000 census structure) with the proposed initiatives for the 2010 census. ASSESSMENT The panel enthusiastically endorses and supports the work that the Census Bureau has performed on its pilot logical architecture project and strongly urges its continuance. Completion of the first phase alone development of a logical ar- chitecture moclel for the 2000 decennial census is a major accomplish- ment and deserves recognition for its potential utility. As the contrac- tor's report notes, the Census Bureau has traditionally put "little em- phasis on assessment of the entire 'enct-to-enct' decennial census pro- cess" (Centech Group, Inc., 2002a:vii). Hence, the bureau's efforts with this moclel of the 2000 census are incleect very encouraging. The reengineering exercise was, unclerstanclably, very limited in scope, but it demonstrates that the Census Bureau is now poised to make fuller use of the modeling techniques in formalizing a logical architecture for the 2010 census. The logical model for the 2010 census can then be translated and operationalizec! in assembling the physical, technical infrastructure for 2010. The panel is comfortable with the bureau's selection of its modeling product en c! paradigm (System Architect and IDEFO, respectively), which appears to be quite sound. Recommendation TI-1: Having completed a logical architecture mode} for the 2000 census and having con- ducted a limited-scope experiment to refit part of the mode} to reflect "2010 assumptions," the Census Bu- reau should continue and extend its logical architecture modeling activities. If necessary to gain experience with modeling functionality, additional small-scale experi- ments should be conducted to apply 2010-design ideas to parts of the architecture mode} that were not addressed in the first exercise. However, the Census Bureau should proceed as quickly as possible to construct alternative reengineered business process models for the 2010 census as a total system. The most promising mode} should be

32 PLANNING THE 2010 CENSUS used to develop a final design and to assemble a physical technical infrastructure. EXTENDING THE PILOT WORK: THE NEED FOR INSTITUTIONAL COMMITMENT The Census Bureau's emerging plans for the 2010 census are laden with new initiatives and new technologies: a parallel data process in the ACS; more extensive ties to an updated MAF/TIGER system; data capture and transmissions from MCDs; Internet transactions; use of administrative records systems; and in-time collection and archiving of information for immediate use in quality control and quality assurance. Each of these activities will require care when incorporated into a logical architecture for the 2010 census. Constructing an extensively reconfigured logical architecture- and, more importantly, using the resulting model as a template for building the actual physical infrastructure for the 2010 census is an arduous task. And though the effort of using a completely realized logical architecture to build the physical technical architecture will ultimately reduce operational risk in census conduct, the architecture- building process is not without risks of its own. In terms of general recommendations as the Census Bureau continues with its architecture work, the panel's suggestions are generally consistent with an earlier National Research Council panel on which members of the current panel also served. The earlier panel was charged to advise the Internal Revenue Service on the modernization of its internal systems (National Research Council, 1996), a task similar in certain respects to reconfig- uring the decennial census. Accordingly, our lead recommendations are similar: first, successful reengineering efforts typically require active "champions" at the highest management levels, and the bureau must seek champions for its architecture construction process. Second, in order to conduct a successful reengineering process, the Census Bureau will need to bolster its technical expertise in enterprise modeling. Management "Champions" . The major technological enhancements envisioned under the Cen- sus Bureau's proposed plan for the 2010 census are distinctive not only

REAL REENGINEERING 33 for their range but also for the manner in which they cut across long- stancling organizational divisions within the Census Bureau. For ex- ample, MCDs with GPS receivers are a fielct data collection tool, and so many requirements for the crevices will have to be ciriven by fielc! personnel neects; however, they are of limited use if the positional accu- racy of TIGER is not improved. Aciclitionally, computer-assistec! ques- tionnaires contained on the crevices would benefit from cognitive and usability testing. The approach of enterprise or logical architecture mocleling is to concentrate on function and information flow rather than preexist- ing work conditions, though incleec! the finisher! result of modeling may suggest more efficient ways to structure operational workload. However, experience in carrying out similar infrastructure remoclelings suggests that it will be vitally important to have strong support at the highest levels of management at the bureau in effect, to have influential "champions" of architecture reengineering. These people can effectively convey the importance of the task and encourage all divisions to "buy in" to modeling activities, and then coordinate and . . integrate to ae emerging system. Establishing a System Architect The development of an acloquate business process moclel for the 2010 census will require a serious effort that must be well staffer! and well supportecl. Although top-level management support and commit- ment are necessary, it is our view that authority for coordinating and developing that model should be vested in one person a system archi- tect for the 2010 decennial census. We recommenc! that such a position be created as soon as possible en cl that a well-qualifiecl candidate be hirect to fill the job. Recommendation TI-2: The Census Bureau should create and staff the position of system architect for the decennial census, conducting a search of persons with expertise in modeling business processes and conducting reengineering activities. The system architect must have the authority to work with and coordinate efforts among the organizational divisions within the Census Bureau

34 PLANNING THE 2010 CENSUS and should serve as a champion of the idea and the importance of architecture reengineering at the highest levels of management within the bureau. The system architect should be supported by a full-time staff of rea- sonable size; this is important in orcler to achieve necessary expertise in a modeling methodology that is new to the Census Bureau. The system architect anct related staff have a primary role as information gatherers, tapping expertise of other Census staff to build anc! revise architecture models. But an important role is also outreach, in a sense helping to build commitment to architectural principles by informing other parts of the Census Bureau of modeling results anct demonstrating their use- fulness. CHALLENGES IN TRANSITION FROM LOGICAL TO PHYSICAL INFRASTRUCTURE A business process or logical architecture moclel will clefine the ac- tivities anct the informational interfaces/clepenclencies required to carry out the 2010 census. Between now anct the ctress rehearsal in 2008 (with 1 1 . 1 . . ~ ~ ~ ~ ~ . . 1 r an opportunity to CIO related testing In zuuo), an 1ntegratecl 1ntormat1on system a physical technical infrastructure must be put into place to support those activities anc! satisfy their informational requirements. In preparation for the refinement of the 2010 logical architecture en cl the transition to a physical infrastructure, we offer some further comments based on past experience with reconfiguring information systems, and we will revisit the architecture efforts in our final report. We raise these points some of them cautionary in nature not to cleter the Census Bureau from proceeding with architecture modeling efforts but merely to emphasize the difficulty anct the importance of the task. Changing Architecture and Methods Simultaneously . Reengineering the Census Bureau's information systems is a very large and complex project in its own right. However, it is made vastly harcler because the Census Bureau will be reengineering a very large anct complex integrated system at the same time as it attempts to make .

REAL REENGINEERING 35 substantial changes in the tools anc! methods it plans to use for in- stance, the migration of the MAF/TIGER system to a commercial off- the-shelf database system, the development (in the ACS) of a complete data system parallel to the census, anc! the implementation of new re- sponse mocles. The aciclect difficulty involved in developing new meth- ocis simultaneously with new architecture argues ever more strongly for a strong, coorctinatect system architect for the census, since synchroniz- ing efforts will be key to successful implementation. For example, one part of the proposed MAF/TIGER Enhance- ments Program which we treat in detail in the next chapter is the conversion of the existing MAF anc! TIGER databases to a moclern database environment. One cited goal of this single objective of the Enhancements Program is implementation of pilot projects to improve the Census Bureau's Capability Maturity Moclel (CMM) score, a measure of an organization's maturity in software engineering (Franz, 2002~. This is certainly a lauclable goal. However, in isolation, the time anc! investment it takes organizations to move up one CMM level is around 2 to 3 years, anct this progress is slowoct further by attempting broacler systemic engineering at the same time. Allowing one of these paths improving software engineering capability or designing system architecture to proceed in isolation from the other could be a critical anc! costly error, if time anc! resources elapse without both contributing . . . . o1nt. y to census 0 electives. Potential Pitfall: Locking in Physical Infrastructure Too Early A major cianger in making the transition from retooler! logi- cal infrastructure to completed physical infrastructure is a rush to judgment a rush to finalize physical structures too early. Moore's Law the aclage that computing power tenets to clouble roughly every 18 months is well known; the rate of change in the computer tech- nology world is incleect astounding. Thus, in settling on the purchase of a particular computer or software package, the Census Bureau runs the same risk faced by millions of personal computer buyers in the past several years: namely, instant obsolescence, as the capabilities of the chosen product are bested shortly thereafter by the next generation of procluct.

36 PLANNING THE 2010 CENSUS The selection of MCDs is a particular area in which the Census Bu- reau shoulc! remain cognizant of the ciangers of clecicling on physical form too early. At present, small-scale tests of basic skills are being concluctec! navigation using a map clisplayoc! on a palm-sizec! screen, administering a computerized questionnaire on a small computing cle- vice, and so forth. It is important that the Census Bureau concluct pro- totype testing of this nature, to get some sense of current capabilities and form factors; however, it is likely to be a mistake to ciraw final con- clusions on qualities like clesirect MCD weight, size, and memory capac- ity based on early test results. MCDs are, essentially, relatively simple computing crevices with reliable storage and test input facilities; acicti- tional features that may be clesirec! include: a color display with gooc! resolution, a GPS latitucle-longitucle acquisition crevice, electronic com- munication facilities such as a lanciline moclem, and perhaps encryption and decryption capabilities. However, the most important product of early MCD testing is not so much a checklist of clesirect features but a clearly articulated plan of the workflows and information flows that must be satisfied by MCDs, as they fit into the broader infrastructure. It would be a mistake to make assumptions at an early stage that unnecessarily limit the functionality or constrain the human factors of these crevices. Given the rate of technological development, it is not unreasonable that a tablet-size MCD with a full-blown operating system, acloquate memory, a 20 gigabyte hare! cirive, a GPS receiver, a moclem, encryption facilities, and an 8-inch full-color screen display will be available in the market by 2007 at a price of $500 or less in the quantities required by the bureau. So to prototype systems and to put too much emphasis on usability tests using crevices of considerably less capability rather than using early testing to further refine the basic logical and informational requirements that the final crevice must satisfy is probably too conservative and will result in the acquisition and use of crevices that will be less effective than necessary. Enterprise Architecture as Learning Too} and Guide to Organizational Change The end goal of business process or logical architecture reengi- neering is the production of a smoothly functioning finisher! physical architecture an amalgam of software, computer systems, and telecom-

REAL REENGINEERING 37 munications systems. Given this purpose, it is perhaps too easy to cast the effort as purely technical anc! technological, a highly inaccurate impression. We strongly encourage the Census Bureau to take full advantage of the exercise of architecture reengineering. That is, we urge the Census Bureau to view the effort not merely as the means to reengineer its computer systems but also as a key information tool to . . . . . reengineer its own organization anc operations. IDEFO logical architecture models emphasize function en c! process, nclepenclent of extant labor anct institutional boundaries within the organization. Large organizations that develop rigid internal clivisions over time can benefit from and find refreshing the basic exercise of stepping back and specifying the most basic flows of information, without regard to which division performs a given function or to which directorate it may report. For the Census Bureau, this logical architecture modeling represents a "new, and very clifferent, perspective on decennial census operations," one "basecl on logical groupings of functions Lancl highlighting] the commonality across similar processes that were developed independently for different operations" (Centech Group, Inc., 2002a:vii). Accorclingly, this new approach represents a potential step away from the "compartmentalizecl thinking" the panel warned against in its letter report (National Research Council, 2001c). By these comments, we do not suggest the need for wholesale change in the way the Census Bureau is currently structurecl. What we do suggest is that the Census Bureau could benefit greatly from the development of a task-basecl project management approach. The analysis of information flows in architecture models may suggest log- ical clusterings of activities or redundancy in activities and provide clues for how parts of the bureau may best be mobilized to carry out the task. .

Next: 3. Modernizing Geographic Resources »
Planning the 2010 Census: Second Interim Report Get This Book
×
Buy Paperback | $49.00 Buy Ebook | $39.99
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

The Panel on Research on Future Census Methods has a broad charge to review the early planning process for the 2010 census. Its work includes observing the operation of the 2000 census, deriving lessons for 2010, and advising on effective evaluations and tests. This is the panel's third report; they have previously issued an interim report offering suggestions on the Census Bureau's evaluation plan for 2000 and a letter report commenting on the bureau's proposed general structure for the 2010 census.

  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!