Assistant Secretary of Defense Reaffirms DoD Commitment to Ada Remarks by the Hon. Emmett Paige, Jr., Assistant Secretary of Defense for Command, Control, Communications and Intelligence, March 24, 1994, at the Twelfth Annual National Conference on Ada Technology, held in Williamsburg, Va. (Mr. Paige retired from the Army in 1988 as a Lieutenant General, his last position being head of the U.S. Army Information Systems Command.) Good morning. It is indeed a pleasure to be with you again. As most of you know, my command -- with Jim Schell as the quarterback -- started these sessions quite a few years ago, with the first conference being held in Atlanta at Morehouse University in the Martin Luther King Auditorium. So I am no stranger to most of you. You already know that I view Ada as fundamental to the success of automated software-driven systems in DoD, to include our weapon systems, command-and-control systems, intelligence systems, combat-support systems, business systems, and all other management-information systems. As most of you know that have heard me talk about management-information systems and command-and-control systems, I consider them as one and the same or interchangeable terms. The same goes for intelligence systems, business systems, and combat-support systems. So I firmly believe that the need for Ada as the standard programming language is essential for all of our DoD software-driven systems where DoD will be responsible for lifecycle maintenance and software support. The cost of software lifecycle maintenance was one of the driving factors in the DoD thrust to develop Ada back in the late 1970's. The cost of maintenance has not gone down. If anything, it has increased. Another driving factor was the need for transportability of software across platforms. Again, that need has not gone away. Our need for transportability is as great today as it ever was. Another driving factor was the need for reliability. Again, that need is still with us as much as it ever was. Let there be no doubt, C and C++ have made a difference in terms of availability of quality higher-order-language availability to the software-development world, but there are almost as many versions of those languages as there are versions of the Spanish language. There is no single standard, and the quality and reliability do not match that of Ada. So, with those declarations as an entree, I will proceed. Continue on course I believe we must continue and accelerate our efforts to achieve truly integrated systems. Ada is vital to reaching this promised land of information availability to all users when they need it, as they need it, no matter where they need it. But Ada alone is not the answer. We need a whole suite of things, from compilers to [relational database management systems] RDBMSs. Above all else, we need the full commitment of our managers at all levels to comply with the policies and standards that are established by [the Office of the Secretary of Defense] OSD. We need the commitment of our managers at all levels to comply with the full intent and spirit of legislative language as it comes from Congress. This morning, I'd like to look first at the status of Ada itself, then at the overall context of software engineering. Finally, I want to place all this within the context of where we are going in terms of overall technological progress as I view the world from my vantage point. I suppose you've heard me called an Ada zealot or an Ada fanatic. I want you to know that I am neither. Winston Churchill once said that a fanatic was someone who can't change his mind and won't change the subject. Well, I am here to tell you that I can and will change my mind when given the facts to do so. I have not been given any facts that convince me that Ada is a bad business decision for the DoD or that it is not superior to anything else that exists. Those of you that have been around should recall my warnings of the past that Ada must be dynamic. It must continue to evolve and meet the needs of the DoD. I believe it is doing that. However, I must admit that the process is a lot slower than I would like, but that's the price we must pay for being an international standard. As for changing the subject, I would be happy to change the subject when there is no longer a reason to talk about software programming languages in DoD. The DoD policy on the use of Ada is clear and simple. We will use commercial off-the-shelf software as much as possible, and that means we will depend on the marketplace for lifecycle maintenance and support. There is no reason for us to develop software and be responsible for updating and maintenance when the commercial base and demands from the marketplace will cause industry to do that. When DoD needs to develop new code, which means we will be responsible for lifecycle maintenance and support, we will write it in Ada. This includes the code for interfacing among [commercial off-the-shelf] COTS packages and for interfacing among systems supporting various defense functions. Early use of Ada 9X Ada itself is still growing, and I look forward to the widespread availability of the new features that are being added to Ada 9X to make Ada easier to use and more amenable to working with modules written in other languages. I recently approved use of the Ada 9X compilers in certain cases prior to full approval of the updated standard. Ada 9X has progressed to the point that we are confident of its approval by the national and international standards body this year. We want to ease the transition to the new version. We also want to give the earliest possible access to the new version's many enhancements. These include full support for object-oriented programming, enhancements for real-time programming, and convenient interfacing to other languages and systems. I want to stress that DoD is not in any way diluting the consistent power of Ada, which comes from using only compilers that have been validated. What we are doing is expediting the availability of Ada enhancements that are soon to come. The interim use of unvalidated Ada 9X compilers is restricted to: research and development programs proof-of-concept prototypes, as long as any subsequent system is delivered using validated Ada 9X compilers, and system development programs, also with the proviso that subsequent production systems use validated Ada 9X compilers. We are streamlining access to Ada 9X so that we can obtain more quickly the benefits of its use. This is in keeping this administration's goals of streamlining the way our government works. We can still maintain our emphasis on standardization of the language while facilitating access to the upcoming version. Getting information where it's needed The President has challenged us with making our government work better and cost less. Ada is a major contributor to doing this with regard to our software-driven systems. I realize that there are a number of people here from outside the government, but what I am talking about just makes good business and technical sense in terms of software development and maintenance. More importantly, this translates to better service for the users of our systems throughout the department of defense. Our ultimate customer is the warfighter and the people of this great nation of ours. This is my focus. We must give our warfighters the right information at the right location at the right time. And access must remain constant and easy even in the worst of circumstances. Our information systems must help to cut through the fog of war, rather than add to it by being unwieldy, complicated, inconsistent, unreliable, or just plain unavailable. We owe the people of this country the best possible support to our fighting forces at the most affordable price. I am convinced that our declared software policies will ensure that we do just that. Strengths of the language There are a number of steps that we can take to upgrading the quality of our software and information systems. One way is to stick to programming practices that produce reliable, fail-safe code. I believe that Ada does this. I realize that using Ada does not appeal to hackers who like to dabble with pointers and bits, but we are not interested in quick fixes that endanger long-term operations. This is not to say that quality software can't be written in other languages. It can. But maintaining it is much easier if the code is Ada, and it will likely be vastly more reliable. This is also not to say that high-quality software can't be developed quickly in other languages. But this usually is restricted to relatively small programs when dealing in other than Ada. I am pleased to hear about what is being called the "Ada effect" -- when software development is completed before the hardware platform is procured, or before the weapon-system platform is completed. I feel that I am no longer a voice crying in the wilderness about the advantages of Ada, when I hear about the success stories due to its use. And some of the most successful applications are in areas that would have been considered as high-risk for other languages -- applications as transportation-control networks, submarine-combat systems, medical systems, warning receivers for electronic-warfare systems, and controllers for air-to-air missiles. Other Ada users are finding that they can more easily adapt to their customers' needs. For financial services, public utilities, satellite communications, and steel mills, Ada is giving the adaptability we must achieve in the software industry to put our users in their proper place -- in the driver's seat. Our users often see software developers as outsiders, who say they will make work easier, but instead introduce all sorts of bells and whistles, added steps and menus. An everyday example is in commercial word-processing software, where added power sometimes comes at the expense of added keystrokes. Another example is a radar display that shows the flight path of an airplane, but does not simultaneously display altitude data or whether the aircraft is ascending or descending. In the time to switch between applications -- or even to make the human decision that such a switch is necessary -- disaster can occur. Support from the top The need for seamless, adaptable, reliable software should make the use of Ada an obvious choice. And I suppose that testimonials on the success of Ada, such as those available through the Ada Information Clearinghouse, should make persuasive arguments for the use of Ada. But it appears that more aggressive steps are needed, and hopefully, we are taking them. Perhaps I am preaching to the Ada choir at this point, so let's take a look at the use of Ada along with other information technology standards. As a taxpayer, I am appalled at the hands-off approach that has been taken to enforcement of standards in the past. Those days are gone. I do not believe we have had good enforcement. We are moving out with enforcement of language standards, data standards, and DoD-wide standard systems to support each defense function. We will enforce the standards and policies as a part of the [Defense Acquisition Board] DAB process with the C3I systems review group, and also the [Major Automated Information Systems Review Council] MAISRC process. Across the DoD, we are in the midst of bringing down our number of information systems to one per function. DoD is taking this on as a top management issue, and by the end of this month each functional leader will determine which of its legacy systems will be continued as a department standard. Each leader will also plan for the elimination of all other legacy systems on a three-year timetable. Our move to standard data will occur over the same three years. The step beyond both of these is to optimize the operations within and among the functions. This includes both functions being supported by the target systems and the target systems themselves. Adapting to change But let's look first at the move to standard, DoD-wide migration systems. All decisions are being based on a single set of criteria that cover functional, technical, and programmatic factors, along with the ability to support use of standard data. I'd like to give you a few details on the technical criteria. An overarching goal in setting our technical criteria is to plan for change. Many of these parallel the design criteria that resulted in the development of Ada, such as reliability, maintainability, and machine independence. In addition, we look for use of Ada or the ability to transition to Ada. We also look for the applicability of commercial-off-the-shelf software and the ability to re-use software as much as possible. We seek to leverage as much of our existing resources and investments as possible. The future of defense information systems is much the same as for defense weapon systems -- instead of starting from scratch to obtain new capabilities, we will build upon existing capabilities as much as possible. We will have more of what is seen as product improvements or technology insertion rather than the development of whole or completely new systems. We will reuse software to the fullest extent possible. Ada, with its strong typing, is well suited for reuse, since it supports error-free interfaces among software modules. This also makes Ada ideal for being the glue between software modules written in other languages. Its strong control and data-specification features can act as filters for errors that may have been introduced or brought to light in the combining of dissimilar or separately developed modules. As you already know, Ada is also conducive to reuse because of its reliance on sound software-engineering principles. As you already know, Ada is meant to produce independent, verifiable software components that can be combined and recombined in various ways. We must get on with fully exploiting Ada by concentrating on building the right things once and then reusing them. The overarching problem thus becomes that of establishing the framework for combining reusable software modules. The basic structure or architecture determines how well a system can evolve, be enhanced, or be reused in a way that is cost-effective and still responsive to user needs. We are placing more emphasis on development of domain models and domain architectures in which we will fit our reusable Ada code. DoD has several pilot projects underway for developing domain-specific models. Hopefully, these will become the frameworks for the future. The days of focusing only on code are over. Our emphasis includes overall functional architectures and their integration into a department-wide whole. Professionalism I would like for you to consider in human terms the implications of our view of software, which is engineered within an overarching framework, which is within the context of overall user and mission support. Consider first the software engineers. As I see it, some people confuse software scientists and software engineers. The scientists are on the cutting edge of research and are pushing the envelope of what can be done technologically. Engineers are usually devoted more to practical applications and implement the technology to a specific task. In my view, software engineering is among the youngest members of the engineering family. As of yet, software engineering is not a profession in the sense of having a basic core of knowledge, education, and standards associated with it. I am encouraged by the work begun by the IEEE Computer Society last spring to take a look at establishing software engineering as a profession. They are looking at standard definitions, the required body of knowledge, recommended practices, ethical considerations, and educational curricula. Whether or not this results in formal licensing or certification, this will emphasize rigor in the software development process across the board. This type of rigor is already implicit in the use of Ada. And the use of Ada results in systems that are engineered to be re-engineered, that is, changeable to fit changing times. Education It is ironic that, while Vice-President Gore is urging us to move from the industrial age to the information age, our information systems are often hindrances to re-engineering our business processes. Adaptability to new situations, new customers, and new business processes should be built into our systems. And it should be instilled into our people, by which I mean all of our software professionals. For this we rely on the curricula of our colleges and universities. By using Ada in software-engineering courses, students are exposed to software excellence from the start. It reinforces the value of adhering to valid software-engineering principles and demonstrates that software skill is a larger construct than just the writing of clever code. I am not alone in holding this view. The free Ada compiler for educational users has been downloaded by over 4,000 users in its DOS form since September 1993. There were an additional one thousand users in the first three weeks of the Macintosh version's availability in January 1994. People skills in programming Ada was developed with the understanding that programming is a human activity. We should keep this precept in mind with other aspects of the preparation of our future software engineers. We cannot overlook the people skills that are involved. Allow me to elaborate on a few of these: Our engineers must be more attuned to listening to user requirements. Our engineers must be more flexible in changing their own work products. A solution that was perfect yesterday may be inadequate for tomorrow's requirements. Our engineers must be immunized against a "not invented here" syndrome. The flip side of this is that our engineers must be open to sharing their results and using it to leverage the work of others. And all of these go double for the managers. We cannot ask any more of our engineers than we ask of ourselves. As a technical manager for the DoD, I find that our customers have increased their expectations of what information technology can do for them. I find these increased expectations to be well founded. For not only do we have the technologies at our fingertips for making great change, we also have an increased spirit of cooperation throughout the leadership of the DoD. Looking ahead Much of the defense leadership has a solid background in the corporate world. We have seen the problems introduced by the short-term, quick-profit thinking. We have steered corporations through storms created by international competition -- we've even stirred up some of the storms ourselves. We have all become accustomed to the fantastic rate of innovation in the information technology realm. We also know that real value of the new technologies come from the use. For instance, the national information superhighway, in and of itself, is interesting technologically. But when we see what it can bring in terms of educational, medical, and other personal terms, the superhighway becomes an exciting way to improve the quality of life throughout our country. For the information superhighway, we are relying primarily on the private sector for innovation and development. This is in keeping with this administration's emphasis on breaking down barriers between our government and the corporate world and with academia. We are forming new partnerships to improve our technology base and the resulting products and services. Our Ada programs exemplify the progress that can be made through these partnerships. We are placing special emphasis on dual-use. We look forward to further gains from the increased use of Ada we anticipate following the availability of validated Ada 9X compilers. Finding solutions together The increased reliance on computers in government and industry and in our homes and schools means that our software must be increasingly reliable, adaptable, and accurate. And our costs must drop. To do this in DoD, we have chosen the path of reusable Ada software. I appreciate your attention this morning. I would be glad to entertain any questions that you may have. Let there be no doubt that Ada is still alive and well. The detractors will say that it is a relic, a language of the past, a language that has missed its opportunity as the train has left the station and the C++ train has arrived as the silver bullet that we have all been waiting for. I proclaim to you that Ada has not missed the window of opportunity. She is still alive and well. Ada 9X takes a sip from the fountain of youth, and it will be around as the next evolution. Certainly there will and must be something beyond Ada, something beyond C++ and any of the languages or methods that we know today. Hopefully, the R&D community will devote some of their resources to finding the silver bullet that we need. We will not throw the baby out with the bath water. Thank you very much. ********************** Flyer N130-0494c paige394.txt The Ada Information Clearinghouse maintains an electronic copy of this document on the AdaIC's Internet host: sw-eng.falls-church.va.us The views, opinions, and findings contained in this report are those of the author(s) and should not be construed as an official Agency position, policy, or decision, unless so designated by other official documentation. Ada Information Clearinghouse (AdaIC) P.O. Box 1866 Falls Church, VA 22041 Phone: 800/232-4211 or 703/681-2466 Fax: 703/681-2869 E-mail: adainfo@sw-eng.falls-church.va.us The AdaIC is sponsored by the Defense Information Systems Agency's Ada Joint Program Office (DOD/DISA/JIEO/CFSW/AJPO), and operated by IIT Research Institute.