Future AITS Architectures
Object Services and Consulting,
29 July 1997
The Homework Assignment (Tuesday, 29 July 1997)
Dave Signori has put together a small tiger team to further work
out the AITS architecture and roadmap. We had our first meeting on
17 July and the next is scheduled for 12 August (with plenty of assignments
in between!). The goal is to have a good briefing on the architecture
and roadmap in October.
In this context, Dave asked me to put together some high-level
descriptions of what future AITS architectures might be. The
purpose is to have some idea of how the current architecture might change
(possibly radically) in the longer term so that some of the right "hooks"
can be put in it now. There are (at least) two things to be addressed
I would appreciate input from you on these subjects since I'm sure you
all have some definite ideas! So please pepper me with your thoughts
-- anything from a snippet or two to a well elaborated thesis! This
is a real chance to start coalescing some ideas that will affect the eventual
evolution of the AITS architecture.
The new architectural concepts themselves, e.g., composability of fine
grained elements or the use of intelligent agents. These don't necessarily
have to be new architectures in their entirety, but can also be new approaches
for some component of the architecture -- e.g., means for greater robustness
in stressing environments.
The framework for expressing these new ideas. That is, at the
highest level, the framework might be enabling technologies, the general
architectural concept, and implications from a user's perspective, all
expressed in a time-phased way. Then the trick is to figure out how
to bin the technologies and determine the right categories for expressing
the elements of the architecture (e.g., data distribution mechanism, method
for overall system control, approach for achieving semantic consistency
of exchanged information).
I would appreciate it very much if you could start feeding me input
this week or early next week so I can begin to collect my thoughts for
the August meeting. Thanks in advance for your help.
Requirements driven architecture
The AITS architecture, like all enterprise-level systems, will be built
to meet requirements. There are three kinds:
There is real value in trying to write down the requirements and review
them periodically since they represent a way to scope the system
and also avoid rework. The scope today is the requirements you can
check off as satisfied. A growth path is to assign dates to requirements
on a roadmap. Since AITS is a large, evolving architecture, one can
immediately predict that it involves programming in the large, which always
involves discovery of "the (previously) unknown requirement" -- either
due to size or time related scaling. We cannot protect against this.
requirements that we can predict and that the initial system is built to
requirements that we can predict but that current resources cannot implement
but the design should not preclude, and
requirements that we cannot predict in advance and that
may be easy to satisfy
may be hard to satisfy and may cut across the current design in unforeseen
ways to force redesign
AITS Scope TBD
A big question for me is, where does the scope of AITS end? Right
now, it is at least a command and control, crisis management, simulation,
logistics, and infrastructure architecture. Most of these architectures
are, at the moment, loosely coupled. There is much more that a DoD
architecture could cover and the architectures could be more tightly coupled.
What are the scope bounds and how do you know when you have reached them.
What is an architecture really?
Along these lines, do you want to think of AITS as one architecture meeting
all needs or a composition of architectures? Hint: the latter.
If so, it makes sense to consider a requirement
that the multiple architectures be capable of interoperating. Given
these intuitions, how do we characterize architectures, treat them as units,
and characterize potential inter-architecture interfaces? What type of
information and mediation is needed to enable architectures based on different
architectural assumptions (of what type?) to interoperate. Along
these lines, how do we characterize stovepipe architectures and how do
we know AITS as implemented is not one? Is there evidence of module
replacement, mix and match, best-of-breed modules? Is there a notion
of a lightweight and heavyweight variant of the AITS?
AITS and the ilities
The ilities are generally cross-cutting meta-architecture constraints that
are often hard to add to a conventional system when designed as a stovepipe
or missing an ility. DARPA ITO has or is planning whole programs
devoted to some key ilities:
There are more ilities (e.g., understandability, affordability, agility,
performance) but focusing on just these, one could use them as a metric
to measure AITS against now, with the presumption that AITS must grow to
meet these predicable architectural framework requirements. For instance,
One can say much more about the ilities. (Including trying to list
ilities and characterize what exactly they are. To what extent to
ilities have to built in to all modules and when can they provide a framework
that is imposed from outside without requiring cooperation from the managed
components, which might be ility-unaware?
how can one replicate JTF architectural instances so many command and control
instances can co-exist. How do they compose hierarchically to meet
the needs of hierarchical control? How do functions cooperate across
cell boundaries so an intelligence function can feed many command and control
cells, so a tracked object can move smoothly between one tracking dbms
and another? etc.
how can JTF/AITS evolve to add anchor desks, to provide more battlefield
info, to filter better, to take advantage of the latest trends in infrastructure
technology? how can the AITS architecture evolve consistently to
reflect (changing) DoD Joint doctrine (business rules?) which is currently
distributed in many documents and software programs.
what are the threat models and how can the AITS survive attacks
AITS Business Model missing
Right now, AITS has a technical and application architecture and a rendezvous
path for taking ITO technologies and testing them in ISO programs, then
migrating these in DISA/LES/COE. But there is less focus on how DARPA
work can affect industry standards or industry technology trends.
NIMA and HLA have aggressive models of getting industry to partner in the
adoption of their critical path architectures. How will DARPA do
this with AITS (which includes HLA and might also include NIMA's architecture
if DARPA pursues the Dynamic Database program)?
Focusing together on infrastructure and evolution, we can predict several
industry trends the AITS architecture must take into account. These
are environmental in nature but can affect the core nature of the AITS
architecture. The following sample of Nostradamus-like predictions
will surely be true to some extent so the issues are, how to accelerate
these directions since there are technical and social barriers for each,
and how will these trends affect AITS.
Componentware will increasingly be an economic force
in software development and programming will get easier
the OMG Object Management Architecture Next Generation
will include (my list): ilities, dynamic binding, mobile code, composition
containment model, exoskeleton, metadata repository, packaging technology,
policy managers, distributed system management, federation, web + object
integration, convergence with Java
Agents will replace objects (OMG and also OBJS will have to change our
names!). The agents that prevail will need to be simpler than the
intelligent agents of today so anyone can program
them; they will be mobile and massively distributed.
caveat: one can well ask if this is a prediction
about technology or terminology, particularly given the varied definitions
of what an "agent" is. A related question is what the relationship
is between "agents" and "components" (see below) -- are these competing
or complementary technologies?
how do we converge objects, agents, ontologies, KBMS
systems, rules systems, constraints?
how do we get pervasive adoption of a reasonable
agent model (by analogy, having 20++ variations on object models was not
all that helpful for interoperability).
how can we insure mobility, i.e., the ability
to move, not necessarily whether or not there is actual movement. Movement
itself might need to be governed by load balancing, demand, free market
economy schemes where agents have funds and pay for what they want, and/or
A corollary is that system management will be more
important than it is now, and more technology will need to be developed
to support it. This doesn't necessarily mean the centralized kind of management
practiced now, but it does mean more work on what metadata is required
to do the right kinds of management, what protocols are needed, and what
hooks need to be built into both lower level system components and higher
level application components to enable this to happen. System management
must itself be controllable from the outside. The mechanism by which
services bid for resources and migrate in response to attacks must itself
be situation dependent. Services priorities change as the real world
situation changes. This is a value judgement that must be made from
the outside, since all applications think they are the most important.
The web digital library will become richer,
better organized, easier for us all to augment. One corollary:
dynamic dbms (GIS) will provide a pervasively available spatial index for
locating places in a 3D world. Another corollary: new annotation
technologies will make situation modeling easier for communities of experts
and better support pedigrees and web views
Electronic commerce will make sharing code and software much easier, which
will break down some organizational barriers, for instance, virtual enterprises
and supply chains will change the information boundaries of organizations,
affecting ALP at least. A corollary: AITS will be harder to
distinguish from the rest of the information space which it will depend
on more than is shown in the current architecture.
Some of the technology puzzles that seem relevant to AITS that I hope to
understand more about in the next year or two are:
how can we converge web and distributed object technologies (including
agent technologies) so that the right infrastructure is in place for load
balancing, application partitioning, and other forms of distributed mobile
how can we build a new system from a bin of parts when we see all the functionality
we need in the bin but a little is in part A and a little in part B and
so on. How can we routinely write software that can be deconstructed
how do we make components that have an extensible exoskeleton so we can
expose new interfaces over the life of the component even if we are not
the component designer. That means exposing new metadata via new
how can we put in place system management interfaces to get end-to-end
managed object systems? Agent-based architectures look like part
of the solution.
how do we expose QoS information from parts and compose it for end-to-end
and bottom-to-top QoS solutions? and what do we do in resource poor
environments where not all customers can be served? and what
happens when some components are opaque and do not expose QoS (or system
how do we figure out what QoS (and other metadata)
we need to have in the first place (we need to know that before we can
expose it). What metadata is required, particularly at the higher levels,
to describe QoS and other important characteristics is far from clear right
now (e.g., how do I described the "qualities" of various high-level services).
Technology like the W3C's PICS, which allows people to develop their own
rating schemes in a self-describing way (so they can be understood by Web
clients without being built into them), extended to deal with arbitrary
types of ratings and other metadata (the focus of W3C's Resource Description
Framework (RDF) activity), seems like a key component for dealing with
some of these issues.
how can we build algorithms that are incremental or partial or ... that
provide useful answers in open world assumption environments where not
all is known.
how can we build broad coverage ontologies that are not thin and narrow
knowledge representations that take PhDs to develop small coverage systems
but rather broad area coverage ontologies (poor man ontologies) that might
be useful in broadening and narrowing web searches so we tend to augment
queries to get much more appropriate related answer sets. Related,
how can we cover queries to structured, semistructured,
and unstructured information sources via an augmentable query service.
what additional meta data must be stored about services
so services can be controlled from the outside by various policy managers?
How can that data be reasonably collected?
how can we scale by using a federation pattern to
build global systems from components? How can we end-to-end federate
systems that have made heterogeneous policy decisions, e.g., compose systems
that support linear versioning and others supporting branching versioning?
compose systems with discretionary and mandatory access control?
support optimistic and pessimistic transactions? etc.
AITS Future Architecture
Now, to be specific, and not knowing enough about the AITS architecture
yet, here is my current view of some components that could change in the
next few years:
The AITS infrastructure services layer can depend increasingly on
OMG services, Java libraries, and convergence of these.
Some experimenting makes sense with various kinds of mobile intelligent
agents especially those compatible with Java. It might make sense
for the C2 Schema that is currently based on OO technology to think
about augmenting object definitions with KBMS augmentations like rules,
constraints, etc. or agent frameworks.
The web server could become more of a web knowledge base and the
web data structures (HTML and MIME) can handle metadata much better to
augment the current syntactic web with much more
semantics to enable better searching and other operations. This could
happen not only within AITS but also within W3C, via the RDF activity mentioned
above, as well as other activities like XML (Extensible Markup Language).
This is a simple dialect of SGML that is richer and more powerful than
HTML. Microsoft seems to be paying a lot of attention to it, as is Netscape;
a number of recent proposed technologies from both these companies are
based on the use of XML. Also, it should be possible for third parties
to augment web-based knowledge either via group annotations or public/community
annotations since often experts or agents other than the authors have useful
augmentations. PICS/RDF-like technology would appear to be crucial
in supporting this. Along these lines, more work is needed on defining
web-based views so some can see a higher level view and others a more detailed
view. And work is needed on webbase viewers to display the
level of information needed and still permit expansion or drill down to
At the same time, if this infrastructure can become a useful situation
server data model then it should be the case that the rest of the web
can benefit from a richer information base than just HTML and improvements
by a much broader community can accelerate the situation
server's representational capabilities as well as the structure of information
that an AITS might find useful both from within the intelligence community
and also from the normal industrial and educational communities.
XML seems relevant here as well
The query server architecture, whether SAIC's
or MCC Infosleuth's or I*3's, will need convergence and transition to OMG,
where we are starting up similar work.
Right now, HLA is enticing industry to adopt
its framework for federating simulations. This could lead
to a revolution in gameplaying on the web which in turn could lead to rapid
improvements in HLA and simulation technology.
Similarly, if NIMA's commercialization strategy is successful, then industry
will be a better partner in making GIS backplane battlefield information
more broadly available. If OGIS and Dynamic DBMS does its job right,
this will not lead to stovepipe (though componentized, services based)
GIS systems but it will also be possible to represent thematic information
that is not geographically indexed. The current Map Server will
be a simple special case of the eventual capability.
The JTF architecture will need a view of itself as federated, like
HLA simulation and ALP logistics architectures.
Planning and Scheduling technologies are perhaps ready to
become OMG services.
The above is a "getting started" list of AITS architectural futures that
might start up more discussion or aggregate with other lists. The
long list of possible things to do provides some views of the future.
Prioritization helps to pare this to the current resources. But seeing
the possible future helps defend against being blind-sided.