Obviously, information warfare technology must be developed, acquired, fielded and sustained before it can be used. This topic seeks to explore whether the defining characteristics of information warfare imply the need for changes in how we acquire such systems.
----------- [Moderator] Given that new generations of commercial information technology come, by some accounts, every 18 months, how do we address the need for a quick acquisition cycle time?
[Campen] We begin by abandoning the term "cycle," or at least redefine it as an open-ended, never-ending series of cycles. Also, we rid ourselves of the obsolescent concept that we are "buying a system." It has been almost 20 years since an AFCEA [Armed Forces Communications and Electronics Association]-run study coined the phrase "evolutionary acquisition" in an effort to make the point that there is never a Final Operational Capability, only a series of buy a little, test a little increments. The DoD Authorization Act of 1996 (HR 1530) makes some useful changes by focusing oversight on the function of an organization and the outputs to be gained from new information technology, and by urging "modular, incremental" procurements of "information technology." But that is not nearly enough for the U.S. to avoid being technically leap-frogged by adversaries that are not crippled by machine-age procurement regulations and cultures, nor burdened with an enormous investment in obsolete legacy systems. I think Navy Commander Loescher is the one to credit with the notion that we no longer procure information systems; instead, we acquire information services. (My words, his idea). We need to visualize the continuous enhancement of information systems in much the same way that we do software upgrades. We know there is always a software revision on the horizon and we program funds accordingly. The Block approach to aircraft upgrades is a step in this direction, but it can't be done if each increment must be refought with the Congress annually. We don't approach Congress with a line item to purchase electricity or water and we ought not need one to purchase INFORMATION SERVICES.
[Cebrowski] Spirited debate surrounding DoD Acquisition reform is not new. However, the strategic environment has changed so significantly since the inception of the current acquisition system that modernization is clearly warranted. A revitalized acquisition system that can keep pace with market forces is the surest way to maintain the most modern weapons systems. The focus should be on capabilities, not systems. The strategy should be one of continuous incremental technology insertion.
[Cochrane] The characteristics of information warfare dictate that a new software or network tool can provide battlefield advantage within hours of its conception. Therefore the research, development and supply chains will require re-engineering to suit. Commercial information technology may go through a generation in less than two years but changes in the fundamental platform and network architectures are much slower. Possession of the very latest technology will be critical to front-line Information Warfare units. More conventional units with less pressing needs could easily be supplied by normal commercial processes. Above all the growth in computing ability has to be allowed for when designing systems and then factoring extra security on top to be safe.
[Cohen] New IT doesn't often mean new underlying uses or techniques_they come far more slowly. Furthermore, for the first 6 months or so, any environment is unstable. The strategy should be to seek out more stable environments for conditions where long-term results are desired_hence you go for Unix and MVS and VMS and other stable environments as opposed to DOS and WINDOWS, etc [Note: these are all different types of computer operating systems]. Furthermore, re-acquiring technology every 18 months is not cost effective. Seek out technology that will last for 5-8 years and build on the more stable base. Abandon the reckless approach in favor of the more solid one. The exception is in experimental environments, where the state-of-the-art should be tracked, and in special cases where a really new capability enables advantages that are so significant that they warrant the extremely increased likelihood of failure associated with new technology.
[Dunnigan] Go commercial or die. Your likely future opponents will not have a military-industrial complex and will automatically go commercial and have the latest stuff.
[Garigue] Our present notion of information system delivery is outdated. We do not deliver systems anymore, we "grow" them. The present maturity of IT permits an organization to adopt a "technology insertion" strategy rather than a system development strategy. As new generation of network components are made available we can insert them readily into existing networks and IT infrastructures. We introduce these components in a prototyping context.
The focal point however is not just on managing the technology but on managing the functionality. As functions have a longer cycle than technology we must ensure that we outline a migration of the stable functions embedded in older technology to the new ones. We must also ensure that such a migration path will ensure the minimal amount of disruption of service over the course of the transition. This way, over time, older technology elements of a network are replaced by newer ones and functions migrate from older hosts to newer ones.
[Giessler] Adopt USN [U.S. Navy] initiative and SECDEF [Secretary of Defense] dictate that COTS is standard unless otherwise strongly justified.
[Gust] We have now begun in the PEO [Program Executive Officer] world an earnest reduction in cycle time. RFPs [Requests for Proposal] are shorter, with fewer CDRLs [Contract Data Requirements List], minimal MILSTDs [Military Standards] for such items as comm waveforms, interoperability, etc. Contract negotiations are now including an oral discussion cycle instead of lengthy IFBs [Invitation for Bid] exchanges of written questions and answers, etc. But still if the new technology cycle is 18 months, we have to do more. One initiative is the POM [Program Objective Memorandum] wedge for unidentified new initiatives. Our Army Chief is asking the Congress for $450M in a wedge to buy the mature, value-added successes from the digitization demo. Another is for the Army TRADOC [Training and Doctrine Command] community to emphasize a reduction in their requirements determination cycle. There are still areas where we can reduce time.
[Hazlett] Lean toward software, vice hardware solutions, ensuring that hardware is easily upgradeable, taking advantage of more powerful chips and faster memory. Go to more modular systems.
[King] First, it is not necessary to always keep up with every new wave of products which is more alike every six months. Second, long term contracts should be developed with vendors who can provide upgrades and new systems over the life of the contract in an efficient manner.
[Loescher] There is a logic set here that we are missing consistently. The InfoTech industry, at this moment, appears to be growing much like the oil industry, automobile industry, power industry, and other markets initiated by broad change in technology. A global infrastructure is being built as the market for goods increases. We are still in the stage where the industry is dominated by engineers, who are attempting to sell specific products. It is analogous to trying to sell spark plugs instead of cars. Gradually, however, the market is becoming one of commodity and service_America Online, Netscape, Java, are all examples of the coming service market. In the future, I would bet acquisition time will become irrelevant_because we're not going to "acquire" it, we're going to buy information services and information itself as a commodity. Acquisition won't matter_C4I is dead; we'll be transitioning to the direct use of information itself, not building information systems, which will all be commercial_and perhaps common to the foe and the friend.
[Probst] Use ATDs [Advanced Technology Demonstrations].
[Schwartau] In basic COTS PCs this is true, but integration of complex systems requires greater development and testing time. The key here is platform and O/S [Operating Systems] standards, backward compatibility and an acquisition awareness that what is RFI'd [Request for Information] today is obsolete by the time the buy occurs. I would examine acquisitions which permit the upgrade of systems performance to current standards as of the date of purchase.
[Steele] Functional standards (as opposed to fixed standards), and true openness and inter-operability, are critical. HOWEVER, also critical are the identification and legislation of standards of security and other basic forms of functionality which must be embedded in all civil communications and computing capabilities in as much as 95% of DoD traffic goes over same. It is NOT possible to BUY what we need. It is only possible to LEASE, TEMPORARILY, civil capabilities in this area. The real progress will come not from firewalling internal unilateral systems, but from raising the generic security and capability of the ENTIRE global network.
[Todd] In the past, the U.S. military has done a dismal job of integrating information systems. That, however, has been a blessing in disguises in that our "system of systems" have not been susceptible to contamination (either malicious or accidental). But future systems should be easier to integrate and as such, we need to ensure these systems while acting independent are yet able to communicate among them (linked). Fully integrated systems may be like a house of cards and if attacked, not degrade gracefully.
----------- [Moderator] Should there be a shift from hardware to software orientation in development? Should we lease hardware and concentrate our efforts on incrementally improving software?
[Campen] The functionality comes from the software; the hardware will provide the bits and the bandwidth accordingly and automatically. The emphasis should be on the leasing, acquisition or rental of information services, with each new increment improving functionality, speed, accuracy, security and reliability.
[Cebrowski] Warfighting requirements will always dictate development decisions while economies prevail in decisions to lease or own. Advancing technology itself has hardware and software on a natural collision course_neither will dominate, instead both will fuse into mutual dependence. The more important question is how to shift funding and management attention to the requirement and design phases rather than waiting for problems to become big and intractable.
[Cochrane] The split between hardware and software is somewhat arbitrary: you cannot divorce them in this way. (Why should you trust hardware more than software? There could be just as many problems in the silicon_storing away keys which are picked up by a "maintenance" visit for example) We must always consider the whole system, stop looking at elements in isolation, concentrating on reducing the time taken to develop integrated hardware and software solutions.
[Cohen] Leasing hardware is an extraordinarily poor investment. It's almost always better to buy the hardware and convert older systems for less than state-of-the-art uses. For example, even a 5-year old PC is still perfectly capable of being used for office automation functions.
[Dunnigan] This has already been going on.
[Garigue] We should buy hardware like we buy food. So that it can be consumed rapidly (if you don't it goes bad very quickly). Software on the other hand are the functions that are required whatever the hardware. Software is the essence of the system as it represents the processes required to support the decision maker. Computers are consumable. Most of the critical components of the network are already in the commercial sector anyway; what makes systems "military" are the fact that the tools and the technology are applied to military problems.
Software itself is being modularized and becoming more and more generic. So there is an opportunity to take advantage of this and tailor some systems to our needs. The point in all this is to know when our requirements for timeliness, pertinence, accuracy of the data cannot be meet by the existing components and to custom design our own solutions.
[Giessler] We should not be developing either hardware or software in the military or the national security establishment unless the commercial market is not meeting our needs because there is insufficient profitable demand. Even our interoperability needs should be met by commercial interface packages.
[Gust] We in the Army night vision business have a unique incident that we are working. During Desert Storm we bought an overstock of Generation I tubes that are now obsolete. Since we have moved on to Generation II FLIR [Forward Looking Infrared] technology, can we salvage any of this "sunk cost"? The answer is we may have found a way to sell back to the contractor the older versions for their direct sale to other customers, then receive credit on the contract to buy new Generation II devices. Lease of hardware is probably a better option for a weapons platform of less dubious value, like a truck. Every system the Army is buying now is specifying the Common Operating Environment and Army Architecture standard version 4.0. This is a flexible format conducive to the use of software upgrades as a process for insertion of increased capability.
[Hazlett] Yes, we should shift to software solutions where possible, leasing and outsourcing hardware where possible. May need to develop "wrappers" or metaphors to deal with unruly or yet-to-be-developed components.
[King] Yes, in most cases, the emphasis should be on software but changes in hardware technologies need to be monitored.
[Loescher] We should concentrate on identifying and categorizing information families and let the commercial world worry about hardware and software. If the future, the intelligence communities will become less and less useful, though that may be their best kept secret yet. The best intelligence, especially for Information Warfare, is going to come from industry sources_much like it did in the early days of World War II. I'm not going to want to know what DIA thinks about Guatemala, I'm going to want to know what the Guatemalan information infrastructure is_that's not going to come from DIA, or NSA, or CIA, that'll come from the commercial sector that does business in Guatemala.
[Probst] The situation is more complex than that. In large part, DoD needs to use third-party parallel hardware and software. DoD also needs to articulate the parallel hardware and software at the margin that will not be available elsewhere. Certainly the bulk of DoD time will be spent in writing defense applications, taking advantage of reuse wherever possible.
[Schwartau] Software must be improved in two ways: - Quality of testing and reliability through the use of better automated development tools. - Standards for platform migration will alleviate the constant need for total redesign every time a new hardware widget comes along.
[Steele] Not hardware, not software, NOT EVEN DATA COLLECTION. Our focus should not be on technology, except in-so-far as we mandate certain standards of performance, but rather on "intelligence," meaning; what information can be discovered, discriminated, distilled, and disseminated to the commander so as to enhance mission fulfillment? Taking SPOT Imagery as an example: it is not necessary to mandate anything other than the fact that we need 1:50,000 with contour lines and precision points (either GPS [Global Positioning System] or NRO [National Reconnaissance Office]).
----------- [Moderator] With an increasing array of new commercial information technologies, who should be responsible for finding these new capabilities and how should we conduct commercial-military integration?
[Campen] The user, not some surrogate electronic arsenal attempting to craft a formal ROC [Required Operational Capability]. The Air Force Fort Franklin shows the way by providing an environment for experimentation, testing and functional demonstration.
[Cebrowski] The technologist must inform his potential customer, the operator_and operator must inform technologists. We shouldn't be concerned about commercial-military integration. The DoD should buy the 70-80 percent solution from industry; then reengineer business practices and requirements to make that a 100 percent solution. We can't afford otherwise.
[Cochrane] Integration is the wrong approach. Ordinary commercial organisations are becoming more aware of the need to have secure systems and therefore demanding the same strength as military products. If the military were to specify their needs at an early stage the commercial systems would be developed to the military requirements. This would produce economies of scale, reducing the costs of military systems. The military would no longer have to identify the capabilities of systems they were getting because they specified the capabilities.
[Cohen] You might try having an advanced technology group in the DoD that constantly seeks out new and useful technologies and applications and forwards information on these new developments to the appropriate other groups for consideration.
[Dunnigan] Someone in the military, I hope
[Garigue] All organizations need to be doing some type of technology assessment activity. Comparing the recent developments in the commercial world with military requirements in test laboratories and doing technology insertion proof of concepts are a good way to "test and try."
[Giessler] The ultimate user should find the acquisition with the aid of people at places like NRAD, ESC, NRL, ARL [Note: these are all military acquisition or research organizations], service labs and academic places like NPS. This is going to be the toughest partHow to stay current and adapt/adopt/acquire/find/be aware of the available and useful technology. JWIDs [Joint Warrior Interoperability Demonstrations], Ft. Franklin, and ACTDs etc., will have to be used as well as displays at shows and conferences. We may find that we have to put DoD people out in industry just so we can keep abreast of what is going to be available. It may require a new specialty officer called the information science and technologist.
[Gust] The responsible party should be consensus forums, not single function activities like ARPA [Advanced Research Projects Agency], laboratories or PMs [Program Managers]. Using ACTDs [Advanced Concept Technology Demonstrations] from the R&D community results in the follow-on program fund lines to have in them a source of leave-behind funding for O&M [Operations and Maintenance] commands to evaluate in the field for two years. Also, fund lines need a production wedge for those R&D initiatives that will mature shortly, i.e., those funded at a 6.3 or 6.4 [Note: these are different kinds of R&D monies] maturity level.
[Hazlett] Need to coordinate information management across the services and agencies. Take better advantage of economies of scale, like needs and like requirements.
[King] There needs to be a group that keeps up to date on changes and can understand which new items are worth incorporating into the existing systems. It is probably best to outsource as much of the actual integration work as possible.
[Loescher] I disagree with the premise. The "array" of commercial information technologies is becoming more and more homogeneous, as standards become valuable to the marketplace. Thus, an information system for MacDonald's in the future will be much like that for DoD_they'll just need different information in different times and places.
[Probst] Well-trained specialists with reasonable career paths.
[Schwartau] I have no earthy idea how to solve this. How about establishing a technology excellence center, a sort of government help desk, which is staffed to address questions from interested acquisition officers on what the latest and greatest is. This center should also track the real-world commercial implementation of advanced technology, most notably in the financial arenas. Why reinvent the wheel for the sake of job security?
[Steele] Let the free market work its magic. Our biggest enemy now is misplaced security constraints which prevent openness, and procurement constraints which give an advantage to beltway bandits skilled at paperwork rather than genuine innovators with something unique to offer. DoD cannot put its house in order by itself; the White House must offer an umbrella program, and a genuine Chief Information Officer network at Undersecretary levels, with real resource authority, or the Services will continue to protect pet rocks and "special arrangements."
----------- [Moderator] Given increased use of commercial parts, should the military rely more on the commercial world for its information technology logistics support? Will it be better to "throw away" a broken system and order a new one rather than maintain the capability to repair it?
[Campen] Don't get trapped by the definition of parts for broken THINGS. Other than a cheap, commercial, dumb, terminal in the field, that does nothing more than accept applets from a global information service supplier, there is nothing to repair. If the dumb terminal is broken, then throw it away. The main concern ought to be ensuring continuity of information services.
[Cebrowski] Generally, yes; but where that is too expensive, do something else like reassess the requirement.
[Cochrane] See previous question. Presume that by "broken" you mean breached security. I would say the "new or repair?" question probably needs to be reviewed on a "per case" basis. However, it is probably safe to say that repair would be a valid option in many cases. The system breach might be fixed easily with little extra cost and with a good deal of confidence in the new level of security, without the worries of implementing a completely new system. If the replace option is taken it may be necessary to run the broken system until a replacement is available, this necessitates a certain level of repair. If a "broken" system were to be replaced it may be redeployed for use with lower grade information thus increasing its lifespan. It may be more economical to replace the infrastructure of the system with a new one.
[Cohen] Waste not want not.
[Dunnigan] The commercial model for operations stresses efficiency, thus it is the one to follow (as the military has done for centuries)
[Garigue] There are no universal rules. The solution must be dictated by the problem and not a policy. In many cases there are good reason to dispose of systems in a rapid way. The fixed cost of repairing some components are not worth it. Better buy replacements. But new components sometimes come at the cost of poor backward compatibility and increased dependence on outside organizations.
[Giessler] Yes to both questions. And often we will throw it away because it is superseded_redistribution will replace maintenance.
[Gust] Actually, PEO-IEW [Program Executive Officer-Intelligence and Electronic Warfare] embarked on a "policy" several years ago that helps to solve this problem. We focused on 6UVME-formatted circuitry. This standard has turned out in industry like the VHS format in video recorders. With an open bus architecture, it is possible to plug in the next generation card and that is better than both repair of the old card or replacement of the entire system.
[Hazlett] The military should rely on civilian components except in those areas where there is no civilian equivalent, or there specific requirements that dictate a "military only" solution. Should go to more modular systems that can be incrementally upgraded, so that there are very few, true "legacy" systems. Upgrades to older systems often cost more over the long run, and provide less capability gains than new, replacement systems.
[King] For standard commercial systems, there are several vendors that can provide worldwide support. It is normally best to keep spare systems/components and switch to those while repairing the broken units. The repair versus throw-away decision should be based on economics.
[Loescher] It's better to do neither. We should lease the infrastructure and pay for it on our monthly "information bill."
[Probst] This is basically a question of outsourcing. If your source is competent, and will always be there for you, fine. Otherwise, watch out.
[Schwartau] That's a pure cost justification decision. Ask the commercial sector how it does it in comparable situations. Also, the IRS should change the depreciation of computer equipment from 5 to 2 years.
[Steele] It depends. On balance, because of the speed with which technology changes, it is NOT cost effective nor performance-mandated to protect legacy systems. In fact, they end up costing 80 cents on the dollar to maintain. However, there are going to be some elements that are not only critical, but too arcane for the private sector_and this leads to an interesting idea: if the private sector does not understand the value of a particular system, then either a) it really does not have a value and the military is overestimating its value or b) we should declassify the threat that inspired our value, and see if the private sector cannot adopt the same standards.