4
Barriers

Introduction

History is littered with plans, both strategic and tactical, that were conceptually and technically brilliant but failed because the barriers to success were not carefully considered. Many barriers must be overcome to develop and implement AEEs that achieve the vision and meet the objectives described in this report. Barriers, however, can often be transformed into opportunities if creative minds are brought to bear on the problem. For example, a lack of interoperability among tools and data sets currently hinders the effective use of AEE technologies. Efficient resolution of interoperability issues will require cooperation among developers and users of AEE technologies and systems, and the mutual understanding that results from such cooperative efforts could have benefits that extend far beyond the development of AEEs. This chapter summarizes the barriers associated with achieving the AEE vision and carrying out the recommendations in Chapter 5. The barriers are organized into four groups (see Table 4-1).

Integration of Tools, Systems, and Data

The incompatibility of different software tools and hardware systems is viewed by some as inevitable. Commercial competition, which has fostered many incompatibility problems, has also resulted in many improvements that have benefited all users. Nevertheless, the committee does not believe current levels of incompatibility are either inevitable or beneficial.

A high level of integration, which is one of the defining characteristics of AEEs, is required to create an "environment" as opposed to a loosely bundled collection of tools and techniques. AEEs will be used to link researchers, technologists, designers, manufacturers, suppliers, customers, and other personnel who have a broad range of expertise and widely varying concerns. Effective AEEs must efficiently integrate tools and systems that address all areas of concern. Although efforts to develop AEE technologies and systems face many challenging problems, the integration of tools, systems, and data is the greatest barrier to achieving the AEE vision.

Integration problems are caused by many factors, and addressing them all will not be easy. To begin with, software tools are inherently incompatible unless interoperability was a specific goal of the software development process used to create them. For most tool developers, interoperability has had a relatively low priority. Commercial software vendors tend to operate in secrecy to protect proprietary information, especially as new software is being developed. Many tools, especially those generated by R&D organizations or manufacturers for in-house use, are tailored to address specific problems with maximum efficiency and cannot be easily integrated with more generic tools for application to a broad range of problems. With few exceptions, effective integration of software tools is currently possible only if all of the tools are provided by the same vendor. Accordingly, some organizations have selected a single vendor to provide an integrated suite of tools, based on the performance of the tool set as a whole.

A more common approach is for a company, project manager, or individual engineer to purchase the best tool for each application (or to create new tools when commercially available tools are not satisfactory). As a result, organizations sometimes cannot make their tools work together. In fact, the drive to improve the performance and efficiency of individual products and processes encourages the proliferation of new tools to take advantage of the latest advances in the state of the art. However, proliferation itself may become a significant barrier because it can dramatically complicate the interoperability problem, especially if an organization has been addressing this problem by creating individual links between different tools. The same integration problems apply to hardware systems. Systems provided by different vendors are sometimes incompatible, and software written



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 29
4 Barriers Introduction History is littered with plans, both strategic and tactical, that were conceptually and technically brilliant but failed because the barriers to success were not carefully considered. Many barriers must be overcome to develop and implement AEEs that achieve the vision and meet the objectives described in this report. Barriers, however, can often be transformed into opportunities if creative minds are brought to bear on the problem. For example, a lack of interoperability among tools and data sets currently hinders the effective use of AEE technologies. Efficient resolution of interoperability issues will require cooperation among developers and users of AEE technologies and systems, and the mutual understanding that results from such cooperative efforts could have benefits that extend far beyond the development of AEEs. This chapter summarizes the barriers associated with achieving the AEE vision and carrying out the recommendations in Chapter 5. The barriers are organized into four groups (see Table 4-1). Integration of Tools, Systems, and Data The incompatibility of different software tools and hardware systems is viewed by some as inevitable. Commercial competition, which has fostered many incompatibility problems, has also resulted in many improvements that have benefited all users. Nevertheless, the committee does not believe current levels of incompatibility are either inevitable or beneficial. A high level of integration, which is one of the defining characteristics of AEEs, is required to create an "environment" as opposed to a loosely bundled collection of tools and techniques. AEEs will be used to link researchers, technologists, designers, manufacturers, suppliers, customers, and other personnel who have a broad range of expertise and widely varying concerns. Effective AEEs must efficiently integrate tools and systems that address all areas of concern. Although efforts to develop AEE technologies and systems face many challenging problems, the integration of tools, systems, and data is the greatest barrier to achieving the AEE vision. Integration problems are caused by many factors, and addressing them all will not be easy. To begin with, software tools are inherently incompatible unless interoperability was a specific goal of the software development process used to create them. For most tool developers, interoperability has had a relatively low priority. Commercial software vendors tend to operate in secrecy to protect proprietary information, especially as new software is being developed. Many tools, especially those generated by R&D organizations or manufacturers for in-house use, are tailored to address specific problems with maximum efficiency and cannot be easily integrated with more generic tools for application to a broad range of problems. With few exceptions, effective integration of software tools is currently possible only if all of the tools are provided by the same vendor. Accordingly, some organizations have selected a single vendor to provide an integrated suite of tools, based on the performance of the tool set as a whole. A more common approach is for a company, project manager, or individual engineer to purchase the best tool for each application (or to create new tools when commercially available tools are not satisfactory). As a result, organizations sometimes cannot make their tools work together. In fact, the drive to improve the performance and efficiency of individual products and processes encourages the proliferation of new tools to take advantage of the latest advances in the state of the art. However, proliferation itself may become a significant barrier because it can dramatically complicate the interoperability problem, especially if an organization has been addressing this problem by creating individual links between different tools. The same integration problems apply to hardware systems. Systems provided by different vendors are sometimes incompatible, and software written

