> Unfortunately some folks will read the report an say that Ada is
> inappropriate for development of financial or logistical applications.
> I believe this is not the intent of the report and these people
> have incorrectly interpreted the recommendations. If this is indeed
> the case then I think the report has done a disservice.
We recommended that Ada be considered for any custom 3GL development.
However, the best choice of custom development technology may depend
on what commercial technology the financial or logistical application
Remember, for better or worse, the DoD is strongly committed to
capitalizing on commercial investment in domain areas where that
makes sense. The committee felt that in the high-assurance,
real-time domain, Ada already leads the way, and using Ada had
compelling business and techical advantages for the DoD.
However in other domains, where the commercial investment outside the
DoD dwarfs the DoD's own investments, we felt that the business case for
using Ada was not as clear cut, and the use of Ada should not be
considered a prerequisite in the choice of contractor and development
The point has been made that logistics, and even financial systems, can
be critical to the success of a DoD mission. The committee certainly
agrees with the importance of these domains. However, "importance" did
not necessarily equate with "needing an Ada mandate." The committee
felt that in the logistics and financial systems domain, use of
commercially-based networking, database, and graphical user interface
components (among others) was inevitable, and could in fact produce
a higher quality product on a shorter schedule than a full custom
DoD-unique solution. Given the heavy use of commercially-based
components, we did not believe that using Ada just for the "glue"
was always the right tradeoff. A commercial contractor with
a good "glue factory" for integrating such systems might well do
a higher quality, more cost-effective job if allowed to use
the tools of their own choice, which might or might not be Ada.
When looking at a cost/benefit analysis, it is always easiest to
see the benefits of a favored solution, and the costs of a disfavored
solution. However, any sort of mandate incurs costs, in addition
to potential benefits. In the high-assurance/real-time area,
the committee felt that the cost/benefit analysis for an Ada
mandate was clearly in favor of the mandate, whereas in other domains,
the cost/benefit analysis was not as clear. In particular, the committee
concluded that there were not as many overriding DoD-wide benefits to
enforcing a homogeneous 3GL approach in domains where solutions were
in any case expected to be based on a heterogeneous set of 4GLs and
COTS components (with 3GL glue). In these domains, the committee felt that
it was much more important to establish some kind of Architectural Review
process to make sure that consistency, reuse, and "product-line" thinking
was used in designing and building such systems of systems.
As of today, most DoD systems involving high-assurance and/or real-time
are already written in Ada, and most DoD systems in domains such
as logistics or financial systems are not written in Ada. The committee
did not see any compelling arguments for pushing the Ada mandate heavily
into the logistics or financial systems domain, particularly given
the general DoD move toward capitalizing on commercial investments.
Conversely, the committee felt that Ada has proven to be an excellent
3GL for the creation of the high-assurance, real-time systems in the
DoD. Vigorously promoting the continued use of Ada in this domain
makes excellent business sense, particularly if the current unsatisfactory
"waiver" process is folded into a more encompassing Software
Engineering/Architecture Review process, and the annual AJPO-directed
investment in Ada is beefed up from its current $3Million-and-dropping to
a steady $15Million per year.
Ada is a general purpose language, and as such, can be used productively
and effectively in any domain. However, for the purposes of mandated
use, the committee felt that only in DoD-dominated domains did the DoD
accrue sufficient DoD-wide benefit to justify focusing on a single 3GL.
In other domains, picking the best set of COTS components and tools, and the
best integration contractor, and the best product-line architecture, deserved
more attention than did mandating use of a particular 3GL.
> -Brian Nettleton
> Thomson Software Products
-Tucker Taft [log in to unmask]