White Paper: DARPA Participation in Industry Standards Development
Organizations
Craig Thompson, Frank Manola
Object Services and Consulting, Inc.
{thompson, fmanola}@objs.com,
972-379-3320
May 19, 1998
The Thesis
The thesis of this white paper is that DARPA should participate more actively
in key standards development organizations (SDOs), especially the Object
Management Group and the World Wide Web Consortium. DARPA needs industry
connections and an open vendor-neutral forum to pin its results to, while
these groups need R&D participation, and can act as technology transition
partners. DARPA will better execute its DoD mission if it becomes actively
involved in leveraging key SDOs as one important means of transferring
technology out of (and back into) its research initiatives. This white
paper suggests a means of building these DARPA-industry relationships.
Synergy will mean accelerated progress, fewer dead-ends, lower DoD costs,
and accelerated impact for technology transition.
Background
The DARPA role is to provide DoD with technology superiority and to prevent
technological surprise. The recent DARPA publication Technology
Transition <http://www.darpa.mil/acrobat/transition.pdf> describes
technologies that DARPA has developed for the Armed Services - a substantial
list. To accomplish its role, DARPA funds leading-edge software research
to insure that future DoD software-driven systems will meet DoD needs.
In recent years, DoD has recognized that to keep software costs in check
it must depend, as much as possible, on commercial-off-the-shelf (COTS)
software. This, in turn, has led to a heavy DoD emphasis on standards-based,
and increasingly on component-based, software, to insure that the COTS
software will interoperate, particularly in a distributed environment.
Where possible, DARPA encourages the use of standards like CORBA and
the Web, as well as de facto standards like Java and DCOM. Much
DARPA research results in prototypes. Especially promising prototypes are
showcased in DoD demonstrations, and more mature technologies are transitioned
to DISA - one effective route for technology transfer directly to DoD.
Ideas from the prototypes, described in papers, often have impact on
industry direction, though the impact is often indirect or intangible.
Few prototypes become products; little of the detailed work influences
industry (COTS) software providers. This is partly because DARPA contractors
are mostly either university researchers or DoD integration contractors,
often not in the business of commercializing software for the COTS marketplace,
so the software remains prototype or one-of-a-kind and tends not to be
widely available at the end of a contract. In addition, few DARPA researchers
or program managers contribute much to industry standards efforts. As a
consequence, DARPA is more an observer and less a player in influencing
and leveraging COTS directions. To summarize, the technology transition
paths from DARPA to DoD and from Industry to DoD are strong but the bidirectional
path from DARPA to the COTS industry needs strengthening. It would be desirable
if DARPA research had a more immediate impact on the COTS software industry
both in influencing broad industry initiatives to meet DoD needs and in
placing specific technologies into the COTS arena.
Increasing DARPA Impact
At a recent meeting with Dave Signori at DARPA we discussed several mechanisms
for increasing DARPA's impact on software industry directions. All these
are subject to the constraint that DARPA should not invest if industry
will anyway. Mechanisms we discussed were:
-
influence key industry standards development organizations. This is the
subject of this white paper and is discussed at length in the remainder
of the paper.
-
influence key industry leaders to develop software to meet DoD needs. In
particular, we discussed creating an industry forum where key COTS software
players are invited to DARPA to discuss technology roadmaps. These might
include Richard Soley (OMG), Tim Berners-Lee (W3C), Marc Andreesson (Netscape),
Jim Mitchell (Javasoft), Microsoft software architects of ActiveX, OLE
DB, ... This would provide DARPA an understanding of industry roadmaps
and also a chance to influence these. Possibly this also offers a chance
for these companies to play a steering committee role in some DARPA programs.
-
sponsor DARPA-industry workshops. An example was the recent OMG-DARPA
Workshop on Compositional Software Architectures <http://www.objs.com/workshops/ws9801/index.html>
which provided a mixing place for industry and DoD practitioners working
on component software and quality of service. The opportunity is to use
such workshops to connect DARPA researchers with industry developers.
-
encourage DARPA researchers to invest more quickly in ActiveX, XML, and
CORBA
-
find ways to make DARPA ISO AITS component technologies and ITO research
components more directly available to third parties for continued development
(both interfaces and implementations).
This list is not meant to be exhaustive. More brainstorming on this topic
would probably yield other technology transfer ideas. Also, the status
of the list is as a collection of technology transfer experiments
- they may be tried out and, if successful, could be selectively institutionalized
where they make sense.
Why DARPA should Participate in Industry SDOs?
Focusing just on the first bullet above, DARPA participation in selected
industry standards development organizations, this is a fruitful avenue
for transferring DARPA technology to and from industry because it can provide
one-stop-shopping for a wide variety of technical discussions with top
industry players. SDOs are vendor-neutral industry forums - they exist
to foster consensus for emerging technologies. While it is unlikely that
DARPA would participate in SDOs that are focused on reaching final consensus
on established practice (e.g., small changes to SQL), many SDOs exist to
provide a way to coalesce development experience into standards so much
larger communities can benefit. Generally, these standards can be viewed
as establishing best practice. This is particularly true in the case of
SDOs such as OMG and W3C, where the standards being developed are based
largely on shipping COTS software, and are targeted at distributed environments
in which standards-based interoperability is essential for systems to function
effectively. Such standards are typically developed very quickly (e.g.,
a year or so) and can have massive impact. SDOs that are developing suites
of standards are essentially creating an organizational data structure
( a kind of industry-wide corporate memory) onto which research results
can be pinned so they are not lost over time. DoD would benefit from participation
by influencing industry directions, getting particular needed standards
in place, and by being an early adopter. The DARPA researcher's role in
participating is based on his/her deep experience and insight into the
subject matter, and the objective of participation is to both accelerate
consensus leading toward standards and to insure that the standards
developed reflect particular DoD requirements that may be overlooked without
this participation.
DARPA Strategy
Not all SDOs are equal. Some lead a substantial portion of the industry.
Others are backwaters. For some key technology areas (man-machine interfaces,
planning) there are no SDOs. Active participation by DARPA in SDOs should
target key organizations that have established a beachhead in a technology
area DARPA feels is mission-critical and in which DARPA is investing research
dollars. In fact, DARPA researchers in such overlap areas are not exercising
due diligence if they are not aware of, and keeping up with, industry standards
in their areas; and in cases where their research can establish or improve
a standard, their not actively participating is a missed opportunity to
transfer technology to a broad open forum where their work is likely to
have significant influence and important visibility.
Standards often take time so DARPA participation should be viewed as
a long term commitment. On the other hand, the relevance of standards groups
can change over time and DARPA should continually assess if participation
is providing value back.
DARPA participation in industry SDOs should be viewed as one of several
technology transition vehicles, where circumstances dictate the right one
to choose for the most effective result. To make an impact in influencing
SDOs, DARPA will need to focus at three levels:
-
DARPA vision and roadmap. The DoD vision is Joint Vision 2010. The
DARPA mission is to insure this vision by providing the needed technology.
Comparing DARPA's interpretation of Vision 2010 requirements against 1998
technologies provides a picture of gaps and weaknesses that DARPA is responsible
for filling. DARPA programs are designed to fill key gaps. Leveraging related
SDOs is one key mechanism for leveraging DARPA research resources.
-
DARPA will need an understanding of the big picture of the standards
landscape. What are the specific SDOs to influence? What is their scope
and roadmap and how do they relate to Vision 2010 and DARPA research programs?
How do they operate and in what time frame can results be expected? How
does one make an impact? The answers for different SDOs are different.
-
To leverage its funds, DARPA will need to do precision targeting,
to affect just those specific standards that DoD needs most and will have
largest impact. This can be done in a variety of ways, by helping SDOs
develop reference architectures, frameworks, and roadmaps; by helping them
draft Requests for Information and Requests for Proposals;
by responding to these; and by providing public domain reference implementations.
Focus is important because, while any level of participation can reap important
benefits, DARPA will obtain maximum value from standards participation
if it has its own agenda, so that it can push distinct DoD requirements,
priorities, and goals that would not otherwise be addressed, or addressed
in the same timeframe. Failure to actively engage with SDOs when the opportunity
is there is at best a missed opportunity. At worst, it means DARPA technology
might diverge from industry directions instead of leading the charge.
Targeting Specific SDOs
In our view, two SDOs should be at the top of the DARPA software target
list. OMG is selected because it is developing a rich suite of standards
aimed at distributed component software interoperability. W3C is selected
because it is leading the industry effort "to lead the World Wide Web to
its full potential by developing common protocols that promote its evolution
and ensure its interoperability." A reason to focus on these two is that
together they control much of the software infrastructure for future distributed
application development and delivery via the web. Also they have good liaisons
to other relevant standards development organizations.
Object Management Group (OMG)
<http://www.omg.org>
-
OMG's focus is interoperable, modular object-oriented middleware services,
facilities, and domain standards (including C4I).
-
800 companies are members of OMG. OMG meets six times a year, three meeting
in the U.S. and three International. OMG has a small technical and administrative
staff. Most work is done by member organizations. Key staff members are
Richard Soley (chair), Andrew Watson (chair, Architecture committee), and
Dave Curtis (chair, Platform Technical Committee).
-
OMG is driven by the Object Management Architecture (OMA). Key standards
include CORBA, IIOP, and various CORBAservices. OMG operates by issuing
Requests for Information (RFIs) to understand a new area and Requests
for Proposals (RFPs) for API and interchange format specifications.
See http://www.omg.org/library/docxpl
an.htm. OMG requires commercial availability of implementations of
specifications within a year (not strictly enforced).
-
OMG is structured into three committees: the Architecture Technical Committee,
the Platform Technical Committee, and the Domain Technical Committee. These
in turn are made up of working groups called task forces (which issue RFPs)
and special interest groups - these working groups are where the main work
of OMG takes place. For a list of OMG task forces and SIGs, see http://www.omg.org/about/task.htm.
The scope covers many areas of current or potential overlap with DARPA
programs (component architectures, security, QoS, distributed systems,
C4I, HLA, GIS and more).
-
DARPA can join directly as a Government Member for $10,000/year (the price
might be negotiable). The role is similar to an Influencing Member - Government
Members can chair and vote in committees and do work (e.g., write RFIs
and RFPs) but cannot by themselves submit technology proposals or vote
in technology adoptions in the Platform or Domain Technical Committees).
See http://www.omg.org/about/meminf.htm
for information on membership.
-
DARPA could contribute to the OMG in the following ways
-
extend the architecture roadmap - e.g., Next Generation OMA
-
partner on existing technical work that overlaps DARPA programs where DARPA
is in the lead - e.g., Security and Information Assurance Reference Architecture,
Quorum/QoS, Triggers to improve OMG Event, Policy Managers, Versioning
Service, Replication Service, WebServer Architecture, DataServer Architecture,
Agents, I3, BADD, C4I Object Model, GIS SIG, Internet SIG, ALP clusters
and HLA confederates
-
develop reference implementations of new or potential OMG technologies
-
champion new task forces that will benefit DoD - e.g., Logistics, Planning
World Wide Web Consortium (W3C)
<http://www.w3.org>
-
W3C's focus is on a wide range of Web-related standards.
-
W3C has over 260 member organizations. Its host institutions are MIT, INRIA,
and Keio University. Work is done by W3C technical staff as well as industry
technology submitters. Key person: Tim Berners-Lee.
-
W3C is structured as three Domains: User
Interface <http://www.w3.org/UI/Overview.html>, Technology
& Society <http://www.w3.org/TandS/Overview.html>, and Architecture
<http://www.w3.org/Architecture/Overview.html>. Each Domain is responsible
for investigating and leading development in several Activity Areas (see
the cited URLs for a list of the Areas).
-
Specifications developed within the Consortium must be formally approved
by the Membership. Consensus is reached after a specification has proceeded
through the review stages of Working Draft, Proposed Recommendation, and
Recommendation. See http://www.w3.org/TR/Overview.html
for a list of W3C specifications. In addition, and unlike OMG, W3C develops
software prototypes that it releases to its members and later to the public.
-
DARPA can join W3C as an Affiliate member for $5,000/year (three year commitment).
There are no differences in Member benefits between Affiliate and Full
members.
DARPA should also know about and track other SDOs and standards. Some of
these can be tracked from OMG or W3C, but all have a life of their own.
Examples include:
How to track and contribute to SDOs
At present, at DARPA, there is no organized means of technology transfer
to SDOs, and there is little actual participation. It is a missed opportunity
when DARPA programs generate technologies that are aligned with industry
standards efforts but where there is no interchange. This happens for several
reasons: PMs and PIs may not be too aware of the standards efforts; they
may view standards as too incremental and the process too slow; they may
view the cost of getting involved as too high; they do not know where to
get started; they may not feel encouraged by DARPA management to engage
with industry SDOs.
To change the situation, some changes must take place at DARPA: individual
PMs and individual PIs must be given incentives to choose to participate
in key SDOs relevant to their programs and learning how must become easier;
DARPA management must see value in this participation and encourage it;
and the DARPA process must be changed to encourage such technology transition
(e.g., including participation with SDOs as a criterion in BAA source selection).
Since SDO participation has not happened to date in much of an organized
fashion, it is likely that if no action is taken, the situation will not
improve.
To change the situation will require change at several levels:
-
DARPA management needs to gain a better understanding of how to align DARPA
and industry roadmaps. This will involve understanding the standards landscape
and deciding where there is overlap and an opportunity to influence industry
directions.
-
individual PMs and PIs in overlap areas must be educated to understand
how to engage with industry to get the maximum effect.
-
some changes will be needed in the DARPA process.
We suggest that a good way to implement these changes is to task an agent
to develop this technology transfer path. The agent could be a DARPA or
other Government employee, or someone from industry. The person or persons
would have the following responsibilities:
-
report to DARPA ISO management, e.g., to Dave Signori
-
develop a map of DARPA programs and a map of corresponding industry SDOs.
This would involve talking to DARPA PMs (with encouragement by DARPA management
to be interested) about the main technology transition opportunities they
see within their programs. This might be done in conjunction with others
in DARPA who are assessing technologies for readiness for technology transfer
(e.g., Ann Jones) and by selected participation in some PI meetings.
-
participate in OMG and W3C meetings as appropriate and provide DARPA PMs
and management feedback on SDO progress and technology transition opportunities;
this may range from giving talks, to participating in drafting RFP responses,
to setting organizational directions.
The ideal agent would be a respected and experienced person with a depth
of understanding in areas relevant to the SDOs mission, mode of operation,
and status, who knows the players, and who also has an understanding of
DARPA research programs and directions. In the best case, the person would
have an agenda of creating a harmonized big picture, where DARPA and SDO
activities aligned across a several year roadmap. The measure of success
of this person would be how well the SDO and DARPA directions aligned and
a listing of discrete interactions that improved the DARPA-SDO technology
interchange.