OCR for page 29
Table 4-1 Barriers to Achieving the AEE Vision Integration of Tools, Systems, and Data 1. Lack of tool interoperability 2. Continued proliferation of tools, which aggravates interoperability issues 3. Existing investments in legacy systems and the difficulty of integrating legacy systems with advanced tools that support AEE capabilities 4. Little effort by most software vendors to address interoperability or data-exchange issues outside of their own suite of tools 5. Multiple hardware platform issues—computers, hardware, databases, and operating systems 6. Lack of formal or informal standards for interfaces, files, and data terminology 7. Increasing complexity of the tools that would support AEE capabilities 8. Difficulty of inserting emerging and advanced technologies, tools, and processes into current product and service environments 9. Supplier integration issues 10. Difficulty of integrating AEE technologies and systems with other industry-wide initiatives, such as product data management, enterprise resource management, design for manufacturability/ assembly, and supply-chain management Information Management 1. Proliferation of all types of information, which makes it difficult to identify and separate important information from the flood of available information 2. Difficulty of maintaining configuration management for product designs, processes, and resources 3. Need to provide system "agility" so that different types of users can easily input, extract, understand, move, change, and store data using familiar formats and terminology 4. Difficulty of upgrading internal infrastructures to support large bandwidths associated with sharing of data and information 5. Need to provide system security and to protect proprietary data without degrading system efficiency Culture, Management, and Economics 1. Difficulty of justifying a strong corporate commitment to implementing AEE technologies or systems because of their complexity and uncertainties regarding costs, metrics, and benefits 2. Lack of practical metrics for determining the effectiveness of AEE technologies that have been implemented 3. Unknowns concerning the total costs of implementing AEE technologies and systems and the return on investment 4. Difficulty of securing funding to cover the often high initial and maintenance costs of new AEE technologies and systems in a cost-constrained environment 5. Risk—and someone to assume the risk (management, system providers, or customers) 6. Planning and timing issues—when to bring in the new and retire the old 7. Difficulty of managing constant change as vendors continually upgrade AEE tools and other technologies 8. Diversity of cultures among different units of the same company Education and Training 1. Need to upgrade labor force skills along with technology and tools to support an AEE capability 2. Difficulty of incorporating AEE technologies into university design curricula for hardware systems from one vendor may be incompatible with systems from other vendors. Standards have been used in many fields to prevent or correct interoperability problems associated with, for example, tool interfaces, files, and data terminology and definitions. Some standards are formally approved for industry-wide applications. In other cases, informal standards serve as ad hoc guidelines for individual companies or small groups of companies working on joint projects. The committee reviewed engineering environments used by various government agencies and industries and found that in all cases users perceived the lack of general standards for engineering processes, work practices, and support systems as a major problem. Although many of the organizations had documented processes for their engineering enterprise, few actually adhered to them, and there was not enough continuity or commonality among the elements of individual organizations, especially between research and operational elements. One way to create highly integrated AEEs is through the use of open architectures that allow the insertion of new elements using interfaces designed in accordance with predefined standards. Open architectures would extend the shelf life of AEE system architectures and reduce the cost of implementation and training by allowing system capabilities to change with minimal impact on user interfaces. A major impediment to establishing "official" industry-wide standards is that the coordination and approval process takes years, which is much longer than the life cycle of many technologies. Also, economic and business factors seem to provide little incentive for software companies to create standards-based solutions to compatibility problems. The user community—in individual industries and, in some cases, within individual companies—has not been able to reach consensus on appropriate standards, and, thus, it has been unable to motivate vendors to provide interoperable tools and systems. As a result, state-of-the-art technology and standards-based technology may be mutually exclusive, at least in the near term. The committee believes it may be time to develop an alternative approach, such as a process for generating, rapidly approving, and frequently updating flexible, change-tolerant standards. Another solution would be to adopt tiered guidelines, with high-level information technology standards to govern communications in a particular industry and technology standards (e.g., SQL, OLE, or HTML) as local guidelines for individual organizations or major facilities in an organization. Individual projects could then use industry-wide and organizational standards to guide the development of new tools, and software vendors could produce tools compatible with industry standards for specific markets. In any case, standards should be developed with care because overly restrictive or poorly chosen standards would hinder, rather than foster, the development and application of advanced new tools and systems. Even if new tools and systems are highly interoperable,

