Questions for DARPA/ISO Architecture Review Team
Response from Craig Thompson
Object Services and Consulting,
November 17, 1997
As a member of the DARPA/ISO AITS Architecture Review Team, I attended
Integration and Transition Off-Site Conference held at the Arlington
Hilton on 21-22 October 1997. This document lists
I am sending my comments on Rich Ivanetich's High
Level Framework for AITS Architecture and Teknowledge's AITS
Reference Architecture separately.
the initial recommendations of the review team provided at the meeting
my responses to Signori's "Questions for DARPA/ISO Architecture Review
Team," which includes my observations and recommendations based on
These were the initial recommendations by the Architecture Review Team
provided at the Off-Site Conference.
Initial Recommendations of DARPA/ISO Architecture Review
Rapid commercial development of middleware continues (info bus, ORB vendors,
network management tools) so avoid over-commitments.
AITS Reference Architecture needs to begin to encourage design of capabilities
for rapid-on-the-fly evolution (e.g., to support unforeseen additional
functional requirements that arise during force deployment - i.e new kinds
of distributed data)
need focused deliberate participation in OMG, W3C as well as other open
while we need a richer view of architecture to deal with heterogeneity,
at the same time we need simpler ways to explain it. Decide on key themes.
Reuse portrays certain issues, tie together heterogeneity, evolution view,
… manage complexity.
At the conference and then again by email sent November 8 1997, Ed Brady
(Stategic Perspectives) and Rich Ivanetich (IDA) asked the AITS review
team to complete the following questionnaire. Here are my responses, which
incorporate my observations and recommandations from the meeting.
Questions for DARPA/ISO Architecture Review Group - my
What should ISO's FY98 priorities be? (near term and mid-term architecture)
Shift from JTF-centered architecture to AITS-centered architecture
AITS must be viewed both inside and outside DARPA as the DARPA architecture
whose job it is to show how to integrate command and control, intelligence
gathering, logistics, crisis management, etc. for DoD in such a way that
it does not result in a stovepipe of stovepipes but rather provides the
architecture for an evolvable, configurable, and affordable system
of components. Right now, it still suffers from the historical view
that it is JTF with other architectures concatenated on the side.
Some of the programs like ALP openly say their architecture is different
from AITS (meaning JTF, I think). I recommend a careful pass through
the foils to remove vestiges of JTF dominance and lobbying with the various
Managing the Complexity of AITS Architecture
To be useful, AITS must be understandable. It is complex and growing
more so as it tries to cover more ground. But the complexity can
be managed. Foilology does this to a reasonable extent but one is
always wondering where the foils end and the architecture takes over.
Views of the AITS Architecture. A top node of the AITS
presentation should be that the architecture must be understood from a
consistent, interlocked collection of viewpoints or perspectives, where,
as Rick said, each reveals and each misleads. I recommend more explicitly
adopting the notion of views of the architecture -- this may not require
many changes to the foils. The views must not just be foils.
There must eventually represent reified systems and mappings that connect
the views. Taken together they must become the architecture.
You might eventually consider implementing mappings from some foils to
architectural components via point-and-click on the AITS web site, to make
the architecture more understandable.
Here are some architecture views yof interest (overly simplistic list,
you have many of these already):
Definitions of Basic Terms. Many basic terms are not defined.
These include architecture, interoperability, framework, component,
service or server, DSSA, application architecture, openness, view, federation.
Each of these has several senses and a deep analysis could run to pages
or more. But they are pivotal terms.
ABIS view - mostly notional, serves to connect 2010 objective to AITS
Joint Services' application view(s) - what services are they getting from
AITS from end-user perspective
application program views
as an integrated system providing command and control, crisis management,
one per program, e.g., JTF view, Genoa view, ALP view, etc.
various abstract technical architecture views
OMG like services view of application/domain services and common system
services in several variations, showing various AITS applications like
JTF, Genoa, BADD resting on common services
data representations view
federation view - need core work on this - poorly understood.
OBJS is working in this area.
ility view - need core work on this - poorly understood. OBJS is
working in this area.
compositional view - AITS and OMG OMA need work in this area. It explains
how a part is actually constructed or constructable from components it
evolution view - populated view vs. planned - critical investment and capability
system management view
survivability view - poorly understood. OBJS is working in this area.
communications architecture view
cost and maintenance view
implementation guidance as constraints
which specific implementations connect to which
There are some organizational frameworks that are not themselves the AITS
architecture but that provide a list of considerations about AITS that
can be iteratively institutionalized and evolved to prevent surprise and
foster widespread adoption. These include questions like (very incomplete
list of standing questions, a FAQ could evolve with answers):
Who are the customers, are they involved in the process, what are their
What is industry doing now and their likely vector? How can we leverge
How can we make the system more affordable, easier for many folks to extend?
What are the priorities in the near, mid, long term?
How do we do it today and what are the advantages of the proposed change?
What are the technical discontinuities coming in the next 3-5 years?
Issues and Resolutions Log (e.g., how to specify component connectivity)
Managing Availablity of AITS Documents and Implementations
I have not checked lately but when I last checked I did not find the AITS
web site to be a good central source for documentation on AITS or on various
specifications of its parts. This is a missed opportunity.
Major consideration should be given to how to make AITS information much
more available. This includes all major architecture documents, all
major specifications, accessibility information on getting implementations
like Data Server, Web Server, ... If these are not available to ISO
and ITO PMs and PIs and there is not a routine way to publish availability
of new components into a DARPA marketplace of componentry, then AITS is
likely not to succeed as well as it otherwise could. It should be very
easy to do this, perhaps PIs just advertise their wares by program, nothing
too sophisticated, no vetting or heavyweight promises of code maturity.
Tech Transfer Process needs more work
Right now, PIs in ISO programs are told that if they are to be successful,
they will transfer technology via the following route: TIE, IFD,
ATD, ACTD, GCCS LES, DISA (or variations on that). They are also
told DARPA does not invest in areas industry will, that their customer
is DoD, and that DoD is moving as fast as possible to COTS technology to
reduce cost and take advantage of training. Finally, there is an
emphasis on open systems standards in GCCS and some general encouragement,
even mandate, to use certain technologies like OMG, Java, ... over some
others. But I see the following problems in this picture:
A concerted effort should be made to identify additional barriers to the
DARPA technology transfer process and a plan plus some controlled experiments
are needed to break through these barriers. It might be critical
to get industry to buy into your detailed AITS architecture to broaden
the applicability of the architecture, for instance. Right now industry
trends "happen to" DARPA.
PIs in ITO (and maybe ISO) need some more rapid way to become educated
on DoD problems (scenarios), infrastructure (GCCS), process (DII COE levels
of compliance), military doctrine, ... That is, it will help if it
becomes easier for them to understand the DoD customer problem. Today,
this is done by having some ALP etc people come to ICV etc workshops and
give talks but there are not many other ways to understand DoD for many
The food chain from TIE to DISA is long but the pace of technology change
is very fast.
DARPA projects do not often result in technologies that other DARPA projects
can use except in one-on-one, human intensive cases. There is no
marketplace for advertising your component technologies or pre-thought-out
means to micro-license them -- see above, also more below on reuse.
Those technologies that run the gauntlet like Visage may have Achilles
heals, like only 10 programmers in the world know how to use them, there
is no installed base, there is no commercialization plan, so what is sometimes
being delivered to DoD is beyond prototypes but not nearly COTS and DoD
is left to maintain and extend complex DARPA software that has no route
Universities and large DoD integrators tend to accumulate lots of DARPA
technology within their proprietary walls (and on their shelves) leading
to winning future DARPA contracts but there is a barrier to making it easily
available outside those walls.
DARPA talks a lot about OMG and other open standards, is being influenced
by them, but is doing relatively little to work with them to leverage DoD
technology into the marketplace. DARPA could be the research arm
of these open standards efforts, or at least active in influencing these
groups to focus on problems DARPA needs industry to solve.
One major area where DARPA should invest in establishing a high leverage
beachhead is in industry open systems forums, OMG, W3C, WfMC, IETF, joint
workshops, etc. DARPA must take a leadership role, providing a research
arm for these industry standards-setting groups, accelerating consensus
leading toward standards that AITS will need.
Some general tech transfer things to do are:
Some specific interactions that could happen between DARPA and OMG are
require low-cost licensable technology as outputs of ITO and ISO programs
download as much technology as possible via the web
more focused DARPA-industry workshops
Having said all this about OMG, I must also say that intersection with
W3C might end up being at least as important. We might be able to
help here too with some initial tech transfer ideas. Our work on
Web Object Model is a starting
point. The AITS WebServer is kind of a cross between ORB representations
and web representations, if you stand back far and squint. It must
align with evolving standards like XML. I commented on some WebServer
direction changes earlier.
DARPA AITS management team should meet with OMG's Richard Soley to plan
a strategy. If you don't take concrete steps to plan a rendezvous
with OMG, it will not happen. Rick Hayes-Roth or Dave Signori might
do an OMG plenary talk. DARPA could sponsor an OMG meeting.
focused DARPA-OMG workshops
I invited DARPA PMs to come to our OMG-DARPA workshop
DARPA could sponsor workshops with OMG on agents,
PMs and PIs to participate in OMG meetings
I'll invite Sami to OMG Security SIG to brief his DARPA Security Reference
I'll invite David Wells (OBJS) to OMG Security SIG to brief his DARPA Survivability
There is almost no connection between DARPA QoS and OMG/ISO/ODP QoS in
industry - I could talk to Gary Koob and send him OMG documents on QoS.
Then invite him to OMG.
Brian Sharley could start up an OMG Logistics SIG or Task Force.
I could help him do this.
We could push the Query Server design through OMG as a Data Access Facility.
Whatever AITS learns about federation, scaling and other ilities will be
useful to OMG. I am trying to get this onto their OMA roadmap.
DARPA has many extra-CORBA services that would be useful to OMG -- webserver,
policy, versioning, trigger, publish and subscribe, replication, … many
more. If they are moved to OMG, then DARPA will not be alone with
idiosyncratic approaches when OMG gets around to similar but different
services. DARPA helps to "accelerate consensus leading to standards."
OMG has a C4I SIG but no DARPA JTF representation
OMG is working with WfMC on process, task, and workflow.
No OMG work on a planning service -- an opportunity to introduce this into
DARPA might not want to adopt every little thing about OMG's OMA or process,
but the general architecture and model approach and many of the service
are well aligned to AITS.
Who are your customers. Insure that DoD architects for
NIMA, DMSO, as well as some industry enterprise architects are involved
in AITS DDB, etc. Insure Deputy Under Secretary of Defense/Logistics
(USD/L) coordinates with ALP via Logistics Community Manager (contact Janet
Putman, who says the connection is tenuous). [This reminds me of
a past life in a big corporation where there was no way for the researchers
to really provide value to the product groups, at least in software --
a lesson was to get early and continuous buy in.]
Architecture Hot Spots
Software Architecture in General. The area of software architecture
is still pretty new and evolving -- not that much is known. DARPA
might consider funding efforts in ISO on software architecture.
AITS and Federation. It would be worth convening an effort
to see if there can be a consistent one architecture story on federation
(clusters) across JTF, ALP, HLA, DDB and whether you could transfer this
federation story into OMG. I'd volunteer to lead such an effort.
I view this as critical to scaling systems because big and centralized
does not always scale well. But do not expect over night answers.
AITS and Survivability. We at OBJS are starting to understand
how to insert Survivability
into Object Service Architectures. This effort should be accelerated
over the next year. It is related to QoS, Security, and other ilities,
which we talk about in our OMG
AITS and HLA. An effort to see how to hook these two architectures
together seems worthwhile sooner rather than later. The interface
to DMSO seems organizationally and technically weak though there is great
opportunity to make it aligned. The HLA interface is on the list for the
AITS architecture working group. One promising area is to focus on
overlaps in schemas. By the way, the DMSO HLA has already established
a beachhead in OMG, having formed the Simulation SIG; DARPA should support
Resolve Object-Agent wars before they start. AITS RA objects
must be able to accept delegated work, must know their resources, etc.
DARPA should decide on the relationships between object and agents early
on, I hope, taking the view that objects are degenerate agents that can
be made more mobile and intelligent. The idea is to ward off the
school of thought that objects and agents are very different, so different
that we need an AITS based on objects and another based on agents, or a
similar bifurcation of the AITS community.
Implementation guidelines and waivers
consider Lisp for planning
allow Java generally, not just for applet GUIs, begin to prefer Java over
add UML to representations list. Some OA&D tools can generate
IDL or Java or ... making transitions easier for object modeling.
What are commercial trends which will have the greatest impact on mid-term
architecture? What is their basis (if any) in OMA/Corba?
I wrote a paper on Future
AITS Architecture in July and another on OMG
OMA Next Generation in September. These try to lay out commercial
as well as research trends that will affect AITS and OMA/CORBA futures.
Some candidates for big impacts are:
understanding architecture, don't assume industry will provide all OMG,
web technology infrastructure you need
architectural properties (ilities) - especially security, reliability,
scalability (composability and federation),
OMG does not yet provide mix-and-match, plug-and-play
the January Workshop
on Compositional Software Architectures will identify the state of
practice and barriers to component software
after all this time we do not have good definitions of interoperable, framework,
web object models (like XML,
DOM, WIDL, ...) - situation modeling using the AITS
web server may need rethinking [I need to learn more about the web
HTTP-ORB integrtion architectures
federated web object DBMS
a big variable is Java/CORBA convergence or divergence; divergence will
converge Common Object Base with Simulation object models
doctrine as business rules
The approach to developing the architecture thus far has primarily been
to extend the layered view developed in the JTF ATD. Are there important
changes that should be made to the current architectural approach?
AITS is leading down the right path toward an integration architecture.
But, as mentioned above, it is time to defuse a JTF-centric architectural
view with a JTF-historic view and make AITS architecture the center and
JTF yet-another-program. One pass over the foils and Reference Architecture
is needed to re-orient. This is needed to increase buy in of AITS
and reduce jealousy regarding JTF. Also, JTF does not really handle
federation at all and that must be a hallmark of AITS application architectures
including future command and control architectures. But the basic
approach of AITS-JTF of modular services seems right to me.
What role can the Architecture Review Team play in terms of the long-term
Current Role as Reviewers
So far, I have wondered if the review team is adding sufficient value.
It has seemed our current role is to act as fairly knowledgeable
reviewers to provide Dave Signori a variety of independent points of view
on the AITS architecture (including providing longer term technical and
programmatic guidance) based mainly on reviews of documents presented at
more or less quarterly meetings. To date, several review team members
do not seem to be participating. In some cases, you might not need
continuous membership but mainly targeted expertise, e.g., for briefings
on particular topics.
Recommendation: switch to once-by-invitation or semiannual/annual,
renewable terms for reviewers
Recommendation: give the review team some feedback and visibility
into how their recommendations are being used. What would be more
useful than what we are providing?
Recommendation: get some reviewers from outside the DARPA
community. Candidates are:
DoD customers - especially services architects for major initiatives (e.g.,
HLA, NIMA, DUSD/L, …)
industry gurus - from OMG, W3C, OGC, academics. This might better
connect AITS to industry and it lets DARPA provide these organizations
a much needed research arm.
Future Role of Review Team
It has been suggested that a second role of the review team might be to
rough out a long-term architectural framework for the AITS. I'd certainly
welcome this role. And I believe AITS needs to have a long-term as
well as near-term target. In my experience, architectures break when
they fail to be able to evolve to meet unanticipated requirements.
So having an advance team aimed at early identification of significant
relevant trends, issues identification and resolution, and continuous evolution
is well worth the investment. Such a review team must be at least
a little more closely coupled and proactively involved in setting AITS
directions than the current review team has been. Ideally, it should
be made up of current area architects as well as reviewers. Also,
it must help the current process become more proactively involved in industry
directions than current AITS has been.
Recommendation: identify a small core team; they must be full
participants with today's ITO program architects. Their job is to
identify and resolve architectural direction changes and issues with the
help of the programs. This is probably a more than part time position;
it might be full-time. The team works with Signori to pull in the
expertise they need to get their tasks accomplished.
An example study might be like the one Rich is working on (High Level Framework
for AITS Architecture) regarding inserting architectural ilities into AITS
(based on inputs from the current review team, MCC, and his own insights)
-- see separate
comments. Other examples are:
an issue resolution log for AITS;
web object models and directions and how they will affect AITS;
study in how to connect DARPA programs to DoD data sources (or how to converge
DataServer, InfoSleuth, BADD, I*3) to result in an AITS Data Access Architecture;
study in how to componentize and microlicense DARPA ISO technologies so
they will fit into ITO applications in a more streamlined way;
study in the ITO process and how to connect it into the industry-products
pipeline so US research results in US products and not one-of-a-kind fielded
How important is the "reuse concept" in an organization like DARPA (internally,
externally)? Should it be included in parallel development efforts?
The answer depends on DARPA's changing role and its research investment
portfolio strategy. DARPA essentially has a fixed pie of money/resources
to invest to get maximum technology gain for DoD. It seems to be
dividing its investment portfolio into two parts: ITO technology
and ISO applications that both require leaps forward to stay leading edge.
But recently, the joint services are coming to depend on DARPA technology
to create at least the skeleton of next generation fielded systems; hence
the major emphasis on the TIE-IFD-ACT-ACTD-AJPO-GCCS LES technology transfer
process from ITO to ISO to JPO. In the ITO technology area in programs
like IC&V/IM, this seems to call for opportunistic funding of a sparse
collection of program-theme-related technologies; there is less emphais
on any program-imposed architecture. But ISO application programs
are driven to provide architecture frameworks that can be created then
populated with a common suite of technologies and fleshed out over their
lifetimes in an open modular manner. The process puzzle is to see
how to accomplish the twin goals of (a) funding revolutionary, continuously
leading edge opportunistic but sparsely-related technology and (b) technology
that must fit into an evolving architecture framework in such a way as
to flesh out critical paths to solve pressing DoD problems. A tall
Now, to try to answer the question about reuse more directly.
Parallel development efforts make sense especially in areas where
there are more than one interesting different approaches or where there
is a rich design space of alternatives and it is especially important to
get a variety of results or to get results quickly.
If the only goal was the first one, DARPA could afford to ignore reuse.
But it would lose a lot of the value of its investment by doing so.
In fact, I think right now it does lose a lot of its investment in ISO
programs. There is not currently a good way to encourage or require
PIs to provide their technology in modular chunks and there is no encouragement
in setting up a marketplace that permits microlicensing or sharing such
results. So the main kind of tech transfer is very human intensive
and a few more mature technologies are transferred one at a time.
This encourages prototypes over engineered solutions, low amounts of code
sharing, and no direct link to ISO needs except through a kind of shopping
when ITO architects visit ISO programs often in person looking for technology
to reuse. Missed opportunities seem to be a marketplace of code that
others than the developers have access to and almost no real interactions
with industry or insight into the ISO program architecture needs.
There is no way to accomplish the second goal without reuse. Rick
Hayes-Roth was elegant about reuse at the DARPA Off-site Conference and
largely I agree with him. A major consideration in AITS is architecture
driven reuse across ISO programs to decrease investments. If this
is so, then it should be more visible what technology is available (e.g.,
what components of JTF are easily available for reuse) and the opportunity
for reuse should be extended to not only other ISO programs but also ITO
Some barriers of reuse are:
A key element about reuse is availability. The architecture-driven component
approach should lead to more capable, cheaper platforms but only if componentware
is unlocked from creators' control and shared. Developers may view this
as not in their interest but the economy is still in their favor even if
they make their components available for free (because they have invested
in the expertise).
prototypes versus engineered solutions
researchers aversion to productization
unavailability of code (ISO and ITO) in modular pieces
no marketplace of code or expertise
no model for microlicensing
institutional IP barriers (e.g., integration contractors, even universities)
do not make code reuse easy. Each licensing experience is unique,
involves lawyers, try-before-buy is not the rule.
need for constructive descriptions of AITS architecture so people can see
how to populate it
routes to transition technology to industry then DoD versus the primary
emphasis being to DoD. It is a false economy to transition technology
prototypes to JPO for maintenance since they will die an expensive death
or become one-of-a-kind maintenance hogs without amortizing continuous
At the same time, reuse is not the ultimate mindless goal in all cases:
DARPA must continue to fund some percentage of new starts and retire some
percent. A certain percent must be in areas that have promise even
if they do not fit into today's view of the architectural direction.
In addition, it is probably good for DARPA to encourage loose coupled architectures
and not require every component to be built and transitioned as part of
an existing high level framework.
How should CORBA and DCOM be viewed (competing concepts, different ways
of doing things for different purposes)? Should DARPA be investing in only
one, both (security features)?
CORBA and DCOM represent competing concepts, different ways of doing things
for the same general purpose. But they are at different levels
of maturity, align differently with Java and the web, have different openness
properties, and have attracted different communities. CORBA/Java
represents open systems and multiple vendors; DCOM is less mature but Microsoft
has focus, market strength, deep expertise and has a good chance of winning
the entire middleware and enterprise computing war over the next 10 years.
So investments in both camps will be needed.1 One good
reason to invest in the CORBA/open systems camp is to set the blueprint
for infrastructure technology2 which is ultimately what AITS
must do for DoD -- but that will require a much more active presence in
open forums than DARPA is currently encouraging in its PM and PI community.
A reason to invest in Microsoft is that DARPA currently has too little
investment in Microsoft technology and culture so it should encourage a
balanced portfolio from its PI community. Generally, DARPA might
consider some industry wide initiatives that encourage vendors and PIs
to work together and increase communication bandwidth -- our upcoming OMG-DARPA
workshop is one example.
1 Bridge technology exists for Java Beans, IDL COM-CORBA
Interoperability but such mappings create indirections; this area is liable
to be very fast changing and unstable so invest in this only as needed.
2 Microsoft technology is technically open but effectively
proprietary because Microsift owns the frameworks and how they evolve,
and can own the plug-in components too, if its good business to do so.
OMG is an open systems environment where DARPA can influence directions
much more readily, creating a blueprint for industry -- even if Microsoft