Back to FAQ



   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 softwaredriven systems in DoD, to include our weapon
   systems, commandandcontrol systems, intelligence systems,
   combatsupport systems, business systems, and all other
   managementinformation systems. As most of you know that have heard me
   talk about managementinformation systems and commandandcontrol
   systems, I consider them as one and the same or interchangeable terms.
   The same goes for intelligence systems, business systems, and
   combatsupport systems. So I firmly believe that the need for Ada as
   the standard programming language is essential for all of our DoD
   softwaredriven 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 higherorderlanguage
   availability to the softwaredevelopment 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 offtheshelf 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 offtheshelf] 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 objectoriented programming,
     * enhancements for realtime 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
     * proofofconcept 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 softwaredriven 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, failsafe 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 longterm 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 highquality 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 weaponsystem 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 highrisk for other languages
   applications as transportationcontrol networks, submarinecombat
   systems, medical systems, warning receivers for electronicwarfare
   systems, and controllers for airtoair 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 wordprocessing 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 handsoff 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 DoDwide
   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
   threeyear 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, DoDwide 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
   commercialofftheshelf software and the ability to reuse 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 errorfree
   interfaces among software modules. This also makes Ada ideal for being
   the glue between software modules written in other languages. Its
   strong control and dataspecification 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 softwareengineering 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 costeffective 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 domainspecific
   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
   departmentwide 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 reengineered, that
   is, changeable to fit changing times.

   Education

   It is ironic that, while VicePresident Gore is urging us to move from
   the industrial age to the information age, our information systems are
   often hindrances to reengineering 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 softwareengineering courses, students are exposed to
   software excellence from the start. It reinforces the value of
   adhering to valid softwareengineering 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 shortterm,
   quickprofit 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 dualuse. 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.