OCR for page 29
AEEs will not become a practical reality unless they can be effectively integrated with legacy tools and systems. This is an immediate issue when assessing the practicality of inserting AEE technologies into an existing product environment. For example, the Electric Boat Division of General Dynamics created more than 6,000 programs (more than 4.5 million lines of code) to integrate its design, analysis, manufacturing, and program management tools with CATIA. This effort has generated important improvements in the design process, but seamlessly integrating the analysis process with the CAD process will require much additional work. Another complicating factor is the increasing complexity of software tools and hardware systems. Companies must do more than simply integrate their processes internally. Increasingly, manufacturers are focusing their expertise on the assembly of products using systems, subsystems, and components provided by others. Currently, one-half to three-quarters of product costs may be associated with suppliers and subcontractors, and manufacturers' labor costs are reduced if suppliers provide subassemblies that are easily assembled. This requires closely involving first-tier suppliers in the design and manufacturing development process. Thus, external interfaces are becoming just as critical as internal interfaces, and engineering and design systems must be integrated across organizational boundaries. For example, DaimlerChrysler requires first-tier suppliers on some projects to use the same CAD/CAM software tools as DaimlerChrysler. Information Management One of the important advantages of AEEs will be the capability to construct, analyze, and test new designs and processes quickly in a simulated environment. Because this process will not involve building physical models, it will be possible to assess a much larger number of designs than with traditional methods. Also, because the collection of test data will not be constrained by physical instruments, the amount of data that can be collected will be limitless. With sophisticated new analysis methods, AEEs will generate tremendous volumes of data, even for relatively mundane products. This capability could become a critical barrier to the effective use of AEEs, however, if a flood of data hinders rather than facilitates an in-depth understanding of how new designs will perform. Another serious challenge associated with the development and long-term use of virtual and distributed environments, such as AEEs, is configuration management (i.e., making sure that all engineering orders and other design changes are reflected in the simulations and models used to create and evaluate new designs and design changes). Configuration management has traditionally been used just for products, but it is being expanded to include processes and resources. This can be complicated. The same products may be manufactured in different plants, in different countries, with different tools, and by workers with very different skills. International sales often require that manufacturers provide economic offsets. As a result, advanced technology products may be produced in both the United States and foreign countries. In countries with very low labor costs, manufacturing processes tend to involve more manual labor and less automation than in a U.S. factory making the same products. The design process, simulations, and change-control system must be able to accommodate these differences. Given projected rates of software obsolescence, the life spans of many products will vastly exceed the life span of the software used to develop them. For some products, design, analysis, and decision processes used today will have to be accessible in 20 or 30 years to facilitate reviews, redesigns, and upgrades that may occur late in the product life cycle. This will require long-term compatibility of current systems with future systems. For example, when Boeing upgrades its CAD software, legacy data are migrated upward into the upgraded software, but it is also retained in the original format. Retention of original data is required by the Federal Aviation Administration to enable reviews of the original product definition during accident investigations, certification of design modifications, and other purposes. However, problems associated with ensuring the usability of original, computer-generated data in native formats for decades have yet to be resolved. Organizations reviewed by the committee have, in general, made good progress in making computer systems available to their workers, although some variability in performance is common. The principal infrastructure barrier cited by these organizations was network availability and bandwidth. A related concern was the lack of connectivity between organizational intranets and the Internet, which inhibits interorganizational sharing of data. In many cases, this lack of connectivity is intentional because of security considerations. Although the utility of AEEs would generally be increased by technologies that facilitate the rapid exchange of information among system elements, AEE designers will also have to provide security to protect against the careless alteration or deletion of data, blatant vandalism (erasing files or data), and more subtle sabotage (altering data). Most data and software produced by government agencies are in the public domain, but it is essential that AEEs protect proprietary data in projects with industry participation. AEEs should prevent unauthorized users from gaining access to the system and allow organizations involved in cooperative enterprises to use proprietary data in some analyses without revealing that data to the other partners. Project participants must also resolve the issue of who will be liable if incorrect data caused by errors or vandalism in one organization's portion of an engineering effort are unknowingly passed along to other organizations.

OCR for page 29
Culture, Management, and Economics Even when new AEE technologies are ready for use, they will have to overcome cultural barriers that often prevent innovative technologies and methods from being used. Senior and middle managers must learn what is possible because without their support it is unlikely that AEE technologies or systems will be implemented and used to their full potential. For example, AEEs do not fit the traditional cost-time curve for new product development and acquisition. Additional resources will be needed early in the product development cycle to carry out the sophisticated analyses and simulations that are characteristic of AEE-based acquisitions. Senior managers will also have to ensure that personnel maintain proficiency with new AEE technologies and systems, even if this periodically causes short-term reductions in productivity. AEE advocates argue that AEEs can reduce costs throughout the product life cycle. Implementing new AEE technologies, however, can be expensive. Two of the largest costs in moving to a new CAD tool, for instance, are the training of personnel and the translation of legacy data. AEE technologies and systems will also incur substantial ongoing costs to keep tools, systems, and staff training up to date. Additional expenses will be incurred when AEEs are applied to new design problems. AEE simulations can reduce the need to conduct physical tests of new designs, but only if the simulations have been validated. Once an AEE technology has been implemented, it is difficult to prove that it is responsible for reduced costs or increased quality. AEE technologies generally reduce the size of the engineering staff required for a given project, and staff size is easy to measure. The overall effectiveness of a design process, however, can be very difficult to measure, especially because a cost estimating function—for the final product and for the design process itself—is not part of most design processes. In addition, many variables are usually at work while AEE technologies are being implemented, and isolating the effects of individual factors on costs or quality is usually not feasible. Even if advanced design processes have the potential to improve product quality and increase profits in the long term, a company may be more concerned with near-term profits. A large investment in new infrastructure with an uncertain payoff may not be viewed favorably by business managers who must decide whether to accept the risk. Ideally, business decisions would be guided by metrics that predict the future performance of AEEs in specific applications and, once implemented, measure the success of AEEs in reaching specified goals. These metrics are not currently available. Similar factors will also affect the implementation of AEE technologies and systems by government agencies. Managers of major acquisition programs with fixed budgets are generally reluctant to fund AEE activities unless they can be justified by a positive return on investment during the lifetime of that program. Unfortunately, the lifetime of many programs is too short to justify a large investment in new computer systems, software tools, and related infrastructure. Furthermore, program managers at agencies like NASA are often involved in complex first- or one-of-a-kind missions, such as the international space station or a planetary exploration mission. Using AEE simulations to replace physical tests on these missions would be especially risky without reliable methods for continuously validating the simulations. Models and simulations are generally based on past experience, but when they are applied to first-of-a-kind applications they must be extrapolated into new, untested territory. In these situations, program managers are faced with the challenge of assessing how well the applicable physics is known and how well it has been modeled. Overcoming this challenge often requires that program managers and technical experts work together to develop implementation plans that are consistent with organizational goals, existing processes, and available resources. Involving key vendors, subcontractors, and customers, as appropriate, can also help reduce risk. In situations where conventional methods are particularly expensive and/or time consuming, it becomes easier to demonstrate the advantages of AEE alternatives in terms of cost and risk. For example, NASA's involvement in the development of improved training systems using AEE technologies is motivated by the high cost of traditional astronaut training methods. NASA's space shuttle training facilities were expensive to acquire (about $250 million for three shuttle simulators) and are expensive to operate (about $40,000 per hour for a shuttle simulator). The quality of current training systems is generally satisfactory, however, so NASA's primary motivation is reducing costs without degrading effectiveness. A substantial amount of money would be saved if NASA were able to shut down one or two shuttle simulators and replace them with comparable virtual reality training facilities. Education and Training One barrier to the use of state-of-the-art engineering and design tools is the steep learning curve. It currently takes an individual about three or four months to become proficient with some tools, and proficiency may be greatly degraded after six months of inactivity. Industry and government employers bear most of the training burden. Universities believe (and the committee agrees) that the university educational mission generally does not include the task of training students to become proficient with particular software packages. AEEs should be designed to make use of the system as natural as possible to minimize the need for specialized training. Even so, education and training will be essential to teach people how to use AEE tools and how the results of their work will be used by others, so that output data produced in

OCR for page 29
one phase or element of a project meets the informational requirements of other phases and elements. In addition, senior personnel, in what amounts to a technical mentoring role, should ensure that AEEs are used consistently within a given project or organization. Training must be consistent and continually available to refresh existing staff and to support new users. In some cases, investments in new training technologies may be warranted. For example, AEEs could themselves be used to facilitate training. Training is also a concern because sometimes software changes faster than staff can be trained. Therefore, some companies may replace comprehensive training on new tools with a strategy that trains staff to perform specific software functions only as needed. This would reduce unnecessary training, shorten the time between training and practical application, and minimize the need for retraining.